Containers · Term

What is CAP_SYS_ADMIN?

CAP_SYS_ADMIN is the Linux capability so broad it is nicknamed "the new root". Granted to a container, it opens several routes to escape onto the host. Here is what it allows and why containers should not have it.

Containers · TermCloud Penetration Testing
TL;DR

CAP_SYS_ADMIN is a Linux capability that grants a huge, catch-all set of privileged operations, mounting filesystems, configuring namespaces, and much more, so broad it is often called "the new root". A container holding CAP_SYS_ADMIN can usually escape to the host, classically by abusing the cgroup `release_agent` mechanism or mounting host filesystems. It is sometimes added for convenience, but it effectively undoes capability dropping. Containers should run with it removed.

By John Dill, Red Team Lead, SecureLayer7Updated

What CAP_SYS_ADMIN is

Linux capabilities split the old all-or-nothing root power into units, so a process can be given just the privileges it needs. CAP_SYS_ADMIN is the exception: it bundles such a large and varied set of privileged operations (mount, pivot_root, namespace and cgroup configuration, and more) that it approximates full root.

That breadth is why it is called "the new root" and why granting it to a container largely defeats the point of running containers with reduced privileges.

The escape and payload

A container with CAP_SYS_ADMIN has well-known escape routes:

  • cgroup release_agent escape: mount the cgroup filesystem, set a release_agent script and notify_on_release, then trigger it so the host executes the attacker’s script as root.
  • Mounting host filesystems directly, then reading or writing host files (similar to a privileged container).

These turn the capability into root code execution on the host. Documented techniques shown for defenders.

How to defend

  • Do not grant CAP_SYS_ADMIN to application containers; find a narrower capability or a different design.
  • Drop all capabilities (--cap-drop=ALL) and add back only the specific, minimal ones required.
  • Block added capabilities with Pod Security Standards (restricted) and admission control.
  • Keep seccomp and AppArmor enabled to limit what even a capable container can do.
  • Audit manifests for SYS_ADMIN in capabilities.add and test for cgroup-based escapes.

References

  1. [1]Linux man-pages: capabilities(7)(man7.org)
  2. [2]NIST SP 800-190 Application Container Security Guide(NIST)
  3. [3]MITRE ATT&CK: Containers Matrix(MITRE)
Related terms

Common questions

Container security, asked often

Want your containers and clusters tested for these paths?

Scope an engagement

Find the container escape paths before an attacker does.

We test your Docker hosts and Kubernetes clusters the way a real intruder would, from a compromised pod to the node and the rest of the cluster, then hand your team reproducible evidence and a fix for every step. Free re-test included.

See cloud penetration testing30-min scoping call, fixed-price proposal in 48 hours.