disk group abuse

The disk group grants read and write access to the system's block devices (/dev/sda, /dev/dm-0, etc.). Belonging to this group is, in practice, equivalent to having read access to the entire disk without going through the filesystem or its permissions: if you can read the raw device, you can read any file that lives on it, including /etc/shadow.

The hint shows up in id: a user with groups=...,6(disk). To enumerate which devices belong to the group:

id
find / -group disk 2>/dev/null

The handiest tool to exploit it is debugfs, an ext filesystem debugger that lets you browse and dump files from the device interactively:

debugfs /dev/dm-0
debugfs:  cat /etc/shadow

Running cat /etc/shadow from debugfs retrieves root's hash even though the file has 640 permissions owned by root:shadow, because the read goes against the block device, not the protected path. From there, the hash ($6$..., sha512crypt) is cracked offline with John or hashcat and you get root's password.

Why it's so powerful. It's not an exploit or a race condition: it's a misgranted group permission. The disk group is meant for storage administration tasks, but bypassing the filesystem permission layer turns it into full read access (and write, which even allows modifying files directly on the device).

debugfs also writes: with -w the device is mounted read/write and you can replace a binary or inject a key, though the clean route is still to read and crack:

debugfs -w /dev/dm-0
debugfs:  cat /root/.ssh/id_rsa      # steal root's private key straight off the disk

Find the root device to point debugfs at:

df -h /            # or: lsblk ; mount | grep ' / '

Nuances. debugfs works on ext families (ext2/3/4); with other filesystems you'd use the equivalent tool. And although the group grants write access to the device, editing on-disk structures live is risky (corruption): reading /etc/shadow or root's SSH key is the reliable move.

How to detect it. The signature is direct block-device access bypassing the filesystem: a process opening /dev/sda//dev/dm-0 for reading that isn't a legitimate storage utility (auditd with -w /dev/dm-0 -p rwa, or watching debugfs/dd executions by non-admin users). At rest, a user who doesn't manage storage belonging to the disk group is already the config deviation; and reading /etc/shadow without going through the VFS (no open of the path but one of the device) is the sign that the permission layer was sidestepped.

Defence. Don't add users to the disk group unless truly needed; treat membership in disk (and shadow, docker, etc.) as equivalent to root for threat-modeling purposes. Related to other privileged group and privileged-configuration abuses.