agent-readings

Isolation and Sandboxing

gVisor

gVisor is a Linux-compatible userspace application kernel that intercepts container syscalls, implements them in a separate Sentry, and sharply limits direct host-kernel exposure.

7Claims
7Evidence

Why It Matters

For agent infrastructure, gVisor is attractive when you want stronger isolation than ordinary containers while retaining Kubernetes/Docker ergonomics and faster/lighter operation than a full microVM boundary.

Problem

  • Native containers rely on host-kernel security primitives, so untrusted code can still reach a large kernel API surface.
  • Rule-based syscall filtering is hard to configure safely for arbitrary or previously unknown applications.
  • VMs provide stronger workload isolation but can impose fixed resource overhead, slower startup, and extra proxies or agents for container use.
  • Agent-generated and user-uploaded code need defense in depth without necessarily requiring a full VM for every execution.

Key gap: gVisor asks whether a container runtime can reduce host-kernel attack surface by reimplementing the Linux application interface outside the host kernel.

Method

Intercept application system calls before they reach the host kernel, implement Linux-like behavior in a Go Sentry, route filesystem access through a Gofer, and restrict the host system calls that gVisor itself can make.

  • Start a container through runsc instead of a conventional OCI runtime.
  • Create a gVisor sandbox containing a Sentry and one or more Gofer processes.
  • Intercept the workload's system calls through systrap, KVM, or another platform.
  • Handle supported system calls in the Sentry rather than passing them through to the host kernel.
  • Send host filesystem operations that escape internal sandbox state to the Gofer.
  • Run the Sentry with a strict seccomp/user/mount namespace profile and minimal host privileges.
  • Use cgroups and network policy outside the sandbox for resource and egress controls.
  • Accept compatibility or performance losses where gVisor does not implement a feature or where syscall mediation is expensive.

Claims

C1 · source-supported

gVisor is an application kernel, not a conventional VM or syscall filter, and it implements a Linux-like interface in userspace.

Scope: What is gVisor and Introduction to gVisor security.

  • E-application-kernel: The docs describe gVisor as an open-source workload isolation solution and application kernel, not a VM hypervisor or syscall filter, written in memory-safe Go and running in userspace.

C2 · source-supported

gVisor minimizes direct host System API exposure by preventing sandboxed applications from passing system calls directly to the host kernel.

Scope: Security Model and Intro docs.

  • E-no-passthrough: The docs state that applications' direct interactions with the host System API are intercepted by the Sentry, no supported syscall is passed through directly, and applications cannot directly craft host syscall arguments.

C3 · source-supported

The Sentry is a Go userspace kernel that implements system calls, memory management, process management, signals, namespaces, filesystems, and networking behavior needed by applications.

Scope: What is gVisor and Intro docs.

  • E-sentry: The Sentry is described as implementing syscalls, signal delivery, memory management, page faulting, threading, process management, namespaces, filesystems, and networking, while not allowing the application to directly control host system calls.

C4 · source-supported

gVisor's defense-in-depth rules include no direct syscall pass-through, common-functionality-only implementation, minimized host surface for the Sentry, no CGo in the Sentry, and controlled unsafe Go use.

Scope: Security Model docs.

  • E-defense-in-depth: The docs list engineering principles: no direct host syscall pass-through, implement only common functionality, minimize the host surface accessible to the Sentry, isolate unsafe Go code, disallow CGo, restrict imports, fuzz continuously, and triage production crashes.

C5 · source-supported

gVisor supports multiple interception platforms, with systrap as the current default, KVM for bare-metal performance/isolation tradeoffs, and ptrace deprecated because of high context-switch overhead.

Scope: Platform Guide.

  • E-platforms: The platform guide says bare-metal deployments generally get best performance from KVM, systrap is better inside VMs or without virtualization support and replaced ptrace as default in mid-2023, while ptrace has high context-switch overhead and is no longer supported.

C6 · source-supported

gVisor aims for lower fixed overhead and better container ergonomics than VMs, but accepts reduced compatibility and higher per-syscall overhead versus native containers.

Scope: What is gVisor and Intro docs.

  • E-tradeoffs: The docs describe gVisor as providing many VM-like security benefits with lower resource footprint, fast startup, and userspace flexibility, but at the price of reduced application compatibility and higher per-system-call overhead.

C7 · source-supported

gVisor does not protect against higher-level stack compromise, hardware side channels, exploits inside the sandboxed workload itself, or resources explicitly exposed to the sandbox.

Scope: Intro and Security Model docs.

  • E-non-goals: The docs say gVisor does not protect against higher-level stack exploits before the sandbox runs, Spectre-style side channels, compromise of software inside the sandbox, or access to resources the sandbox is configured to expose.

Agent Infrastructure Takeaways

  • gVisor is a strong middle option for local agent tool sandboxes where full microVM startup or fixed resource allocation is too expensive.
  • The key architectural point is syscall mediation, not policy text. The agent's code talks to a fake Linux kernel first, not directly to the host kernel.
  • Compatibility is a budget. Agent tools that depend on unusual syscalls, ioctls, /proc, /sys, GPU paths, or filesystem behavior need explicit testing under gVisor.
  • Host egress and resource controls still live outside the sandbox. Pair gVisor with network policy, cgroups, credentials isolation, and filesystem allowlists.
  • Runtime monitoring and checkpoint/restore are agent-relevant because tool execution needs provenance, forensics, and sometimes warm sandbox reuse.
  • gVisor does not stop malicious instructions from using allowed APIs. It limits host escape; it does not decide whether the allowed API call should happen.

Caveats

  • This is a project/docs review, not a peer-reviewed paper entry.
  • Documentation reflects current gVisor behavior as of the review date and can drift.
  • gVisor is not a VM in the Firecracker sense and should not be presented as one.
  • Reduced compatibility and per-syscall overhead are first-order tradeoffs for syscall-heavy workloads.
  • The sandbox relies on host kernel, firmware, cgroups, and network policy for several important protections.
  • Side channels and higher-layer compromise remain outside gVisor's core protection envelope.