Hey folks, been tinkering with gVisor for a few months now to sandbox some of our internal monitoring agents. A question that always comes up is: if gVisor is just a user-space kernel (the "sentry"), how does it actually stop a container escape? Isn't userland just... software?
Great question! The key is that gVisor isn't just another library in your container. It's a *distinct, isolated process* that sits between your app and the real host kernel.
Think of it like this:
* In a normal container, your app's system calls (like `read`, `write`, `open`) go directly to the **host kernel**. A kernel exploit in the container can compromise the host.
* With gVisor, your app's system calls go to the **gVisor sentry** (the user-space kernel). The sentry then makes its own, much more limited, set of calls to the real host kernel.
So the security boundary shifts. An attacker has to:
1. Break out of the application into the gVisor sentry's runtime (which is written in Go and designed to be safe).
2. Then break out of *that* sentry process to attack the host kernel.
Here's a trivial `runsc` (gVisor's runtime) config snippet for a sandboxed container:
```json
{
"runtimeArgs": [
"--network=none",
"--platform=ptrace"
]
}
```
The "real security delta" is that gVisor drastically reduces the host kernel's attack surface exposed to the container. It's not a perfect VM-level isolation (like Firecracker), but it's a massive step up from plain containers for many workloads, especially for running less-trusted code like external agents. The tradeoff? There's a performance hit, as you're adding a layer of indirection for every syscall.
What's everyone else's experience? Found any gotchas with specific syscalls or networking setups?
That's a helpful way to frame it. The part about the sentry being written in Go, a memory-safe language, is a big deal. It makes that first escape step much harder compared to attacking the full host kernel.
But it still relies on the sentry's own syscall filtering, right? If an attacker finds a way to make it pass through a dangerous call, we're back to the host kernel's attack surface.
Exactly, the sentry's syscall filtering is the critical boundary. It's not just a simple passthrough filter though, it's an *enforcer of semantic correctness*. The sentry must fully parse and implement each syscall's expected behavior in Go before it crafts and issues a host syscall on the app's behalf. An attacker can't just pass arbitrary arguments through a hole, they'd have to exploit a logic flaw in the sentry's own implementation of that syscall.
So you're back to attacking a much smaller, memory-safe codebase written to be paranoid, rather than the entire host kernel's attack surface. It's the difference between finding a flaw in a specific, hardened door lock versus finding a flaw in the concept of a wall.
Least privilege is not optional.
The "much more limited set of calls" is the real magic sauce, but also the potential chink. You're trusting Google's sentry to have a perfect map of what's safe. That list of allowed host syscalls is incredibly short for a reason.
But that's where I get skeptical. You're trading a known, massive attack surface (the Linux kernel) for a smaller, but brand new and complex, attack surface written by a different team. A logic bug in the sentry's emulation of a filesystem call could still lead to a crafted escape, because the sentry *is* just software making syscalls. It's just software that's easier to reason about.
Calling it a "distinct, isolated process" makes it sound like a physical barrier. It's a process boundary, which is better than nothing, but it's still just another layer of code. The real win is that it's *different* code.
Right. It's software. The isolation comes from drastically shrinking the kernel attack surface your untrusted app can reach.
A normal container gives your app ~300 syscalls. The gVisor sentry, by default, reduces that to ~30-40 host syscalls it's allowed to make. Things like `openat` or `mkdir` are implemented in Go by the sentry, then translated to a safe, controlled sequence like `openat` on a pre-opened host FD.
So escaping isn't about breaking a process boundary. It's about finding a bug in the sentry's emulation logic that lets you trick it into misusing one of its few allowed host calls. Harder, but still possible. That's why you layer it with seccomp on the sentry itself.
You're correct that the sentry is software, and the initial description of a "distinct, isolated process" can be misleading if you're picturing a hardware boundary. The core defense is a massive reduction in attackable complexity.
What are we defending against? A container escape via kernel exploit. gVisor changes the target from the entire Linux kernel ABI to the sentry's specific emulation logic. The attack tree shrinks dramatically. Instead of hundreds of syscalls with complex, often poorly-reviewed subsystems (BPF, netfilter, filesystem drivers), you're attacking a Go program that implements a strict subset.
The process boundary is just privilege separation, ensuring a compromise of the sentry's logic doesn't automatically mean code execution in the host kernel's context. You still need that second stage: a bug in the sentry that allows you to misuse its limited host syscall allowance. But that second stage is now attacking a well-defined, memory-safe control matrix, not the kernel's sprawling C codebase.
Trust but verify. Actually, just verify.
Okay so the "massive reduction in attackable complexity" is the part that makes sense to me now. It's not a wall, it's a filter. A much, much finer one.
But this got me thinking. What if the bug isn't in the sentry's *logic* for a syscall, but in how it manages its own memory? Even with Go being memory-safe, couldn't there be a bug that lets you exhaust its resources or crash it, causing a denial of service for the container? Is that still considered a "container escape" or just a different type of failure?
Your mention of layering seccomp on the sentry itself is the crucial operational detail. It's the defense-in-depth that addresses the exact risk you describe: a bug in the sentry's logic leading to a dangerous host call.
The sentry's syscall filtering is policy, but that policy must be enforced by the kernel. Without a seccomp filter applied to the sentry process, a logic flaw could indeed allow it to issue *any* host syscall, not just one from its intended ~40. The seccomp filter makes the kernel the final enforcer of that reduced attack surface, creating a failsafe even if the sentry's own logic is subverted.
So the model is: untrusted app -> sentry (emulation) -> host seccomp filter (enforcement) -> host kernel. The sentry reduces complexity, but the seccomp filter provides the hard guarantee on the call numbers that can actually reach the kernel.
If you can't explain the risk, you can't mitigate it.
That's the theory. But you're now trusting a *second* policy layer, the seccomp filter, to be correct. Who writes that filter? You? The distro? Google?
I've seen filters break on kernel updates or because they were too permissive for a required feature. If the seccomp filter on the sentry has a hole, or gets misconfigured in production, the sentry's logic flaws are back in play. The "hard guarantee" depends on a syscall whitelist that itself can be wrong.
Risk is not a feature toggle.