carlos / platform Public

Found by adversarial review of the #162 replica work (branch replica-placements-162), where it stopped three attempts at a defence.

infra/modules/region-host/main.tf:166-170 grants a region host s3:PutObject on ${deployment_bucket_arn}/*. The deployment bucket is the control plane: every account's instance records live under apps/<sqid>/<app>/instances/. So any region box, or anything that obtains its role, can author a record in ANY account's prefix.

Why that surfaced now. #162 lets a record say "I am a replica of host H", which makes the reconcile pass and the siblings-file pass read one record and act on another. We added cross-record rails so the passes would refuse a replica whose home is not in the same account and app. Three rounds of review broke three versions of those rails:

1. The record map was keyed by host, so a record in another prefix carrying the victim's host displaced the victim's entry and the rails compared against attacker-controlled data.
2. Keying by RecordKey(account, app, host) fixed that, so we added "the home must be the record that owns its host", arbitrated by first-sorting key. An attacker whose account sqid sorts earlier simply is the owner. At id 5,000 there are ~93,000 earlier-sorting sqids to choose from.
3. That rail also became a weapon: an earlier-sorting plain record in a region nobody serves made the victim's box clear its own replica's link, severing a live pair with a record the victim cannot see or delete.

The rails are now fail-safe only — a contested host vouches for nothing, and no pass revokes anything. That removes the theft and the severing. It leaves a denial of service: a bucket-wide writer can contest any host and freeze the pairing.

No pass can do better, and that is the point. A rail asking "does this account own this host" needs an ownership source the attacker cannot write, and inside the deployment bucket there isn't one — the attacker can write the manifest too. The defence has to be the grant.

What would settle it: can region-host be scoped to the prefixes a box legitimately writes (control/edges/<box>.json, its own hibernate prefix, cert material) with instance records excluded, or narrowed per region so a box can only write records it could serve? The boxes do write records today in some paths, so this needs the write inventory before the policy, and it is production infrastructure, so it wants scoped approval rather than an agent applying it.

Not blocking #162: that branch's rails are fail-safe as they stand and its spec §6 states the limit plainly. Filing so the grant is a decision somebody made rather than one nobody noticed.