flawopen.com/Reference/Docker Socket & Capability Escapes

Docker Socket Mounts & Linux Capability Escapes

Critical Host Risk CWE-269 Supply Chain & Runtime

ELI5 — The Master Remote Control in the Guest Bedroom

Imagine renting out your guest bedroom to an unknown Airbnb guest. You lock the door to your private master bedroom and hide the keys. But on the guest room nightstand, you leave the master smart-home touchscreen that has full administrative power to unlock every door, turn off the security alarms, and format the house computer. In container security, mounting /var/run/docker.sock inside a container is the master touchscreen—it allows any process inside the container to command the host Docker daemon to give it root control over the physical server.

Target: Docker / Kubernetes container runtimes, CI/CD runner agents

Vector: Volume mounting /var/run/docker.sock, running with --privileged

Impact: Total root breakout from container to underlying physical host or VM

Remediation: Rootless Docker, Kaniko for image building, dropping all capabilities

The Mechanism & Root Cause

The Docker Unix socket (/var/run/docker.sock) is the control interface for the Docker daemon. Giving a container read/write access to this socket gives it equivalent power to root on the host. Any process inside the container can issue HTTP API calls to the socket, commanding Docker to spawn a new container with the host root filesystem mounted at /host and chrooting into it.

docker-run.sh (Vulnerable Deployment)Vulnerable

# VULNERABLE: Mounting docker socket for CI/CD or monitoring container
docker run -d \
  --name build-runner \
  -v /var/run/docker.sock:/var/run/docker.sock \ # Instant host compromise!
  ci-runner:latest

# Inside the container, any unprivileged user runs:
# curl --unix-socket /var/run/docker.sock http://localhost/containers/create \
#   -d '{"Image":"alpine","Cmd":["chroot","/host","sh"],"Binds":["/:/host"]}'

docker-run.sh (Hardened Non-Root)Hardened

# HARDENED: Run rootless, drop capabilities, and never expose host socket
docker run -d \
  --name secure-app \
  --user 10001:10001 \
  --read-only \
  --cap-drop=ALL \
  --security-opt no-new-privileges:true \
  --tmpfs /tmp:rw,noexec,nosuid,size=64M \
  app-image:latest

The Attack & Exploit Sequence

1An application running inside a container suffers a vulnerability (e.g. Command Injection).:
2The attacker inspects mounted volumes and finds /var/run/docker.sock.:
3The attacker communicates with the socket: docker run -v /:/host_root alpine chroot /host_root.
4The host Docker daemon launches the requested container, granting the attacker interactive root access over the host's actual operating system.:

Defensive Engineering & Prevention Rules

✓Never Mount /var/run/docker.sock into Workload Containers: If building images in CI/CD, use rootless user-space builders like Kaniko or Buildah that require no daemon socket.
✓Never Run Containers with --privileged: The --privileged flag disables all AppArmor, Seccomp, and namespace protections, enabling trivial device escapes.
✓Drop All Linux Capabilities by Default: Specify --cap-drop=ALL and selectively add back only the specific capabilities needed (e.g. CAP_NET_BIND_SERVICE).
✓Enable User Namespaces (Rootless Containers): Map container UID 0 (root) to an unprivileged high UID on the host (e.g. UID 100000) so container escapes cannot gain host root power.

Explore related security topics and post-mortems: Complete Security Directory →