On Wed, 2018-01-31 at 11:01 -0600, Serge E. Hallyn wrote: > Quoting Srivatsa S. Bhat (srivatsa@csail.mit.edu): > > From: Srivatsa S. Bhat <srivatsa@csail.mit.edu> > > > > The existing patch which disallows unprivileged CLONE_NEWUSER applies > > the check for CAP_SYS_ADMIN capability on the 'init_user_ns' > > namespace, which is not entirely correct. Consider the following sequence: > > > > 1. A process with root privileges calls > > clone(child_fn, ..., CLONE_NEWUSER, ...) to create a new user namespace. > > > > 2. child_fn, now running in the newly created user namespace enjoys the > > full set of capabilities in the new user namespace, but has lost > > its capabilities in the old user namespace (init_user_ns in this > > case). > > > > 3. child_fn now calls > > clone(child_fn2, ..., CLONE_NEWUSER, ...) to create a new (nested) > > user namespace. > > > > Step 3 should have succeeded because child_fn has full privileges > > No, it should not. If the host has unprivileged_userns_clone=false, > then it should require privilege against the init_user_ns to change > or bypass that. Yes the userns was *created* by someone with that > privilege, but likely they did so precisely so that they could run > more sandboxed code. [...] I think I agree with this reasoning. Ben. -- Ben Hutchings All extremists should be taken out and shot.
Attachment:
signature.asc
Description: This is a digitally signed message part