One Docker Misconfig, Three Minutes to Host Root: Escape Paths & Hardening

Containers are not virtual machines; they share the host kernel. Isolation exists but misconfiguration equals an unlocked door. The author recounts a real incident: an attacker exploited a web vulnerability, gained container access, and within three minutes achieved host root, exfiltrating all containers, databases, and secrets.

Three Isolation Mechanisms

Container isolation relies on three Linux kernel features: Namespaces (isolate processes, network, filesystem), Cgroups (limit resources), and Capabilities (restrict root privileges). All three can be weakened by configuration, allowing container processes to reach the host.

Six Dangerous Configurations

--privileged : Grants nearly all host root capabilities — device access, kernel module loading, direct host filesystem manipulation. Often added for convenience (e.g., running Docker-in-Docker or hardware access) but eliminates security.

Mounting /var/run/docker.sock : Intended to let containers manage other containers, but enables creating new containers that mount the host root filesystem, effectively surrendering the entire host.

Mounting sensitive host directories : Example -v /:/host gives the container direct read/write access to the host filesystem. Attackers can modify crontab, inject SSH keys, or replace binaries.

Sharing namespaces : --pid=host lets the container see and kill host processes; --network=host bypasses network isolation by using the host network stack directly.

Excessive capabilities : SYS_ADMIN is a master key; granting it makes the container no longer a container.

Running as root : Many images default to root. If escape occurs, the attacker immediately becomes host root.

How to Audit: Two Commands

Docker containers:

docker inspect <container-name> | grep -E "Privileged|CapAdd|Binds|NetworkMode|PidMode"

Check for Privileged: true, CapAdd containing SYS_ADMIN, Binds containing /var/run/docker.sock or /.

Kubernetes Pods:

kubectl get pod <pod-name> -o yaml | grep -E "privileged|hostPath|hostNetwork|hostPID|capabilities"

Look for privileged: true, hostPath, hostNetwork: true, hostPID: true.

Automated tools: docker-bench-security for Docker, kube-bench for Kubernetes, trivy for image scanning, falco for runtime detection.

Hardening Checklist

Never use --privileged . For hardware access, use fine-grained device permissions; for container management, use a socket proxy.

Drop all capabilities, then add only what is needed : --cap-drop=ALL --cap-add=NET_BIND_SERVICE Run containers as non-root :

RUN useradd -r -u 1001 appuser
USER appuser

In Kubernetes:

securityContext:
  runAsNonRoot: true
  runAsUser: 1001

Set root filesystem read-only with --read-only; mount writable directories as separate tmpfs volumes.

Avoid mounting /var/run/docker.sock . If required, use a socket proxy that exposes only necessary APIs with authentication.

Minimize hostPath in Kubernetes . When unavoidable, mount read-only and restrict the path.

Enable seccomp, AppArmor, SELinux . Docker's default seccomp profile blocks many syscalls; do not disable it.

Keep Docker, runc, and the kernel updated . Historical escape vulnerabilities were fixed via upgrades.

Enable Kubernetes Pod Security Standards using baseline or restricted profiles to forbid privileged containers, hostPath, and hostNetwork.

Pre-Deployment Routine

Before going live, do three things: run a security baseline scan and remediate all high-risk findings; scan images with trivy and avoid base images with known vulnerabilities; deploy falco for runtime anomaly alerting. Container security is not a one-time configuration — it requires continuous auditing and monitoring. Privileged containers, docker.sock mounts, and host directory mounts: any one of them hands over host root.