Security Model

Defense in Depth

VoidBox uses a layered security model with five distinct isolation boundaries. Each layer provides independent protection — compromise of one layer does not grant access through subsequent layers.

Five Layers of Defense

Defense in depth

Layer 1: Hardware isolation (KVM)
  — Separate kernel, memory space, devices per VM

Layer 2: Seccomp-BPF (VMM process)
  — VMM thread restricted to KVM ioctls + vsock + networking syscalls

Layer 3: Session authentication (vsock)
  — 32-byte random secret, per-VM, injected at boot

Layer 4: Guest hardening (guest-agent)
  — Command allowlist, rlimits, privilege drop, timeout watchdog

Layer 5: Network isolation (SLIRP)
  — Rate limiting, max connections, CIDR deny list

Layer 1: Hardware Isolation (KVM)

Each VoidBox runs in its own micro-VM with a separate kernel, memory space, and devices. Hardware virtualization enforces isolation — not advisory process controls. On macOS, Apple's Virtualization.framework provides equivalent hypervisor-level isolation.

Layer 2: Seccomp-BPF (VMM Process)

The VMM thread is restricted via seccomp-BPF to only the syscalls needed for KVM operation: KVM ioctls, vsock communication, and networking syscalls. All other syscalls are blocked at the kernel level.

Layer 3: Session Authentication (vsock)

Every VM gets a unique 32-byte random session secret, injected via kernel command line. The guest-agent requires this secret on every request.

Session secret flow

Host                                    Guest
  |                                       |
  +-- getrandom(32 bytes)                 |
  +-- hex-encode -> kernel cmdline        |
  |   voidbox.secret=abc123...            |
  |                                       |
  |              boot                     |
  | ------------------------------------> |
  |                                       +-- parse /proc/cmdline
  |                                       +-- store in OnceLock
  |                                       |
  +-- ExecRequest { secret: "abc123..." } |
  | ------------------------------------> |
  |                                       +-- verify secret
  |                                       +-- execute if match
  | <------------------------------------ |
  |  ExecResponse { ... }                 |

Layer 4: Guest Hardening (guest-agent)

The guest-agent (PID 1) enforces four independent controls:

Command Allowlist

Only approved binaries execute. The allowlist is read from /etc/voidbox/allowed_commands.json, provisioned by the trusted host at boot.

Resource Limits

setrlimit enforces memory, file descriptor, and process count limits. Read from /etc/voidbox/resource_limits.json.

Privilege Drop

Child processes run as uid:1000. The guest-agent drops privileges before executing any command, preventing root access inside the VM.

Timeout Watchdog

A watchdog timer sends SIGKILL to child processes that exceed the configured timeout, preventing runaway execution.

Layer 5: Network Isolation (SLIRP)

VoidBox uses smoltcp-based usermode networking (SLIRP) — no root, no TAP devices, no bridge configuration.

Rate limiting on new connections — prevents connection floods from guest
Maximum concurrent connection limit — bounds host resource usage
CIDR deny list — configurable via ipnet, blocks access to specified network ranges

Snapshot Security Considerations

Snapshot cloning shares identical VM state across restored instances. Three areas require awareness:

RNG Entropy

Restored VMs inherit the same /dev/urandom pool. Mitigated by: fresh CID per restore, hardware RDRAND re-seeding on rdtsc.

ASLR

Clones share guest page table layout. Mitigated by: short-lived tasks, no direct network addressability (SLIRP NAT), command allowlist limiting attack surface.

Session Isolation

Restored VMs reuse the snapshot's stored session secret for vsock authentication (the secret is baked into the guest's kernel cmdline in snapshot memory). Per-restore secret rotation would require guest-side support.