User Namespace Remapping

The core mechanism maps a container's root user (UID 0) to a high-numbered, unprivileged UID on the host (e.g., UID 65536). This means a process running as root inside the container has zero superuser privileges on the host kernel. If an attacker achieves a container breakout via a kernel exploit, they land on the host not as the all-powerful root user, but as an unprivileged user with no access to critical system files, devices, or other processes.

The mapping relies on subordinate ID ranges defined in /etc/subuid and /etc/subgid. These files allocate a block of host UIDs/GIDs to a specific user or process. For example, dockremap:100000:65536 assigns 65,536 subordinate UIDs starting at 100000. The kernel translates container UID 0 to host UID 100000, container UID 1 to host UID 100001, and so on. This creates a complete identity isolation boundary.

When user namespaces are enabled, the filesystem layer performs bidirectional UID translation. Files created by container root (UID 0) appear on the host as owned by the mapped subordinate UID (e.g., 100000). Conversely, files on a mounted volume owned by host UID 1000 appear inside the container as owned by a shifted UID. This prevents privilege escalation through setuid binaries and ensures consistent permission enforcement across the namespace boundary.

Even within a user namespace, the container's root user gains a limited set of capabilities scoped exclusively to that namespace. Capabilities like CAP_SYS_ADMIN or CAP_NET_RAW apply only to resources governed by the namespace, not the host. This means a container root can mount filesystems or configure network interfaces inside the container, but these operations have no effect on the host system. The namespace acts as a capability jail.

User namespace remapping is most effective when combined with seccomp profiles and capability dropping. A container running with a remapped root user, a restrictive seccomp profile that blocks dangerous system calls like clone or mount, and a minimal capability set creates a deeply layered security posture. This defense-in-depth approach means an attacker must bypass multiple independent controls simultaneously to achieve meaningful host compromise.

Docker's rootless mode leverages user namespaces to run the entire Docker daemon and all containers without any host root privileges. The daemon itself runs inside a user namespace, and all containers are nested within that namespace. This eliminates the traditional attack surface of the Docker socket and daemon. Even if a container escapes, the attacker is confined to the unprivileged user context of the daemon, not the host root.