|Container||Node||Escape to Host, T1611|
Mount the host disk and gain access to the host via arbitrary filesystem write
A container running with
privileged: true disables almost all the container isolation mechanisms. As such an attacker can trivially gain access to the host's resources, including the disk, to escape the container. In this attack, we simply list the disks on the host machine, mount them into the container and exploit a privileged file write to gain execution on the host.
Execution within a privileged container process.
See the example pod spec.
From within a running container, determine whether it is running with as privileged by examining capabilities:
# Check the current process' capabilities cat /proc/self/status | grep CapEff # CapEff: 000001ffffffffff # Decode the capabilities (on current box or offline) and check for CAP_SYS_ADMIN # NOTE: can install capsh via apt-get update && apt-get install libcap2-bin capsh --decode=000001ffffffffff | grep cap_sys_admin
Check that the host disks are visible to our container process:
Mount the disks into the container
With the disk now writeable from the container, follow the steps in EXPLOIT_HOST_WRITE.
mountevents originating from containers
- See EXPLOIT_HOST_WRITE
Implement security policies
Use a pod security policy or admission controller to prevent or limit the creation of pods with
Avoid running containers as the
root user. Enforce running as an unprivileged user account using the
runAsNonRoot setting inside
securityContext (or explicitly setting
runAsUser to an unprivileged user). Additionally, ensure that
allowPrivilegeEscalation: false is set in
securityContext to prevent a container running as an unprivileged user from being able to escalate to running as the