Messages in this thread | | | From | (Eric W. Biederman) | Date | Thu, 15 Dec 2011 22:14:36 -0800 | Subject | Re: chroot(2) and bind mounts as non-root |
| |
Colin Walters <walters@verbum.org> writes:
> On Mon, 2011-12-12 at 23:11 +0000, Serge E. Hallyn wrote: > >> Look at the cap_get_bound.3 manpage, and look for CAP_IS_SUPPORTED. >> If you start at CAP_LAST_CAP and keep going up/down depending on whether >> it was support or not it shouldn't take too long to find the last >> valid value. Not ideal, but should be reliable. > > Blah =/ I think I'll just rely on the MS_NOSUID bind mount for now. > >> I haven't taken a critical look at the mount code but other than that >> it seems reasonable and useful to me! Thanks. > > Can you link me to any discussion of how the user namespace stuff you're > working on would enable any of this (chroot, bind mounts) to be > available to "unprivileged" users? Is it that once a non-uid 0 process > enters a new namespace, when executing a setuid 0 binary from the > filesystem, because that binary is from a different user namespace, the > setuid bits don't apply? > > What does it even mean for a file to be "owned" by a user namespace - > unless you're talking about patching e.g. ext4 to persist namespaces > somehow. > > Where I'd ultimately like to get is having this utility in util-linux, > but before I propose that I'd like to have a good idea what the > possibilities are with user namespaces.
The essentials is that all of the security credentials a process sees (uids, gids, capabilities, keys) all belong to the user namespace. This allows process migration while still being able to use the same global identifiers you were using before. At the same time this means that once you enter a user namespace all of the capabilities you can acquire are relative to that user namespace.
You can look at the details of ns_capable (merged) to see how those capabilities will work.
It is envisioned that the other namespaces will start recording the user namespace that created them so we can evaluate ns_capable relative to the creator of those namespaces. (It is trivial work we are just holding off so we don't introduce a security hole while we get the other bits implemented).
Which means it is safe to enter a new user namespace without root privileges as once you are in if you execute a suid app it will be suid relative to your user namespace. The careful changing of capable to ns_capable will allow other namespaces and other things that today are root only because of fears of mucking up the execution environment to be enabled.
What is slightly up in the air is how do we map user namespaces to filesystems. The simplest solution looks to be to setup a uid and gid mappings from each child user namespace to the initial system user namespace. Then in a child user namespace setuid(2) will fail if you attempt to use an id that does not have a mapping.
Similarly in fs/exec.c:prepare_binprm() at the point where we test MNT_NOSUID we will add an additional test to see if the uid and gid of the executable will map to the target user namespace. If the ids don't map we skip the suid step entirely.
Since except at the edges of userspace we use uids and gids in the initial user namespace, the implications for confusing other security mechanisms is minimized.
The downside of requiring a mapping is that there is the tiniest bit of user policy that will have to be added to the distributions to take full advantage of the user namespace. If you don't have that policy setup your real uid will not change but you will appear to userspace and uid 0. Which should be sufficient to compile, chroot, mount and just about everything else interesting without privileges.
> The more I think about this though, the more I am a big fan of what the > OpenWall people are doing - if it gets me chroot as a user, I am totally > on board with just removing all setuid binaries. We're already fairly > far along on doing that in GNOME by using PolicyKit mechanisms > anyways.
I am a great fan of the idea of removing from user space applications the ability to gain privileges during exec. There are some many fewer cases you have to audit for, and it requires less kernel code to support overall. Although I admit the direction you have suggested at the beginning of this thread has it's appeal.
Still I find in the kernel it generally is easier to solve the general case. It makes everyone happy and it removes the need to ask people to rewrite all of their in house applications.
Eric
| |