Process Capabilities Mapping

Identify which system-level operations require specific kernel capabilities.

In this lesson, you will learn how to map specific system-level operations to their corresponding kernel capabilities, allowing you to move away from the "all-or-nothing" root user model.

The Problem with Root

Historically, Linux binary permissions were binary: you were either a normal user or the superuser (root), who could do everything. This created a massive security risk, as a compromised process running as root had unrestricted access to the entire kernel. Capabilities divide the power of "root" into distinct, granular privileges that can be independently assigned to a process.

Mapping Operations to Capabilities

To secure your containers, you must identify exactly which system calls a process needs and map them to their required capability. If a process does not have the capability, the kernel will deny the request even if the process is running as root.

For example, consider common containerized operations:

Changing file ownership: If a process needs to use chown(), it requires CAP_CHOWN.
Binding to privileged ports (< 1024): If a web server needs to bind to port 80, it requires CAP_NET_BIND_SERVICE.
Setting system time: If a process needs to call adjtimex(), it requires CAP_SYS_TIME.

Implementation Illustration

When you configure a container runtime, you define the "Capability Set." Instead of granting full privileges, you drop all capabilities and add back only those mapped to the task:

# Example of restricting a process to only net_bind_service
# CAP_NET_BIND_SERVICE allows binding to ports < 1024
# All other root privileges are revoked.
docker run --cap-drop=ALL --cap-add=NET_BIND_SERVICE nginx

If you attempt to perform an action not mapped to your assigned capabilities—such as attempting to change the system clock from within this specific container—the kernel will return an EPERM (Operation not permitted) error, successfully trapping the unauthorized request at the syscall interface. Mapping these correctly is the primary defense against container breakout attacks.

Key Takeaway: Process capability mapping replaces monolithic superuser authority by explicitly linking privileged kernel operations to specific, granular capability bits.