SECURITY: control.config.setUpstream is ordinary-tier, persists an attacker-chosen RPC upstream, and survives pairing.revoke

[MichaelTaylor3d]

Task

control.config.setUpstream sits at ordinary tier, persists a caller-chosen RPC upstream, and
survives pairing.revoke. By the rule dig-node-control-interface 0.18.0 just introduced, it belongs
at master tier.

Sibling of #254 (the 0.18.0 adoption), parent
https://github.com/DIG-Network/dig_ecosystem/issues/2870.

Measured on origin/main

• Ordinary tier. is_pairing_admin_method (crates/dig-node-service/src/control.rs:281-286)
  matches only control.pairing.list|approve|revoke. setUpstream is absent, so a paired token
  reaches it — the same token class the crate documents as able to "drive control.* mutations but
  neither mint more tokens nor hide/revoke itself."
• It persists. config_set_upstream (control.rs:898-920) validates only that the string carries no
  control character, normalizes it, then set_upstream_override(&ctx.config_path, &normalized) writes it
  to config.json.
• It is read on next start as the RPC passthrough target — Config::from_env
  (crates/dig-node-service/src/config.rs:195-210): DIG_RPC_UPSTREAM env > the persisted override >
  the default.
• pairing.revoke does not undo it. pairing::revoke_paired_token (pairing.rs:398-403) loads the
  paired-tokens file, retains away the id, writes it back. It touches no config value.

Why this is the same defect class as #254's item 1, with broader reach

The escalation delegates and is not revocable: after the call the attacker no longer needs the token,
and the operator's remedy — revoking the pairing — leaves the hostile value in place. That is precisely
why chiaPeers.add was moved to master tier rather than being handled in the remedy.

The reach is arguably wider. A trusted Chia peer bypasses corroboration for chain reads. The upstream
is where every method this node does not implement gets forwarded — dig-node ships with no upstream
precisely so that an unimplemented method answers a truthful local -32601 rather than something a third
party made up (config.rs:55-60 says exactly this, and says the emptiness must stay). Pointing it at an
attacker-controlled URL makes that surface answerable by the attacker.

One honest mitigation, which does not change the verdict: the running node captured its upstream at
construction, so the change takes effect on the next start (requires_restart). It is persistent and
silent rather than immediate — which makes it harder to notice, not less serious.

Scope

1. Move control.config.setUpstream to master tier — by calling
   ControlMethod::requires_master_token() from the 0.18.0 contract, not by adding a string to
   is_pairing_admin_method. SECURITY: adopt dnci 0.18.0 — a paired token can still call chiaPeers.add here, because the master-tier predicate is restated as a string list #254 item 1 explains why: a predicate restated across a repo boundary as a
   string match is the byte-drift bug that produced this whole family.
2. Decide and state whether any other ordinary-tier method persists caller-chosen state that survives
   revocation. The rule the contract now names is "master-tier means the effect outlives the token that
   invoked it." Apply it as a rule rather than patching two known instances — cache.setCap and
   log.setLevel also persist, and should be judged explicitly rather than left unexamined.
3. Consider validating the upstream is a well-formed https URL. Today only control characters are
   rejected, and that check exists for a different reason (#526/B2 — a control character would be baked
   verbatim into a root-owned systemd unit line at install time).

Evidence

A test proving a paired token is refused on control.config.setUpstream and still accepted on the
ordinary reads it legitimately drives. Plus the lockstep test from #254 so dig-node's master set can never
silently diverge from the contract's again.

Effort

Medium for item 1, high for item 2 — item 2 is a judgement over the whole control surface, and it is the
half that stops this recurring.

[MichaelTaylor3d]

This is now the THIRD instance of one defect class — worth naming the class before fixing instances

A security gate on PR #248 found that chiaPeers.add/remove were closed on the control.* plane while still open on the Sage-parity wallet plane (wallet_authz.rs:70-71, policy master || is_paired, landing on the byte-identical writer). Measured, not inferred.

So the pattern to date:

#	Method	Tier	Effect outlives the token?
dig-node#254	control.chiaPeers.add / remove	was ordinary	yes — installs PeerTrust::Operator, survives pairing.revoke
PR #248 gate	add_peer / remove_peer on the wallet plane	master or paired	yes — same writer, both transports
this ticket	control.config.setUpstream	ordinary	yes — persists an RPC upstream read on next start

