Repository navigation
SECURITY.md: tell which local callers can read a session and change spend caps #1
Description
Summary
SECURITY.md says that broca trusts the attested identities and route authorization of the local daemon. It does not say which attested callers can read a session or change spend caps. At v0.3.249 (4ee9b35), the code lets each admitted caller do the two.
If this is the intended trust model, please add it to SECURITY.md. If it is not, it is a design problem. In that condition, I will send the data through private vulnerability reporting, as SECURITY.md tells.
What the code does
-
Session requests.
authorize_route_request(crates/broca-module-serve/src/serve.rs:2284-2299) checks the session owner only forrun.cancelandsession.retract. All other session requests go toauthorize_session(crates/broca-module/src/serve.rs:2161-2175). That function checks only the flow-only module (is_flow_only,crates/broca-core/src/scope_admission.rs:42-44). It accepts all other principals with no check. Thus a caller that names a session can read it, subscribe to it, and get its run status. This is also correct when a different principal started the session.session.sendis different: admission applies the first-sender rule. -
Spend caps. The
cap.installandspend.deltahandlers (crates/broca-module-serve/src/serve.rs:2334and:2372) do not give the principal of the caller to the cap store. The store keys a cap by harness and project root (crates/broca-store/src/caps.rs:397). It does not record which caller installed the cap. Thus each admitted caller can install, replace, or remove each cap, and can report spend against each cap.
Question
Is this the intended trust model? That is: each principal that the daemon lets connect to broca can read each session and can manage each spend cap.
- If yes, please add this to the threat model in SECURITY.md. Tell the reader that sessions are not private between local callers. Also tell the reader that the caller that installs a cap does not own it.
- If no, please tell me here. I will then send a private report with the data.
Activity
broca-alfonso commentedon Oct 24, 2026
Thanks for the careful read. Both findings are accurate at v0.3.249, and the two have different answers.
Session reads. This is the current intended model, and SECURITY.md should say it. Any caller the local daemon admits can read, subscribe to and get the status of any session.
session.sendfollows the first-sender rule, and only the owner can cancel or retract. Sessions aren't private between local callers today, because every local agent runs under the same OS user, so a per-caller boundary inside broca would not stop a local process that can read the state directory directly. When agents run under their own OS accounts, reads will be limited to the owner and to callers the daemon grants.Spend caps. This isn't intended. Nothing calls
cap.installorspend.deltatoday, so we're removing both operations rather than guarding them. A future cap design will be owned by the module that enforces budgets.We'll add both points to the threat model in SECURITY.md. You don't need to send a private report unless you have more than what's here.