Project Status As I move further into the Container Security Sandbox project, I’ve reached an important transition point. The initial phase of the project has focused on building and validating a set of baseline container configurations, both intentionally insecure and deliberately hardened. Before moving into attack narratives and exploitation scenarios, I want to pause and document where the project stands and why these baselines matter. At this stage, the goal has not been to “break” anything yet. Instead, the focus has been on understanding how different container configurations behave under normal conditions, what assumptions they make about trust and isolation, and how those assumptions change depending on how the container is built and run. Establishing these baselines provides a clear reference point for evaluating security risks later in the project. +---------------------------------+ | Container Security | | Sandbox | +---------------------------------+ | v +---------------------------------+ | Baseline Phase | +---------------------------------+ | | v v +------------------+ +-------------------+ | Insecure | | Secure | | Containers | | Containers | +------------------+ +-------------------+ | - root user | | - non-root user | | - privileged | | - dropped caps | | - host access | | - read-only fs | +------------------+ +---------------------+ | | +-----------+-----------+ | v +-------------------------------------+ | Attack Narratives | | (compare behavior & risk) | +-------------------------------------+ Insecure Container Baselines On the insecure side, I have created containers that reflect common real-world misconfigurations. These include containers running as the root user, containers launched with excessive privileges, and configurations that expose sensitive host interfaces. These setups are not unusual in development or poorly hardened environments, and they serve as realistic examples of how convenience and lack of awareness can undermine container isolation. At this point, these insecure containers are not being exploited yet; they exist to define the starting conditions that many systems unknowingly operate under. Secure Container Baselines In parallel, I have built secure counterparts designed to demonstrate reasonable hardening practices. These containers run as non-root users, explicitly drop Linux capabilities, restrict filesystem access, and avoid unnecessary exposure to host resources. Rather than aiming for theoretical “perfect security,” these configurations are meant to reflect practical steps that can be taken in production environments to reduce risk. Validating that these controls behave as expected by observing what actions are denied is just as important as demonstrating what insecure containers allow. Why Establishing Baselines Matters One of the key lessons from this phase is that container security is inherently comparative. An attack only has meaning when it can be measured against a more secure alternative. Without a clear baseline, it becomes difficult to distinguish between a genuine vulnerability and expected behavior. By first defining both insecure and hardened environments, the project can later show not just that an attack works, but why it works and why it fails when appropriate controls are in place. This approach also mirrors how security work is performed in real operational settings. Systems are rarely attacked in isolation; they are evaluated based on how they are configured, what privileges they grant, and how they interact with the host and surrounding infrastructure. Understanding these conditions before testing them under adversarial scenarios leads to more meaningful conclusions and clearer documentation. Looking Ahead: Attack Narratives With these baselines now established, the next phase of the project will focus on attack narratives. These scenarios will intentionally attempt to abuse the insecure configurations and then repeat the same techniques against their hardened counterparts. The goal is not exploitation for its own sake, but to clearly demonstrate how configuration choices directly affect security outcomes. This checkpoint marks the transition from setup and validation to active testing. By documenting the state of the system now, the upcoming attack scenarios can be evaluated in context, making their impact and the value of mitigations much easier to understand.