Escaping Hardened Containers

Most container escapes documented online assume --privileged. The work starts when the container IS hardened -- seccomp is on, capabilities are dropped, and the obvious paths are blocked. The remaining attack surface is smaller but not zero, and single capabilities or filesystem mounts are often enough.

Only against systems you are authorized to test.

When to Use

• The container is not privileged but retains one or more interesting capabilities (CAP_SYS_ADMIN, CAP_SYS_PTRACE, CAP_DAC_READ_SEARCH, CAP_NET_RAW)
• A seccomp profile is active and blocks common escape syscalls -- you need to map what is still allowed
• AppArmor or SELinux enforcement is present and you need to identify profile gaps
• The target runs under gVisor (runsc) or Kata Containers and you need sandbox-specific techniques
• You have identified a hostPath mount, host PID namespace, or mounted socket but the container is otherwise locked down
• A runtime CVE (runc, containerd, CRI-O) may apply despite hardening