Re: Unprivileged containers and co-ordinating user namespaces

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Wed, 2016-05-04 at 10:02 -0500, Eric W. Biederman wrote:
> James Bottomley <James.Bottomley@HansenPartnership.com> writes:
> 
> > On Thu, 2016-04-28 at 16:00 -0700, W. Trevor King wrote:
> > > On Thu, Apr 28, 2016 at 03:02:08PM -0700, James Bottomley wrote:
> > > > /etc/usernamespaces
> > > > 
> > > > and the format be :::
> > > > 
> > > > …
> > > > 
> > > > If this sounds OK to people, I can code up a utility that does 
> > > > this, which should probably belong in util-linux.
> > > 
> > > This sounds a lot like shadow's newuidmap and newgidmap [1,2,3].
> > > 
> > > Cheers,
> > > Trevor
> > > 
> > > [1]: https://github.com/shadow-maint/shadow/commit/673c2a6f9aa6c6
> > > 9588f4c1be08589b8d3475a520
> > > [2]: http://man7.org/linux/man-pages/man1/newuidmap.1.html
> > > [3]: http://man7.org/linux/man-pages/man5/subuid.5.html
> > 
> > I think that mostly works.  No-one's packaging it yet, which is why 
> > I didn't notice.  It also looks like the build dependencies have
> > vastly expanded, so I can't get it to build in the build service
> > yet.
> 
> Both Fedora and Ubuntu should be packaging it.  Further Docker should
> already be using these files.
> 
> > It looks like the only addition it needs is the setgroups flag for
> > newgidmap, which the security people will need, so I can patch 
> > that.  Plus it's trying to install newgidmap/newuidmap as setuid 
> > root rather than cap_setuid/cap_setgid, but that's fixable in the 
> > spec file.
> 
> I read the rest of this thread and I don't understand the setgroups 
> flag that you desire.  It sounds like someone with an incomplete 
> grasp on the situtation being cautious.
> 
> As far as I can tell the use cases for containers not supporting
> setgroups is very limited.  Basically just using user namespaces to
> drop privileges, and mapping the existing uids and gids to 0.
> 
> I don't think it actually makes sense to have a knob.  From a 
> practical standpoint entering any subordinate ids into the subgid 
> file for a user is a permission to use groups in such a way that can 
> not use them as a negative acl (because we allow them to be dropped).
> 
> Certainly it has been that way for quite a while now.

I don't quite get this.  If setgroups is set to deny and I have a set
of group mappings, I still can't get rid of the negative acl group.  I
can map it to a different gid inside my container, or I can not map it
at all, but in either case I still can't get access to anything with
the negative acl group marker because the group permission checks
occurs with the kguid_t set which includes my mapped or unmapped group.
 The only way I can lose it is to call sys_setgroups().

It's a bit ugly because I have to enter the container with --preserve
-credentials and I can't su to myself if I enter as root (-S 0), I have
to re-enter as myself instead, but it works.

> Except for the negative acl aspect there are no issues with dropping
> groups, as setgroups will limit you to the groups allowed in your 
> user namespace.

Well, notwithstanding the merits of negative acls, which I don't want
to debate because I don't think they're that useful, the use case might
be that a user possessing a negative acl still wants to use an
architecture emulation container for building.  Installing such a
container requires being able to set a set of groups and uids (required
by the installer), but it doesn't require the sys_setgroups() system
call, so they could reasonably be given the ability to set one up with
the nosetgroups flag and a range of gids allocated in subgid to ensure
they still can't get access to resources denied by the negative acl
group.

James