[lxc-devel] capset fails with userns

[Serge Hallyn]

Quoting Stéphane Graber (stgraber at ubuntu.com):
> On Wed, Feb 26, 2014 at 08:48:37AM -0600, Serge Hallyn wrote:
> > Quoting Stephan Sachse (ste.sachse at gmail.com):
> > > for me there is no valid reason why a container is not allowed to set
> > > file capabilities.
> > > 
> > > and here is the patch (send to Eric W. Biederman <ebiederm at xmission.com>)
> > > 
> > > works for me
> > 
> > Nak, Nak, three times nak :)
> > 
> > But if you do as I suggested in the previous email, that would be
> > terrific.
> 
> In case the reason for the above triple nak isn't obvious, here's a
> quick example of what I'd be able to do with that patch :)
> 
> Assume I write a piece of software, test.c in my container:
> """
> #include <errno.h>
> #include <stdio.h>
> #include <string.h>
> #include <unistd.h>
> 
> int main(int argc, char** argv) {
>     if (setgid(0) < 0)
>         printf("Failed to setgid: %s\n", strerror(errno));
> 
>     if (setuid(0) < 0)
>         printf("Failed to setuid: %s\n", strerror(errno));
> 
>     if (initgroups("root", 0) < 0)
>         printf("Failed to initgroups: %s\n", strerror(errno));
> 
>     if (execl("/usr/bin/id", "/usr/bin/id", NULL) < 0)
>         printf("Failed to execl: %s\n", strerror(errno));
> 
>     return 1;
> }
> """
> 
> Running this as a user will print 3 errors, then show the result of the
> id command.
> 
> Now with the proposed patch, I could, still in that container do:
>  sudo setcap cap_setgid,cap_setuid=ep test
> 
> 
> After that, from outside the container, I can simply run that same
> binary and get:
>  stgraber at castiana:~$ ./test
>  uid=0(root) gid=0(root) groups=0(root)
> 
> 
> So yeah, letting anyone write to trusted.* because they are uid 0 in a
> userns is a very very bad idea.

<nit> that's security.*  I point this out bc I'm still curious whether
there *is* a good reason for the same restriction on trusted.*.  That's
bc I have no idea what - other than overlayfs - uses those.