gVisor lane: request-supplied startup_script runs under the bundle CID's identity+key without being content-addressed

[clawdbot-glitch003]

Summary

On the gVisor any-language lane, a request-supplied startup_script executes under the bundle CID's identity and key material but is itself not part of the content-addressed, authorized artifact. Because CID-derived key access (lit get-action-private-key, getLitActionPublicKey({ipfsId}), group/PKP decrypt) is keyed by the bundle CID alone, anyone holding an execute-scoped usage key for the bundle's group can run arbitrary code that wields the audited bundle's key — by sending their own startup script against the cached bundle CID.

This breaks the property the JS lane provides and that our sovereignty story depends on: "the exact audited bytes are what ran, and only that code can hold the CID-derived key." On this lane, the CID no longer pins the code that runs.

Where it lives

• The endpoint forwards the request's startup_script straight through to the runner, beside the bundle, while authorizing only on the derived bundle checksum:
  • lit-api-server/src/core/core_features.rs — lit_binary_action: auth is can_execute_action(api_key, cid_hash) on the bundle checksum (resolve_binary_bundle derives it from the tar bytes), and ExecutionOptions { action_ipfs_id: Some(checksum), startup_script: request.startup_script.clone()… }. The startup script never enters the checksum.
• The supervisor materializes and runs the request script verbatim, request-script-wins:
  • lit-actions/gvisor-server/src/supervisor.rs — "the request-supplied script wins (one cached bundle, many scripts)".
• Key derivation is keyed by ipfs_id (= the bundle checksum), independent of the script:
  • lit-api-server/src/actions/client/op_code_helpers/private_keys.rs — get_lit_action_key(ipfs_id) → private key / public key / wallet address.
• The behavior is documented as intentional today:
  • lit-actions/gvisor-server/README.md: "authorization keys on the bundle CID alone; the per-request startup script is authenticated by API-key authorization, not content-addressing."

So the current guarantee is only: "someone authorized for this bundle ran some script with this bundle's key." It is not: "the audited bundle's own logic ran."

Concrete attack

1. Vendor publishes an audited bundle; its CID Qm… is registered in a group; the customer encrypts a secret to getLitActionPublicKey({ipfsId: Qm…}) and authorizes the CID.
2. A holder of any execute-scoped usage key for that group calls POST /lit_binary_action with checksum: "Qm…" (cache hit, no bundle bytes) and startup_script: a one-liner: lit get-action-private-key / lit aes-decrypt … / decrypt the customer ciphertext, then exfiltrate.
3. The sandbox runs the attacker's script under Qm…'s identity, hands it Qm…'s derived key, and it opens everything encrypted to the audited build — which the audited build would never have exfiltrated.

The audit of the bundle bytes provides no protection, because the audited bytes are not what executed.

Why the JS lane doesn't have this

On /lit_action, the executed code is the content-addressed artifact (code hashes to the CID; ipfs_id references previously-submitted code by that same hash). There is no separate, unbound "entrypoint override" channel, so the CID pins the running code and thus who can hold the CID key.

Requested fix (options, in preference order)

1. Bind the startup script into the authorized content id. When a startup_script is supplied, derive the authorized identity from hash(bundle_checksum ‖ startup_script) (or make the CID cover the script), so a different script ⇒ a different id ⇒ a separate authorization and a separate derived key. One cached bundle can still serve many scripts; each just authorizes and keys independently. Preserves the "cache the big bundle, vary the small script" ergonomic while restoring "the running code is what was authorized."
2. Opt-in lock. Let a bundle (via lit.json) or its registration declare startup_script_override: false, so key-bearing sovereign workloads can require the script to come from inside the CID. Requests supplying an override against a locked CID are rejected.
3. At minimum, gate + document. If the override stays unbound, refuse CID-key ops (get-action-private-key, group decrypt, aes-decrypt) when a request-supplied startup script is present, and make the security note in the README explicit that request-scripts must not be used with any CID that holds secrets.

Happy to test whichever lands against the test env — this is the one caveat blocking us from treating a gVisor bundle CID as a sovereign-workload identity the way we treat a JS action CID.

Context

Found while porting our sovereign code-review workload (client-encrypted secret in, CID-key-signed receipt out) from the JS lane to the gVisor lane. Everything else carried over cleanly — deterministic-tar CID, lane-independent key derivation, encrypt-to-CID, JCS/EIP-191 receipts — and is live-verified against test.chipotle.litprotocol.com. This is the remaining structural gap.

[GTC6244]

Confirmed — this is a real gap, and thank you for the precise writeup. Every claim checks out against the code, with one scheduling nuance:

The startup_script override channel isn't on main yet. It lives on the CPL-355 branch (PR #571). That's actually the good news: this is a pre-merge fix, so we can close the hole before the feature ships rather than after.

On that branch your analysis is accurate:

• lit_binary_action authorizes on the bundle checksum only (can_execute_action(api_key, cid_hash) where the checksum comes from resolve_binary_bundle, which hashes the tar bytes and never incorporates startup_script), then passes startup_script through in ExecutionOptions beside the bundle.
• The supervisor lets the request script win ("one cached bundle, many scripts"), materializing it as startup.sh.
• CID-derived key access (get_lit_action_key(ipfs_id)) is keyed by the bundle checksum alone, independent of the script.
• The README documents this as intentional ("authorization keys on the bundle CID alone; the per-request startup script is authenticated by API-key authorization, not content-addressing").

So the current guarantee is only "someone authorized for this bundle ran some script with this bundle's key," not "the audited bundle's own logic ran" — which, as you note, breaks the sovereignty property the JS lane provides.

Direction: option 1 (bind the script into the authorized identity). When a startup_script is supplied, derive the authorized id (and thus the key-derivation id) from hash(bundle_checksum ‖ startup_script) after resolve_binary_bundle returns, and use that for both can_execute_action and action_ipfs_id. This keeps the "cache the big bundle, vary the small script" ergonomic (the runner/bundle cache still keys on the raw bundle CID) while restoring "the running code is what was authorized/keyed." Implementation notes we'll carry into the fix:

• Registration UX changes: to hold CID-derived secrets you'd register/authorize hash(bundle ‖ script), not the plain bundle CID.
• Need a consistent rule for the no-request-script fallback (bundle-root startup.sh), which should keep the plain-CID identity — the composite id applies only when a request script is present.

We'll also fold in option 3 as defense-in-depth (and update the README security note) so the two are consistent. Marking this as a blocker on PR #571 landing with the override unbound. Appreciate the offer to test against test.chipotle.litprotocol.com — we'll take you up on it once the composite-id change is up.