Container Isolation: cgroups
A privileged Docker container had extensive Linux capabilities, including cap_sys_admin. I confirmed the container could cross the host isolation boundary through the cgroup release_agent mechanism and identified the runtime controls needed to prevent it.
Status: ASSESSED · VERIFIED
TOOLS
Objective
I set out to assess whether a privileged Docker container could escape its isolation boundary by exploiting excessive Linux capabilities, specifically cap_sys_admin.
Scenario
A Docker container was running in privileged mode with the full set of Linux capabilities. I wanted to determine whether those capabilities allowed a process inside the container to interact with the host operating system and cross the container isolation boundary.
What I found
FINDING 01 (CRITICAL): CONTAINER HAD EXCESSIVE LINUX CAPABILITIES
The container was running with the full capability set, including cap_sys_admin, which grants the ability to mount filesystems and manipulate cgroups.
Container mode: Privileged
cap_sys_admin: Granted
Full capability set: GrantedFINDING 02 (CRITICAL): CGROUP RELEASE_AGENT ALLOWED HOST-LEVEL EXECUTION
With cap_sys_admin, the container could mount a cgroup filesystem, create a child cgroup, and configure the release_agent mechanism. When the cgroup was triggered, the release agent executed on the host, not inside the container.
Mechanism: cgroup release_agent
Execution context: Host operating system
Trigger: cgroup release notification
Result: Host filesystem accessible from containerThe escape path was confirmed by retrieving host-level data from inside the container.
What I did
- Enumerated capabilities
I used
capsh --printinside the container and confirmed the full capability set, includingcap_sys_admin. - Assessed the cgroup mechanism
The container could mount a cgroup filesystem and configure
notify_on_releaseandrelease_agenton a child cgroup. - Confirmed the escape
The release agent executed on the host, making host-level data accessible from inside the container.
- Documented the missing controls
The container should not have been running in privileged mode, and
cap_sys_adminshould not have been granted.
EVIDENCE
# Capability assessment
capsh --print output: Full capability set including cap_sys_admin
Container mode: Privileged (all capabilities granted)
Escape mechanism: cgroup release_agent executing on hostValidation
The cgroup release_agent mechanism executed on the host operating system, and host-level data was retrieved from inside the container. The container escape was confirmed.
Before and after
| CONTROL | BEFORE | AFTER |
|---|---|---|
| Container mode | Privileged | Escape documented; non-privileged recommended |
| Linux capabilities | Full set | Recommended: drop all, add only what is needed |
cap_sys_admin | Granted | Recommended: never grant unless required |
| cgroup access | Unrestricted | Recommended: restrict with seccomp/AppArmor |
| Host isolation | Bypassed | Recommended: enforce with minimal capabilities |
What I recommend
- 01Never run containers in privileged mode unless there is a documented and approved requirement.
- 02Drop all capabilities by default and add only the specific ones the application needs (
--cap-drop ALL --cap-add <specific>). - 03Use seccomp profiles to restrict the system calls available inside the container.
- 04Apply AppArmor or SELinux profiles to limit what the container process can access.
- 05Monitor for containers running with
cap_sys_adminor in privileged mode and alert on new instances.
“Container isolation depends heavily on runtime privileges. Giving a container excessive Linux capabilities can turn a container compromise into a host compromise.”
SKILLS IT PROVES
- Container Security
- Docker Security
- Linux Security
- Linux Capabilities
- Privilege Escalation
- Vulnerability Assessment
- Security Hardening
- Access Control
- Privilege Management
- Host Isolation
- Container Runtime Security