[sandbox audit] README: state the real security model and its known limitations - #15
Draft
Wauplin wants to merge 1 commit into
Draft
[sandbox audit] README: state the real security model and its known limitations#15Wauplin wants to merge 1 commit into
Wauplin wants to merge 1 commit into
Conversation
An internal security review found gaps between what the README promises and
what the server delivers. The code fixes follow as separate PRs; this
documents the current state first, so nobody deploys host mode on the
strength of a guarantee it does not provide.
- SBX_TOKEN is one token per server process, not per sandbox. In host mode
it authorizes every /v1/sandboxes/{id}/* route for every sandbox plus the
pool-management routes, so a leak is host-wide. Said so explicitly, and
flagged the fail-open case in the configuration table.
- The host-mode file-path paragraph implied a confined path; the rooting is
lexical, not symlink-proof. Pointed it at the new section.
- Added a "Known limitations" section: both route surfaces always
registered, the file API and port proxy following symlinks as root,
fail-open auth, fail-open Landlock and ABI 1 acceptance, unclamped
caller-supplied limits and the unchecked memory multiplication, the HTTP
front end's missing deadlines/caps and lax parsing, DELETE /processes
answering 200 for an unknown id, the process-supervision gaps, and the
unauthenticated /health plus the non-CSPRNG id fallback.
No code change. Each subsequent hardening PR should delete its entry from
that section, so it doubles as the remediation tracker.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Wauplin
marked this pull request as draft
September 8, 2026 13:07
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
An internal security review of the Sandbox API found gaps between what the docs promise and
what the server delivers. The code fixes follow as separate PRs; this documents the current
state first, so nobody deploys host mode on the strength of a guarantee it does not provide.
No code change.
What changed
Token scope.
SBX_TOKENis one token per server process, not per sandbox. In dedicatedmode the job is the sandbox so the two coincide; in host mode the same value authorizes every
/v1/sandboxes/{id}/*route for every sandbox plus the pool-management routes, so a leak ishost-wide. Said so explicitly.
New "Known limitations" section listing what is currently unhardened in host mode:
/v1/execand friends stay live in host modeand run as the server's root identity (and
/v1/sandboxes*stays live in dedicated mode)<home>/.sbx/proxy/<port>.sockby name, withoutO_NOFOLLOWorSO_PEERCRED, and does not validate<port>in host modeSBX_TOKENis unset or empty(TCP bind) and ABI 6 (abstract-socket scoping)
max_procs/max_mem_mbare unclamped and the memory multiplication is notchecked_mul; an invalidSBX_CAPACITYbecomesusize::MAXtreats an invalid
Content-Lengthas zero, and authenticates a hijacked proxy connectiononly once
DELETE /v1/processes/{id}answers 200 for an unknown idraw pid, foreground commands invisible to the idle watchdog,
setsidsurvivors, unreapedorphans at PID 1, non-recycled uids (~45k creations per host lifetime)
/healthis unauthenticated; sandbox ids fall back to a timestamp if/dev/urandomfailsAlso flagged the two places in the existing text that read as stronger guarantees than they
are: the
SBX_TOKENrow in the configuration table, and the host-mode file-path paragraph.Companion
huggingface/huggingface_hub#4831 does the same for the user-facing docs.
Follow-ups
Each hardening PR should delete its entry here, so the section doubles as the remediation
tracker. Next up: the file API and port-proxy symlink handling, then route-surface separation
and fail-closed auth.