linux-kernel - 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>] [day] [month] [year] [list]

Message-ID: <20150922162157.GB27286@vapier.lan>
Date:	Tue, 22 Sep 2015 12:21:57 -0400
From:	Mike Frysinger <vapier@...too.org>
To:	containers@...ts.linux-foundation.org
Cc:	ebiederm@...ssion.com, linux-kernel@...r.kernel.org
Subject: handling of supplemental groups with userns

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 ?

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).

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.

i've attached a simple test program to show the issue.  it can map the
current uid/gid fine, but fails to do so with a supplemental group.

my reading of kernel/user_namespace.c shows that it's not possible:
(1) if gid_map has any entries, map_write bails early with EPERM
(2) if gid_map is empty, then writing a single entry (e.g. "0 100 1")
    works, but then a 2nd write runs into (1)
(3) if gid_map is empty, then writing multiple entries (e.g.
    "0 100 1\n250 250 1\n") fails in new_idmap_permitted -- the first
    check is skipped (since new_map->nr_extents is 2), and the user
    does not have caps in the parent ns

i'm aware UID_GID_MAP_MAX_EXTENTS is low, so it's not even possible if i
had the caps to map all the existing supplemental groups, which is why i
only want to map the few critical groups.  but assuming this use case is
one we want to support, maybe it makes sense to add a knob to map all of
the user's supplemental groups ?

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 ?
-mike

View attachment "test.c" of type "text/x-c" (2281 bytes)

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