Restricting Container Capabilities: Reducing the Kernel Attack Surface in Docker

When you run a container in Docker, it shares the host’s Linux kernel. This is an efficient and powerful model, but it comes with inherent risks. Because containers can interact with the kernel, any excessive or unneeded privileges granted to them become potential avenues for attack. That is where Linux capabilities come in. By understanding and controlling these capabilities, you can significantly reduce the container’s power and shrink the attack surface it presents to the system.

Linux capabilities are a set of fine-grained privileges that split up the all-powerful root role into distinct functional units. Rather than giving a container full root access, Docker allows it to operate with only a subset of these capabilities by default. For example, capabilities control whether a process can perform actions like modifying network interfaces, loading kernel modules, or changing file ownership.

Docker removes many of these capabilities automatically when running a container, but depending on your application or configuration, you may still be running with more access than necessary. One of the most effective security strategies you can apply is the principle of least privilege: only grant the specific capabilities your container needs to function, and drop everything else.

To implement this, you can use the --cap-drop and --cap-add flags when starting containers. For example, if your application does not need to manipulate network settings, you can explicitly drop the NET_ADMIN capability. Similarly, if it never spawns new user sessions or manages process priorities, you can drop capabilities like SYS_ADMIN or SYS_NICE. On the other hand, if a container does need specific privileges for its intended purpose — like packet sniffing or firewall rules — you can add only those capabilities with a clear understanding of the trade-offs.

Let us take a closer look at a few dangerous capabilities that should usually be removed:

• SYS_ADMIN: This is one of the most powerful capabilities, often described as a “root of capabilities” because it grants access to a wide array of privileged operations. Unless absolutely necessary, containers should never have this enabled.
• NET_RAW: Allows raw socket access, which is useful for creating custom network packets. This can be abused for scanning or crafting malicious traffic, and should be removed unless your container is explicitly performing network diagnostics.
• MKNOD: Permits creation of device files, which could be exploited to interfere with host hardware if not properly contained.
• SYS_MODULE: Enables loading and unloading kernel modules. Containers should never be allowed this unless they are specifically designed for kernel development.

Beyond simply dropping capabilities, you can also leverage seccomp profiles to control system call access at a more granular level. Docker uses a default seccomp profile that blocks some dangerous calls, but you can define your own custom policies to lock down your containers even further. This combination of limited capabilities and restricted syscalls forms a strong barrier between containers and the host system.

It is also worth noting that some capabilities interact in unexpected ways. A container with CAP_DAC_OVERRIDE can bypass file permission checks, potentially exposing sensitive data. CAP_SYS_PTRACE can be used to inspect and manipulate other processes, which is useful for debugging but dangerous in multi-tenant environments. Always evaluate the security implications of each capability and consider whether it aligns with your container’s role.

You can inspect the active capabilities of a running container using tools like capsh, pscap, or by reading from /proc/<pid>/status. This helps verify that your containers are running with the appropriate restrictions in place.

Another technique for tightening container security is to run them with user namespaces and as non-root users. Even if a container has some capabilities, if it is not running as root, the scope of potential damage is much smaller. Combining user-level isolation with capability restrictions ensures multiple layers of defense.

In production environments, automating these restrictions is crucial. Infrastructure as code tools like Docker Compose and Kubernetes allow you to define capabilities and security settings declaratively. This ensures that restrictions are consistently applied and easy to audit.

Hardening containers through capability management should become a standard part of your development and deployment process. It is not enough to build a container that works — it needs to work securely, even under adverse conditions. Reducing privileges makes it harder for attackers to succeed, limits the blast radius of potential exploits, and aligns your workloads with modern security standards.

If you want to learn how to apply these techniques and many more in real-world deployments, take a look at my comprehensive 20-page PDF, Mastering Security & Isolation in Docker Like a Pro. Whether you are a developer, DevOps engineer, or security professional, this guide covers everything you need to confidently build, deploy, and manage secure containerized applications. Dive deep into best practices for hardening Docker images, enforcing runtime protections, securing Kubernetes clusters, implementing advanced policies, and preparing for incident response. Packed with practical examples and actionable insights, this resource empowers you to safeguard your containers and infrastructure against evolving threats without sacrificing performance or scalability.

If you found this article useful and want to support more work like this, please consider buying me a coffee. Your support helps me keep creating focused, helpful content for developers and security professionals alike.