Runtime Risk

A well-built image can still be run unsafely. Runtime risk is about what happens when docker run is called with flags that weaken or remove the default isolation Docker applies.

Run the lab in this section only on an isolated Linux VM you control. Do not use a shared workstation or a production machine.

Default Docker isolation

By default, Docker starts a container with a reduced set of Linux capabilities, no access to the host filesystem beyond what the image provides, and its own network namespace. These defaults are not perfect, but they remove many of the most obvious attack paths.

Default vs privileged

flowchart TB
    subgraph DEF["Default container"]
        AP1["App Process"] -->|"reduced caps, own namespace"| HK1["Host Kernel"]
    end
    subgraph PRV["--privileged container"]
        AP2["App Process"] -->|"near-full access"| HK2["Host Kernel"]
        HK2 --> HS["Host filesystem, network, devices"]
    end

What breaks isolation

Three common patterns break that default isolation.

Bind mounts map a directory from the host into the container. If you mount /etc or / from the host, the container can read or modify host system files. Mounting the Docker socket (/var/run/docker.sock) is particularly dangerous: it lets the container start new containers with any configuration, including privileged ones.

Privileged mode (--privileged) disables almost all of Docker’s default restrictions. A process inside a privileged container can load kernel modules, modify network rules, and read raw block devices. For practical purposes, a privileged container should be treated as having host-level access.

Extra capabilities are a finer-grained version of privileged mode. Each Linux capability unlocks a specific class of action. CAP_NET_ADMIN lets a process reconfigure networking. CAP_SYS_PTRACE lets a process inspect other processes. Granting capabilities beyond what the application needs widens the attack surface.

What this means in practice

The flags that introduce these risks are often added during development for convenience and then left in place. Part of an image and deployment review is checking whether --privileged, host mounts, and extra capabilities appear without a documented reason, and whether that reason is actually valid.

Labs: Host mounts and privileged containers shows mount and nsenter patterns on an isolated VM. Linux capabilities walks through cap-drop, cap-add, and comparison with --privileged.