flawopen.com/Reference/Docker Socket Exposure & Container Privileges

Docker Socket Exposure & Container Privileges

How Socket Access and Capabilities Change the Threat Model

The Docker Unix socket is an API endpoint for the Docker daemon. A process that can issue requests through it can exercise the authority granted to that daemon; on a default rootful installation, Docker documents daemon control as effectively root-level access. The exact impact still depends on socket permissions, authorization controls, daemon mode, user-namespace settings, and host policy. Separately, CAP_SYS_ADMIN is a broad capability that covers many system-administration operations, but it is not by itself a universal host-escape primitive. The --privileged option grants a much broader set of permissions and devices, so avoid it for ordinary workloads.

# RISKY: This workload receives the host daemon control socket.
services:
  build-runner:
    image: example-build-runner:stable
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock

# HARDENED: Keep daemon control outside the application workload.
services:
  app:
    image: example-app:stable
    user: "10001:10001"
    read_only: true
    cap_drop:
      - ALL
    security_opt:
      - no-new-privileges:true
    tmpfs:
      - /tmp:rw,noexec,nosuid,size=64m

A Typical Exposure Path

• 1A workload is compromised or misused: An attacker gains code execution in a process that should have limited authority.
• 2A privileged boundary is exposed: The workload can access a writable Docker socket, or it has capabilities and device access beyond its needs.
• 3The service acts with its own authority: Requests accepted by a rootful daemon may affect host resources; capability effects depend on namespaces and other controls.
• 4Impact follows the configuration: Assess the daemon's privilege, authorization policy, user namespaces, and host confinement before assigning a blast radius.

Defensive Engineering Checklist

• 1A workload is compromised or misused: An attacker gains code execution in a process that should have limited authority.
• 2A privileged boundary is exposed: The workload can access a writable Docker socket, or it has capabilities and device access beyond its needs.
• 3The service acts with its own authority: Requests accepted by a rootful daemon may affect host resources; capability effects depend on namespaces and other controls.
• 4Impact follows the configuration: Assess the daemon's privilege, authorization policy, user namespaces, and host confinement before assigning a blast radius.

Primary sources

• Docker Engine security
• Docker rootless mode
• Docker user namespace remapping
• Docker run reference: privileged mode
• Linux capabilities: capabilities(7)
• CWE-732: Incorrect Permission Assignment for Critical Resource