On Tue, Dec 13, 2016 at 9:17 AM, Casey Schaufler [off-list ref] wrote:

On 12/13/2016 8:49 AM, John Stultz wrote:

quoted

On Tue, Dec 13, 2016 at 8:39 AM, Casey Schaufler [off-list ref] wrote:

quoted

On 12/13/2016 1:47 AM, Michael Kerrisk (man-pages) wrote:

quoted

How about CAP_CGROUP_CONTROL or some such, with the idea that this
might be a capability that allows the holder to step outside usual
cgroup rules? At the moment, that capability would allow only one such
step, but maybe there would be others in the future.

I agree, but want to put it more strongly. The granularity of
capabilities can never be fine enough for some people, and this
is an example of a case where you're going a bit too far. If the
use case is Android as you say, you don't need this. As my friends
on the far side of the aisle would say, "just write SELinux policy"
to correctly control access as required.

So.. The trouble is that while selinux is good for restricting
permissions, the in-kernel permission checks here are already too
restrictive.

Why did the original authors of cgroups make it that restrictive?
If there isn't a good reason, loosen it up. If there is a good
reason, then pay heed to it.

That's what this patch is proposing. And I agree with Michael that the
newly proposed cap was a bit to narrowly focused on my immediate use
case, and broadening it to CGROUP_CONTROL is smart. Then that
capability could be further restricted w/ selinux policy, as you
suggest.

thanks
-john