Messages in this thread | | | Date | Fri, 14 Mar 2008 09:35:34 -0500 | From | "Serge E. Hallyn" <> | Subject | Re: [RFC] cgroups: implement device whitelist lsm (v2) |
| |
Quoting Paul Menage (menage@google.com): > On Fri, Mar 14, 2008 at 7:05 AM, Serge E. Hallyn <serue@us.ibm.com> wrote: > > > > A task may only be moved to another devcgroup if it is moving to > > > > a direct descendent of its current devcgroup. > > > > > > What's the rationale for that? > > > > To prevent it escaping to laxer device permissions, which of course only > > makes sense if we do what you recommend above :) > > > > That makes it impossible for a root process to enter a child cgroup, > do something, and then go back to its own cgroup.
Yes, but it can fire off a child in the child cgroup to do something, and go on on its own cgroup when the child finishes.
> Why aren't the > existing cgroup security semantics sufficient?
Because the point of this is to provide some restrictions to otherwise privileged users, and cgroups only provides dac-based permissions.
But that doesn't mean that I'm not doing too much. I could just add a CAP_SYS_ADMIN or CAP_CONT_OVERRIDE+CAP_SYS_ADMIN check, and not restrict which cgroups a task can move to. Does that sound good?
-serge
| |