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

On Fri, 2016-06-17 at 08:54 +0200, Peter Zijlstra wrote: > On Thu, Jun 16, 2016 at 03:27:55PM -0700, Kees Cook wrote: > > Hi guys, > > > > This patch wasn't originally CCed to you (I'm fixing that now). > > Would > > you consider taking this into the perf tree?  > > No. > > > It's been in

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

> As a debian user, is this a good place to complain? Because it does > get > it the way. It would be relevant to whether or not it should be set to 3 by default in the kernel without explicit configuration, but there's no proposal to do that. Debian has to pick a trade-off beyond security and a

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

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 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

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... > >

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

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] [PATCH 1/2] security, perf: allow further restriction of perf_event_open

On Wed, 2016-10-19 at 07:26 -0300, Arnaldo Carvalho de Melo wrote: > > But self profiling JITs would be useful for non-developers, on Android > (anywhere, really), and for that it would require being able to at > least, well, self profile, using sys_perf_event_open() by a normal > process,

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

On Wed, 2016-10-19 at 10:41 +0100, Mark Rutland wrote: > On Mon, Oct 17, 2016 at 10:54:33AM -0400, Daniel Micay wrote: > > On Mon, 2016-10-17 at 14:44 +0100, Mark Rutland wrote: > > > It's also my understanding that for Android, perf_event_paranoid > > > is > >

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

On Tue, 2016-10-18 at 13:48 -0700, Kees Cook wrote: > On Mon, Oct 17, 2016 at 6:44 AM, Mark Rutland > wrote: > > Hi, > > > > Attempt to revive discussions below... > > > > On Wed, Jul 27, 2016 at 07:45:46AM -0700, Jeff Vander Stoep wrote: > > > When

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

On Mon, 2016-10-17 at 14:44 +0100, Mark Rutland wrote: > Hi, > > Attempt to revive discussions below... > > 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