Introduction In the first attack narrative, I demonstrated how mounting the Docker socket effectively grants root-equivalent access to the host. That scenario relied on access to the Docker daemon itself. In this second attack, I examined a different but equally dangerous misconfiguration: running a container with the --privileged flag. Unlike the Docker socket scenario, this attack does not depend on API access to the host. Instead, it weakens the container’s isolation model directly by removing many of the security restrictions that normally separate containers from the host system. Threat Overview By default, containers operate with: A reduced set of Linux capabilities Namespace isolation Device access restrictions Seccomp filtering When a container is launched with: docker run --privileged ... Docker grants the container: All Linux capabilities Access to all host devices Disabled seccomp restrictions Relaxed AppArmor/SELinux controls (depending on host configuration) In practical terms, this significantly erodes the security boundary between the container and the host. Architecture Breakdown Default Container: +-------------------------+ | Limited Capabilities | | Restricted Devices | | Namespaces Isolated | | Seccomp Filtering | +-------------------------+ Privileged Container: +-------------------------+ | All Capabilities | | Host Device Access | | Minimal Restrictions | | Isolation Weakened | +-------------------------+ The container still appears isolated — but its permissions now resemble those of the host root user. Insecure Scenario In the insecure configuration, the container is launched with: docker run -it --privileged insecure_image The container runs as root and is granted all Linux capabilities. Verifying capabilities inside the container shows a dramatic difference from the hardened baseline: capsh --print Instead of seeing an empty capability set, the privileged container retains full capability access, including highly sensitive capabilities such as: CAP_SYS_ADMIN CAP_SYS_MODULE CAP_SYS_PTRACE CAP_SYS_ADMIN alone is often described as “the new root” due to the breadth of actions it allows. Attack Execution With full capabilities enabled, the container gains expanded control over system resources. Examples of elevated access may include: Mounting filesystems Inspecting kernel parameters Interacting with host devices under /dev Manipulating namespaces While the container may not automatically share the host’s PID namespace (as in the Docker socket example), the expanded capability set dramatically increases the potential attack surface. Even without an immediate breakout, this configuration turns the container into a highly trusted process running with near-host-level authority. Impact Running containers in privileged mode introduces multiple risks: Device abuse (e.g., accessing block devices) Kernel attack surface exposure Greater ability to exploit host misconfigurations Increased potential for container escape via kernel vulnerabilities Privileged containers remove the defense-in-depth protections that make containers relatively safe by default. Instead of a constrained workload environment, the container becomes a lightly isolated root process. Secure Comparison In the hardened baseline established earlier in this project, containers were launched with: --cap-drop=ALL --security-opt no-new-privileges --read-only Additionally: No privileged mode No device passthrough No added capabilities When examining capabilities in the hardened container: capsh --print | grep Current The output confirmed that no effective capabilities were retained. The contrast is clear: Configuration Capability Set Risk Level --privileged Full Extreme Hardened baseline None Minimal The secure configuration restores meaningful isolation by enforcing least privilege. Key Takeaway The --privileged flag should be treated as an emergency tool — not a convenience option. While it may simplify debugging or development, it fundamentally undermines container isolation by granting broad authority over the host system. Like the Docker socket mount, privileged mode demonstrates a recurring theme: Containers are only as secure as their runtime configuration. The technology itself provides strong isolation primitives. Misconfiguration disables them. Security in containerized environments is less about avoiding exotic exploits and more about resisting convenience-driven decisions that erode boundaries.