refactor: make Linux bootstrap independent of shell utilities

[jy-tan]

Summary

Replace the generated shell-based Linux bootstrap with a short-lived Go initializer and dedicated bridge helper. Fence initialization no longer depends on shell utilities that can be collaterally masked when runtime-denied commands share a multicall binary, fixing the Nix/BusyBox failure behind #90.

Changes

• add versioned bootstrap and bridge plans with bounded transport and strict endpoint, duplicate-listener, and reserved-port validation
• move runtime environment repair and sandbox-side HTTP/SOCKS, reverse, and local-outbound relays into Go
• preserve workload process identity by execing through the existing argv and Landlock security chain after bridge readiness
• tie bridge and runtime-directory cleanup to workload lifetime using pidfd monitoring with a parent-PID fallback
• bound relay concurrency and handle transient resource exhaustion without terminating all sandbox bridges
• use direct random host proxy ports when the workload shares the host network namespace, avoiding fixed-port and exposed-service collisions
• preserve Fence’s private /tmp mount even when /tmp is explicitly allowlisted for writes
• centralize private helper dispatch and expose helper-backed Landlock and argv policy to Go library users
• remove the generated shell bootstrap and sandbox-side socat staging (host-side socat remains for a follow-up PR)
• add relay, lifecycle, library, bridge-parity, shared-network, and BusyBox/coreutils multicall regression coverage
• update architecture, mount-order, Linux security, library, and testing documentation

Compatibility

Linux library callers must now configure a compatible helper with Manager.SetLinuxHelperPath. Applications using their own executable as the helper must dispatch private modes through fence.DispatchInternalHelper. The Fence CLI configures this automatically.

[cubic-dev-ai]

We've triggered an ultrareview automatically — This is a significant refactor of the core Linux sandbox initialization path, replacing shell-based bootstrapping with a Go initializer. It touches security-critical components like Landlock enforcement, network relay logic, and the process execution chain.... I'll post findings when complete.

An ultrareview is cubic's deepest review, catching hard-to-find bugs in the most critical PRs. It runs a longer, multi-pass analysis using cubic's most capable review models, and typically takes around 30 minutes. It consumes your team's reviewed-lines allowance at 3× the standard rate.

Automated ultrareviews are disabled by default. We triggered this run as part of your trial. Want cubic to do this for every high-risk PR? Enable auto-ultrareview in your settings.

[cubic-dev-ai]

Ultrareview completed in 30m 30s

All reported issues were addressed across 32 files

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[cubic-dev-ai]

All reported issues were addressed across 16 files (changes from recent commits).

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[dwt]

If I read those tests correctly, they only trigger if busybox is installed, while they could also trigger if coreutils is installed (that should trigger them during the nixos build in the nixos build sandbox).

I am currently experimenting with adding a nixos-vm test to the nixpkgs build definition that actually creates a nixos-vm, and checks the behavior of fence inside of it.

Would you be interested to extend the nix code in this repo to customize said test with a locally built binary so this test is also runnable from this repo?

[jy-tan]

@dwt I'll look into generalizing the multicall regression test. And yes, happy to include a NixOS VM test in this repo.