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

[Peter Zijlstra <peterz@infradead.org>]

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.
> 
> Which is a long way of saying a user namespace is one way of marking
> processes that may or may not use perf.
> 
> It was given in this case as an example of something that has been
> looked at that appears to solve peoples concerns.

> What is attractive to me semantically about something like this is
> applications that have perf_event disabled can still be traced with perf.

> > So far I'm still liking the new capability bit better, assuming I
> > understood those right.
> 
> Your subsystem your call.  I have never had much luck with capability
> bits.  They are not particularly flexible, and are hard to get rid of
> permanently any suid root app gains them all.

Right, so I've no experience with any of this.

But from what I understood amluto recently made capabilities much more
useful with: 58319057b784 ("capabilities: ambient capabilities").

And the thing I like is having file capabilities, so even though the
user cannot in general create perf events, we could mark the
/usr/bin/perf executable as having CAP_PERF and allow it to create them,
because its a 'trusted' executable.

Can something like that be done with userns? Afaiu once you create a
userns with perf disabled, even a nested one cannot re-enable it,
otherwise you cannot create sandboxes.