Summary

Closes the "subprocess plugin sandbox runs wide open" security issue (#2) by making the sandbox secure-by-default.

Plugin hook subprocesses previously ran with network and filesystem access enabled by default, and the Linux seccomp / Landlock backends were not in the runtime's default feature set — so the shipped binary applied no syscall or LSM filtering at all unless an operator hand-enabled the features and every plugin opted into restriction. This flips the posture: deny by default, opt in explicitly.

Changes

Breaking: secure-by-default

• allow_network / allow_filesystem now default to false (were true) in every default source, kept consistent:
  • HookConfig::default() in crates/librefang-runtime/src/plugin_runtime.rs.
  • The serde default for ContextEngineHooks in crates/librefang-types/src/config/types.rs — the two fields moved from #[serde(default = "default_true_bool")] to plain #[serde(default)] (bool false). The now-unused default_true_bool helper is removed. This also makes the derived Default and the serde-omitted default agree; before this change they silently disagreed (derived Default already produced false, serde produced true).
• seccomp-sandbox and landlock-sandbox are added to the runtime's default feature set.

Cross-platform gating (confirmed)

The Linux-only deps seccompiler and landlock were under plain [dependencies]. Adding the features to default as-is would have pulled them into the macOS / Windows dependency graph and broken those CI lanes. They are now moved under [target.'cfg(target_os = "linux")'.dependencies], so:

• The dep:seccompiler / dep:landlock feature activations are no-ops on non-Linux targets (the dep simply isn't present for that target).
• All code that references these crates is already #[cfg(all(target_os = "linux", feature = ...))], so the source compiles unchanged on every platform.

cargo check -p librefang-runtime --lib (which now builds with the new default features) compiles cleanly in the Linux dev container. Verified on Linux only (the dev container is Linux). The macOS / Windows builds need CI confirmation — the change is the dependency-section move above, which is the standard pattern for platform-gated optional deps, but it has not been compiled on those hosts here.

Two latent bugs surfaced by turning the sandbox on by default

Both are in the same file / feature as the change, so they are in-scope rather than deferred:

• Seccomp allowlist was incomplete. With seccomp-sandbox off by default the allowlist was never exercised by the standard test path. Enabling it by default revealed that the ~60-syscall KillProcess allowlist was missing glibc / language-runtime start-up syscalls (rseq, set_robust_list, get_robust_list, rt_sigtimedwait, restart_syscall, clock_getres, sched_getaffinity, sched_yield, statx, membarrier). Every hook child (/bin/sh, python3) was SIGSYS-killed before it read stdin, surfacing to the parent as "Broken pipe". Added the universal start-up set (present on both x86_64 and aarch64).
• unshare namespace probe was wrong. try_wrap_with_unshare / try_wrap_with_unshare_mount probed unshare --help to decide whether to wrap a deny-network / deny-filesystem hook. --help succeeding does not mean the kernel will grant the namespace: in unprivileged containers (Docker without --privileged) and hardened CI, CLONE_NEWNET / CLONE_NEWNS returns EPERM. The wrapper was therefore prepended, unshare exited non-zero before exec, and the child was killed — which, now that deny is the default, would break essentially every plugin in such environments. The probe now runs unshare --<ns> -- true and only wraps when the namespace can actually be created; otherwise it falls open to the env-var / Landlock soft isolation that is applied separately (never fatal to the hook).

Migration (operator action required)

Existing plugins that relied on the old open-by-default behaviour will stop reaching the network / writing files after upgrade until they declare the access in their plugin.toml:

[hooks]
allow_network = true       # only if the plugin needs outbound network
allow_filesystem = true    # only if the plugin needs to write files

A plugin that needs neither requires no change. Hooks that only read stdin and write stdout (the common case) keep working with no edit.

Tests

• librefang-types: omitted [hooks] flags deserialize to deny; explicit opt-in is honoured; derived Default matches the serde-omitted default. (context_engine_hooks_omitted_sandbox_flags_default_to_deny, context_engine_hooks_explicit_opt_in_is_honoured)
• librefang-runtime: HookConfig::default() denies both (hook_config_default_denies_network_and_filesystem); locked_down_default_hook_completes_round_trip runs a hook under the full deny-by-default sandbox (seccomp filter applied + unshare-or-fallback) and asserts a clean JSON round trip — the direct regression guard for both the seccomp allowlist completeness and the unshare probe.

Verification (Linux dev container)

• cargo check -p librefang-runtime --lib — clean (compiles with the new default features incl. seccomp + landlock).
• cargo clippy -p librefang-runtime --lib -- -D warnings — zero warnings.
• cargo test -p librefang-runtime --lib plugin — 58 passed, 0 failed.
• cargo test -p librefang-types context_engine_hooks — 2 passed, 0 failed.
• cargo fmt -p librefang-runtime -p librefang-types --check — clean.

Cross-platform caveat for reviewers

Docker-based verification covers Linux only. Please confirm the macOS and Windows CI lanes are green — the only platform-sensitive change is moving seccompiler / landlock under [target.'cfg(target_os = "linux")'.dependencies]; the runtime code paths that touch them are already Linux-gated, so non-Linux builds should treat the new default features as no-ops, but that has not been compiled outside the Linux container here.