Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open

On Thu, Aug 04, 2016 at 12:32:32PM -0400, Daniel Micay wrote: > On Thu, 2016-08-04 at 17:10 +0100, Mark Rutland wrote: > I wasn't talking specifically about perf. Then this is irrelevant to a discussion about limiting access to the perf interface. Hardening drivers in general is a very

Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open

On Thu, 2016-08-04 at 17:10 +0100, Mark Rutland wrote: > On Thu, Aug 04, 2016 at 11:44:28AM -0400, Daniel Micay wrote: > > > > Qualcomm's drivers might be lower quality than core kernel code, but > > they're way above the baseline set by mainline kernel drivers... > > I don't think that's true

Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open

On Thu, Aug 04, 2016 at 11:44:28AM -0400, Daniel Micay wrote: > Qualcomm's drivers might be lower quality than core kernel code, but > they're way above the baseline set by mainline kernel drivers... I don't think that's true for the arm/arm64 perf code. I think we've done a reasonable job of

Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open

On Thu, Aug 04, 2016 at 10:13:29AM -0500, Eric W. Biederman wrote: > The bits useful to the perf situation are: > - user namespaces nest. > - anyone can create a user namespace. > - a sysctl can be bound to the userns that takes local privilege to > change so you can't override it arbitrarily.

Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open

Peter Zijlstra writes: > On Wed, Aug 03, 2016 at 09:50:37PM -0500, Eric W. Biederman wrote: > >> What this means in practice is user namespaces can be enabled by default >> on a system, and yet you can easily disable them in a sandbox that was >> built with a user

Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open

On Thu, Aug 04, 2016 at 09:45:23AM -0400, Daniel Micay wrote: > Qualcomm's perf driver is out-of-tree along with most of their other > drivers. So you're asking us to maim upstream perf for some out of tree junk? Srously? *plonk* -- To unsubscribe from this list: send the line "unsubscribe

Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open

On Thu, 2016-08-04 at 11:28 +0100, Mark Rutland wrote: > On Wed, Aug 03, 2016 at 03:36:16PM -0400, Daniel Micay wrote: > > > > There's a lot of architecture and vendor specific perf events code > > and > > lots of bleeding edge features. On Android, a lot of the perf events > > vulnerabilities

Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open

On Wed, Aug 03, 2016 at 03:36:16PM -0400, Daniel Micay wrote: > There's a lot of architecture and vendor specific perf events code and > lots of bleeding edge features. On Android, a lot of the perf events > vulnerabilities have been specific to the Qualcomm SoC platform. Other > platforms are

Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open

Peter Zijlstra writes: > On Wed, Aug 03, 2016 at 11:53:41AM -0700, Kees Cook wrote: >> > Kees Cook writes: >> > >> >> On Tue, Aug 2, 2016 at 1:30 PM, Peter Zijlstra >> >> wrote: >> >> Let me take this another way instead. What

Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open

On Wed, Aug 03, 2016 at 11:53:41AM -0700, Kees Cook wrote: > > Kees Cook writes: > > > >> On Tue, Aug 2, 2016 at 1:30 PM, Peter Zijlstra > >> wrote: > >> Let me take this another way instead. What would be a better way to > >> provide a mechanism for

Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open

Sigh. Kees we have already had this conversation about user namespaces and apparently you missed the point. As I have said before the problem with a system wide off switch is what happens when you have a single application that needs to use the feature. Without care your system wide protection

Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open

> One of the strengths of linux is applications of features the authors > of > the software had not imagined.  Your proposals seem to be trying to > put > the world a tiny little box where if someone had not imagined and > preapproved a use of a feature it should not happen.   Let's please > avoid

Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open

On Wed, Aug 3, 2016 at 10:25 AM, Eric W. Biederman wrote: > > Sigh. > > Kees we have already had this conversation about user namespaces and > apparently you missed the point. Well, I didn't miss the point: that's why I CCed you. :) This is nearly the same discussion

RE: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open

de Melo <a...@kernel.org>; Alexander Shishkin > <alexander.shish...@linux.intel.com>; linux-doc@vger.kernel.org; kernel- > harden...@lists.openwall.com; LKML <linux-ker...@vger.kernel.org>; > Jonathan Corbet <cor...@lwn.net>; Eric W. Biederman > <ebied...@xmi

Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open

On Tue, Aug 02, 2016 at 01:51:47PM -0700, Kees Cook wrote: > Let me take this another way instead. What would be a better way to > provide a mechanism for system owners to disable perf without an LSM? > (Since far fewer folks run with an enforcing "big" LSM: I'm seeking as > wide a coverage as

Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open

On Wed, Aug 03, 2016 at 08:28:10AM -0400, Daniel Micay wrote: > I don't think there are runtimes using this for JIT tracing. Perhaps it > doesn't actually suit their needs. It's a theoretical use case. I know there are compiler teams using perf for FDO, see for example:

Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open

Having this in Yama would also make it probable that there would be a security-centric default. It would end up wiping out unprivileged perf events access on distributions using Yama for ptrace_scope unless they make the explicit decision to disable it. Having the perf subsystem extend the

Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open

> The default has no impact on the "it's too coarse and limiting" > negative property  > of this patch, which is the show-stopper aspect. Please fix that > aspect instead of  > trying to argue around it. Disabling perf events in the kernel configuration is even more limiting, and is currently the

Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open

* Kees Cook wrote: > > I see 0 up-sides of this approach and, as per the above, a whole bunch of > > very > > serious downsides. > > > > A global (esp. default inhibited) knob is too coarse and limiting. > > I haven't suggested it be default inhibit in the upstream

Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open

Far from trying to kill perf, we want (and require) perf to be available to developers on Android. All that this patch enables us to do is gate it behind developer settings - just like we do with other developer targeted features. (apologies for the dup, bounced due to non-plaintext) On Tue, Aug

Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open

On Tue, Aug 2, 2016 at 1:30 PM, Peter Zijlstra wrote: > On Tue, Aug 02, 2016 at 12:04:34PM -0700, Kees Cook wrote: > >> Now, obviously, these API have huge value, otherwise they wouldn't >> exist in the first place, and they wouldn't be built into end-user >> kernels if they

Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open

On Tue, Aug 02, 2016 at 12:04:34PM -0700, Kees Cook wrote: > Now, obviously, these API have huge value, otherwise they wouldn't > exist in the first place, and they wouldn't be built into end-user > kernels if they were universally undesirable. But that's not the > situation: the APIs are needed,

Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open

> > So the problem I have with this is that it will completely inhibit > > development of things like JITs that self-profile to re-compile > > frequently used code. > > Or reimplement strace with sys_perf_event_open(), speeding it up > greatly > by not using ptrace (see 'perf trace', one such

Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open

On Tue, 2016-08-02 at 11:52 +0200, Peter Zijlstra wrote: > On Wed, Jul 27, 2016 at 07:45:46AM -0700, Jeff Vander Stoep wrote: > > > > When kernel.perf_event_paranoid is set to 3 (or greater), disallow > > all access to performance events by users without CAP_SYS_ADMIN. > > > > This new level of