sandbox: nested passthrough is tier-blind — an in-sandbox strict request silently runs at the host tier

[buluoray]

Summary

wrap_argv()'s nested-sandbox passthrough is tier-blind: the KIROCREW_SANDBOX_ACTIVE marker check sits above the sandbox_level derivation, so an in-sandbox caller asking for a stricter tier than its host sandbox silently gets the host's tier instead.

# src/kiro_crew/sandbox.py (main)
1709:    if _inside_kirocrew_sandbox():        # marker check — tier not computed yet
             ...                              # audit + return argv unchanged
1766:        sandbox_level = "strict"          # derived only AFTER the passthrough

This affects both platforms and predates the macOS marker work in #686 (which does not touch these lines — git diff origin/main -- src/kiro_crew/sandbox.py | grep -c sandbox_level is 0).

Where it bites today

Dev Fleet runs inside an app backend spawned at standard (apps/backend.py:701), and asks for strict in six spawns. None of them has ever received it:

site	spawn
dev_fleet/server.py rebase (×2)	_run_cmd(..., mode="strict")
dev_fleet/server.py sync raw_steps (×3)	sandboxed_spawn_argv(argv, "strict") — ff-merge, pip install -e ., npm ci / npm run build
dev_fleet/server.py pod provision	sandboxed_spawn_argv(..., "strict")

