What are Linux capabilities in Docker?

Capabilities split root into fine-grained privileges (e.g., CAP_NET_ADMIN, CAP_CHOWN) that you can selectively grant to processes. Docker uses namespaces to scope many effects to the container, enabling least privilege instead of full root.

Which capabilities are the most dangerous?

Host-impacting caps like CAP_SYS_ADMIN, CAP_BPF, CAP_SYS_MODULE, CAP_SYS_TIME, CAP_SYS_RAWIO, and CAP_MAC_* can pierce isolation or change global host state. Avoid them unless absolutely required.

Why is CAP_SYS_ADMIN considered near-root?

It covers a very broad set of operations (mounts, namespace ops, ioctls…). Many actions affect the host or bypass container boundaries, making it effectively equivalent to root in many scenarios.

Is changing time namespaced in Docker?

Typically no. Docker doesn’t enable time namespaces by default, so CAP_SYS_TIME can impact the host clock and should not be granted to containers.

Should I use --privileged?

Avoid it. --privileged grants all capabilities and relaxes other kernel controls (like device cgroups). Prefer dropping all caps and adding back only what’s needed.

How do I follow least privilege with Docker?

Start with cap_drop: [ALL], add back minimal caps via cap_add, keep bridged networking for netns isolation, run as a non-root user, and use seccomp/AppArmor/SELinux profiles.

What about bind mounts and file-system caps?

If you mount host paths into a container, capabilities like CHOWN or LINUX_IMMUTABLE can change metadata on host files. Use carefully, or prefer volumes.

Do user namespaces help?

Yes. With user-namespace remapping, container root maps to an unprivileged UID on the host, reducing blast radius even if the container process is compromised.

Docker Capabilities – Namespaced vs Global

Gonzague Dambricourt

2 days ago

Quick take: Linux capabilities are checked by the host kernel. With Docker’s default namespaces, many actions are contained to the container’s view of the system. Some capabilities, however, still impact the whole host and should be treated as near-root. This guide keeps your container perms tight and your host safe.

Understanding namespaces & capabilities (and why it matters)

Docker isolates processes using Linux namespaces (PID, NET, MNT, IPC, UTS, USER…), while capabilities split the all-powerful root into fine-grained privileges (e.g., CAP_NET_ADMIN, CAP_SYS_ADMIN). Namespaces define where an action applies; capabilities define what the process may do. Together, they allow “least privilege” containers instead of full root.

Important: some capabilities remain effectively global in common Docker setups (for example, host time isn’t namespaced by default, so CAP_SYS_TIME can affect the host). Treat these like sharp tools.

Security baseline: Drop everything and add back only what you need (--cap-drop ALL then selective --cap-add), and avoid --privileged entirely unless you truly need host-level access.

Bonus hardening: Consider User Namespace Remapping so “root” inside the container maps to an unprivileged UID on the host.

Mostly namespaced / safer (with Docker’s default isolation)

Capability	What it allows	Scope (typical)	Risk	Typical uses
`CAP_NET_ADMIN`	Change IPs, routes, firewall rules, links.	Network namespace	🟧 Medium	VPN clients, routing, tc/iptables tweaks inside container netns.
`CAP_NET_RAW`	Raw sockets (ping, packet capture).	Network namespace	🟧 Medium	Ping, tcpdump, IDS/packet tools.
`CAP_NET_BIND_SERVICE`	Bind to ports < 1024.	Network namespace	🟩 Low	Listening on :80/:443 as non-root.
`CAP_NET_BROADCAST`	Send broadcast/multicast.	Network namespace	🟧 Medium	Service discovery, custom L2/L3 testing.
`CAP_CHOWN`	Change file owners.	Mount namespace	🟧 Medium	Installers, packaging steps.
`CAP_DAC_OVERRIDE`	Bypass file R/W/X perms.	Mount namespace	🟧 Medium	Backup/restore tools, init scripts.
`CAP_DAC_READ_SEARCH`	Bypass read/search perms.	Mount namespace	🟧 Medium	Indexing, scanning.
`CAP_FOWNER`	Bypass file ownership checks.	Mount namespace	🟧 Medium	Fixing perms across app files.
`CAP_FSETID`	Preserve/set setuid/setgid bits.	Mount namespace	🟧 Medium	Packaging special binaries.
`CAP_MKNOD`	Create special device files.	Mount namespace	🟧 Medium	Init systems, device simulations.
`CAP_LINUX_IMMUTABLE`	Set immutable/append-only flags.	Mount namespace	🟧 Medium	Hardening files (careful with bind mounts!).
`CAP_SETUID`	Set process UID arbitrarily.	PID namespace	🟧 Medium	Daemons dropping/raising privileges.
`CAP_SETGID`	Set process GID arbitrarily.	PID namespace	🟧 Medium	Same as above (groups).
`CAP_SETPCAP`	Grant/remove process capabilities.	PID namespace	🟧 Medium	Init wrappers, launchers.
`CAP_SETFCAP`	Set file xattrs for capabilities.	Mount namespace	🟧 Medium	Packaging binaries with caps.
`CAP_KILL`	Signal any process (in same PID ns).	PID namespace	🟧 Medium	Supervisors, debuggers.
`CAP_SYS_NICE`	Change priorities/scheduling.	PID namespace	🟧 Medium	Low-latency apps.
`CAP_SYS_RESOURCE`	Override resource limits (ulimits).	PID namespace	🟧 Medium	DBs, HPC, large RLIMITs.
`CAP_SYS_TTY_CONFIG`	Configure TTYs.	PID/UTS namespaces	🟧 Medium	Interactive daemons, serial tools.
`CAP_IPC_LOCK`	Lock memory into RAM.	IPC/PID namespaces	🟧 Medium	Crypto, low-latency apps.
`CAP_IPC_OWNER`	Bypass IPC ownership checks.	IPC namespace	🟧 Medium	Legacy IPC mgmt.
`CAP_SYS_CHROOT`	Use `chroot`.	Mount/PID namespaces	🟧 Medium	Build systems, init tools.
`CAP_SYS_PTRACE`	Trace/debug processes (same PID ns).	PID namespace	🟧 Medium	Debuggers, profilers.
`CAP_AUDIT_READ`	Read audit logs (where available).	Namespaced/filtered	🟧 Medium	Security tooling (limited in containers).
`CAP_CHECKPOINT_RESTORE`	CRIU checkpoint/restore operations.	PID/NET/MNT interplay	🟧 Medium	Live-migrate processes, fast restarts.

