registry: isolate the documentation worker's runs from the service #233
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Follow-up of #17.
The documentation worker (
tools/registry/src/documentation.trb) runstorb doc --check --no-runandtorb docon a stranger's package. Those runs are bounded bytimeout,prlimitandenv -i, but they are not isolated. They run as the service's user, beside/srv/torb/registry,/srv/torb/databaseand the index mirror, and they can read/proc/<registry>/environ, which holds the signing key and the operator token.No code of the package runs, so this is defence in depth against a toolchain bug. The path-traversal bug fixed in the PR of #17 is one example of such a bug.
Proposal: render in a separate container or process with:
/srv/torbmounts, andThe service hands over the unpacked package and takes the site back. Bubblewrap is an alternative where user namespaces are allowed.
Acceptance: a render cannot read the service's environment or write to its files, and a test shows it.
Should be done before the worker is enabled in production.
Epic. Too large for one PR; steps (each its own issue when it starts):
security_opt/seccomp profile; a separate no-network renderer container if the probe cannot pass), live check that the worker starts; then the production switch-ontorb docfor every version #17[loop:torbscript] intake: in scope (author orion, label loop), follow-up of #17, not a duplicate. Registry hardening of the documentation worker (isolation of stranger packages); security-relevant, refine should pick the isolation mechanism. next: waiting (refine queued, ready buffer full) until 2026-10-10T04:00:00Z
[loop:torbscript] claim refine by session:loop-torbscript-20261026-1044 until 2026-10-26T11:56:08Z
[loop:torbscript] decided by the loop: isolation mechanism is bubblewrap inside the registry image, not a sibling container. Why:
sandboxedintools/registry/src/documentation.trbis the one place every run goes through, so a wrapper there meets all acceptance points (no network, read-only root, tmpfs, no/srv/torbmount, other uid, own pid namespace so/proc/<registry>/environis gone) without a new protocol, service or shared volume; a sibling renderer container would need a request/response channel for the package and the site (a second server in TorbScript, or a shared exchange volume) and is kept as the fallback for step 2 if user namespaces cannot be allowed in the container. Fail-closed: the worker refuses to start when the isolated--versionprobe fails.[loop:torbscript] refine: #233 is too large for one PR (code + image + deployment/seccomp + live proof), so it stays an epic without
ready; its checklist now holds both steps. Step 1 is filed as #497 (labelloop+ready, no keyword duplicate among the open issues; #236 and #234 touch the same file but other concerns), seed untouched, one commit. Step 2 (deployment, production switch-on) is filed when step 1 has landed. next: waiting (epic, step 1 = #497 ready for implement). Tokens: ~60k.