Container Breakout Prevention

A security profile that blocks all system calls by default for a containerized process, explicitly allowing only a minimal set required for the application to function. This drastically reduces the kernel attack surface by preventing an attacker from invoking unusual or dangerous syscalls like mount, ptrace, or reboot even if they achieve code execution inside the container. Custom profiles are generated by tracing an application's normal execution to build a precise allowlist.

A Linux kernel feature that maps a container's root user (UID 0) to an unprivileged user on the host system, significantly mitigating the impact of a container breakout vulnerability. If a process escapes the container, it operates with the permissions of a high-numbered, unprivileged host user rather than the true root. This defense-in-depth mechanism neutralizes many privilege escalation paths that rely on the assumption that root inside equals root outside.

The practice of explicitly removing Linux capabilities from a container's runtime to enforce the principle of least privilege. By default, Docker drops all capabilities except a minimal set; operators should further restrict these by removing dangerous capabilities such as:

• CAP_SYS_ADMIN: Grants a broad range of administrative operations, including mounting filesystems.
• CAP_NET_RAW: Allows crafting raw network packets, enabling spoofing attacks.
• CAP_SYS_PTRACE: Permits tracing arbitrary processes, facilitating credential theft. A container running a simple web server typically requires zero added capabilities.

Mounting the container's root filesystem as read-only prevents an attacker from writing malicious binaries, modifying configuration files, or planting cron jobs even after exploiting an application vulnerability. Writable directories for temporary files or logs are explicitly mounted as separate tmpfs or persistent volumes. This configuration enforces immutable infrastructure principles and disrupts post-exploitation persistence techniques that rely on filesystem modification.

A security flag that prevents a containerized process from gaining any additional privileges through setuid binaries or setgid operations. When set, even if an attacker executes a sudo-like binary inside the container, the kernel blocks the privilege escalation. This flag is a critical complement to capability dropping, ensuring that a compromised process cannot leverage misconfigured binaries to elevate its access level.

A minimal container image that contains only the application and its runtime dependencies, excluding package managers, shells, and other standard OS utilities to reduce the attack surface. Without a shell or common Unix tools, an attacker who gains code execution cannot easily spawn reverse shells, download payloads, or explore the filesystem. Google's distroless images are a production-hardened implementation of this principle, forcing attackers to operate in a barren environment.

Maps the container's root user (UID 0) to an unprivileged, high-UID user on the host. Even if a process achieves root within the container, it has zero privileges on the host kernel. This is enabled via userns-remap in Docker or securityContext.runAsUser in Kubernetes. Without this, a breakout immediately grants host root access.

A Secure Computing Mode profile that blocks all system calls by default and explicitly allowlists only those required. Key blocked calls include:

• mount — prevents remounting host filesystems
• ptrace — blocks process injection
• reboot — prevents host shutdown
• kexec_load — blocks loading a new kernel A default-deny profile can reduce the kernel attack surface by over 60% compared to the default Docker seccomp profile.

Linux capabilities grant fine-grained kernel permissions without full root. Containers should drop all capabilities and add back only those essential:

• Drop CAP_SYS_ADMIN — prevents mount, swapon, and namespace creation
• Drop CAP_NET_RAW — blocks raw socket creation
• Drop CAP_SYS_PTRACE — prevents debugging host processes
• Drop CAP_SYS_MODULE — blocks kernel module loading Kubernetes enforces this via securityContext.capabilities.drop: ["ALL"].

Mounting the container's root filesystem as read-only prevents an attacker from writing malicious binaries, modifying configuration, or planting persistence mechanisms after an initial compromise. Writable directories like /tmp or /var/run are mounted as separate tmpfs volumes. Enforced via readOnlyRootFilesystem: true in Kubernetes security contexts.

AppArmor (Debian/Ubuntu) and SELinux (RHEL/CentOS) provide mandatory access control profiles that restrict container capabilities at the kernel level beyond standard Linux permissions. A well-tuned AppArmor profile can:

• Restrict file paths a process can access
• Deny specific network operations
• Block execution of binaries outside approved directories These act as a second layer even if seccomp or capabilities are misconfigured.

gVisor implements a user-space kernel that intercepts system calls and reimplements them with strong isolation, preventing direct access to the host kernel. Firecracker uses KVM-based micro-VMs for hardware-level isolation. Both provide defense-in-depth beyond namespace isolation:

• gVisor: syscall filtering in userspace
• Firecracker: each container gets its own minimal kernel
• Both eliminate the shared-kernel attack surface entirely