Docker Compose check · critical

cap_add: SYS_ADMIN and cap_add: ALL

Docker starts containers with a reduced set of Linux capabilities. cap_add: ALL gives back all of them, and SYS_ADMIN alone covers a very wide range of administrative operations, including mounting filesystems. Both remove much of the isolation privileged mode would remove, so the explainer marks them critical. Add only the specific capability the service needs.

$ explain docker-compose.yml
! app adds capability SYS_ADMIN critical
line 4
fix: see below
$ 

What the free Docker Compose explainer reports on the risky example below.

Why it matters

Capabilities split root's power into pieces so a container can have only some of them. Docker's default set leaves out the dangerous ones, including SYS_ADMIN, SYS_MODULE and SYS_PTRACE.

SYS_ADMIN is the broadest single capability in Linux. It allows mount operations and many other administrative calls, and it is a frequent ingredient in published container escape techniques. `ALL` includes it and every other capability.

Like privileged mode, these are often added to make one feature work (a FUSE mount, a VPN client) and then never narrowed.

Risky and safer docker-compose.yml

Riskydocker-compose.yml
services:
  app:
    image: example/app:1.4.2
    cap_add:
      - SYS_ADMIN
    restart: unless-stopped
    mem_limit: 512m
Saferdocker-compose.yml
services:
  app:
    image: example/app:1.4.2
    # Drop everything, then add back the one capability needed
    cap_drop:
      - ALL
    cap_add:
      - NET_BIND_SERVICE
    restart: unless-stopped
    mem_limit: 512m

How to fix it

  • Remove SYS_ADMIN or ALL from cap_add.
  • Find the operation that failed without it and add only the matching capability, for example NET_ADMIN for network configuration or NET_BIND_SERVICE for ports below 1024.
  • Consider cap_drop: [ALL] and adding back what is needed, so the service runs with the smallest set.
  • If a FUSE or other mount is the reason, check whether a volume or bind mount prepared on the host can replace mounting inside the container.

When it's acceptable

  • Trusted system tools that must mount filesystems or manage the host, run on machines where that level of access is expected.

Check your own docker-compose.yml

The risky example is loaded below. Paste your own file to check it for this and every other Docker Compose rule. It runs in your browser; nothing is uploaded.

docker-compose.yml

Parsed in your browser. Nothing is uploaded.

Explanation

1 service0 networks0 volumes1 critical

Top level

appexample/app:1.4.2

  • Docs for image (opens in a new tab)

    Runs the image example/app:1.4.2.

  • Docs for cap_add (opens in a new tab)

    Adds Linux capabilities: SYS_ADMIN.

    These capabilities are close to root on the host and are a common step in container escapes.

    Safer: Remove it and add back only the narrow capabilities the service actually needs.

  • Docs for restart (opens in a new tab)

    Restarts if it stops or after a daemon restart (unless-stopped), but stays down if you stopped it manually.

  • Docs for mem_limit (opens in a new tab)

    Limits memory to 512m. The container is killed if it exceeds this.

Questions

Why is CAP_SYS_ADMIN dangerous in Docker?

It covers a very wide set of privileged operations, including mounting filesystems, which is a common step in container escapes. Docker leaves it out of the default set for that reason.

Is cap_add: ALL the same as privileged: true?

Not exactly. privileged also gives access to all host devices and turns off seccomp and AppArmor. But cap_add: ALL already removes most of the capability-based limits, so both are treated as critical.

Does the explainer flag CAP_SYS_ADMIN written with the prefix?

Yes. It accepts both SYS_ADMIN and CAP_SYS_ADMIN, in any case, and flags ALL the same way.