Docker group abuse

The Docker daemon runs as root, and any user in the docker group can talk to it without sudo. That is, in fact, equivalent to being root: belonging to the docker group lets you launch containers that mount the host's filesystem and operate on it with full privileges. It isn't a Docker bug but a documented consequence of its permission model, so always check id:

id
# uid=1000(eleanor) ... ,999(docker)
docker images        # see which images are available locally

The classic technique: start a container (from any present image) mounting the host root inside it and chroot-ing into that mount, which leaves us as root over the host's real disk:

docker run -it --rm -v /:/mnt <image> chroot /mnt bash
id      # uid=0(root) gid=0(root)

From there the entire host filesystem is under our control with root permissions. Rather than always operating from the container, it's usual to consolidate access cleanly and persistently, e.g. setting the SUID bit on bash or creating a user:

chmod u+s /bin/bash      # SUID bash on the host
# or:
adduser <user>           # create an account and log in over SSH later

Then a shell that keeps privileges closes the escalation (SUID abuse):

bash -p                  # euid=0 thanks to the freshly set SUID

Worth distinguishing this from container pivoting: there you have root inside an isolated container and the goal is extracting secrets; here the -v /:/mnt mount deliberately breaks the isolation and yields root on the host.

How to detect it. The Docker daemon logs every action in its journal (journalctl -u docker): the signature is a docker run with -v /:/mnt (or --privileged, --pid=host) by a user who doesn't deploy apps, followed by a chroot. On the host, auditd/Sysmon for Linux see a bash/sh process with uid=0 whose ancestor is containerd-shim/runc touching real system files (/etc/passwd, /root/.ssh, a chmod +s /bin/bash), something an application container never does. Mounting the host root inside a container is the central indicator.

Defence. Treat docker group membership as granting root: don't add users there unless necessary, use rootless Docker or a mediated socket, and audit who's in the group. Related to Docker container pivoting and SUID binary abuse.