Disk Group Membership — Reading Root's Filesystem Directly

Most privilege escalation paths on Linux revolve around file permissions — SUID bits, sudo rules, writable scripts. This one skips permissions entirely. If you belong to the disk group, you don’t need read access to /etc/shadow. You have read access to the entire disk it lives on.

That distinction is the whole exploit.

The Setup

I had a shell as a low-privilege user, dora, on an Ubuntu box. Standard first move: check group memberships.

id

uid=1000(dora) gid=1000(dora) groups=1000(dora),6(disk)

groups=...,6(disk) immediately stood out. The disk group on most distributions grants raw read/write access to block devices under /dev — the actual disk hardware, not the filesystem layered on top of it. That’s an enormous amount of trust to hand to a non-root user, and it’s frequently added to service accounts or forgotten during provisioning without anyone realizing what it actually implies.

Enumeration

Membership in disk is only useful if I know which device to target. A quick look at the mounted filesystems answered that:

df -h

Filesystem                         Size  Used Avail Use% Mounted on
/dev/mapper/ubuntu--vg-ubuntu--lv  9.8G  5.1G  4.2G  55% /

The root filesystem sat on an LVM logical volume, /dev/mapper/ubuntu--vg-ubuntu--lv. Because it’s LVM rather than a plain partition, the entire filesystem — including files I’d normally never be allowed to open, like /etc/shadow — lives inside that single block device. If I can read the raw bytes of that device, I can read the bytes of every file on it, permission bits or not.

Being in the disk group is exactly what makes reading that raw device possible.

Exploitation

Rather than trying to dd the whole volume and parse a raw ext4 image by hand, I used debugfs — a filesystem debugger that ships with e2fsprogs and understands ext-family filesystems natively. Critically, it doesn’t respect Unix file permissions at all; it just reads the block device directly and asks it “give me this inode.”

debugfs /dev/mapper/ubuntu--vg-ubuntu--lv

Inside the debugfs shell, cat reads a file straight out of the volume:

debugfs: cat /etc/shadow

root:$6$AIWcIr8PEVxEWgv1$3mFpTQAc9Kzp4BGUQ2sPYYFE/dygqhDiv2Yw.XcU.Q8n1YO05.a/4.D/x4ojQAkPnv/v7Qrw7Ici7.hs0sZiC.:19453:0:99999:7:::

There it is — the root password hash, pulled without ever touching the file’s actual permission bits, because I never asked the filesystem layer for permission in the first place. I was reading disk sectors, and disk sectors don’t have an owner.

With the hash in hand, I cracked it offline with John the Ripper against rockyou.txt:

john hash.txt --wordlist=/usr/share/wordlists/rockyou.txt

The cracked password was explorer. Full simplicity from here:

su root

Password: explorer
root@dora:/# id
uid=0(root) gid=0(root) groups=0(root)

Root.

Why This Works

Standard Unix permission checks — rwx bits, ownership, ACLs — are enforced by the filesystem layer when a process asks the kernel to open a file by path. debugfs doesn’t go through that path at all. It opens the block device node directly (/dev/mapper/...), parses the ext4 superblock and inode tables itself, and hands back whatever data lives at a given inode. The kernel’s only gate at that point is: can this process open the device node? And that gate is controlled by a single group membership — disk — not by anything /etc/shadow’s own -rw-r----- permissions say.

In other words, disk group membership is functionally equivalent to root-level read/write access to the entire filesystem. It just doesn’t look that dangerous at a glance, because nobody thinks of “membership in a supplementary group” as “full disk access.”

LVM makes this even more convenient for an attacker: instead of hunting for the right partition, the whole root filesystem is one clean logical volume with a predictable device-mapper path shown right in df -h.

Root Cause

The dora user should never have been added to the disk group. It’s not required for normal desktop or service operation, and its access model bypasses the entire discretionary access control system that /etc/shadow’s permissions are supposed to enforce.

Fix:

# Remove the unnecessary group membership
gpasswd -d dora disk

# Audit every account for dangerous supplementary groups
for u in $(cut -d: -f1 /etc/passwd); do
  groups "$u" | grep -E '\b(disk|video|kmem)\b' && echo "^ review: $u"
done

More broadly: disk, kmem, and similar low-level groups should be treated with the same caution as sudo or wheel. They’re rarely audited with the same rigor, which is exactly why this technique keeps working in the wild.

Key Takeaways

• Group membership matters just as much as file permissions — always run id first and check every group listed, not just the primary one
• disk group access effectively bypasses all filesystem-level permission checks by giving raw read/write to the block device itself
• debugfs can read any file on an ext-family filesystem without ever satisfying that file’s own permission bits, as long as you can open the underlying device
• LVM logical volumes are single, predictable device-mapper paths — df -h will usually hand you the exact target
• Never stop at hash extraction — a crackable password (found here via John against rockyou.txt) turns “I can read the shadow file” into full interactive root

Questions? Hit me up on X.