Lion Cipher Lab

Escape a container through a mounted Docker socket

• Cloud Security
• Advanced
• ~45 min
• Free · no account required

Why it matters

Bind-mounting the Docker daemon socket into a container — `-v /var/run/docker.sock:/var/run/docker.sock` — is one of the most common configurations in real infrastructure, and one of the most dangerous. CI runners do it so a build job can build images. Monitoring agents (cAdvisor, Portainer, Watchtower, countless dashboards) do it so they can list and inspect containers. Reverse-proxy automation does it to watch for new containers. Every one of those is handing the container a direct line to the host's Docker daemon, and the Docker daemon runs as root and can do anything root can do. The…

What you'll learn

• explaining in plain language what the Docker daemon socket is, and why access to it is exactly equivalent to root on the host
• starting a container with the daemon socket bind-mounted in (the real-world CI/monitoring pattern) on your own disposable lab host
• confirming, as an attacker who has landed inside that container, that you can talk to the host daemon two ways: the docker CLI and a raw curl to the socket API
• performing the full escape: launching a new container that bind-mounts the host root filesystem and reading/altering host files (/etc/shadow, /root/.ssh) to prove socket access == host root
• measuring before/after: the same escape attempt succeeds with the socket mounted and fails once it is removed
• knowing the honest negative — that a non-root user inside the container, dropped capabilities, a read-only rootfs and seccomp do NOTHING once the socket is mounted
• applying the real fixes: never mount the socket; if a container genuinely needs Docker, front it with a read-only socket proxy (tecnativa/docker-socket-proxy), or use rootless Docker
• detecting the behaviour with Falco's 'Launch Privileged Container' and Docker-socket rules

Steps in this lab

1. Before anything else: this runs on YOUR throwaway host, and here is why that matters
2. What the Docker socket actually is, and why touching it means root
3. The trap: 'it's just for the CI runner' (why this misconfig is everywhere)
4. Build the vulnerable container (the real-world pattern, on your lab host)
5. Confirm you can reach the host daemon (two ways)
6. The escape: mount the host's whole filesystem and read /etc/shadow
7. The honest negative: the hardening you'd reach for does NOTHING here
8. Measure the fix: remove the socket and watch the same escape fail
9. When a container really does need Docker: a read-only socket proxy
10. Detect it: Falco alerts on the socket and on privileged launches
11. Do it better — the judgment to carry out of this lab

Open the full interactive lab →