Reviewing Docker Seccomp Profiles by Capability, Not Copying One

The default Docker seccomp profile is an allowlist of Linux system calls. It blocks many less common calls while allowing those needed by normal container workloads. A custom profile can tighten that set, but it can also create a false sense of safety. The useful question is which syscall authority the workload genuinely needs, and how the team will detect a profile change that silently broadens it.

Docker documents that a container can use the default profile, a custom profile, or unconfined. The last option removes this layer. Some applications also need capabilities that adjust the profile's behavior. A profile copied from a tutorial may block a call used only under error handling, only on a different CPU architecture, or only after a package upgrade. Tightening without testing can produce outages; leaving it unconfined can remove an important containment layer.

Start with the workload contract

Map the process tree, required files, network operations, and device access for a representative workload. The default profile is a reasonable baseline for many services. Build a custom profile only when the workload has a known gap or when the team can justify a narrower set. Keep the profile in version control with the image and runtime configuration.

Do not add a system call merely because a one-off diagnostic command needs it in an interactive shell. Run diagnostics in a separate environment with a documented exception. Treat --privileged as a separate, high-risk change rather than a shortcut for a missing capability.

Test the profile as a deployment artifact

Run the application's integration tests under the exact profile and runtime version used in production. Exercise startup, graceful shutdown, health checks, error paths, and file operations. Include at least one negative test that should be denied. Capture the audit or runtime evidence without logging sensitive application data.

Monitor image and runtime upgrades. A new library may call a syscall that the prior version did not. A kernel upgrade can change behavior even when the application image is unchanged. Pin the runtime and seccomp profile together, and require an explicit review when either changes.

Check that the deployment cannot override the profile through an untrusted workload manifest. Policy at the orchestration layer should reject seccomp=unconfined and unexpected profile paths. If the platform permits custom profiles, validate their content and ownership before scheduling the workload.

Treat exceptions as security changes

An emergency exception should have an owner, a reason, an expiry, and a monitoring plan. Record which calls were blocked and what evidence justified the change. Do not leave a broad profile in place because the application happened to work. Re-test after the incident and restore the narrower profile when possible.

Seccomp limits system-call access. It does not replace a read-only file system, non-root execution, dropped capabilities, network policy, or patched images. Those controls cover different failure paths. A good review explains the narrow property each layer provides.

The practical outcome is a profile that matches a known workload and can be reproduced in CI. If the team cannot explain why a syscall is allowed, that is a review finding. The same applies to a profile that is never tested after the runtime changes.

References

• Docker, Seccomp security profiles for Docker
• Docker, docker container run
• Kubernetes, Linux kernel security constraints for Pods and containers