PiCloud/security_audit/02_authz_isolation.md

Authorization & Cross-App Isolation

Audit date: 2026-06-11 Scope: Capability machinery, authz::{can, require, script_gate}, resolve_app, per-handler capability gating, SDK service app_id discipline, dispatcher fan-out, dashboard-supplied app ids, slug-history (redirected) path, public-script anonymous semantics.

Method (what I actually traced)

Two SDK paths traced from Rhai surface to SQL bind:

1. kv::collection("x").set(k, v) — bridge in crates/executor-core/src/sdk/kv.rs:45 captures Arc<SdkCallCx> set at crates/executor-core/src/engine.rs:218-228 (app_id: req.app_id), where req.app_id = script.app_id from crates/orchestrator-core/src/api.rs:123 (the resolver's row). The KvService::set impl at crates/manager-core/src/kv_service.rs:130-187 calls self.repo.set(cx.app_id, …) which lands at crates/manager-core/src/kv_repo.rs:113-127 with WHERE app_id = $1 AND collection = $2 AND key = $3. No script-controlled app_id enters the call chain. ✅
2. dead_letters::replay(id) — bridge at crates/executor-core/src/sdk/dead_letters.rs, impl crates/manager-core/src/dead_letter_service.rs:62-94. Capability check (AppDeadLetterManage(cx.app_id)) runs first; the row is loaded by id, then row.app_id != cx.app_id short-circuits to NotFound (line 67-71). Cross-app id probing is timing-flat with intra-app not-found. ✅

Two admin handlers traced from URL → resolve → require → repo:

3. DELETE /admin/apps/{slug}/triggers/{trigger_id} — crates/manager-core/src/triggers_api.rs:659-687. resolve_app (line 664) → require(Capability::AppManageTriggers(app_id)) against the RESOLVED app id (line 669) → load row → reject if trigger.app_id != app_id (line 680). No TOCTOU between resolve and authz; both run on the same app_id value. ✅
4. POST /admin/apps/{slug}/dead-letters/{id}/replay — crates/manager-core/src/dead_letters_api.rs:175-188. resolve_app → admin-synth SdkCallCx carrying the resolved app_id + principal (line 208-222) → service.replay(&cx, dl_id). Authz lives inside the service (above). ✅

Service-trait sweep: every *Service trait in crates/shared/src/{kv,docs,files,secrets,email,http,queue,pubsub,dead_letters,invoke,events}.rs takes &SdkCallCx and does NOT accept app_id as a side argument. The only methods with an explicit app_id parameter are admin-mediated UsersService::{verify_session_for_realtime, admin_*, list_invitations, revoke_invitation} — called from the manager-core HTTP layer or the realtime authority, never from a script bridge.

High

Queue dispatcher does not assert script.app_id == claimed.app_id

• Where: crates/manager-core/src/dispatcher.rs:290-340
• What: dispatch_one_queue claims a queue message scoped to consumer.app_id, resolves script by consumer.script_id (line 290), and builds an ExecRequest with app_id: claimed.app_id (line 334) and script_id: consumer.script_id — but never cross-checks that script.app_id == claimed.app_id. The analogous build_invoke_request does (line 752: if script.app_id != row.app_id { return Err(...) }), and the cross-app invoke guard in invoke_service.rs:83-85 does too. Trigger registration (triggers_api.rs:280-303 validate_trigger_target) blocks same-app divergence at create time, so today this is guarded by a write-path invariant only. If a trigger row is hand-edited, restored from a partial backup, or (future) script-move-between-apps is added, the dispatcher would happily execute a script from app B under app A's SdkCallCx — every kv::*, docs::*, files::*, secrets::*, pubsub::*, email::* SDK call would scope to app A. The script's source belongs to app B but reads/writes app A's data.
• Impact: Latent cross-app data read/write if any of the above ever holds. Defense-in-depth is missing on the single most security-critical fan-out path. The same gap is absent in the (sibling) build_invoke_request precisely because it was added there explicitly — the queue arm just wasn't audited the same way.
• Recommendation: Mirror the invoke guard. After self.scripts.get(consumer.script_id) succeeds, check if script.app_id != consumer.app_id { dead_letter the message + tracing::error!("queue trigger script app mismatch"); return; }. Same fix in build_http_request (dispatcher.rs:651-718) — its script.app_id is never compared to row.app_id, only used.

Medium

get_script and list_routes_for_script return 404 before authz — cross-app id enumeration

• Where: crates/manager-core/src/api.rs:184-197 (get_script), crates/manager-core/src/route_admin.rs:141-158 (list_routes)
• What: Both handlers load the resource by id and 404 if absent, before the authz check. A Member of app A who guesses a script_id belonging to app B observes 404 for non-existent ids and 403 for ids that exist in app B (authz denies on AppRead(script.app_id)). The discriminator confirms script-id existence across the whole instance. Same gap on the routes-for-script list. Note this contrasts with apps_api::create_script (line 204-213), which intentionally inverts the order to avoid app-existence enumeration ("checking authz first means a Member trying to create against an unknown app gets 403 (no enumeration of app existence)").
• Impact: Low-grade information leak — a malicious member can map out script-id space across apps. ScriptIds are UUIDv4, so brute-force enumeration is impractical, but ids leak through logs, error messages, and dashboard URLs (a former member with a stale screenshot can re-confirm validity post-revocation).
• Recommendation: Either (a) collapse NotFound and Forbidden to the same response for these two handlers, or (b) flip the order: do a cheap authz pre-check (you can't, because you need the resource's app_id) — so (a) is the practical fix. Same shape as the membership-on-other-app pattern already in use elsewhere.

Capability check on routes:check / routes:match trusts a body-supplied app_id

• Where: crates/manager-core/src/route_admin.rs:261-329
• What: Both handlers pull app_id from the JSON body (CheckRouteRequest / MatchRouteRequest) and authz against it. Because authz blocks a Member of app A from AppRead(B), this is currently safe at runtime. The structural risk: the dashboard sends { app_id: appId, … } from dashboard/src/lib/api.ts:709-718 and any future code path that strips authz (e.g., a "public health-check" wrapper, a new internal caller) would have no second line of defense — the resource (app) isn't path-bound and isn't loaded.
• Impact: Defense-in-depth gap. Inconsistent with every other recently-refactored handler (queues_api, files_api, secrets_api, topics_api, dead_letters_api, triggers_api) which path-bind the slug and load the app row before authz.
• Recommendation: Either move to POST /admin/apps/{slug}/routes:check (path-bind the slug, then resolve_app), or load state.apps.get_by_id(input.app_id) and fail closed on None before authz. Both restore the resolve-then-authz invariant.

Cron / trigger fan-out runs forever under a deactivated user's principal — PrincipalResolver rejects but the dispatch arm has no recovery

• Where: crates/manager-core/src/principal_resolver.rs:42-61, crates/manager-core/src/dispatcher.rs:314-318
• What: When the registrant is deactivated (is_active = false), PrincipalResolver::resolve returns Inactive(user_id) → the dispatcher surfaces ResolveTrigger(...) and the dispatch loop logs and moves on. The outbox row stays claimed-then-rescheduled forever (or the cron row keeps inserting). There's no "disable the trigger when its owner is gone" path. Per dispatcher.rs:316, the resolver error short-circuits the dispatch but doesn't disable the trigger. This means a deactivated former admin's cron jobs continue to attempt execution indefinitely, building outbox backpressure.
• Impact: Not a direct authz break (the script never runs because the principal isn't resolvable), but: (a) operational noise; (b) if the registrant is reactivated later with reduced privileges, every backed-up cron tick suddenly fires under their new (possibly weaker) identity at once; (c) if an attacker who briefly held InstanceManageUsers registered crons under a sock-puppet account and was then locked out, the crons remain dormant and re-arm on any future user revival with the same id.
• Recommendation: On Inactive from the resolver, mark the trigger enabled = false (with an audit note) and dead-letter any in-flight outbox row that targets it. Mirrors the script-missing arm at dispatcher.rs:292-310 which already dead-letters cleanly.

Public/anonymous scripts can call same-app AppDeadLetterManage only because the service explicitly rejects principal: None

• Where: crates/manager-core/src/dead_letter_service.rs:40-51
• What: For dead letters specifically, the service handles "anonymous caller" with a hard Err(Forbidden) rather than script_gate's default "skip the check for cx.principal == None." That's the correct intent (managing dead letters is an admin act). The risk is that the convention for every other stateful service (kv, docs, files, secrets, pubsub, email, users) is the OPPOSITE: anonymous public-HTTP scripts skip the capability check entirely (see authz::script_gate at authz.rs:327-342). A public, anonymous-callable HTTP script in app A can write to kv::collection("x"), send email via email::send, publish on pubsub::*, mutate app-users via users::*, etc. — all under "script-as-gate" semantics. This is by design (the author owns the script and decides whether to expose it via a public route), but it means a single misconfigured route exposes powerful capabilities. There's no global toggle to require auth on a public route.
• Impact: Documented design, but the boundary is one config mistake away from anonymous-internet → email send → SMTP-amplification-of-app-secrets. The "script is the gate" guarantee depends on the script author's discipline.
• Recommendation: Two improvements — (a) document this loudly in the route-create endpoint response ("this route is anonymous-callable; the script you bound holds capabilities X, Y, Z and will execute them un-gated"); (b) consider a per-route require_principal: bool toggle so app admins can flip a route to "no anonymous calls allowed" without rewriting the script. Defers cleanly to v1.2.

Low

build_http_request does not cross-check script.app_id == row.app_id

• Where: crates/manager-core/src/dispatcher.rs:651-718
• What: Same shape as the High above. The HTTP outbox arm uses row.app_id to build the ExecRequest (line 686) and script (resolved by row.script_id at line 660) is trusted to live in the same app. Routes are guaranteed same-app by route_admin.rs:179 (app_id = script.app_id), so today no row violates the invariant. Listing as Low (not High) because the write-path is tighter for HTTP than for queue triggers — there's no validate_trigger_target equivalent because routes carry their own app_id. Still worth the belt-and-suspenders check.
• Recommendation: One line: if script.app_id != row.app_id { return Err(DispatcherError::ResolveTrigger("http row app mismatch")); } after the script load.

Email-inbound writes outbox with URL app_id, not target.app_id

• Where: crates/manager-core/src/email_inbound_api.rs:144-189
• What: After cross-checking target.app_id != app_id at line 145, the outbox insert at line 177 uses the URL-derived app_id. They're equal because of the check, but target.app_id is the canonical source of truth (it survives even if the cross-check were ever relaxed). One-character fix; matters only if the cross-check ever gets refactored.
• Recommendation: app_id: target.app_id in the NewOutboxRow.

AppLookup.redirected flag is consumed only in apps_api::get_app

• Where: crates/manager-core/src/app_repo.rs:25-48, crates/manager-core/src/apps_api.rs:213-217
• What: Every other consumer (triggers_api, topics_api, files_api, secrets_api, queues_api, dead_letters_api, users_admin_api, app_members_api) silently discards the flag via .map(|l| l.app.id) / .map(|l| l.app). That's fine — historical slugs are valid identifiers for the canonical app. No authz check is bypassed; the resolved app.id carries the same authority as the live-slug path. I traced this exhaustively; listing as Info to confirm no privilege escalation via redirect, but moving to Low because the convention is implicit (each consumer must remember to discard, not skip a check). A clearer API might be resolve_app returning (AppId, Option<String> /* redirected_from */) so the call site can never accidentally use the slug.
• Recommendation: Cosmetic. Consider tightening the type.

RESERVED_MODULE_NAMES is a hard-coded list — drift risk on future SDK module additions

• Where: crates/manager-core/src/api.rs:261-280
• What: New SDK modules added to executor-core (queue is the most recent) must be remembered to be added to this list. It's not an authz issue per se; the shadow risk is that a user-supplied module of the same name resolves the user copy. Not load-bearing for cross-app isolation (each app's modules are app-scoped anyway), but worth a comment pointing at crates/executor-core/src/sdk/mod.rs so the next contributor edits both.
• Recommendation: Centralize the reserved-name list in picloud-shared next to the SDK trait registrations.

Info

SDK trait surface is clean on app_id discipline

• Every *Service trait method that a Rhai bridge can invoke takes &SdkCallCx and never accepts app_id as a parameter. Verified by grep across crates/shared/src/{kv,docs,files,secrets,email,http,queue,pubsub,dead_letters,invoke,events}.rs. The only app_id-parameter methods are admin-mediated (UsersService::admin_*, verify_session_for_realtime, list_invitations, revoke_invitation) and live under the HTTP admin layer, not the Rhai bridge.

Capability enum is exhaustively matched

• Capability::app_id() and Capability::required_scope() use full match arms with no default branch, so adding a new variant forces every call site to be updated. Test capability_required_scope_mapping_is_complete at authz.rs:868-887 plus compiler enforcement makes this a self-healing surface.

Bound API keys cannot escape their app

• binding_allows at authz.rs:449-461 denies instance-scoped capabilities for bound keys outright and requires target_app == bound_app for app-scoped ones. Mint-handler also rejects the combination upfront; the runtime layer is defense-in-depth. Tested at authz.rs:730-767.

Anonymous public scripts are visibly distinguishable in script_gate

• authz::script_gate at authz.rs:327-342 explicitly distinguishes cx.principal.is_none() ("skip the check, script-as-gate") from authenticated callers. Recorded for clarity; the trade-off discussed in the Medium "Public/anonymous scripts" item above.

default slug has no runtime-privileged behavior

• Only crates/manager-core/src/app_bootstrap.rs:39 references the slug at all, and only at fresh-install seed time. An attacker creating a new app and then deleting and recreating it cannot influence anything keyed on the slug — every authz check uses app_id (UUID), never the slug.

Out of scope (cross-references)

• Capability check on the inbound-email HMAC is in agent 3's lane (crypto).
• Rate limits on the cap-check Argon2 surface — agent 7 (DoS).
• The dashboard's localStorage echo of the bearer token leaking the principal — agent 6 (network/CSRF) and agent 1 (authn).
• The principal-cache TTL window letting a freshly-revoked admin still execute one request — agent 1 (authn) F-P-009 follow-up.