DEV Community

Cover image for Seccomp in Docker: Locking Down System Calls for a Leaner Attack Surface
HexShift
HexShift

Posted on

Seccomp in Docker: Locking Down System Calls for a Leaner Attack Surface

While containers offer a convenient and efficient way to package applications, they still share the host’s kernel, which introduces a set of security concerns. Every process inside a container has the potential to make system calls to the host kernel, and that opens the door to possible exploitation. Docker’s support for seccomp (short for secure computing mode) provides a vital mechanism for limiting the system calls that containers are allowed to make. This significantly reduces the potential for abuse if a container is ever compromised.

Seccomp works by allowing or denying specific system calls made by processes. Linux exposes hundreds of system calls, but the vast majority of containerized applications only need a small subset to function. By filtering out unnecessary or dangerous system calls, seccomp acts as a protective gatekeeper between the container and the underlying operating system. If a container tries to make a call that is not allowed by the seccomp profile, it is immediately blocked, preventing potential damage.

Docker uses a default seccomp profile that blocks a range of high-risk system calls, including those that can be used for kernel module loading, raw socket manipulation, and process tracing. This default profile is a solid starting point for general-purpose workloads, providing security enhancements with minimal disruption. However, for high-assurance environments or particularly sensitive applications, creating custom seccomp profiles can provide much tighter control.

Custom seccomp profiles are defined in JSON format. Each profile specifies a list of allowed or denied system calls, along with the conditions under which they can be made. For example, you might allow the read, write, and exit calls but deny dangerous ones like ptrace, mknod, or clone with untrusted flags. These profiles can then be passed to Docker when starting a container.

Crafting a custom profile may seem daunting at first, but many tools and templates exist to help you get started. Begin with the default profile and remove system calls that your application does not need. Use monitoring tools or system call tracing utilities to identify which calls are actually used during runtime. With some trial and observation, you can create minimal, highly restrictive profiles that suit your workloads.

Seccomp is especially effective when combined with other Linux security modules like AppArmor or SELinux. While AppArmor controls access to files and resources, and namespaces isolate users and networks, seccomp provides a low-level layer of defense that targets kernel-level interaction. It is this layered approach — defense in depth — that makes containerized workloads robust and resilient to exploitation.

In practice, seccomp provides valuable protection against many classes of container escape and privilege escalation attacks. Exploits that rely on dangerous system calls can be fully neutralized by simply excluding them. Even advanced attack chains that succeed in injecting code into a container often fail to progress if the necessary system calls are blocked.

One of the great strengths of seccomp is its performance. Because it operates at the kernel level and uses simple allow or deny logic, it imposes virtually no runtime overhead. This means you can harden your containers significantly without sacrificing speed or scalability — an ideal outcome for modern applications.

It is worth noting that not all container runtimes implement seccomp equally. Docker supports it natively on Linux, but certain Kubernetes deployments or alternative runtimes may require additional configuration. Ensure that your orchestration stack is capable of enforcing seccomp and test your workloads accordingly.

Ultimately, seccomp profiles help enforce the principle of least privilege at the kernel interface. Containers should only have access to the exact system functionality they require — nothing more. By taking the time to tune these permissions, you protect not just the container, but the host system and all other running workloads from cross-container attacks.

If you want to learn more about strengthening container security and building production-grade protection for your infrastructure, check out my detailed 20-page guide, Mastering Security & Isolation in Docker Like a Pro. This in-depth resource walks you through proven strategies for hardening images, defending Kubernetes environments, controlling runtime behavior, and preparing for real-world incidents. It is packed with hands-on techniques and insights for developers, DevOps teams, and security professionals.

If you find these articles useful and would like to support more high-quality technical content, feel free to buy me a coffee. Your support helps keep this work going and makes it possible to continue sharing practical, actionable advice with the community.

Top comments (0)