Is Docker’s Root Really Safe? Exploring Linux Capabilities and Container Security

Docker container root and host root

Docker containers share the same UID 0 for root inside the container and on the host, raising concerns about whether container root can affect other containers or the host.

Although the root user inside a container maps to the host's root, Docker uses Linux capabilities to create a large permission gap.

Capabilities allow fine‑grained control; by omitting the

--privileged

flag, containers run with a limited set of capabilities.

<code>docker run -it --privileged=false ubuntu:14.04 /bin/bash
# or
docker run -it ubuntu:14.04 /bin/bash</code>

To grant full privileges, set

--privileged=true

:

<code>docker run -it --privileged=true ubuntu:14.04 /bin/bash</code>

Additional flags

--cap-add

and

--cap-drop

let users flexibly modify capabilities.

Linux Capabilities

Traditional Unix distinguishes privileged (UID 0) and non‑privileged processes. Linux splits the superuser’s powers into many capabilities, each controlling a specific permission.

Key capabilities include:

CAP_SYS_ADMIN : system administration tasks such as disk quotas, mounting filesystems, creating namespaces.

CAP_NET_ADMIN : network configuration, firewall, routing.

CAP_SETUID : modify process UIDs.

CAP_SYS_MODULE : load or unload kernel modules.

CAP_SYS_NICE : adjust scheduling, priority, CPU affinity.

There are roughly 40 capabilities, meaning not all root privileges are identical.

Docker containers and Linux Capabilities

By default Docker enables only 14 basic capabilities, excluding powerful ones like

CAP_SYS_ADMIN

and

CAP_NET_ADMIN

, so container root cannot perform many system‑level actions.

In non‑privileged mode, Docker’s root lacks capabilities for disk quotas, mounts, namespace creation, and network administration.

Privileged mode

When

--privileged=true

is used, Docker grants 37 capabilities, effectively giving the container root full kernel management rights, which raises security concerns.

Comparing the two modes

Choosing between security and permission is a trade‑off, especially in public‑cloud scenarios where PaaS may tolerate limited system access, but CaaS often requires broader capabilities.

Docker and Linux User Namespace

Support for Linux User Namespaces would map container root to a non‑zero UID on the host, turning it into an ordinary user while still allowing capabilities inside the container, greatly mitigating security risks.

Summary

Docker container root security is not as vulnerable as it seems; Linux capabilities provide a nuanced permission model. Future support for User Namespaces promises a significant reduction in the security‑vs‑permission dilemma.