Skip to main content

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.

Supported byBecome a sponsor
BitriseAtomsizedDigitalOceanDevDojoSMTPfastQuizAPI
1 / 6

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.

Overview

A container is not a security boundary by default, and most container escapes come from a single flag rather than a kernel exploit. This challenge shows six real docker run commands, each the kind of thing people ship because a tutorial said so: a CI runner, an "it did not work so I added this" container, a backup job, a monitoring agent, one that looks careful, and a final one. Each command is split into tokens, and you click the ones you think give an attacker the host. Then you see the actual escape path for each dangerous token and the safer fix. The cases include mounting the Docker socket, which is equivalent to root on the host because the daemon runs as root; --privileged, which hands the container nearly every capability and access to host devices; sharing the host process namespace with --pid=host; and capabilities such as SYS_ADMIN and SYS_PTRACE. The careful-looking scenario shows that swapping --privileged for --cap-add=SYS_ADMIN with an unconfined AppArmor profile is not much safer, and the last one is a hardened command with --read-only, --cap-drop=ALL, no-new-privileges, a narrow read-only mount and a non-root user, so you also learn to recognize a safe line. You come away able to review a docker run line or a compose file with a security eye.

Try this

  1. In "The CI runner", find the token that gives away the host and read why the Docker socket equals root.
  2. Work through "The one that looks careful" to see why --cap-add=SYS_ADMIN with AppArmor unconfined is still an escape.
  3. Finish all six scenarios and compare the fixes, such as rootless builders and socket proxies, with what you run today.

Frequently asked questions

Why is mounting /var/run/docker.sock dangerous?
The socket is the Docker daemon API, and the daemon runs as root. Anyone who can reach it can start a new container that mounts the host filesystem, which is full control of the host.
What does --privileged do?
It gives the container almost all Linux capabilities, access to host devices and fewer security restrictions, so a process inside can usually take over the host.
Is a container as isolated as a virtual machine?
No. Containers share the host kernel, so isolation depends on namespaces, capabilities, seccomp and other settings. One risky flag can remove most of it.

Try next

Sponsored
Carbon Ads
$ cd /games
// share