With the Docker socket and privileged container scenarios explored, I turned to a configuration that appears far less dramatic but still meaningfully weakens isolation: sharing the host’s PID namespace using --pid=host. Unlike mounting the Docker socket or running with --privileged, this configuration does not immediately grant full host control. However, it removes one of the fundamental isolation boundaries containers rely on: process namespace separation. Threat Overview Containers use Linux namespaces to isolate resources. One of these is the PID namespace, which ensures that processes inside a container can only see and interact with other processes inside that same container. By default: A container has its own PID namespace. Process ID 1 inside the container is typically the container’s init or shell. Host processes are invisible. When a container is launched with: --pid=host It joins the host’s PID namespace instead of receiving its own. This means: The container can see all host processes. The container shares the same process table as the host. Process isolation is removed. Insecure Scenario The container was launched as: docker run -it --pid=host insecure_pid Inside the container, running: ps aux | head Produced: root 1 ... /sbin/init splash root 2 ... [kthreadd] root 4 ... [kworker/...] These are host-level processes, not container-local ones. The presence of /sbin/init and kernel worker threads confirms that the container is operating within the host’s process namespace. The container has not “escaped.” Instead, it was deliberately placed inside the host namespace by configuration choice. Why This Matters Even without --privileged, sharing the PID namespace introduces several risks: Host process enumeration Visibility into running services Ability to monitor system activity Potential signal-based interference if capabilities allow Expanded attack surface for kernel or service-level vulnerabilities This weakens the isolation model containers are expected to provide. Importantly, this configuration is sometimes used for debugging or monitoring tools, which makes it a realistic misconfiguration rather than an obviously reckless one. Secure Comparison When the same container was launched under the hardened baseline: Non-root user Dropped capabilities No host namespace sharing Running ps aux only showed container-local processes. Isolation was restored. Impact This attack demonstrates a key principle: Container security is not binary. Isolation can degrade incrementally. The container did not gain full control of the host, but it gained visibility into host processes. That visibility alone may be enough to facilitate further attacks. Unlike the Docker socket scenario, this attack is subtle. It does not appear catastrophic at first glance, yet it meaningfully erodes one of the core security guarantees of containerization.