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.
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.
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.
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.