Dangerous / global-effect (host-level impact; avoid unless you truly need them)

Capability	What it allows	Why dangerous	Risk	Typical uses
`CAP_SYS_ADMIN`	Mounts, many ioctls, namespace ops; huge surface.	Swiss-army knife; many actions leak outside namespaces, often near-root.	🟥 High	FUSE, loop mounts, advanced storage/network — prefer alternatives.
`CAP_SYS_MODULE`	Load/unload kernel modules.	Direct kernel modification on the host.	🟥 High	Kernel dev (not for typical containers).
`CAP_SYS_BOOT`	Reboot the machine.	Affects entire host.	🟥 High	Almost never in containers.
`CAP_SYS_TIME`	Set system clock/timers.	Host time (often) isn’t namespaced in Docker; changes the host clock.	🟥 High	Time-sync daemons (not recommended in containers).
`CAP_SYS_RAWIO`	Direct hardware I/O port access.	Bypasses driver abstractions.	🟥 High	Specialized HW tooling.
`CAP_SYSLOG`	Read kernel logs (`dmesg`), control klog.	Leaky visibility into host kernel state.	🟥 High	Kernel troubleshooting (host tools preferred).
`CAP_AUDIT_CONTROL`	Configure audit subsystem.	Global security policy changes.	🟥 High	Host security mgmt, not containers.
`CAP_AUDIT_WRITE`	Write to audit logs.	Global audit channel abuse possible.	🟥 High	Rare in containers.
`CAP_MAC_ADMIN`	Configure MAC (e.g., SELinux/Smack).	Alters host security policy.	🟥 High	Security frameworks (host-level).
`CAP_MAC_OVERRIDE`	Bypass MAC restrictions.	Defeats host MAC confinement.	🟥 High	Almost never safe.
`CAP_PERFMON`	Advanced perf events tracing.	Can observe host kernel/other tasks.	🟥 High	Low-level perf analysis (host tools better).
`CAP_BPF`	Load/manage (e)BPF programs/maps.	Hooks into host kernel paths; potential escapes/DoS.	🟥 High	Net observability/firewalls — prefer dedicated agents.
`CAP_BLOCK_SUSPEND`	Block system suspend.	Impacts host power mgmt.	🟥 High	Power daemons (host-level).
`CAP_WAKE_ALARM`	Schedule RTC wakeups.	Host power/timing side effects.	🟥 High	Embedded/power mgmt; avoid in containers.

Practical tips (production-ready)

Prefer least privilege: --cap-drop ALL then add only what you truly need with --cap-add.
Avoid --privileged: it adds all capabilities and lifts device cgroup restrictions—near host-root.
Beware bind mounts: file-system caps (CHOWN, LINUX_IMMUTABLE, etc.) can modify host files if you’ve mounted host paths.
Network safety: if you grant strong NET caps, avoid network_mode: host so you keep the network namespace boundary.
Layer controls: combine capabilities with seccomp (syscall allow-list) and AppArmor/SELinux for defense-in-depth.

Docker Compose example (safe pattern)

services:
  app:
    image: your/image:stable
    # 1) Drop everything, add back only what you need
    cap_drop:
      - ALL
    cap_add:
      - NET_BIND_SERVICE
      - NET_ADMIN   # only if you really need it
    # 2) Keep default bridged networking to preserve NET namespace
    # network_mode: bridge
    # 3) Optional: run as non-root user inside the container
    user: "1000:1000"
    # 4) Optional: use a restrictive seccomp profile
    security_opt:
      - seccomp:default

By the way, check out our Docker post about syslog-ng and our other docker posts.