Messages in this thread | | | Date | Wed, 02 Nov 2011 12:08:19 +0400 | From | Michael Tokarev <> | Subject | Re: [lxc-devel] Detecting if you are running in a container |
| |
On 02.11.2011 03:51, Eric W. Biederman wrote: [] >> And having CAP_MKNOD in container may not be that bad either, while >> cgroup device.permission is set correctly - some nodes may need to >> be created still, even in an unprivileged containers. Who filters >> out CAP_MKNOD during container startup (I don't see it in the code, >> which only removes CAP_SYS_BOOT, and even that due to current >> limitation), and which evil things can be done if it is not filtered? > > If you don't filter which device nodes you a process can read/write then > that process can access any device on the system. Steal the keyboard, > the X display, access any filesystem, directly access memory. Basically > the process can escalate that permission to full control of the system > without needing any kernel bugs to help it.
There's cap_mknod, and cgroup/devices.{allow,deny}. Even with CAP_MKNOD, container can not _use_ devices not allowed in the latter. That's what I'm talking about - there's more fine control exist than CAP_MKNOD. And my question was about this context - with proper cgroup-level device control in place, what bad CAP_MKNOD have?
Thanks,
/mjt
| |