A Compendium of Container Escapes

Overview: Brandon Edwards and Nick Freeman of Capsulate present an exhaustive technical compendium of Linux container escape vectors. Focusing strictly on breakout techniques available to an attacker with existing code execution inside a contained process escaping onto the underlying Linux host, the authors analyze the architecture of modern container engines like Docker and Kubernetes on Linux 4.x kernels. The presentation demystifies the core primitives of containerization—demonstrating that containers are merely restricted tasks (task_struct) rather than virtual machines—and outlines how engine vulnerabilities, misconfigurations, and kernel exploits break process boundaries.

Key Topics: - Linux container anatomy: Tasks (task_struct) vs. virtual machines - Foundational isolation mechanisms: Namespaces, cgroups, capabilities, and LSMs (AppArmor, SELinux) - Filesystem layering: Exploiting OverlayFS upper and diff directories from the host perspective - Attack volumes: Container engine bugs, deployment misconfigurations, and kernel privilege escalation

Technical Details: The authors emphasize that Linux containers possess no dedicated hypervisor, kernel, or virtualized hardware; they are ordinary Linux tasks (processes or threads) whose resource access and visibility are constrained by the host kernel. Inside the kernel, each process is governed by a task_struct holding references to credentials, capabilities, namespaces, and control groups (cgroups). While early Linux systems operated on coarse UID/GID checks, modern kernels partition root privileges into distinct capabilities (introduced in kernel 2.2/3.0). Container engines configure these primitives differently: Docker drops dangerous capabilities by default, whereas engines like LXC grant broad capabilities but rely heavily on User Namespaces (user_ns) to map root inside the container to an unprivileged UID on the host.

Filesystem isolation in container runtimes typically employs union filesystems like OverlayFS. When a container modifies filesystem contents, changes do not alter the base image layers; instead, they are written to an isolated diff directory designated as the OverlayFS upper directory (upperdir). From an offensive standpoint, understanding this layering is vital because any attacker-controlled file written within the container resides at a predictable, concrete path on the host's underlying storage. Attackers can leverage this host-reachable path to plant malicious payloads or configuration scripts intended to be triggered by host-level processes or kernel helpers.

The compendium categorizes container escape techniques into three primary volumes: container engine bugs, configuration errors, and kernel exploits. Container engine vulnerabilities frequently involve race conditions, symlink traversal flaws, or file descriptor leaks within runtime daemons (such as Docker or runC). Configuration flaws represent the most prevalent breakout vector, including containers deployed with excessive privileges (such as CAP_SYS_ADMIN), mounted host Docker sockets (docker.sock), or disabled Linux Security Modules (AppArmor or SELinux). Finally, kernel-level exploits leverage local privilege escalation bugs within the shared Linux 4.x kernel to manipulate internal task_struct pointers, overwrite credential structures, or pivot across mount namespaces to seize full host execution.

Key Takeaways: Containers provide process containment rather than strong hardware-enforced virtualization boundaries, meaning any vulnerability in the shared host kernel or runtime daemon risks full host compromise. Defenders must strictly adhere to the principle of least privilege by dropping unneeded capabilities (especially CAP_SYS_ADMIN), enforcing non-root user namespaces, and enabling mandatory access controls like AppArmor or SELinux. Securing container environments also requires continuously patching runtime engines and monitoring for abnormal namespace transitions or host socket access.

(AI summary — Gemini Flash)