linux-kernel - Re: handling of supplemental groups with userns

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20150929030613.GA28210@vapier.lan>
Date:	Mon, 28 Sep 2015 23:06:13 -0400
From:	Mike Frysinger <vapier@...too.org>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	linux-kernel@...r.kernel.org, containers@...ts.linux-foundation.org
Subject: Re: handling of supplemental groups with userns

On 22 Sep 2015 17:52, Mike Frysinger wrote:
> On 22 Sep 2015 14:40, Eric W. Biederman wrote:
> > Mike Frysinger writes:
> > > 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 ?

so this does open up a permission people do not have today by themselves.
since there's no requirement that the current gid be in the supplemental
groups, they could drop a single group by changing to a supp one.

for example, if it looked like:
	getuid() = 1000
	getgid() = 1000
	getgroups() = {100, 250}

then if 1000/100/250 were mapped in, they could do:
	setgid(100)
	getgid() = 100
	getgroups() = {100, 250}
and thus group 1000 has been dropped.

the reason this doesn't happen today is that writes to gid_map is permitted
only if the writer has CAP_SETGID in the parent userns and the gid has been
mapped there.  normal users don't start out with that cap, and any setuid
helper has to make sure to drop caps & setuid/setgid before execing the next
layer (i.e. do the standard stuff).

so the only way to permit this behavior is if the knobs were extended and we
had a parallel USERNS_SETGID_ALLOWED.  or we updated setgid to check the bit
USERNS_SETGROUPS_ALLOWED since it seems in spirit to cover that.
-mike

Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)