[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160804153742.GN6879@twins.programming.kicks-ass.net>
Date: Thu, 4 Aug 2016 17:37:42 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
Cc: Kees Cook <keescook@...omium.org>, Jeff Vander Stoep <jeffv@...gle.com>,
Ingo Molnar <mingo@...hat.com>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
"kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>,
LKML <linux-kernel@...r.kernel.org>,
Jonathan Corbet <corbet@....net>
Subject: Re: 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.
>
> 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.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
