Privilege Escalation · intermediate · ~11 min
Recognise capability, writable-service, and docker-group escalations.
Capability-laden binaries (cap_setuid, cap_dac_read_search), writable systemd unit files/ExecStart targets, and docker/lxd group membership are all root-equivalent. Fixes: audit/remove capabilities, root-own non-writable service files, and treat docker-group membership as root.
These are clean, exploit-free escalations: a single capability, a writable unit, or docker-group membership is game over. They're commonly overlooked because they look like normal configuration.
Capabilities. cap_setuid/cap_dac_* = root-equivalent; getcap -r /. Writable units. systemd runs as root → writable unit/ExecStart = root. docker group. Mount host fs as root; lxd/lxc too. Fix. Trim capabilities, root-own service files, restrict container groups.
Beyond sudo/SUID/cron, a few powerful misconfigurations round out Linux privesc.
Capabilities split root's power into units (so a binary can have some root powers without full SUID). Some are escalation-equivalent:
/etc/shadow).
Enumerate with getcap -r / 2>/dev/null. A python3 or custom binary with cap_setuid is instant root.systemd services run as root. If a low-priv user can write a unit file (or a binary/ExecStart script a unit runs), they get root when the service (re)starts — the Linux sibling of the Windows weak-service-permissions issue.
Membership in the docker group is effectively root: you can run a container that mounts the host filesystem and read/write it as root:
docker run -v /:/host -it alpine chroot /host sh
No exploit — the group is the privilege. The same applies to lxd/lxc groups.
Capabilities, writable systemd units, and docker/lxd group membership each grant root without an exploit; defend by auditing capabilities, locking down service-file ownership, and treating container-group membership as root-equivalent.