Admin authorization is npub-membership only — any admin can act on any key #60
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
src/daemon/admin/validations/request-from-admin.ts:15-17is the only gate for every admin RPC:hexpubkeys.includes(hexpubkey). No command checks that its target (keyName,policyId,keyUserId,tokenId) belongs to the caller.add_signing_condition.ts:33-43writes an override for anykeyUserId— and the override layer beats the policy incheckIfPubkeyAllowedstep 3 — so admin A can grant{sign_event, all, allowed:true}on a KeyUser bound to admin B's key.create_new_token.ts:24recordscreatedBybut nothing reads it;revoke_user,revoke_token,update_policy,remove_policy_ruleact on any id.Impact: on a bunker with more than one admin npub, every admin is a full superuser over every key. Today our deployments configure a single admin npub (the lnbits instance), so this is a documented trust assumption rather than an exploitable gap — but it is the thing that stops us from ever adding a second admin or a third-party admin tool.
Fix direction: either (a) add an owner column on
Key(admin pubkey) populated atcreate_new_key/create_account, and scope every command to keys the caller owns (joins through KeyUser → keyName and Token/Policy → keyName), or (b) pin single-tenant explicitly: refuse to start with more than one admin npub and say so in docs. (b) is a two-line change and honest about where we are.Found during reforge run #1 (sandbox nsecbunkerd#20).