Isolation in Layers, Not in Slogans

apple/container draws a security boundary around each Linux workload, but the virtual machine is only its outer layer. This chapter explains how the project combines a per-container VM with a minimal guest, Linux capability and path controls, process supervision, and explicit host bridges. That model helps readers decide which defaults protect a web service, which options change the trust relationship, and why “it runs in a VM” is not a complete security assessment.

The distinction is important because isolation has several meanings. It can mean that one workload does not share a Linux kernel with another. It can mean that a process cannot write sensitive paths, acquire a powerful Linux capability, or see host files. It can also mean that a host port or SSH socket is not exposed unless the user asks for it. apple/container addresses these concerns at different layers, and each layer has its own configuration and failure conditions.

The VM is the outer wall, not the whole security model

On macOS, a Linux container needs a Linux environment. apple/container creates a lightweight VM for each container and uses Apple’s Virtualization framework to manage the guest. The project’s technical overview describes this as giving containers the isolation properties of a full VM while using a minimal set of core utilities and dynamic libraries. The same design is presented as a way to reduce resource use and attack surface, and to mount only necessary host data into each guest instead of making a shared VM a staging area for everything a future container might need.

Those are meaningful architectural properties, but they are not an independent security certification. The VM boundary is a mechanism that separates the guest kernel and guest devices from the macOS host; it does not tell us whether an application is trustworthy, whether a selected kernel is current, or whether a user has opened a broad host share. A workload can be isolated from another guest while still receiving a writable host directory, an SSH agent socket, extra Linux capabilities, or virtualization access. The outer wall matters, but the doors through it matter too.

The guest also has a minimal boot path. The runtime selects a Linux kernel and an initial filesystem, then attaches the image’s root filesystem and starts the guest support needed to run the container. In the current implementation, the runtime adds kernel command-line settings for panic handling and a Linux security-module set when a custom kernel has not already supplied those keys. This shows that security is partly established before the application’s first process runs. It is also why a custom kernel is not a neutral packaging detail: it can change the guest’s available features and security behavior.