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
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
