The one-sentence version
Isolation strength is roughly divided into four levels: Process-level restrictions (seccomp, Seatbelt, Landlock, etc., which limit the system calls a process can make and the files it can access), Containers (namespaces + cgroups, which look like independent systems but share the same kernel with the host), User-space kernels (gVisor, which adds another layer between the container and the real kernel), and Virtual Machines / Micro-VMs (Firecracker, etc., which have their own independent kernels and rely on hardware virtualization for isolation). The further down the list, the more secure it is, but also the heavier and slower it becomes. The choice of layer depends on how untrusted the code you intend to run is.
This article has three layers:
- Layer 1: The Intuition: Partitions in the same building, independent rooms, and independent houses.
- Layer 2: Real-World Use: Browsers, Docker, Google's gVisor, and AWS Lambda's Firecracker.
- Layer 3: Mechanisms, attack surfaces, and overhead comparison for each layer.
Layer 1: The Intuition
1.1 Partitions, Rooms, and Houses
| Layer | Analogy | If Breached |
|---|---|---|
| Process-level restrictions | Drawing a zone for you in an open-plan office, specifying which cabinets you cannot touch | If the rules are poorly written, you can touch them |
| Containers | Independent rooms within the same building, but sharing the same water and electricity pipes (kernel) | If the pipes have an issue, you might enter another room |
| gVisor | Installing a private water and electricity system within the room, connected to the building only through a few valves | You must first breach your own system, then breach the few valves |
| Virtual Machines | An independent house with its own water and electricity (independent kernel), sharing only a single road with the outside world (virtualization layer) | Breaching the virtualization layer is much more difficult |
1.2 Key concept: Is the kernel shared?
The kernel is the core of the operating system, managing all hardware and permissions. For a regular program to do anything "real" (read files, connect to the network, create processes), it must request the kernel via system calls.
- Programs in a container make system calls directly to the host kernel. The kernel has hundreds of system calls and tens of millions of lines of code; if there is a vulnerability in just one place, it could be used to escape the container;
- Programs in a virtual machine make system calls to their own kernel. To affect the host, they must first breach the virtualization layer, which has a much smaller attack surface.
Layer 2: Real-World Use
| Technology | Who uses it | Purpose |
|---|---|---|
| Browser rendering process sandbox | Chrome, Firefox, Safari | The rendering process for each webpage is strictly restricted, making it difficult for a vulnerability in a webpage to directly control the entire computer |
| seccomp-bpf | Default Docker config, Chrome, Android | Disables dangerous system calls using filtering rules |
| macOS Seatbelt, Linux Landlock / bubblewrap | Application sandboxing, some AI coding tools | Limits the file paths and network access available to a process |
| Docker / Containers | Almost all cloud services | Packaging and isolating applications; default configurations are not suitable for running completely untrusted code |
| gVisor (Open sourced by Google in 2018) | Some serverless products in Google Cloud | Re-implements most Linux system calls in user-space, reducing direct exposure to the host kernel |
| Firecracker (Open sourced by AWS in 2018) | AWS Lambda, Fargate | Minimalist micro-VMs that start in about a hundred milliseconds, balancing VM isolation with container speed |
| Kata Containers | Various cloud providers | Allows each container to run inside a lightweight virtual machine |
| WebAssembly Runtime | Edge computing, plugin systems | Language-level sandbox that can only access explicitly granted capabilities |
For cloud execution environments running AI-generated code, providers generally choose stronger isolation like gVisor or Firecracker rather than standard containers.
Layer 3: Principles and Engineering
3.1 Process-level restrictions
| Mechanism | Platform | Function |
|---|---|---|
| seccomp-bpf | Linux | System call allowlist / denylist |
| Landlock | Linux (5.13+) | Allows unprivileged processes to restrict the file paths and network ports they can access |
| Seatbelt (sandbox-exec) | macOS | Uses rules to describe allowed file access, network access, and process operations |
| AppContainer | Windows | Application-level isolation |
| Running with reduced privileges | General | Running as a dedicated low-privilege user instead of root (see "Least Privilege and Key Management") |
The advantage is that it is lightweight with almost zero overhead; the disadvantage is that writing rules is complex and prone to omissions.
3.2 Containers
Container = Namespaces (allowing a process to see an independent filesystem, process list, network, hostname, and user) + cgroups (limiting CPU, memory, and number of processes) + usually supplemented by seccomp and capability restrictions.
It provides isolation, but it is not the end of the security boundary: all containers share the host kernel. Common weakened configurations (privileged mode, mounting the Docker socket, granting too many capabilities) can render isolation useless (see "Container Escape").
3.3 gVisor
The core component of gVisor, Sentry, implements the Linux system call interface in user-space. The program in the container thinks it is talking to the Linux kernel, but it is actually talking to Sentry; Sentry itself only uses a very small portion of the host system calls and is strictly limited by seccomp.
The cost: Programs with heavy system call usage (large amounts of file I/O or network I/O) will slow down significantly; some system calls are not supported.
3.4 Virtual Machines and Micro-VMs
Traditional virtual machines simulate an entire computer (BIOS, various devices), which results in slow startup times and high memory consumption. Micro-VMs like Firecracker only retain the minimum necessary virtual devices (network card, disk, serial port), are written in Rust, start in about a hundred milliseconds, and have a memory overhead of just a few MBs. Isolation relies on CPU hardware virtualization (Intel VT-x, AMD-V); an attacker would need to breach the hypervisor (KVM + the Firecracker process, the latter of which is itself further restricted by seccomp and jail).
3.5 Comparison
| Process-level | Container | gVisor | Micro-VM | |
|---|---|---|---|---|
| Isolation Strength | Low to Medium | Medium | Medium-High | High |
| Shares Host Kernel | Yes | Yes | Partially (very few system calls) | No |
| Startup Time | Instant | Millisecond-level | Millisecond-level | ~100ms |
| Performance Overhead | Minimal | Small | Significant during I/O intensive tasks | Small to Medium |
| Suitable For | Own code, local Agent | Own services | Semi-trusted / Untrusted code | Completely untrusted code |
3.6 Layered Defense
The best practice is layering: running a container inside a micro-VM, using a non-root user within the container, adding seccomp rules, and adding a network egress allowlist (see "Egress Control"). An attacker must successfully breach each layer in succession.
Summary
| Layer | Key points |
|---|---|
| Key Question | Is the kernel shared? |
| Four Levels | Process restrictions → Container → gVisor → Micro-VM |
| Selection | The more untrusted the code, the stronger the isolation required |
| Practice | Layered defense; containers are not the end of the security boundary |