Theory: Host boundary

Containers share the host kernel. Bind mounts, privileged mode, and extra capabilities are the most common ways a container ends up with more access to the host than intended. This page gives you the mental model before the lab.

flowchart TB
    subgraph safe["Default boundary"]
        C1["Container processes"] --> K["Host kernel"]
    end
    subgraph risk["Common breaks"]
        M["Bind mounts to host paths"] --> W["Wider host filesystem view"]
        P["--privileged"] --> A["Near-host device and cap access"]
        X["Extra cap-add"] --> F["Finer-grained privilege growth"]
    end

Filesystem visibility

A bind mount maps a host directory into the container’s filesystem view. The container can then read or write that directory as if it were its own. Mounting sensitive host paths into a container bypasses the idea of a sealed image. The risk is direct: any process in the container can read or modify whatever the host directory contains.

Privilege and capabilities

Privileged mode removes most of the restrictions Docker applies by default. A privileged container can do nearly anything the host user can do. Capabilities are a finer-grained version of the same idea: each capability unlocks a specific class of action. Granting too many capabilities narrows the gap between the container and the host.

Takeaway for the exercises

The following lab demonstrates these patterns on a host you control. The goal is to see what an attacker gains when these settings are misused, so you know what to block in real workloads.

Next: Lab: Host mounts and privileged containers.