On Tue, Apr 10, 2012 at 2:59 PM, Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote: > Andy Lutomirski <luto@xxxxxxx> writes: > >> On 04/07/2012 10:10 PM, Eric W. Biederman wrote: >>> >>> This is a course correction for the user namespace, so that we can reach >>> an inexpensive, maintainable, and reasonably complete implementation. >>> >>> If anyone can think of a reason why the user namespace should not >>> evolve in the direction taken in this patchset please let me know. >>> >>> There is not an obvious maintainer for the scope of what this patchset >>> covers so I intend to host this tree myself and to place it in >>> linux-next after this round of review. >>> >>> Highlights. >>> - The kernel will now fail to build if you attempt to compile in >>> code whose permission checks have not been updated to be user >>> namespace safe. >>> >>> - All uids from child user namespaces are mapped into the initial user >>> namespace before they are processed. Removing the need to add >>> an additional check to see if the user namespace of the compared >>> uids remains the same. >> >> [...] >> >> I haven't read enough of the details to figure out how the uid mapping >> works (do all the child namespace uids map to the same parent uid?), so >> I may be missing some details here. > > You seem to be missing a detail or two. > > What you want to look at are the functions make_kuid and from_kuid > in kernel/user_namespace.c You might look at the patches that talk > about uidgid.h and introducing a mapping layer. > > The implementation creates an incomplete but 1-1 mapping to the uids in > the initial user namespace. Which means except for the change in > datatype (sigh) the existing permission checks don't need to be changed. I'll do my homework at the same time that I write up docs for no_new_privs (i.e. maybe today). > > My understanding of no_new_privs is that current_cred() including > the user, the user namespace and the security label will never change, > with the goal of making the security analysis simple. They can change but only if you already have the privilege to change them yourself and then you do so. For example, PR_SET_NO_NEW_PRIVS, setuid, then drop caps is allowed and useful -- it's a race-free way to make sure that a given uid never executes without no_new_privs set. I've implemented this as a pam module. This still simplifies security analysis: the guarantee is that, if no_new_privs is set, then a task's children cannot do anything that the task could do on it's own. Therefore it's safe for the task to manipulate its own environment in whatever strange ways it wants, because even if that gives it the ability to subvert its children, there is no privilege gained. > > I don't recall how seccomp filters are dealt with if you don't have > no_new_privs enabled. If seccomp filters installed by root > are dropped when we change privilege levels it might be worth looking > at how to keep a seccomp filter installed as long as you stay in > a user namespace. > They're not dropped. I think in the current implementation they can't be dropped at all. > > There are essentially two modes you can use the user namespace in: > with mappings setup (a privileged operation) and with no mappings. > > With no mappings you can not create a new user namespace or change or > uid or gids, and suid exec fails (or possibly ignores the uid/gid change > but I am starting with suid exec fails). Making user namespaces similar > to no_new_privs. > > The emphasis is a bit different from new_new_privs as the user_namespace > does not need to guarantee that the lsm will not change security labels, > etc. Hmm. Is this safe? For example, if there's a program that LSM policy grants extra privileges that malfunctions when run inside a user namespace, can that be used to break out of LSM restrictions? > > At a basic level of interaction I expect no_new_privs will need to fail > any change of the user namespace. As changing the user namespace > changes current_cred(), and fundamentally allows more things to happen. If a user namespace has no visible effect on processes that aren't descendents of whoever created it, then creating one in no_new_privs mode should be safe. On the other hand, it could be somewhat useless. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
