In previous attack narratives, I examined how container isolation can be undermined through explicit privilege escalation flags such as --privileged and through mounting the Docker socket. In both cases, the breakdown of isolation was dramatic and immediate. This attack explores something more subtle. Rather than breaking isolation outright, it demonstrates how allowing a writable root filesystem combined with retained capabilities weakens containment and introduces persistence risk. While this misconfiguration may not always lead directly to host compromise, it significantly increases the blast radius of a container breach. Threat Overview Containers are often described as ephemeral and immutable. In practice, this is only true when: The container filesystem is treated as disposable The image is rebuilt rather than modified at runtime The root filesystem is mounted read-only in sensitive workloads If a container is deployed with a writable root filesystem and retains elevated capabilities, an attacker who gains code execution inside the container can: Modify system binaries Add persistent backdoors Alter configuration files Drop malicious tooling Even without escaping to the host, the integrity of the container environment is compromised. This is particularly dangerous in CI/CD pipelines or long-running service containers where trust assumptions are high. Insecure Scenario In the insecure baseline, the container: Runs with a writable root filesystem Retains default Linux capabilities Does not enforce no-new-privileges Does not drop all capabilities Once inside the container, basic filesystem inspection confirmed write access: touch /root/testfile echo "persistence test" > /root/testfile The command executed successfully, demonstrating that the container root filesystem could be modified freely. Next, capability inspection: capsh --print | grep Current The output showed that the container retained multiple capabilities. While not running with --privileged, it still had more permissions than a minimally hardened container should. Even without CAP_SYS_ADMIN, retained capabilities such as CAP_CHOWN, CAP_DAC_OVERRIDE, or CAP_SETUID can meaningfully expand an attacker’s control within the container boundary. Attack Impact At first glance, writing to /root may appear minor. However, the implications are broader: System binaries under /usr/local/bin could be replaced Startup scripts could be modified Cron jobs could be added Application dependencies could be tampered with If this container mounts shared volumes, those modifications may affect external systems or persist across deployments. The key takeaway is that writable root filesystems expand post-compromise capabilities. Even if host escape is not achieved, containment is weakened. Lessons Learned This attack reinforces a subtle but important principle: Container security is not binary. A container may not be fully compromised at the host level, yet still represent a significant risk due to weakened internal controls. Writable root filesystems are convenient for development, but in production environments they undermine immutability and increase post-compromise persistence. The difference between the insecure and hardened container was not dramatic in terms of functionality. The application still ran. But from a security perspective, the posture was fundamentally different. Isolation is strongest when combined with immutability and least privilege.