description: Aspirational : running a PKGBUILD in an isolated sandbox before approving it.¶
Running the Sandbox¶
Note: The sandbox is not yet available in the current release. This page describes the planned design.
The sandbox executes a candidate PKGBUILD's build and install scripts in an isolated environment. The goal is to catch runtime behaviour that static analysis cannot: unexpected network connections, file writes outside the build directory, or shellcode concealed through obfuscation.
Opt-in only¶
The sandbox is never implicit in trustsight review. It is an explicit, per-package step you opt into when the review raises a question that static analysis cannot answer.
Isolation backends¶
Two isolation levels are planned:
| Backend | Boundary | Use case |
|---|---|---|
| Namespace (best-effort) | Linux user / PID / mount namespace | Quick check : catches accidental writes and obvious network access. Rootless. |
| VM (categorical) | Full virtual machine boundary | Strong isolation. The guest cannot observe or affect the host. Requires root or a hypervisor. |
The namespace backend is best-effort: a determined sandbox escape is possible. The VM backend provides a categorical boundary; an escape lands in an empty, disposable box.
Network default-deny¶
The sandbox enforces default-deny networking:
- Outbound connection attempts are blocked by default.
- A blocked attempt is a signal in the report: not a silent failure.
- If the PKGBUILD needs network access during build (e.g.
go mod download), the sandbox records every destination and includes it in the evidence output.
What the sandbox produces¶
After execution, the sandbox reports:
- Files written: every file created outside the build directory, with hashes.
- Network connections: every attempted outbound connection, blocked or allowed.
- Process tree: every subprocess spawned, with arguments.
- Exit code: whether the build succeeded.
This evidence feeds into the same evidence tier system as the static rules. Runtime findings contribute to tier A (structural) or tier D (verification).
Ceiling: "observed clean" ≠ safe¶
A sandbox run that produces no suspicious output is informative but not conclusive. The sandbox observes a single execution trace. A malicious PKGBUILD can:
- Check for the sandbox environment and behave differently.
- Trigger only on a specific date, network condition, or dependency version.
- Use a timing bomb that activates after install.
The ceiling of sandbox analysis is "observed clean in this specific execution." Treat a clean sandbox as evidence, not proof.
Security model¶
When to use the sandbox¶
| Situation | Use sandbox? |
|---|---|
| Routine version bump, CLEAN verdict | No : static analysis is sufficient |
| FLAGGED, MEDIUM score, novelty only | Optional : inspect first, sandbox if uncertain |
| FLAGGED, HIGH or CRITICAL | Yes : especially if the diff contains new commands or obfuscation |
| FATAL rule (R012/R013) | Sandbox is not useful : do not install. Prompt injection cannot be safely executed. |
| INCONCLUSIVE, cold database | Consider sandbox : it adds runtime evidence the static model lacks |