carlos / platform Public

#162: the shadow-record bypass — key the record map by identity, not by host

Adversarial verification broke the four tenancy rails 1a5f819f added and
reproduced the bypass. The record map both passes read was keyed by HOST,
so it had one slot per host. A writer holding nothing but their own prefix
wrote a record there carrying the VICTIM's host — their account, their app,
so it agreed with its own path — and a bucket listing is lexicographic, so
a later-sorting prefix took the victim's slot. Three things followed, each
a P1: the attacker's replica passed all four rails against its own shadow
and minted, which aliases the victim's public host to the attacker's
process on that box; the victim's own siblings.json named the attacker with
a dial address and a live pair key, both sides agreeing because both derive
the label from the attacker's account; and the victim's LEGITIMATE replica
was refused as "another account's", a denial of service on the real pair
from a record the victim cannot see and cannot delete.

The map is now keyed by the record's identity, RecordKey(account, app,
host), and a replica's home is looked up inside the replica's OWN account
and app. That makes rails one and two true by construction rather than by
comparison, and removes the collision itself: no record can occupy
another's slot. ReconcileConfig.OnRecords says so, because the key is the
safety property its readers inherit.

Both passes now ask one function, provision.PairableHome — they defend the
same property from two sides, so a rail only one of them holds is a rail
the other bypasses. Rails three (a home is not itself a replica) and four
(the placement is named in the home's `replicas`) stay explicit checks.

A fifth rail, found while testing the fix: the home must be the record that
OWNS its host — the first-sorting claimant, the same arbitration the pass
already makes when two records claim one host. Identity keying alone does
not close the mint: the attacker's shadow is a perfectly good home for the
attacker's own replica, so the rails pass and the victim's host is aliased
anyway. The loser of the host arbitration serves nothing anywhere, so a
replica vouched for by one is vouched for by a record with no route, and
the alias it mints diverts the winner's public host. buildSiblings asks the
same question of the file's own host, in both loops: it writes files keyed
by host and has no route arbitration of its own, so without it a record
claiming another account's replica host hands that instance a file naming a
stranger as its home.

Failure handling splits, per the same verification. Rails that can never
fail on a door-written record clear the link (SetReplicaOf ""), and the
domains pass sweeps the alias next run — protecting those leaves a row
nobody vouched for serving an account's public host indefinitely for no
fail-safe benefit. Not reg.Delete: removal carries a grant purge and none
of this is a retirement the bucket asked for. An unreadable home and the
opt-in rail keep `protect`: a bucket blip must not sweep a live placement,
and an OLD CONSOLE legitimately strips `replicas` by round-tripping a home
record, so a console deploy must not be able to take a placement down.

republishRetired now takes the pair's label off the entry buildSiblings
wrote rather than re-deriving it from all[host].Account — that was the last
host-keyed read in the file, and deriving one label twice is how two
derivations drift.

Spec §6 gains a paragraph on what these rails are and are NOT: they defend
an operator's typo and a prefix-scoped writer, and they are not a tenancy
boundary against a writer holding bucket-wide s3:PutObject (a region box's
IAM role does), who can author a record in the victim's OWN prefix where
every rail passes trivially — or a plain instance record claiming the
victim's host, with no replica involved at all.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>