The contract already states the rule that decides all three: "master-tier means the effect outlives the token that invoked it." That is a property of the operation, not of the plane it arrived on — which is exactly what the wallet-plane instance shows, since the same operation had two different answers depending on the door.

What this means for this ticket

Item 2 in its scope — "decide and state whether any OTHER ordinary-tier method persists caller-chosen state that survives revocation" — has been promoted from thoroughness to the main deliverable. Patching setUpstream alone leaves the class open, and the wallet plane is now a demonstrated second door that a control.*-only audit does not see.

The audit must cover both planes. Enumerate every method on CONTROL_METHODS and GATED_WALLET_MUTATIONS, apply the outlives-the-token test to each, and record the verdict per method — including the ones that stay ordinary, so the reasoning survives.

cache.setCap and log.setLevel both persist and were already called out; judge them explicitly rather than leaving them unexamined.

Also relevant

PR #248 is adding a cross-plane test that pins the control-plane predicate and the wallet-plane authorize() together, so the two cannot diverge silently again. Reuse it here rather than writing a second shape — a per-plane test set is structurally blind to exactly this defect.

[MichaelTaylor3d]

Owned by the key-custody/pairing/authz batch lane.

• branch: loop/batch-seckey (worktree dn-seckey, based on origin/main 3e480dd)
• draft PR: fix(security): gate the wallet transport and make the no-mint rule structural #452 (closes this ticket)

Progress will be logged here at each increment.

[MichaelTaylor3d]

Fix landed on loop/batch-seckey (PR #452)

Item 1 — tier. is_pairing_admin_method no longer exists on origin/main; #254 already landed and
requires_master_token delegates to ControlMethod::requires_master_token(). But
ConfigSetUpstream is not in the contract's master set, so delegating alone left the method
ordinary-tier.

The fix does not restate the tier as a string match in the gate. It declares
LOCALLY_MASTER_TIER_CONTROL_METHODS — a single, documented, strictly-widening overlay applied
before the contract lookup — plus
locally_master_tier_methods_are_still_unclassified_by_the_contract, which FAILS the moment the
contract adopts the name, so the overlay is self-retiring and the two statements of one rule
cannot drift. the_overlay_never_demotes_a_contract_master_method asserts the widening direction
over the whole published method list.

The durable fix belongs in dig-node-control-interface and is filed as
https://github.com/DIG-Network/dig-node-control-interface/issues/… (see the PR body) — that repo is
another lane's, so this PR does not write it.

Item 2 — the rule, applied rather than the instances patched. "Outlives the token" is necessary
and not sufficient: cache.setCap and log.setLevel also persist and also survive revocation. The
refined rule is outlives the token AND confers authority on a principal — installs someone the
node will thereafter believe, obey, or speak to.

method	outlives token	names a principal	tier
chiaPeers.add/.remove	yes	a peer believed without corroboration	master
config.setUpstream	yes	the third party every unimplemented method is forwarded to	master (changed)
cache.setCap	yes	no — a local resource budget, visible on cache.get	ordinary (deliberate)
log.setLevel	yes	no — local verbosity	ordinary (deliberate)

Keeping the last two ordinary is a judgement, not an omission: promoting cache.setCap would break
the cache-size control dig-app drives with a paired token, for no authority gained.

Item 3 — validation. config::validate_upstream now refuses a scheme we do not speak, an empty
or whitespace host, and userinfo (https://rpc.dig.net@evil.example reads as one host and
resolves to another). Cleartext http:// is confined to loopback. The empty value stays the
documented "restore the default".

Tests, and the proof they are load-bearing. Deleting the overlay makes
a_paired_token_cannot_set_the_rpc_upstream_but_still_drives_ordinary_config and
master_token_set_matches_the_contract fail (measured). The ordinary-tier half is the control: it
distinguishes the fix from "answer master for everything".

SPEC.md §18.25b records the refined rule.

[MichaelTaylor3d]

Contract child filed: DIG-Network/dig-node-control-interface#40 — adopting it there is what deletes the interim overlay in dig-node.