Capabilities

Linux capabilities split root privileges into smaller pieces.

Containers normally run with a reduced capability set. Escape risk increases when dangerous capabilities are added back.

Enumeration

Check capabilities:

capsh --print
cat /proc/self/status | grep -E "Cap(Inh|Prm|Eff|Bnd|Amb)"

If capsh is missing:

which capsh
cat /proc/self/status | grep Cap

Capability values in /proc/self/status are hexadecimal bitmasks. Tools such as capsh make them readable.

High-Value Capabilities

CAP_SYS_ADMIN

Check:

capsh --print | grep sys_admin

Why it matters:

CAP_SYS_ADMIN is overloaded and controls many privileged kernel operations.

Possible impact depends on other settings:

• Mount filesystems
• Interact with cgroups
• Manipulate namespaces
• Abuse exposed devices
• Combine with host mounts or weak AppArmor/seccomp

Example mount check:

mkdir -p /mnt/test
mount -t tmpfs tmpfs /mnt/test

If mounting succeeds inside a container, the container is unusually privileged.

If host block devices are exposed and CAP_SYS_ADMIN is present, a direct host mount may be possible. The device name is lab-specific:

mkdir -p /mnt/host
mount -t ext4 /dev/sda1 /mnt/host
chroot /mnt/host /bin/bash

This is not a universal command. It requires the device to exist, the filesystem type to match, and the container restrictions to allow the mount. The important lesson is the primitive: CAP_SYS_ADMIN plus device access can turn into host filesystem access.

CAP_SYS_PTRACE

Check:

capsh --print | grep sys_ptrace
ps aux

This is most dangerous when host processes are visible.

Preconditions for host-process abuse:

• CAP_SYS_PTRACE
• Host PID namespace or visible target process
• Permissive ptrace restrictions
• Suitable tooling

Do not assume CAP_SYS_PTRACE alone is an escape. It becomes serious when combined with process visibility.

The dangerous combination is:

CAP_SYS_PTRACE + host PID namespace + permissive ptrace restrictions

With that combination, process injection or credential theft from host processes may become realistic. Without visible host processes, CAP_SYS_PTRACE is still a finding, but the impact is lower.

CAP_DAC_READ_SEARCH

This capability can bypass file read and directory search permissions.

Impact:

• Read files normally blocked by Unix permissions
• Search protected directories
• Exfiltrate secrets from mounted paths

It does not automatically mount the host filesystem. It becomes high impact when sensitive host paths are already mounted.

The common win is reading files that normal Unix permissions would block:

grep -R "password" /host /hostfs /mnt 2>/dev/null
find /host /hostfs /mnt -name "id_rsa" -o -name "*.env" 2>/dev/null

Privileged Containers

Privileged containers receive broad permissions and relaxed device/cgroup controls.

Indicators:

capsh --print
ls -la /dev
mount
cat /proc/self/status | grep Cap

If a container is privileged and host paths are mounted, escape is often straightforward through chroot, nsenter, or device access.

Remediation

• Do not use --privileged for application containers.
• Start with --cap-drop=ALL.
• Add only required capabilities with --cap-add.
• Keep seccomp profiles enabled.
• Keep AppArmor or SELinux profiles enabled.
• Avoid host PID, host network, and broad device mounts.
• Monitor containers with dangerous capabilities.

Example safer run:

docker run --cap-drop=ALL --security-opt no-new-privileges:true IMAGE

Capabilities are not decorations. They are pieces of root.