Seccomp limits which system calls a process can make. Capabilities split root's power into separate pieces a process can hold or lack. No new privileges stops a process gaining extra privilege when it runs a new program. They guard different things, so a hardened container usually sets all three.
The three switches side by side
| Switch | Question it answers | Typical setting |
|---|---|---|
| Seccomp | Which system calls may this process make? | Docker's default allowlist profile |
| Capabilities | Which parts of root's power does this process hold? | Drop all, add back only what is needed |
| No new privileges | Can this process gain privilege by running another program? | Enabled with a security option |
Seccomp: filtering the calls
A seccomp filter is attached to a process and inspects every system call it makes. The kernel manual describes several outcomes a filter can return, such as allow, log, return an error, or kill the process. Docker's default profile denies by default and allows a named list. Read the default profile explainer for the blocked calls.
Capabilities: slicing up root
Docker's security page explains that capabilities turn the root or non root choice into fine grained access control. A web server that only needs to bind a port below 1024 can be given the net_bind_service capability instead of running with full root powers. Docker keeps a default list for containers, and a separate list of capabilities that are off by default and may be added. The practical guide is in drop all, add back what you need.
No new privileges: closing the exec door
The Docker run reference says the no new privileges option disables container processes from gaining new privileges, so commands that raise privilege, such as su or sudo, no longer work. It adds that seccomp filters are then applied after privileges have been dropped, which may allow a more restrictive set of filters.
The kernel manual explains the origin of the rule. To install a seccomp filter without the CAP_SYS_ADMIN capability, a thread must already have the no_new_privs bit set. The stated reason is that otherwise an unprivileged process could apply a hostile filter and then run a set user ID program, which might misbehave under that filter. More on the flag in what no new privileges blocks.
How they combine
Imagine a compromised process in a container. Seccomp reduces the kernel calls it can try. Dropped capabilities mean that the calls still allowed do less. No new privileges means it cannot climb by launching a set user ID helper inside the container. No single layer is complete, and the three work best together with a non root user and a read only filesystem.
A run command that sets all three looks like this:
docker run --rm \
--cap-drop ALL \
--security-opt no-new-privileges \
--security-opt seccomp=builtin \
IMAGE
Docker notes that seccomp=builtin selects the default built in profile, which is useful when a daemon has a custom default or seccomp disabled. Test the workload after each change so a failure points at one setting.
What none of them does
All three act inside the host kernel. A kernel bug in an allowed path can still be reachable. For code you do not trust at all, look at an application kernel or a virtual machine boundary, and read how those compare.
Safeguard does not configure runtime isolation. It scans dependencies and images and can enforce policy gates in CI, with a free scan at gold.safeguard.sh/scan.
Quick check
If I drop all capabilities, do I still need seccomp?
Yes. Capabilities gate privileged operations, while seccomp removes entire system calls from reach. They overlap in places but are not substitutes.
Will no new privileges break sudo inside the container?
Yes, by design. Docker says commands that raise privileges, such as su or sudo, no longer work once it is set.
Sources
- Running containers, Docker Docs
- Docker security, Docker Docs
- seccomp(2), man7.org
- Seccomp security profiles for Docker, Docker Docs
Last reviewed: 19 October 2026.
