Never run containers with --privileged

The fix

# Instead of --privileged, grant the one capability you actually needed:
docker run --cap-drop=ALL --cap-add=NET_ADMIN myimage

docker-compose.yml

services:
  app:
    privileged: false        # the default; the finding is when it's true
    cap_drop: [ALL]
    cap_add: [NET_BIND_SERVICE]

Why it matters

--privileged is not “a few more permissions”. It turns off, simultaneously:

• All capability restrictions — the container gets every capability, including CAP_SYS_ADMIN, CAP_SYS_MODULE and CAP_SYS_PTRACE.
• The seccomp profile — every syscall becomes reachable, including the ones Docker’s default profile blocks specifically because they enable escapes.
• AppArmor / SELinux confinement — the container runs unconfined.
• Device restrictions — /dev from the host is exposed, so the container can see raw block devices.

That last one is usually the end of the story. With host devices visible, a privileged container mounts the host’s root filesystem and writes to it:

docker run --privileged -it alpine sh
# inside:
fdisk -l                      # the host's disks are right there
mount /dev/sda1 /mnt          # mount the host root
echo '...' >> /mnt/root/.ssh/authorized_keys

A privileged container is not isolated from the host in any meaningful way. It is a process running as root with a different filesystem view, and it can drop even that.

Why people set it

Nobody reaches for --privileged maliciously. It’s what makes the error stop:

• Docker-in-Docker for CI. Genuinely needs a lot — but the modern answer is a rootless builder like BuildKit or Kaniko, not a privileged daemon.
• A container that needs one capability — NET_ADMIN for a VPN, SYS_TIME for NTP, SYS_PTRACE for a debugger. --privileged grants it, along with everything else.
• Device access — a serial port, a GPU. --device=/dev/ttyUSB0 grants that one device; --privileged grants all of them.
• Something failed with “operation not permitted” and this made it stop.

In nearly every case the fix is a specific flag. The work is finding out which one, and that’s a five-minute exercise rather than an architectural problem.

Find the capability you actually need

Run the container without --privileged and watch it fail:

docker run --cap-drop=ALL --security-opt seccomp=unconfined myimage

If it now works, you needed a capability, not privilege. Add them back one at a time — strace inside the container names the syscall that failed, and that maps to a capability. Common ones:

Need	Flag
Bind to port < 1024	--cap-add=NET_BIND_SERVICE
Configure interfaces, VPN, iptables	--cap-add=NET_ADMIN
Raw sockets, ping	--cap-add=NET_RAW
A specific device	--device=/dev/ttyUSB0
Set the system clock	--cap-add=SYS_TIME
Mount filesystems, FUSE	--cap-add=SYS_ADMIN — treat this as privileged

CAP_SYS_ADMIN is worth its own warning: it is so broad it is sometimes called “the new root”. Granting it is not a meaningful improvement on --privileged — if you find you need it, the design is what needs revisiting.

Verify it worked

Find every privileged container running right now:

docker ps -q | xargs -r docker inspect \
  --format '{{.Name}}: privileged={{.HostConfig.Privileged}}' | grep -v false

Any output is a container with no isolation from your host.

Check for the softer versions of the same thing:

docker ps -q | xargs -r docker inspect --format \
  '{{.Name}} caps_add={{.HostConfig.CapAdd}} seccomp={{.HostConfig.SecurityOpt}} pid={{.HostConfig.PidMode}} net={{.HostConfig.NetworkMode}}'

Look for SYS_ADMIN in CapAdd, seccomp=unconfined or apparmor=unconfined in SecurityOpt, and pid=host or net=host — each gives up a boundary, and together they add up to --privileged without using the word.

Grep your compose files, which is where it usually lives:

grep -rn 'privileged:\s*true\|--privileged\|seccomp=unconfined\|SYS_ADMIN' \
  --include='*.yml' --include='*.yaml' .

Then prove the confinement is real — inside a hardened container this should fail:

docker exec <container> sh -c 'mount -t tmpfs none /mnt'

Expect permission denied. If it mounts, the container has SYS_ADMIN or privilege.

Before you apply this

Removing --privileged breaks the thing it was added for, and the failure is usually an opaque operation not permitted deep in the application rather than a clear message about capabilities.

Don’t remove it blind. Find the requirement first:

1. Run a copy with --cap-drop=ALL and see how it fails.

2. strace -f -e trace=all inside the container, or check dmesg on the host — the denied syscall or AppArmor denial is logged there:

   sudo dmesg | grep -iE 'apparmor|audit' | tail -20

3. Add the specific capability. Re-test. Repeat until it works.

Docker-in-Docker deserves a real decision. If a CI job builds images with a privileged DinD service, the privileged container is holding your build secrets and can reach the host. Moving to a rootless builder (BuildKit’s rootless image, or Kaniko) removes the need entirely. That’s a change to your CI config, not a container flag — budget accordingly rather than doing it under time pressure.

Existing containers keep their settings. Changing the compose file does nothing until docker compose up -d --force-recreate. Verify with docker inspect after, not before — a config file is a claim, inspect is the fact.

Related

• Drop capabilities — what to grant instead.
• Container escape — where a privileged container ends up.