Privileged groups on Linux

On Linux, membership in certain groups is worth as much as a sudoers entry, but it never shows up in sudo -l and so it gets overlooked. The first command after landing a shell should be id, and if it returns anything beyond the default groups, that deserves a look before anything else.

id
# uid=1000(user) gid=1000(user) groups=1000(user),27(sudo),108(lxd),6(disk)

The groups that hand over root directly, or nearly so, are these:

• disk: raw access to the block devices. With debugfs you read any file on disk, bypassing the filesystem permissions entirely, /etc/shadow or root's private key included.
• docker and lxd: they let you create a container that mounts the host's disk. See abusing the docker group and abusing the lxd group.
• adm: read access to all of /var/log. Not root by itself, but logs routinely contain passwords typed by mistake on a command line.
• shadow: read access to /etc/shadow, that is, hashes ready to crack.
• video: access to the framebuffer, which can capture whatever is on the physical screen.

The disk case is the most telling because it needs no exploit at all:

df -h /
debugfs /dev/sda1
debugfs:  cat /etc/shadow

debugfs opens the device directly, so file permissions stop mattering: whoever can read the disk can read everything on it.

Nuances. A group showing up in id does not guarantee the vector: docker needs the daemon running, lxd needs the service initialised, and disk needs the user to actually reach the device holding the filesystem. Worth checking before assuming it.

How to detect it. Each group leaves a distinct signature when abused: disk generates direct block-device reads (debugfs/dd over /dev/sda* by a non-admin, auditd -w /dev/sda1); docker/lxd, containers mounting the host root (see docker-group-abuse and lxd-privesc); adm, bulk reads of /var/log not coming from a management tool; shadow, an open of /etc/shadow by a process that isn't sshd/login/passwd. The cross-cutting sign at rest is simple: a service or ordinary user account showing up in id as a member of one of these groups is already the config deviation to investigate.

Defence. Treat these groups the way sudo is treated: review who belongs to them, do not use them as a shortcut for one-off permissions, and audit membership changes.