Quoting Stéphane Graber (stgra...@ubuntu.com):
> On Wed, Feb 26, 2014 at 08:48:37AM -0600, Serge Hallyn wrote:
> > Quoting Stephan Sachse (ste.sac...@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 <ebied...@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@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.
_______________________________________________
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel
