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 <email address hidden> 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