Capabilities and privilege control in Docker - Deep Dive

Overview - Capabilities and privilege control

What is it?

Capabilities and privilege control in Docker are ways to limit or grant specific permissions to containers. They control what a container can do on the host system, like accessing devices or changing network settings. This helps keep containers safe by only allowing necessary actions. Without this, containers might have too much power and cause security risks.

Why it matters

Without controlling capabilities and privileges, containers could perform harmful actions on the host, like accessing sensitive files or disrupting network traffic. This could lead to security breaches or system crashes. Proper control ensures containers run safely, protecting the host and other containers. It also helps follow the principle of least privilege, reducing attack surfaces.

Where it fits

Before learning this, you should understand basic Docker concepts like containers, images, and how Docker runs processes isolated from the host. After this, you can learn about Docker security best practices, user namespaces, and advanced container isolation techniques.

Mental Model

Core Idea

Capabilities and privilege control are like giving containers only the keys they need to do their job, no more, no less.

Think of it like...

Imagine a hotel where guests get keys only to their own room and the lobby, not to the manager's office or other guests' rooms. Capabilities control which doors a container can open on the host system.

┌─────────────────────────────┐
│        Host System          │
│ ┌───────────────┐          │
│ │ Capabilities  │          │
│ │ & Privileges  │          │
│ └──────┬────────┘          │
│        │                   │
│  ┌─────▼─────┐             │
│  │ Container │             │
│  │  Process  │             │
│  └───────────┘             │
└─────────────────────────────┘

Capabilities act as keys that control what the container process can do on the host.

Build-Up - 7 Steps

1

Foundation

What are Linux capabilities

Concept: Linux capabilities break down root privileges into smaller, specific permissions.

Linux does not treat root as a single all-powerful user anymore. Instead, it splits root powers into capabilities like CAP_NET_ADMIN (network control) or CAP_SYS_TIME (change system time). Processes can have some capabilities without full root access.

Result

Processes can run with only the permissions they need, improving security.

Understanding Linux capabilities is key because Docker uses them to control container permissions precisely.

2

Foundation

Docker containers and default capabilities

Concept: Docker containers start with a default set of capabilities to balance functionality and security.

By default, Docker gives containers a limited set of capabilities, enough to run most apps but not full root powers. For example, CAP_CHOWN (change file ownership) is included, but CAP_SYS_ADMIN (powerful admin tasks) is not.

Result

Containers can perform common tasks but are restricted from dangerous actions by default.

Knowing Docker's default capabilities helps you understand what containers can do out of the box.

3

Intermediate

Adding and dropping capabilities in Docker

🤔Before reading on: do you think adding capabilities increases or decreases container security? Commit to your answer.

Concept: Docker lets you add or remove capabilities to customize container permissions.

You can add capabilities with --cap-add and remove them with --cap-drop when running containers. For example, docker run --cap-add=NET_ADMIN adds network admin rights. Dropping capabilities reduces what the container can do.

Result

You control container powers precisely, improving security or enabling needed features.

Knowing how to add or drop capabilities lets you tailor container permissions to your app's needs.

4

Intermediate

Understanding privileged containers

🤔Before reading on: does running a container as privileged give it full root on the host? Commit to your answer.

Concept: Privileged containers get almost all capabilities and can access host devices.

Running docker with --privileged gives the container nearly all Linux capabilities and access to devices like /dev. This is useful for special cases but is risky because it breaks isolation.

Result

Privileged containers can do almost anything on the host, which can be dangerous.

Understanding privileged mode helps you avoid security risks by using it only when absolutely necessary.

5

Intermediate

Capability sets and security profiles

Concept: Docker can use security profiles like seccomp to further restrict capabilities.

Docker applies a default seccomp profile that blocks dangerous syscalls even if capabilities allow them. You can customize or disable seccomp to change this behavior. This adds another layer of control beyond capabilities.

Result

Containers are protected from risky system calls, improving security.

Knowing about seccomp shows how capabilities fit into a bigger security system.

6

Advanced

How capabilities affect container isolation

🤔Before reading on: do capabilities control only container processes or also the Docker daemon? Commit to your answer.

Concept: Capabilities control what container processes can do, but the Docker daemon runs with full host privileges.

Capabilities limit container processes but do not restrict the Docker daemon itself. If a container escapes isolation, it might exploit the daemon's privileges. Therefore, capability control is one part of container security.

Result

You see that capabilities protect container processes but not the whole system.

Understanding this boundary helps you design layered security, not relying on capabilities alone.

7

Expert

Surprising effects of capability combinations

🤔Before reading on: can dropping one capability accidentally disable unrelated container features? Commit to your answer.

Concept: Some capabilities interact in complex ways, causing unexpected behavior when changed.

For example, dropping CAP_NET_RAW disables ping inside containers, but also affects other network tools. Adding CAP_SYS_ADMIN grants many powers, sometimes more than expected. Experts test capability changes carefully to avoid breaking apps.

Result

Capability changes can have hidden side effects beyond the obvious.

Knowing these interactions prevents accidental container failures and security holes.

Under the Hood

