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

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

Layer 2: Seccomp-BPF (Linux/KVM)
  — 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
  — Linux/KVM: SLIRP rate limiting, max connections, CIDR deny list
  — macOS/VZ: NAT networking without those host-side filters yet

Layer 1: Hardware Isolation (KVM / VZ)

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 (Linux/KVM)

On Linux/KVM, the VMM thread is restricted via seccomp-BPF to only the syscalls needed for KVM operation: KVM ioctls, vsock communication, and networking syscalls. On macOS/VZ this layer does not apply.

Layer 3: Session Authentication (vsock)

Every VM gets a unique 32-byte random session secret, injected via kernel command line. The host authenticates each control connection with a Ping/Pong handshake before sending any ExecRequest, WriteFile, PTY, or telemetry-subscription messages.

Host                                    Guest
  |                                       |
  +-- getrandom(32 bytes)                 |
  +-- hex-encode -> kernel cmdline        |
  |   voidbox.secret=abc123...            |
  |                                       |
  |              boot                     |
  | ----------------------------------->  |
  |                                       +-- parse /proc/cmdline
  |                                       +-- store in OnceLock
  |                                       |
  +-- Ping [secret + version]             |
  | ----------------------------------->  |
  |                                       +-- verify secret
  |                                       +-- mark connection authenticated
  | <-----------------------------------  |
  |  Pong [version]                       |
  |                                       |
  +-- ExecRequest { ... }                 |
  | ----------------------------------->  |
  |                                       +-- execute on authenticated channel
  | <-----------------------------------  |
  |  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

Linux/KVM 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

On macOS/VZ, networking is provided by VZNATNetworkDeviceAttachment. The VM boundary still applies, but host-side SLIRP controls such as CIDR deny lists, rate limits, and connection caps are not enforced there yet.

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. Operationally, treat cloned snapshots as cloned execution state: use short-lived tasks, avoid assuming fresh entropy after restore, and rebuild snapshots when that matters.

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.