Container Escape via runC Mount Manipulation:
Symlinks and Race Conditions Break Isolation.

runC's Role in Container Isolation

runC is the reference implementation of the OCI (Open Container Initiative) runtime specification. It is responsible for the low-level operations that create container isolation: setting up Linux namespaces, configuring cgroups, mounting the container's root filesystem, applying seccomp and AppArmor/SELinux policies, and starting the container process. Docker, containerd, CRI-O, and Kubernetes all use runC (or an equivalent OCI runtime) as the final layer before a container process starts.

The security boundary that runC creates is implemented through the Linux kernel's namespace and mount mechanisms. When runC sets up a container, it performs a series of mount operations to assemble the container's view of the filesystem. These operations run with root-level privileges on the host — which means any bug in the mount setup code that can be influenced by container-controlled content represents a potential privilege escalation from the container to the host.

The Mount Security Problem

When runC mounts the container's root filesystem, it needs to set up bind mounts, overlay filesystems, and special mounts (proc, sys, dev) within the container's mount namespace. Several of these operations involve path resolution — resolving a path provided in the container specification to an absolute path on the host — before performing a privileged mount operation at that resolved path.

The security requirement is that the resolved path must remain within the intended boundaries. The vulnerability class arises when a container can cause the path resolution to land outside those boundaries — most commonly through symlinks that redirect the path traversal to host filesystem locations outside the container's root.

Symlink Race Condition Mechanics

The canonical symlink attack against a container runtime works as follows. During container setup, runC resolves a path within the container's filesystem — for example, to mount /proc inside the container. It checks that the resolved path is within the container root directory. It then performs the mount operation.

Between the check and the mount operation, there is a window where the container process (or a setup script in the container image) can replace a path component with a symlink that points outside the container root. The mount operation then follows the symlink and operates on a host path instead of a container path — with root privilege, since runC runs as root.

This is a time-of-check to time-of-use (TOCTOU) vulnerability: the security check and the security-sensitive operation are not atomic, and the state can change between them. Linux does not provide a fully atomic version of "check that this path stays within this boundary and then mount here" — solving it requires careful use of openat2 with RESOLVE_IN_ROOT or equivalent mechanisms that prevent symlink traversal across the boundary.

Exploitation Requirements

The practical exploitation of mount manipulation vulnerabilities in runC typically requires either code execution inside the container before the mount setup completes (which is possible for some multi-step container startup processes) or the ability to influence the container image's filesystem content. The latter is more relevant for shared multi-tenant environments where users can supply arbitrary container images.

A container image can pre-stage symlinks in its filesystem that will be encountered during the mount setup phase. If runC follows a container-controlled symlink while setting up a privileged mount, the attacker gains write access to the host filesystem — which immediately allows planting a privileged binary, modifying host configuration, or reading other containers' sensitive files.

Detection and Response

Container escape detection relies on observing anomalous host-level activity that indicates a container process has broken out of its namespace:

• Process namespace violations: A process that was spawned inside a container namespace but is now visible in the host PID namespace without a corresponding legitimate exec chain is a strong escape signal. eBPF-based tools can monitor namespace transitions continuously.
• Host filesystem access from container-namespaced processes: File operations on host paths (outside /var/lib/docker/containers/ or equivalent) by processes whose mount namespace corresponds to a container indicate a successful escape or an in-progress attempt.
• Unexpected symlink creation in container root directories: Creation of symlinks that point outside the container root during the setup phase of a new container can indicate an in-progress exploitation attempt. Runtime security tools that hook the symlink system call and validate the target can detect this.
• runC process making unexpected syscalls: Seccomp profiling of the runC process itself — not just the containers it spawns — can detect anomalous syscall patterns that deviate from expected mount setup behaviour.

Runtime Hardening

1. Keep runC, containerd, and Docker Engine on current versions: Mount manipulation vulnerabilities in runC have been disclosed and patched multiple times. Running outdated runtime versions means running with known-exploitable vulnerabilities. Container runtime updates should be treated with the same urgency as kernel security patches.
2. Use gVisor or Kata Containers for untrusted workloads: gVisor interposes a user-space kernel between the container and the host kernel, eliminating most container escape vectors including mount manipulation. Kata Containers runs each container in a lightweight VM, providing hardware-level isolation. The performance cost is workload-dependent but is justified for multi-tenant or externally-sourced container workloads.
3. Enable Kubernetes Pod Security Standards: Enforce the Restricted policy for namespaces running untrusted workloads. This prevents privileged containers, hostPath mounts, host namespace sharing, and other configurations that simplify container escape exploitation.
4. Deploy a runtime security tool: Tools like Falco, Tetragon, or Sysdig deploy eBPF-based monitoring that can detect anomalous container behaviour — including namespace violations and suspicious file operations — in real time.
5. Restrict image sources: Only allow container images from trusted, scanned registries. An image that pre-stages symlinks for a container escape attack needs to be built into the image — preventing arbitrary image pulls removes the most accessible exploitation path for externally-supplied content.