Re: handling of supplemental groups with userns

[Mike Frysinger <vapier@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 2814 bytes --]

On 22 Sep 2015 14:40, Eric W. Biederman wrote:
> Mike Frysinger writes:
> > is it possible to map in supplemental groups in a userns when the user
> > lacks setgid/etc... capabilities in the parent ns ?  it doesn't seem
> > like it's currently possible, but is there a reason to not enable it ?
> 
> In your unprivileged use scenario, you won't be able to drop
> your supplementary groups so why do you need them mapped?
> 
> > basically i have a build tool that i want to isolate a bit, but it
> > requires access to some of my supplemental groups.  if i map just
> > my effective uid/gid, the build will fail when it tries to use the
> > chown/chgrp commands (gets back EINVAL).
> 
> Yes.  That really isn't valid as you are dropping groups.  Peculiarly
> enough dropping groups can be a security issue as in some permission
> checks not being a member of a group can give you enhanced access to
> files and directories.

i don't want to drop groups ... i want the exact opposite actually :).
ideally, `id` would have the same output before/after.  instead, i get
65534 for all the supplemental groups.  these commands work before i
create a new userns and i want them to keep working afterwards:
	chgrp 100 foo
	chgrp 250 foo
instead, only the first works (since that's my effective gid) and the
second fails (since i'm in that via a supplemental group).

> So to do something like what you want, you need a setuid helper (something
> like newuidmap or newgidmap) to verify that what you are doing is ok
> by local policy.

i know i can get it ahead of time if i have the caps apriori, but that's
not what i want to require.  if i had those, then i would generally be
able to simply create the namespaces directly and not bother with userns
in the first place :).

> > my scenario boils down to:
> >  - normal unprivileged user (uid=8282)
> >  - member of multiple groups (gid=100, getgroups={100,16,250,...})
> >  - create a new userns (to get access to other ns like mount/pid)
> >    but still have access to existing groups where i'm root
> >  - use various features that require caps (new pidns/mntns/etc...)
> >  - create another userns and map back non-root users/groups
> > i.e. i switch from 8282 to 0, do what i need, then switch back to 8282.
> 
> [snip]
> 
> > in the mean time, a "quick" fix might be to change new_idmap_permitted
> > to walk all the extents, and if all the ranges are set to 1, check the
> > supplemental groups in addition to the current egid ?
> 
> That allows dropping groups that you could not drop normally and so we
> can't allow it, by default.

if setgroups is set to deny, then it's not possible for me to drop any
groups, and therefore allowing me to map supplemental groups wouldn't be
a problem right ?
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]