kernel-hardening - Re: [PATCH v2 1/2] Documentation/admin-guide: introduce perf-security.rst file

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20181126132833.5302688b@lwn.net>
Date: Mon, 26 Nov 2018 13:28:33 -0700
From: Jonathan Corbet <corbet@....net>
To: Alexey Budankov <alexey.budankov@...ux.intel.com>
Cc: Thomas Gleixner <tglx@...utronix.de>, Kees Cook <keescook@...omium.org>,
 Jann Horn <jannh@...gle.com>, Ingo Molnar <mingo@...hat.com>, Peter
 Zijlstra <peterz@...radead.org>, Arnaldo Carvalho de Melo
 <acme@...nel.org>, Andi Kleen <ak@...ux.intel.com>, Alexander Shishkin
 <alexander.shishkin@...ux.intel.com>, Jiri Olsa <jolsa@...hat.com>,
 Namhyung Kim <namhyung@...nel.org>, Mark Rutland <mark.rutland@....com>,
 Tvrtko Ursulin <tursulin@...ulin.net>, linux-kernel
 <linux-kernel@...r.kernel.org>, "kernel-hardening@...ts.openwall.com"
 <kernel-hardening@...ts.openwall.com>, "linux-doc@...r.kernel.org"
 <linux-doc@...r.kernel.org>
Subject: Re: [PATCH v2 1/2] Documentation/admin-guide: introduce
 perf-security.rst file

On Mon, 26 Nov 2018 11:57:21 +0300
Alexey Budankov <alexey.budankov@...ux.intel.com> wrote:

> >> +For the purpose of performing security checks Linux implementation splits
> >> +processes into two categories [6]_ : a) privileged processes (whose effective
> >> +user ID is 0, referred to as superuser or root), and b) unprivileged processes
> >> +(whose effective UID is nonzero).  
> > 
> > Is that really what's going on here?  If I understand things correctly,
> > it's looking for CAP_SYS_PTRACE rather than a specific UID; am I missing
> > something here?  
> 
> You are right regarding CAP_SYS_PTRACE but this capability is not the only 
> one which is used by perf_events for security checks, so the capabilities 
> clarification is kept aside of these patches, because patches initial intention 
> is to clarify security specifics of sysctl_perf_even_paranoid settings.
> 
> I agree that the document can be extended with details clarifying capabilities 
> used by perf_events for security checks.

I don't really like the idea of adding a document that we know doesn't
really describe how the security decision is made.  Even a one-line
parenthetical saying that things are more complicated and giving a pointer
to a place to look for details would help, IMO.

Either way, I can merge this, but I'd like to have an ack from the perf
folks first.

Thanks,

jon

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.