Agent 沙箱全景洞察

Principle — isolate by lying, not by virtualizing. Instead of running a second kernel, you tell the one shared kernel to give a group of processes a privatized, filtered view of the system. The processes believe they own the machine; they only see what the kernel permits.

Mechanism

• Namespaces partition the view. Eight flavors exist: PID (own process tree), NET (own network stack + routing table), MNT (own mount tree), IPC, UTS (hostname), USER (UID remapping — a fake root), CGROUP, TIME. Created via clone() / unshare() with flags.
• cgroups v2 partition the budget — CPU, memory, block I/O, PID count — with kernel-enforced hard limits and accounting.
• Capabilities shatter the monolithic root into ~40 granular bits (e.g. CAP_NET_BIND_SERVICE); containers drop everything they don't need.
• seccomp-bpf installs a BPF filter that denies any syscall not on an allow-list (blocks kexec_load, keyctl, …).

Principle — full hardware isolation (a real guest kernel), but amputated to boot in milliseconds. AWS built Firecracker because QEMU carried too much legacy. The bet: a Virtual Machine Monitor that emulates almost nothing, so there is nothing slow to initialize and almost nothing to exploit.

Mechanism (Firecracker)

• VMM, not QEMU. A purpose-built process that drives KVM directly via ioctl. One Firecracker process == one microVM. No BIOS, no firmware.
• Minimal device model. The only emulated devices are virtio-based: virtio-net, virtio-block, virtio-rng, virtio-vsock, a serial console. No PCI bus enumeration, no legacy devices. Less code → smaller attack surface → faster boot.
• The Jailer. A separate binary that sets up a sandbox before exec-ing Firecracker: chroot into an empty root, drop privileges, apply cgroup limits, configure namespaces. Defense-in-depth around the VMM itself.
• Seccomp filters auto-installed — Firecracker's own syscall surface is restricted to a strict allow-list.
• Rate limiters — token-bucket throttling on virtio-net (bandwidth + pps) and virtio-block (throughput + IOPS), enforced in the VMM with zero guest cooperation. This is how multi-tenant platforms contain noisy neighbors.

Principle — give every container its own dedicated, fully-featured virtual machine. To Kubernetes it looks and feels like a container; underneath, each pod is a real VM. You trade startup speed for the strongest boundary in the container world.

Mechanism (Kata)

Docker / Kubernetes (CRI)
        │  OCI spec
        ▼
kata-runtime  ──►  virtcontainers   (sandbox abstraction layer)
        │  creates & manages
        ▼
┌─────────────────────────────────────┐
│  QEMU / KVM Virtual Machine         │   ← the actual "sandbox"
│   ┌─────────────────────────────┐   │
│   │  kata-agent  (gRPC)      │   │   ← runs inside the guest
│   └─────────────────────────────┘   │
└─────────────────────────────────────┘
        ▲   stdio (stdin/stdout/stderr)
   kata-shim    re-attaches to the process inside the VM
   kata-proxy / vsock   host↔guest control channel (vsock in ≥2.x)

• kata-runtime is an OCI-compatible runtime; virtcontainers is the library that abstracts the hypervisor (QEMU, Cloud Hypervisor).
• kata-agent runs inside the guest and executes container lifecycle commands over gRPC.
• kata-shim re-attaches stdio so docker exec / kubectl logs work transparently with in-VM processes.
• kata-proxy (legacy) mediated host↔guest comms; Kata 2.x replaced it with vsock for direct, simpler channels.

Principle — the untrusted workload never touches the host kernel. gVisor (Google, written in Go) implements a user-space version of the Linux kernel interface. Every syscall the application makes is intercepted and emulated in user space. The host kernel only ever sees a normal, unprivileged process issuing a handful of boring syscalls.

Mechanism (gVisor)

┌────────────────────── sandbox ──────────────────────────┐
│   Application (ring 3)                                  │
│        │  syscall instruction → trap        │
│        ▼                                                │
│   ┌─────────┐   emulated            ┌────────┐          │
│   │ SENTRY  │ ◄──────────────────►  │ GOFER  │          │
│   │ (user-  │      9P (9p2000.L)     │ (file  │          │
│   │  space  │   over Unix socket     │  proxy)│          │
│   │  kernel)│                       └────────┘          │
│   └─────────┘                                           │
└──────────────────────┬──────────────────────────────────┘
                       │  only safe, mediated syscalls
                ┌──────▼──────┐
                │ HOST KERNEL │   ← the app never reaches this directly
                └─────────────┘

• Sentry — the user-space kernel. Intercepts and implements every syscall; runs as an unprivileged host process. Most syscalls (futex, mmap, scheduling) are handled entirely inside it.
• Gofer — a separate unprivileged process that performs real filesystem operations on the Sentry's behalf. The app never opens host files directly.
• 9P — Sentry and Gofer speak the Plan-9 filesystem protocol (9p2000.L) over a local Unix domain socket.
• Platform (how syscalls get trapped into the Sentry):
  • ptrace (PTRACE_SYSEMU) — works on any Linux, but two context switches per syscall → slow.
  • KVM (preferred) — the app runs in guest ring-3 of a featherweight KVM VM; the syscall instruction fires a hardware VM-Exit routed (via MSR_LSTAR) straight into the Sentry. Faster, and the host kernel is bypassed entirely.

Principle — isolation is a property of the execution model itself, not a wrapper around it. A WASM module has no ambient authority. It cannot touch the filesystem, the network, or any memory outside its own bounds unless the host explicitly hands it a capability.

Mechanism

• Capability-based security. Unlike a Linux process (which inherits ambient authority — "I can attempt to open any path"), a WASM module starts with nothing. Hosts grant narrow handles — a pre-opened directory, an HTTP client — via WASI (WebAssembly System Interface).
• Linear memory, no forged pointers. WASM memory is one bounds-checked byte array; there is no instruction that can forge a pointer into host memory.
• Validated ahead of time. Modules are type-checked before execution; runtimes (Wasmtime, Wasmer — Bytecode Alliance) compile to native code with near-native speed.
• Millisecond cold start and a tiny footprint.