gVisor vs seccomp-bpf: Sandboxing Offensive Tools

Letting an agent run exploits forces an uncomfortable question: what happens when the tool it launches is malicious, or the agent itself gets it wrong? Our first answer was seccomp-bpf. The second, for higher-risk workloads, is gVisor. They don't compete — they stack.

seccomp-bpf: cheap and sharp

seccomp-bpf filters syscalls at the kernel level at near-zero cost. Perfect for known tools: you define the whitelist nmap or ffuf needs and everything else dies with SIGSYS. The catch: profiles are brittle, and a single extra allowed syscall can be an escape route.

seccomp:
  default_action: SCMP_ACT_ERRNO
  syscalls:
    - names: [read, write, openat, connect, socket]
      action: SCMP_ACT_ALLOW

gVisor: a kernel between you and the real one

gVisor intercepts syscalls in a user-space kernel written in Go: the binary thinks it's talking to Linux, but it's talking to Sentry. The real kernel surface exposed drops dramatically. You pay in performance, but you gain isolation against kernel 0-days.

How we choose

• Trusted tool, known profile: seccomp-bpf.
• Untrusted binary, third-party exploit, malware under analysis: gVisor, with seccomp-bpf inside.
• Always: cgroups for CPU/memory and per-scope network policies.

What we ship

Gwaihir selects the sandbox by the tool's trust level, not a global default. The common case runs under seccomp-bpf for speed; the risky case lands in gVisor. Defense in depth, not a single wall.