Compose service mounts a sensitive host path
ID |
compose_sensitive_host_mount |
Severity |
high |
Remediation Complexity |
trivial |
Remediation Risk |
medium |
Remediation Effort |
low |
Vendor |
Docker |
Resource |
General Security |
Tags |
ASVS50:v13.1.1, reachable |
Description
A Docker Compose service bind-mounts a host path that hands it control of the host:
-
the container runtime socket (
/var/run/docker.sock,/run/podman/podman.sock) is the daemon’s control API. A container that can write to it can start another container with any privilege, any mount and any capability, so mounting the socket is equivalent to giving away root on the host — the Compose spelling of the Kubernetesdocker_socket_volumeflaw. -
the host root filesystem (
/) exposes every file on the host, credentials and the runtime’s own state included.
Both the short syntax (/host:/container) and the long syntax (type: bind with a source) are read.
Examples
Reported:
services:
ci:
image: example/ci:1.2.3
volumes:
- /var/run/docker.sock:/var/run/docker.sock
- /:/host:roNote that :ro does not make the mount safe: read access to the host filesystem is enough to take
its secrets, and the runtime socket ignores the flag as it is not a file operation.
Mitigation / Fix
Where a service orchestrates containers, give it a scoped API instead of the raw socket — a socket-proxy that allows only the calls needed, or the runtime’s rootless socket. Where files are needed, mount only that directory:
services:
ci:
image: example/ci:1.2.3
volumes:
- ./workspace:/workspace