Drop Docker capabilities and set no-new-privileges

The fix

docker run \
  --cap-drop=ALL \
  --security-opt=no-new-privileges:true \
  myimage

services:
  app:
    cap_drop: [ALL]
    security_opt:
      - no-new-privileges:true

Add back only what fails without.

Why it matters

A default Docker container isn’t unprivileged — it gets a default set of around fourteen capabilities, whether or not the workload uses any of them. A Node app serving HTTP holds CAP_CHOWN, CAP_SETUID, CAP_SETGID, CAP_NET_RAW, CAP_DAC_OVERRIDE and others, permanently, for no reason.

Each is a tool waiting for an attacker who gets code execution:

• CAP_DAC_OVERRIDE — bypass file permission checks entirely. Read any file in the container regardless of mode.
• CAP_SETUID / CAP_SETGID — become any user, which turns a compromise of your unprivileged app user into container root.
• CAP_NET_RAW — craft raw packets. Enables ARP spoofing against other containers on the same bridge network.
• CAP_CHOWN — change file ownership, including on bind mounts.

--cap-drop=ALL removes the lot. Most containers need nothing added back, because most containers just run a process and listen on a socket.

no-new-privileges is the cheapest line here

--security-opt=no-new-privileges:true

This sets the kernel’s no_new_privs bit, which means a process can never gain privileges through execve — setuid binaries stop working as an escalation path.

It matters because dropping capabilities from the container doesn’t stop a setuid binary inside the image from re-elevating. If your image ships sudo, su, ping, mount, or any distro package with a setuid bit, an attacker who lands as your unprivileged user can potentially use it. no_new_privs closes that door for everything at once, and it breaks essentially nothing — no normal application gains privileges through exec.

If you set one flag from this page, set this one.

You can also just remove the setuid bits at build time:

RUN find / -xdev -perm /6000 -type f -exec chmod a-s {} + || true

Which ones you might actually need

Need	Capability
Bind port < 1024	NET_BIND_SERVICE — but prefer a high port + -p 80:8080
ping	NET_RAW — or just don’t ping from production containers
Change file ownership at startup	CHOWN — better: fix it at build time
Drop from root to a service user at startup	SETUID, SETGID — better: use USER

Note how many entries say “better”. Most capability requirements are a consequence of the container starting as root and then de-escalating — a pattern that USER in the Dockerfile removes entirely. Fix that and the capability list usually collapses to nothing.

Verify it worked

Check what your containers currently carry:

docker ps -q | xargs -r docker inspect \
  --format '{{.Name}} drop={{.HostConfig.CapDrop}} add={{.HostConfig.CapAdd}}'

drop=[] means the full default set is present.

Look inside a running container at what it actually holds:

docker exec <container> sh -c 'grep CapEff /proc/self/status'

Decode it — this is the definitive answer:

docker run --rm --cap-drop=ALL alpine sh -c 'grep CapEff /proc/self/status'
# CapEff: 0000000000000000    <- nothing. This is the goal.

Any non-zero value is capabilities you’re carrying. Compare with a default container to see the difference:

docker run --rm alpine sh -c 'grep CapEff /proc/self/status'
# CapEff: 00000000a80425fb    <- the default ~14

Confirm no_new_privs is set:

docker exec <container> sh -c 'grep NoNewPrivs /proc/self/status'

Expect NoNewPrivs: 1.

Find setuid binaries lurking in an image:

docker run --rm --entrypoint sh myimage -c 'find / -xdev -perm /6000 -type f 2>/dev/null'

Every result is an escalation candidate that no_new_privs neutralises.

Before you apply this

--cap-drop=ALL breaks containers that de-escalate at startup, which is a very common pattern: the image starts as root, binds port 80, chowns a data directory, then drops to a service user. That sequence needs NET_BIND_SERVICE, CHOWN, SETUID and SETGID — so dropping everything stops it dead, usually with a message from an entrypoint script rather than a clear capability error.

nginx, postgres and redis official images all do some version of this.

Find the requirement rather than guessing:

docker run --rm --cap-drop=ALL myimage 2>&1 | head -20
sudo dmesg | grep -i 'apparmor\|audit' | tail

Then add back the specific capability, or — better — use an image variant that starts unprivileged. Many official images now ship one, and the nginxinc/nginx-unprivileged style images exist precisely for this.

no-new-privileges is safe for essentially everything, with one real exception: containers that legitimately use sudo or a setuid helper at runtime. That’s rare in production and usually a smell — but it does break, and the failure is sudo: effective uid is not 0, which reads like a broken sudo install rather than a policy decision.

Existing containers keep their settings. docker compose up -d --force-recreate and then verify with docker inspect, because the config file is a claim and inspect is the fact.

Related

• Never run with –privileged — the flag that grants all of these at once.
• Run containers as a non-root user — removes most reasons to need any.