Many escapes need no capability trick at all: the container was simply given a host path it should not have. That path can be an explicit directory bind mount, the whole host root, a runtime control socket, or a kernel pseudo-file under /proc and /sys that the host kernel reads back and acts on as root. The common thread is that the object on the other side of the mount belongs to the host, so writing it reaches the host directly.
Enumerate mounts and look for host-owned sources:
cat /proc/self/mountinfo # full mount table with source subtrees
findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS # readable summary; host bind sources stand out
# control sockets and sensitive kernel files
ls -l /var/run/docker.sock /run/containerd/containerd.sock /run/crio/crio.sock 2>/dev/null
ls -l /proc/sys/kernel/core_pattern /proc/sys/kernel/modprobe /sys/kernel/uevent_helper 2>/dev/null
mount | grep -E '/proc|/sys' | grep -v 'ro,' # writable proc/sys indicates host interfaces
A host bind mount shows a host subtree as its source; a writable /proc/sys/kernel/* or a runtime socket is a direct route.
Subtopics#
- Host path mount: a bind mount of a host directory or the root filesystem.
- Runtime socket mount: a mounted Docker, containerd, or CRI-O control socket.
- procfs and sysfs: writable kernel interfaces the host executes as root.