Linux capabilities split root privileges into distinct bits stored in process flags. The kernel checks these bits before allowing privileged operations. Docker sets these bits for container processes based on requested capabilities. Privileged containers get all bits set, while normal containers get a default subset. The Docker daemon manages these settings and enforces isolation using namespaces and cgroups.

Why designed this way?

Originally, root was all-powerful, which was risky. Linux introduced capabilities to reduce this risk by granting only needed powers. Docker adopted this model to improve container security and flexibility. Alternatives like full root or no privileges were too risky or too limiting.

┌───────────────┐
│ Linux Kernel  │
│  ┌─────────┐  │
│  │Capability│  │
│  │Checks   │  │
│  └────┬────┘  │
│       │       │
│  ┌────▼────┐  │
│  │Process  │  │
│  │Flags    │  │
│  └────┬────┘  │
│       │       │
│  ┌────▼────┐  │
│  │Container│  │
│  │Process  │  │
│  └─────────┘  │
└───────────────┘

Docker sets process flags to control capabilities inside containers.

Myth Busters - 4 Common Misconceptions

Quick: Does running a container with --privileged mean it has full root access on the host? Commit yes or no.

Common Belief: Privileged containers have full root access on the host system.

Reality: Privileged containers have almost all capabilities but still run inside container isolation layers like namespaces, so they do not have direct root on the host.

Why it matters: Thinking privileged means full host root can cause unnecessary fear or misuse of privileged mode.

Quick: If you drop CAP_NET_ADMIN, can the container still change network settings? Commit yes or no.

Common Belief: Dropping a capability only removes that exact permission and nothing else.

Reality: Dropping some capabilities can disable multiple related features, causing broader effects than expected.

Why it matters: Misunderstanding this can break container apps unexpectedly.

Quick: Does adding capabilities always increase container security? Commit yes or no.

Common Belief: Adding capabilities makes containers more secure by giving them needed powers.

Reality: Adding capabilities increases container powers and can reduce security if not carefully controlled.

Why it matters: Assuming more capabilities equals more security leads to risky container setups.

Quick: Can the Docker daemon's privileges be limited by container capabilities? Commit yes or no.

Common Belief: Container capabilities also restrict the Docker daemon's permissions.

Reality: Capabilities only affect container processes, not the Docker daemon, which runs with full host privileges.

Why it matters: Ignoring this can lead to overconfidence in container security.

Expert Zone

1

Some capabilities like CAP_SYS_ADMIN are very broad and effectively grant root-like powers, so adding them should be done with extreme caution.

2

The default Docker seccomp profile blocks many syscalls even if capabilities allow them, creating a layered security model.

3

Capability changes can interact with user namespaces and AppArmor/SELinux profiles, affecting overall container security in complex ways.

When NOT to use

Avoid using --privileged or adding broad capabilities in production unless absolutely necessary. Instead, use fine-grained capability additions, user namespaces, and security profiles like seccomp and AppArmor for safer isolation.

Production Patterns

In production, teams start with Docker's default capabilities, then add only specific capabilities needed by the app. Privileged mode is reserved for special cases like device access or system management containers. Security profiles are customized to block risky syscalls while allowing required functionality.

Connections

Principle of Least Privilege

Capabilities implement this principle in container security by granting minimal necessary permissions.

Understanding capabilities helps apply least privilege in software design and system administration.

Operating System Access Control

Capabilities are a form of OS-level access control similar to user permissions and ACLs.

Knowing OS access control models clarifies how capabilities fit into broader security frameworks.

Physical Security Keycards

Both control access by granting specific permissions rather than full access.

Recognizing this pattern across domains helps design secure systems by limiting access precisely.

Common Pitfalls

#1 Giving containers full privileges unnecessarily.

Wrong approach:

docker run --privileged mycontainer

Correct approach:

docker run --cap-add=NET_ADMIN --cap-drop=SYS_ADMIN mycontainer

Root cause:

Misunderstanding that privileged mode is a blunt tool that grants excessive powers instead of fine-tuning capabilities.

#2 Assuming dropping one capability only affects that feature.

Wrong approach:

docker run --cap-drop=NET_ADMIN mycontainer # expecting only network admin disabled

Correct approach:

Test container behavior after dropping capabilities and adjust accordingly; consider dropping related capabilities if needed.

Root cause:

Not realizing capabilities can have overlapping effects on container features.

#3 Ignoring Docker daemon privileges when securing containers.

Wrong approach:

Relying solely on container capabilities for security.

Correct approach:

Combine capability control with daemon security best practices, user namespaces, and security profiles.

Root cause:

Believing container capabilities protect the entire system including the Docker daemon.

Key Takeaways

Linux capabilities break root powers into smaller permissions that Docker uses to control container actions.

Docker containers start with a safe default set of capabilities but can be customized with --cap-add and --cap-drop.

Privileged containers get almost all capabilities and access to host devices, which is risky and should be avoided unless necessary.

Capabilities control container process permissions but do not limit the Docker daemon itself, so layered security is essential.

Changing capabilities can have unexpected side effects, so always test container behavior after modifications.