Hardening Containers Against procfs Escapes: Lessons From runc

Containers share the host’s kernel. That makes them light and fast, and it also means a mistake in how a container is set up can expose the host. One area that has caused real vulnerabilities is /proc, the Linux process filesystem. This guide explains why procfs matters for container isolation, what went wrong in a well-known runc vulnerability, and the settings that reduce the risk.

What runc and procfs are

runc is the low-level container runtime that creates and starts containers according to the Open Container Initiative (OCI) specification. Docker, containerd and many Kubernetes setups use it under the hood. It sets up namespaces, cgroups, capabilities and security profiles, then starts the container’s first process.

procfs, mounted at /proc, is a virtual filesystem that the kernel generates on the fly. It exposes information about running processes and the system: memory, CPU, open files, mounts and more. Some files under /proc can also be written to change kernel behavior. That’s why container runtimes limit what a container can see and touch there.

Why procfs is sensitive for containers

Each process has an entry under /proc/<pid>/. Some of those entries, such as /proc/<pid>/exe and the file descriptors under /proc/<pid>/fd, behave like links back to real files and executables. If a process inside a container can reach entries that point to something on the host, the isolation boundary gets thin.

Runtimes defend against this in several ways: a separate PID namespace so the container only sees its own processes, masking or making read-only certain paths under /proc and /sys, dropping capabilities, and applying AppArmor or SELinux profiles and seccomp filters.

A real example: CVE-2019-5736

In February 2019, researchers disclosed CVE-2019-5736, a runc vulnerability. A malicious process running as root inside a container could overwrite the host’s runc binary by abusing /proc/self/exe during a container exec. The next time runc ran on the host, the attacker’s code ran with root privileges on the host. It affected Docker, containerd, Kubernetes and other platforms that used runc.

The fix made runc copy itself into memory before entering the container, so the binary on disk can’t be reached that way. Docker 18.09.2 shipped the patched version.

In 2024, another runc flaw, CVE-2024-21626 (“Leaky Vessels”), involved a leaked file descriptor that could give a container process access to the host filesystem. It was fixed in runc 1.1.12. Both cases show the same lesson: the runtime is part of your attack surface and needs patching like anything else.

How to harden containers against procfs-based escapes

1. Keep runc and your container engine updated. Check your version with runc --version and follow your distribution’s or vendor’s security advisories.
2. Don’t run containers as root. Set a non-root user in the image (USER in the Dockerfile) or in the Kubernetes securityContext with runAsNonRoot: true. CVE-2019-5736 needed root inside the container.
3. Use user namespaces or rootless mode. With user namespace remapping, root inside the container maps to an unprivileged user on the host. Docker and Podman both support rootless operation.
4. Avoid privileged containers. --privileged removes most of the protections described here, including procfs masking. Grant individual capabilities only when an application really needs them, and drop the rest.
5. Keep the default PID namespace. Don’t use --pid=host or hostPID: true unless you have a specific monitoring need, because it lets the container see host processes in /proc.
6. Leave masked paths alone. Docker and Kubernetes mask sensitive paths under /proc by default. Avoid options that remove those defaults, such as Kubernetes procMount: Unmasked.
7. Enforce mandatory access control. Keep the default AppArmor or SELinux profile enabled, and use the runtime’s default seccomp profile (RuntimeDefault in Kubernetes).
8. Block privilege escalation. Set allowPrivilegeEscalation: false and use a read-only root filesystem where the application allows it.
9. Protect the host’s runtime binaries. Keep them owned by root, on a read-only or immutable filesystem where possible, and watch them with file integrity monitoring.
10. Use trusted images. Pull from known registries, scan images for vulnerabilities and sign them.

Detecting escape attempts

• Run a runtime security tool such as Falco, which ships rules for suspicious container behavior, including writes to sensitive host paths and unexpected shells.
• Alert on changes to container runtime binaries on hosts.
• Watch for containers started with privileged mode, host PID or host mounts, using an admission controller or Kubernetes Pod Security Standards (the “restricted” profile blocks most of these).
• Send container and host logs to a central place so an alert on one host can be investigated quickly.

If you suspect a container escape

Treat the host as compromised, not just the container. Isolate the node, preserve logs and disk images for investigation, rotate any secrets the host could reach, rebuild the node from a known-good image, and check other nodes for the same signs. Then work out how the attacker got into the container in the first place, since that entry point is still open.

For image-level controls, see our guides to container image security and tools to remove CVEs from container images.

M. Ahmad

M. Ahmad is a cybersecurity expert with over four years of experience in threat research and intelligence. He has done master’s from Staffordshire University London in Cyber Security and Forensics. He specializes in cloud security, threat hunting and incident response having worked at FireEye, Blue Hexagon, and Trustwave. He has certifications in Azure Security, Microsoft Defender, and MITRE ATT and CK Defender. Ahmad is a proficient writer and a speaker with his research focusing on vulnerability management, threat detection and malware analysis. He has a passion for sharing his experience and knowledge to keep everyone aware of emerging cybersecurity threats. He has received various awards and certifications.