Skip to content

Plane 3: 0ms OS In-Kernel Sandboxing

The third and final defense plane enforces boundaries directly at the operating system kernel level. Even if an attacker completely bypasses prompt instructions or executes an un-parsed shell command, the OS hardware will refuse the forbidden syscalls.

Zero VM Lag vs. In-Kernel Execution

Architecture Startup Latency Memory Overhead Filesystem Isolation Network Egress Control
Docker / Container 1,200 – 3,500ms 100 – 400 MB Container Rootfs Bridge / iptables
MicroVM (Firecracker) 500 – 1,500ms 128 MB Virtual Disk TAP device
ctxsec In-Kernel 0ms (Native) 0 MB (Static Go) Native Kernel Chroot Native Kernel EPERM

macOS: Apple Seatbelt Profile Language (SBPL)

On macOS, ctxsec dynamically generates Scheme-based Apple Seatbelt profiles invoked via sandbox-exec:

(version 1)
(deny default)

;; Allow basic process execution & Darwin sysctl
(allow process-exec)
(allow sysctl-read)

;; Allow system binary and library reading
(allow file-read* (subpath "/System"))
(allow file-read* (subpath "/usr"))
(allow file-read* (subpath "/bin"))

;; Restrict write operations exclusively to workspace scratch
(allow file-write* (subpath "/Users/binary/Documents/code/go/ctxsec/local/scratch"))

;; Physically drop network egress
(deny network-outbound)

Attempting to connect to an external server results in an instantaneous kernel denial: 

curl: (7) Failed to connect to evil.com port 80: Operation not permitted

Linux: Bubblewrap (bwrap)

On Linux, ctxsec wraps child processes with unprivileged user namespaces and seccomp filters:

bwrap \
  --unshare-net \
  --ro-bind / / \
  --bind /path/to/workspace/local/scratch /tmp \
  --dev /dev \
  --proc /proc \
  /bin/bash -c "<command>"