In this lesson, you will learn how to minimize the attack surface of your containers by replacing the "all-or-nothing" root model with discrete, fine-grained Linux capabilities.
The Problem with Traditional Root
By default, a container running as root possesses all kernel privileges, effectively making it a full administrator of the host system if the isolation layers (like User Namespaces or Seccomp filters) are breached. When we talk about "Privilege Escalation" in this context, we are looking at ways an attacker might use these blanket permissions to escape the container, modify kernel parameters, or gain access to hardware devices.
The Capability Model
Linux Capabilities break down the monolithic power of the superuser into distinct units. Instead of granting a container total control, we can drop unnecessary capabilities or grant only the bare minimum required for the application to function. For example, a web server might only need CAP_NET_BIND_SERVICE to listen on ports below 1024, rather than needing full CAP_SYS_ADMIN to manipulate the network stack or mount filesystems.
Practical Application
When you define a container configuration, you should adopt a "drop-all" strategy and explicitly whitelist only the capabilities required for the task. This restricts the potential damage if a service is compromised.
# Example: Running a container with only specific networking capability
docker run --cap-drop=ALL --cap-add=NET_BIND_SERVICE my-web-app
By dropping CAP_SYS_ADMIN, CAP_SYS_PTRACE, and CAP_DAC_OVERRIDE, you neutralize the most common vectors for container escapes. Even if an attacker gains shell access inside the container, they cannot perform administrative tasks like mounting block devices or injecting code into processes outside their specific PID namespace.
Capabilities serve as a critical secondary defense. When combined with the namespaces we studied previously—such as mapping the container root to a non-privileged host user via User Namespaces—the ability for an attacker to escalate privileges becomes significantly limited, even if a vulnerability in the application exists.
Key Takeaway: Adopting a least-privilege approach by stripping all unnecessary Linux capabilities reduces the blast radius of a container breakout and prevents unauthorized escalation to the host kernel.