On 12/13/2016 10:13 AM, John Stultz wrote: > On Tue, Dec 13, 2016 at 9:48 AM, Casey Schaufler <casey@xxxxxxxxxxxxxxxx> wrote: >> On 12/13/2016 9:24 AM, John Stultz wrote: >>> On Tue, Dec 13, 2016 at 9:17 AM, Casey Schaufler <casey@xxxxxxxxxxxxxxxx> wrote: >>>> On 12/13/2016 8:49 AM, John Stultz wrote: >>>>> On Tue, Dec 13, 2016 at 8:39 AM, Casey Schaufler <casey@xxxxxxxxxxxxxxxx> wrote: >>>>>> On 12/13/2016 1:47 AM, Michael Kerrisk (man-pages) wrote: >>>>>>> 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. >> Adding a new capability is unnecessary. The current use of CAP_SYS_NICE, >> while arguably obscure, provides as much "security" as a new capability >> does. While cgroups are a wonderful thing, they don't need a separate >> capability. > The trouble is that CAP_SYS_NICE or _RESOURCE (which was tried in an > earlier version of this patch) aren't necessarily appropriate for > non-android systems. See Andy's objection here: > https://lkml.org/lkml/2016/11/8/946 Then we need to see what those as-yet-unimplemented systems require and how to address them. I don't think that taking the "someone might want it" approach is really appropriate. > > thanks > -john > -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
