Container Security Challenge
Six real docker run commands, each carrying a flag that hands an attacker the host. Click the dangerous ones, then see the actual escape path and what to grant instead. Covers the Docker socket, --privileged, host PID namespace, SYS_ADMIN and unconfined AppArmor, plus one command with nothing wrong with it.
Category: Security
What You Will Learn
- Why mounting /var/run/docker.sock is equivalent to handing over root on the host
- What --privileged actually grants, and the two escapes it enables
- How --pid=host plus a capability combine into a full container escape
- Why SYS_ADMIN is close to root, even though it looks more careful than --privileged
- What the default AppArmor profile is quietly protecting you from
- What a hardened docker run command looks like when every flag is deliberate
Topics covered: security, docker, containers, escape, privileged, capabilities, hardening, interactive
// simulator
Container Security Challenge
Six real docker run commands, each carrying a flag that hands an attacker the host. Click the dangerous ones, then see the actual escape path and what to grant instead. Covers the Docker socket, --privileged, host PID namespace, SYS_ADMIN and unconfined AppArmor, plus one command with nothing wrong with it.
The CI runner
A build container that needs to build images. Every "docker in docker" tutorial suggests this.
Click every part of this command that would let an attacker reach the host.
About this container security challenge
What you'll learn
- That most container escapes are one flag, not a kernel exploit
- How the Docker socket turns any container into host root
- Why two individually survivable flags can combine into something much worse
- What to grant instead, for each dangerous flag
- That a container is not a security boundary unless you make it one
Why it matters
Image scanning gets the attention, but a scanner never looks at how the container is run. Every scenario here is something people genuinely ship, usually because a tutorial said to, and each one gives an attacker the host without needing a CVE.
The last scenario has nothing wrong with it. Assuming every config is broken is its own failure mode.
Related reading: why your base image reports thousands of CVEs covers the other half of container security, the part scanners do look at. See also your container is not a security boundary.
Try next
// simulator
Fork Bomb Simulator
Visualize how the infamous :(){ :|:& };: fork bomb works. Watch processes multiply exponentially, exhaust system resources, and learn how to protect against it with ulimit, cgroups, and systemd.
// simulator
OAuth/OIDC Flow Simulator
Visualize OAuth 2.0 and OpenID Connect flows with an interactive simulator. Learn authorization code + PKCE, state, nonce, redirect URI checks, ID tokens, access tokens, refresh tokens, scopes, UserInfo, and common auth failure modes.
// simulator
SSL/TLS Handshake Simulator
Visualize how SSL/TLS handshakes work with certificate verification, key exchange, and cipher negotiation. Compare TLS 1.2 and 1.3 protocols.