Architecture • Platform Isolation
Platform Sandboxing Support
RTQ delegates execution containment to platform security mechanisms rather than relying on soft in-process JavaScript checks. Below is the exact evidence, test runner, and known limitations for each supported operating system.
macOS
Apple Seatbelt (sandbox-exec driver)
Compiles Scheme profiles (.sb) dynamically. The kernel driver enforces filesystem subpath allowlists, blocks network sockets, and restricts process execution.
Seatbelt is marked deprecated by Apple in modern macOS versions. Live tests demonstrate file-write and network egress denial, but do not guarantee resistance against kernel-level exploits.
Linux
bubblewrap (bwrap) namespaces
Generates argument vectors for bwrap to isolate PID, mount, IPC, UTS, and network namespaces. Binds host root as read-only and allocates private tmpfs.
Requires the bubblewrap binary installed on the host system. The current Linux test suite asserts argument construction and probe detection; it does not execute live adversarial rootkit binaries in CI.
Windows
AppContainer & Windows Job Object
Executes via PowerShell runner script configuring low-privilege AppContainer SIDs and Job Objects to restrict process capabilities and memory.
Requires Windows 10/11 or Windows Server with PowerShell. Test suite verifies runner script fail-closed behavior and output parsing; does not test native Win32 token isolation against kernel driver bugs.
Fail-Closed Sandbox Invariants
The sandbox execution path rejects execution when the required sandbox backend cannot be initialized. RTQ does not silently fall back to unsandboxed execution:
- •macOS: If
/usr/bin/sandbox-execis missing or returns a configuration error, execution fails withE_SANDBOX_INIT_FAILED. - •Linux: If
bwrapis absent from PATH, execution is blocked before spawning child processes. - •Windows: If AppContainer profile creation or job assignment fails, the runner script exits with code 1 and reports
sandboxed: false.