Six settings do most of the damage: privileged mode, added capabilities, unconfined seccomp or system paths, host networking, writable bind mounts, and a mounted Docker socket. Each removes a layer of the isolation Docker applies by default. Search for them before you run any container you did not write.
The audit table
| Setting | What it changes | Where to look |
|---|---|---|
| privileged | Gives all capabilities and access to all devices | docker run commands, Compose files, dev container settings |
| cap-add | Adds capabilities that are off by default | Same places |
| seccomp=unconfined | Turns off seccomp filtering | security-opt entries |
| systempaths=unconfined | Turns off confinement of masked and read only system paths | security-opt entries |
| network host | Container shares the host network stack | network settings |
| bind mount of a host path | Container can write to host files by default | volume and mount entries |
| Docker socket mount | Container can control the daemon | volume entries |
Every row comes from Docker's own reference pages. None of them is forbidden, and some are needed for real work. The point is that each one needs a stated reason.
Why each one matters
Privileged. By default, Docker says, containers are unprivileged and cannot access devices. A privileged container is given all capabilities and access to all devices on the host. It is a different security posture, not a small tweak. For more, read the privileged mode risks.
Capabilities. Docker starts containers with a default list and documents a longer list that is not granted by default and may be added. One of the entries on that second list is SYS_ADMIN, which the Linux manual calls an overloaded capability. Adding it is rarely a small request.
Unconfined settings. The security option reference lists switches that turn off label confinement, seccomp and system path confinement, and one that swaps the AppArmor profile. Each is a single flag, which is why they spread by copy and paste.
Host networking. In host mode the container does not get its own IP address and shares the host's network namespace. Docker's examples show a host service reachable from the container on localhost. Published port flags are ignored.
Bind mounts. Docker states that bind mounts have write access to host files by default, so a process in the container can create, modify or delete important files on the host. The read only option prevents this.
The socket. Docker's own example mounts the Docker socket into a container. Whoever controls that socket controls the daemon. See why that is root on the host.
A five minute audit
- Search the repository and CI configuration for the names in the table.
- List each hit with the file, the setting and the person who added it.
- Ask whether a narrower option exists: a single added capability instead of privileged, a read only mount instead of a writable one, a custom seccomp profile instead of unconfined.
- Remove what has no owner or no reason.
- Re-run the audit when dependencies or base images change.
What the audit does not tell you
It looks at configuration, not behavior. A container with every setting at default can still contain vulnerable packages, and a container with a reasonable exception can still be fine. Pair this review with image and dependency scanning, and with a clear view of which workloads handle untrusted input.
Safeguard scans container images and dependencies and can gate on policy. You can try the free scan at gold.safeguard.sh/scan.
Quick check
Is a read only bind mount enough to make a mount safe?
It stops the container writing to that path, but the container can still read everything in it. Mount only the folder the workload needs.
Does Docker Desktop change any of this?
Docker says the daemon runs inside a Linux VM on Docker Desktop and handles host path sharing for you. The settings above still decide what a container can reach.
Sources
- Running containers, Docker Docs
- docker container run reference, Docker Docs
- Bind mounts, Docker Docs
- Host network driver, Docker Docs
- capabilities(7), man7.org
Last reviewed: 19 October 2026.
