Does Docker use a seccomp profile by default?

Yes. Unless you override it, Docker runs each container with a built in seccomp profile. It is an allowlist that blocks around 44 of the 300 plus Linux system calls, and a blocked call returns a permission denied error. Docker's own documentation advises against changing that default profile.

What a seccomp profile is

Secure computing mode, or seccomp, is a Linux kernel feature that restricts which system calls a process may make. A system call is how a program asks the kernel to do something, such as opening a file or loading a kernel module. If a compromised container cannot make a risky call, a whole class of kernel exploits is out of reach.

Docker's profile works as an allowlist. The default action is SCMP_ACT_ERRNO, which causes a permission denied error, and the profile then names the calls that are explicitly allowed. A few calls are allowed only with particular arguments.

What the default profile blocks

Docker's page lists the significant calls that are not on the allowlist, with a reason for each. A few examples:

The page says the table is a list of significant calls, not every blocked call. The profile is described as moderately protective while keeping wide application compatibility, so it is a floor and not a complete sandbox.

How to confirm it is on

Seccomp support needs a kernel built with CONFIG_SECCOMP and a Docker build that includes it. To check the kernel:

grep CONFIG_SECCOMP= /boot/config-$(uname -r)

A result of CONFIG_SECCOMP=y means support is present. Then run docker info and look at the Security Options section. A host using the default shows a seccomp line with profile builtin. In Docker's own rootless example the output reads seccomp Profile: builtin.

How it gets switched off

The profile applies unless someone passes a security option. These are the forms to look for in scripts, Compose files and dev container settings:

# custom profile
docker run --security-opt seccomp=/path/to/profile.json IMAGE

# no seccomp filtering at all
docker run --security-opt seccomp=unconfined IMAGE

Docker's own example of the unconfined case runs unshare with a user namespace, which the default profile would normally block. That shows what you give up: calls the default profile exists to refuse become available to code inside the container.

Dev tooling sometimes asks for unconfined seccomp so that debuggers work. The Dev Containers reference gives that exact combination as an example for C++ debugging. If you see it in a repository, treat it as a decision to review, not a harmless default.

A short review routine

1. Search your repositories for seccomp=unconfined and --privileged.
2. For each hit, write down why it is there and who owns it.
3. Try the workload on the default profile and see what breaks.
4. If something genuinely needs a call, prefer a custom profile that adds only that call over turning filtering off.

For how seccomp fits with capabilities and the no new privileges flag, see the three switches explained.

Safeguard does not change how your runtime is configured. It can scan the dependencies and images that go into a container, and you can try a free scan at gold.safeguard.sh/scan.

Quick check

Sources

• Seccomp security profiles for Docker, Docker Docs
• Rootless mode, Docker Docs
• devcontainer.json reference, containers.dev

Last reviewed: 19 October 2026.