Privileged containers and the security boundary

--privileged is not “a container with more capabilities”. It is a single flag that turns off five independent security mechanisms at once, and the reason it is so dangerous is that four of them are not mentioned in its name.

What --privileged actually switches off

Any one of those five is a plausible route out of the container. Together they mean a privileged container is a root shell on the host with a couple of extra steps.

The escalation does not need a vulnerability. With CAP_SYS_ADMIN in hand and every device node available, a process inside the container can mount the host’s root block device onto a directory inside its own mount namespace and then read and write the host’s filesystem directly — placing an authorised key, a systemd unit, or a setuid binary. The container never “escaped”; it was handed the tools to reach around the boundary.

Proving it, from the host

$ PID=$(docker inspect --format '{{.State.Pid}}' dind); grep -E 'CapBnd|CapEff' "/proc/$PID/status"; cat /proc/sys/kernel/cap_last_cap

CapBnd:	000001ffffffffff
CapEff:	000001ffffffffff
40

A CapBnd of all-ones is the fingerprint. 40 is CAP_CHECKPOINT_RESTORE, the highest capability on a current kernel, which is why the mask has 41 bits set. On an older kernel the constant differs — which is exactly why the audit should compare CapBnd against Docker’s default 00000000a80425fb and flag anything larger, rather than looking for one magic value.

docker ps -q | while read -r c; do
  docker inspect --format '{{if .HostConfig.Privileged}}PRIVILEGED {{.Name}} {{.Config.Image}}{{end}}' "$c"
done | grep .

CID=dind
docker inspect "$CID" --format 'apparmor={{.AppArmorProfile}} privileged={{.HostConfig.Privileged}}'
PID=$(docker inspect --format '{{.State.Pid}}' "$CID")
cat "/proc/$PID/attr/current"
grep Seccomp "/proc/$PID/status"

Seccomp: 0 means no filter is loaded. Seccomp: 2 is filter mode, which is what a normal container shows. That single line is the cleanest evidence in a report, because it comes from the kernel and nobody can argue with it.

The legitimate use cases, honestly

Docker’s documentation does not publish a list of sanctioned uses, so be sceptical of any source that claims “the docs say two”. In practice the cases that come up:

1. Docker-in-Docker. A daemon inside a container needs to create namespaces, mount overlayfs, and manage cgroups. This is the common one, and it has good alternatives (below).
2. System containers that manage host hardware — a storage agent that must run mkfs on a raw device, a firmware updater, a driver installer. These are host software packaged as a container, not workloads.
3. Kernel and filesystem development. Legitimate, and by definition not production.

In every one of these, the container is trusted exactly as much as the host. That is the test. If you would not give this code root over SSH, it does not get --privileged, and reasoning about the image’s provenance is a supply-chain question, not a runtime one.

Alternatives, by what you were actually trying to do

Notice how many rows are a single --cap-add. That is the usual truth: the workload needed one capability and somebody reached for all forty.

The Docker-in-Docker case

services:
  # Option 1: privileged. The inner daemon runs as host root.
  dind:
    image: docker:28-dind
    privileged: true

  # Option 2: rootless. The inner daemon runs as an unprivileged
  # user, so an escape lands on an unprivileged host UID.
  dind-rootless:
    image: docker:28-dind-rootless
    security_opt:
      - seccomp:unconfined
      - apparmor:unconfined

Option 2 is strictly safer and is what the docker:dind-rootless image exists for. It is not free: it needs seccomp and apparmor set to unconfined so the inner runtime can create nested user namespaces, which reads alarming in a review and is a real reduction — but a much smaller one than granting every capability and every device.

For production CI the stronger answers are outside Docker’s model entirely: a disposable VM per job, a nested-container runtime such as sysbox, or an image builder that never needs a daemon. Pick based on how much you trust the code in the pull request, which for a public repository is “not at all”.

Knowledge check