At standard the credential directories are deliberately visible, so repo-controlled code executed by those steps (a worktree's pyproject.toml / package.json lifecycle scripts, a rebase applying its commits) runs without the hides the caller asked for. Partial mitigations exist and are unchanged: _GIT_ENV_NEUTRALIZERS pins core.hooksPath to /dev/null and clears core.fsmonitor / credential.helper, and the build steps get _build_env() without the operator's credential helpers. The tier is the gap, not the env.

Note for anyone grepping: a search for mode="strict" finds only two of the six — the other four pass the tier positionally as sandboxed_spawn_argv(argv, "strict"). An AST walk over Constant nodes finds all of them.

Why this is not a one-line fix

A nested wrap is impossible by design on both backends — Linux seccomp denies unshare, macOS Seatbelt refuses sandbox_apply with EPERM — so a sandboxed process cannot tighten the sandbox it is already inside. That leaves exactly three states, and each has a cost:

1. Declare standard honestly. The exposure remains, but stops being a silent lie; both tiers can be recorded in the passthrough audit event. Requires correcting the six sites, and decoupling one thing mode was doing double duty for in _run_cmd: mode == "standard" also gated whether the operator's git credential helpers were injected, so changing the tier alone would hand those helpers to exactly the rebase that must not have them.
2. Declare strict and fail closed on a proven downgrade. Isolation intent is honoured, but Sync and Provision stop working on both platforms — sandboxed_spawn_argv in the raw_steps loop has no except RuntimeError, so the refusal escapes as an HTTP 500 and leaks the already-collected cleanups temp profiles.
3. Make strict actually reachable. Repo-controlled builds are spawned by a process that is not inside the app-backend sandbox — i.e. the gateway wraps them at strict on the app's behalf. This is the only option that delivers the isolation the call sites believe they have. It needs an app → gateway spawn-delegation channel; today the relay runs the other way (gateway → app), and the app backend cannot be spawned at strict itself because Dev Fleet legitimately needs ~/.ssh and the git credential helpers for fetch and PR queries.

Prior art in the review history

#613 implemented (2), then (1), and each was blocked in turn by the same reviewer:

revision	finding	remedy requested
aac58ebf	passthrough permits a proven tier downgrade	refuse the downgrade
872d65db	the refusal breaks Dev Fleet Sync / Provision	preserve the passthrough
974beebf	repo-controlled builds now run at the credential-readable standard tier	restore strict

Worth reading before re-attempting either: both (1) and (2) have been written and reviewed, and the objections to each are on record in that PR.

Suggested scope for a fix

• Decide between (1) and (3) as a design question, ideally with the Dev Fleet owner — (3) is the real fix, (1) is an honest interim that makes the state auditable.
• Whichever is chosen, add a guard so the class of mistake cannot recur silently. An AST-based test over dev_fleet/server.py that rejects any "cc"/"strict" constant outside a docstring works, and catches the positional spelling that a mode="strict" grep misses.
• If (1): record active_tier and requested_tier in the passthrough SEL audit event so a downgrade is visible in the audit log rather than inferred.

Related

• fix(sandbox): mark KiroCrew's own macOS sandbox so nested spawns pass through #686 — macOS marker + diagnostics (does not change tier semantics; this issue is why its GPT 5.6 finding was overridden)
• fix(sandbox): treat macOS nesting EPERM as nesting, not a missing backend #613 — predecessor PR containing working implementations of both (1) and (2), plus the review discussion

[buluoray]

Correcting a factual claim in this issue's framing, and linking a prerequisite.

The app-backend → gateway channel already exists in this repo. My earlier read
("an app backend has no outbound path to the gateway; delegation needs a new
transport") was wrong — it came from grepping apps/builtins/*/server.py for outbound
HTTP and finding none, which is true but for the wrong reason: the mechanism exists,
the builtins just never use it.

What exists on main today:

• POST /api/apps/<name>/token with the per-app X-App-Secret
  (dashboard/handlers/core.py:1614) mints an app token from
  ~/.kirocrew/apps/<name>/.app_secret.
• Outbound calls carrying that token are gated deny-by-default by
  app_token_path_allowed() (dashboard/token_auth.py:1072) against the app's own
  namespace plus its declared permissions.api prefixes
  (_app_api_allowlist, :1008).

So delegation is one new route plus one new manifest field, not a new channel:

POST /api/apps/<name>/spawn          (gateway, unsandboxed)
  auth: app token; the path must appear in permissions.api  → existing gate, no new authz
  body: { shape: "<declared-shape-id>", args: [...], cwd, timeoutSecs }
  gateway: resolve shape → build argv → wrap_argv(argv, mode=<shape.tier>) → run
  resp:  { rc, stdout, stderr }      (+ an SSE variant for progress)

argv must be shape-declared in the manifest, never free-form — a free-form
delegated-spawn endpoint would be a privilege-escalation surface that undoes the gate
it sits behind.

Answers to the four open questions from the original design sketch:

1. Is the gateway unsandboxed? cli.py and gateway.py contain no wrap_argv —
   the gateway never wraps itself. But delegation only produces real strict when
   the gateway itself is not inside a foreign outer sandbox, so it must fail closed
   (not silently downgrade) when the gateway carries the nesting marker. Reuse
   _inside_kirocrew_sandbox() / _macos_sandbox_state() from fix(sandbox): mark KiroCrew's own macOS sandbox so nested spawns pass through #686.
2. Streaming or buffered? Buffered is enough for rebase and pod provision; sync
   renders per-step progress and needs streaming. Ship buffered plus an SSE variant for
   sync rather than making every caller pay for streaming.
3. Credential-helper decoupling. Once tier moves into the shape declaration, the
   git-credential-helper decision must become an explicit repo_controlled flag — it
   must not be implied by the shape's tier. This is the _run_cmd dual-purpose trap
   already recorded above.
4. Allowed argv — resolved by the shape ids.

Prerequisite: #693 (per-app WebSocket event scoping) establishes the
manifest-declaration + SEL-audit idiom on a read surface using the same app-token
gate. This issue is the write surface on that same gate and should follow it —
landing a write surface first front-loads the whole authorization argument.

[bolichen97]

🤖 Kiro Crew Auto-Pipeline [operator: bolichen97] — claimed for the automated security-batch fix run (2026-08-09). A task spec is being generated; an implementation session will open a PR referencing this issue.

[bolichen97]

🤖 Kiro Crew Auto-Pipeline [operator: bolichen97]

Fix opened: #2406

Scope per the triage plan (detect + audit, not fail-closed): both launchers now export KIROCREW_SANDBOX_LEVEL beside the ACTIVE marker; the passthrough compares requested vs active tier, adds requested_tier/active_tier/tier_known/tier_downgrade to the SEL metadata, warns SECURITY: per-call on a proven downgrade, and applies the requested tier's env-scrub delta through a trusted absolute env path. The passthrough return stays (option 1); the gateway spawn-delegation design (option 3) remains tracked here.