gVisor

Summary

gVisor is an open-source Linux container sandbox from Google. It inserts a user-space application kernel between a workload and the host Linux kernel, reducing the host attack surface while keeping a container-like workflow.

It is not a normal container, a system-call filter, or a full virtual machine (VM).

Problem

Normal containers share the host kernel. A kernel flaw can therefore become a container escape.

gVisor gives untrusted code a separate Linux-like interface. Think of it as a security interpreter: the application asks for Linux services, but gVisor answers most requests instead of passing them straight to the host kernel.

How It Works

• runsc is its Open Container Initiative runtime. Docker, containerd, and Kubernetes can use it in place of runc.
• Sentry is the application kernel. Written mainly in memory-safe Go, it implements system calls, memory, processes, filesystems, and networking.
• Gofer handles permitted host filesystem access for each container.
• Systrap is the default interception platform and uses Linux system-call filtering machinery without requiring hardware virtualization.
• KVM is an optional platform that uses Linux hardware virtualization support.
• Netstack is gVisor’s own user-space network stack. Traffic normally crosses one raw packet socket rather than giving the sandbox direct host sockets.

Security Boundary

Full gVisor:

• The workload does not make system calls directly against the host kernel.
• The Sentry exposes a reimplemented Linux interface and itself runs with a strict system-call filter, namespaces, minimal capabilities, and a restricted filesystem view.
• An escape generally needs a chain across both the gVisor boundary and the separate host Linux boundary.
• Each mutually untrusted tenant should use a separate sandbox.

Not covered automatically:

• Bugs before gVisor starts, such as a compromised container manager.
• CPU side-channel attacks such as Spectre.
• Resource exhaustion; host control groups must enforce CPU and memory limits.
• Network policy, secret handling, or unsafe mounted files. Operators must configure these separately.
• Compromise inside the sandbox. An attacker still gets anything deliberately exposed to that sandbox.

Full gVisor Versus Clawk’s Fork

Clawk does not use the full gVisor sandbox. Its workload isolation comes from a Linux VM.

Clawk’s macOS networking uses a small fork of gvisor-tap-vsock, built around gVisor netstack. The fork adds an allow-list check to TCP, UDP, and ICMP forwarders before opening a host connection.

This gives Clawk a user-space network policy point, not gVisor’s application-kernel boundary. Reusing netstack alone does not intercept filesystem access, processes, memory, or Linux system calls.

See Clawk Gvisor Tap Vsock for the fork-specific details.

Platforms

• Host operating system: Production runsc is for Linux.
• Processors: Official builds support x86-64 and ARM64.
• Kernel: The repository lists Linux 4.14.77 or newer.
• Container tools: Docker, containerd, Kubernetes, and direct Open Container Initiative bundles.
• macOS: Some project packages can be tested on macOS, but macOS does not run the full runsc sandbox natively.
• Cloud use: Google uses gVisor in products including GKE Sandbox; the open-source runtime can run outside Google Cloud.

Setup

The simplest supported path is:

1. Install the signed runsc package or official binary.
2. Run runsc install to add it as a Docker runtime.
3. Reload Docker.
4. Start a container with --runtime=runsc.

Production deployments should follow the official production guide. Networked setup normally needs temporary privileges; runsc drops them before untrusted code starts. Rootless mode is possible, but rootless networking has limitations.

Network and Credentials

• Default networking: Netstack implements TCP/IP in the Sentry and moves raw packets through a host packet socket.
• Host networking: --network=host trades netstack’s isolation for native Linux networking and performance.
• Policy: gVisor does not replace container-level network policy. Apply outbound rules outside the sandbox.
• Credentials: gVisor has no built-in secret broker. Environment variables, files, sockets, and mounted credentials remain visible to code inside the sandbox if exposed.
• Filesystem: Open Container Initiative mount rules decide what host paths are visible. The convenience command runsc do exposes the host filesystem read-only by default and is not a production security example.

Strengths

• Smaller host-kernel surface than a standard shared-kernel container.
• Container integration without managing a separate guest operating system image.
• Memory-safe implementation for most of the application kernel.
• Flexible resources: CPU and memory behave more like processes than fixed VM allocations.
• Defense in depth: The workload is isolated from the Sentry, and the Sentry is restricted against the host.
• Mature ecosystem: Docker and Kubernetes support, production use at Google, detailed security documentation, and an Apache 2.0 license.

Limits

• Compatibility gaps: Linux features and system calls work only when gVisor implements them correctly. Some applications need testing or changes.
• Performance cost: System-call-heavy and filesystem-heavy workloads can be slower than native containers.
• Not a VM boundary: Hardware VMs remain the conventional strongest general isolation boundary.
• Linux host required: It is not a native macOS sandbox runtime.
• Operational work remains: Resource limits, network rules, mounts, secrets, logging, and tenant separation are operator responsibilities.
• Netstack API stability: Official docs say its API is fairly stable but not guaranteed and is not published with normal Go module versions.

Activity and Maturity

Checked 2026-07-14:

• The public repository showed about 18,900 stars, 1,800 forks, 11,393 commits, and 269 tags.
• Official documentation and installation channels remain active.
• The project publishes dated builds through Google Storage rather than GitHub Releases; GitHub’s Releases page is empty.
• Google describes it as production workload isolation, not a research preview.
• Assessment: Mature and actively maintained, but workload compatibility and performance still require validation.

Best Fit

• Running untrusted or generated Linux code at higher density than full VMs.
• Adding a stronger boundary to Docker or Kubernetes workloads.
• Multi-tenant build, test, function, or coding-agent infrastructure where standard containers alone are too weak.
• Teams able to test application compatibility and operate external network, resource, and secret controls.

Comparison

Option	Main boundary	Relative overhead	Compatibility	Best use
Standard container	Host namespaces and shared kernel	Lowest	Highest	Trusted workloads
gVisor	User-space application kernel plus restricted host access	Low to medium	Lower than native Linux	Untrusted Linux containers
Firecracker or full VM	Hardware virtualization and guest kernel	Higher	Broad Linux compatibility	Strong tenant isolation
Clawk netstack fork	Network allow-list inside a VM networking path	Small added network cost	Network path only	Clawk outbound filtering

Hacker News Context

• In the Clawk thread, a commenter listed gVisor among stronger container isolation layers that are more VM-like and may suit coding-agent sessions.
• The thread’s central concern was that ordinary containers share the host kernel. gVisor directly reduces that exposure, though it is still not identical to hardware virtualization.
• Clawk’s author separately explained that its gvisor-tap-vsock fork adds a tiny allow-list hook before TCP, UDP, and ICMP forwarding. That comment describes Clawk’s networking component, not a full gVisor deployment.
• Direct comments: stronger isolation suggestion, Clawk networking explanation, and fork explanation.

Direct Sources

• gVisor overview
• Security introduction
• Security model
• Networking and netstack
• Installation
• Platform selection
• Rootless limitations
• Production guide
• Performance guide
• Official Google repository
• Clawk HN discussion

Unknowns

• Clawk integration scope: The exact upstream revision and long-term update process for its gvisor-tap-vsock fork need repository-level verification.
• Workload performance: Current overhead depends heavily on system-call, storage, and network patterns; official docs do not give one representative number.
• Application compatibility: There is no universal answer. Test the exact container image and its kernel-feature needs.
• Security equivalence: No public source supports treating netstack reuse as equivalent to the full gVisor sandbox.

Sources

• • imported AI research note for Gvisor.