fix(security): no VM but Artemis and Hera can make Hera run text; a message runs once; word-ACL elevation removed
Any identity could have arbitrary FORTH run as Zuse: KH-ELEVATE-SEND and KH-BLK-ATTACH-SEND sent any text to Hera, from any VM (shown live). And the drain popped a message after running it, so a payload calling a colon word ran twice. Both fixed test first (FABRIC-3 SXXXVII): - KH-BLK-ATTACH-SEND is ( dev-addr ok? -- sent? ), Artemis only; the kernel writes the reply text. BLK-ATTACH-ACK is Hera's only. - The drain pops before it runs. - Elevation, ruled not needed: KH-ELEVATE-SEND, message type 8, zuse-eligibility.4th, ZUSE-ELIGIBLE?/ZUSE-ELIGIBILITY-ADD/ ELEVATE-PUBKEY-UNPACK and the eligibility list removed; its disk area stays reserved, unused. FABRIC-3.7 closed. Three ISAs: POST 1052 passed; new parity baseline word_count=523 hash=0xb73b58052d591638 (deliberate). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
rajames
co-authored by
Claude Opus 5.5
Claude Opus 5.5
parent
029a8ed9cf
commit
5e26fad30d
@@ -1,6 +1,18 @@
|
||||
# FABRIC-3.7.md — Phase 8 PKI: the elevation entrypoint
|
||||
|
||||
**Status: OPEN — design only, no code written or authorized.**
|
||||
**Status: CLOSED 2026-10-14 — not needed; elevation removed, not built.** Captain Bob, asked
|
||||
"is it even a necessary capability?": privilege comes from the drive (Zuse's drive, or the
|
||||
personality an identity is minted with), so a runtime request-and-grant channel only adds attack
|
||||
surface — and the old one was a live hole: `KH-ELEVATE-SEND` let any identity have arbitrary
|
||||
FORTH run as Zuse. `ELEVATE-GRANT` granted automatically on eligibility-list membership (no
|
||||
human approves), into Hera's own dictionary (never the requester's), and could never reach a
|
||||
FORTH-79-locked identity's words (pinned, and pins are one-way). Removed: `KH-ELEVATE-SEND`,
|
||||
message type 8, `zuse-eligibility.4th`, `ZUSE-ELIGIBLE?`/`ZUSE-ELIGIBILITY-ADD`/
|
||||
`ELEVATE-PUBKEY-UNPACK`, the eligibility list itself and Part B's gate in `zuse.4th`;
|
||||
`devblock_from_top` 1–63 on Artemis's disk stay reserved, unused (his ruling). See
|
||||
`FABRIC-3.md` §XXXVII. Everything below is kept as the record of the design.
|
||||
|
||||
**Former status: OPEN — design only, no code written or authorized.**
|
||||
|
||||
**CORRECTION (2026-09-22, before any code was written against this document): §2's central
|
||||
claim — that the old `SEND-ELEVATE-REQUEST` passed a raw cross-VM address into `ELEVATE-GRANT`'s
|
||||
|
||||
@@ -5580,3 +5580,56 @@ second apart at the prompt all attach (their attach acknowledgements are message
|
||||
POST 1052 tests passed, `PARITY:M7.1a ... hash=0x08873e0f44b7cb2a` unchanged, no unknown word
|
||||
(`logs/20261014-103248`, `-103409`, `-103616`). Superseded attempts, kept: `-092406` (wrong `USE`
|
||||
syntax), `-094908` (before the LIVE-on-yield fix, one line only).
|
||||
|
||||
## XXXVII. Any identity could run FORTH as Zuse; a message could run twice; elevation removed (2026-10-14)
|
||||
|
||||
Found while building FABRIC-3.7's elevation entrypoint, proven live, fixed test first.
|
||||
|
||||
**1. Two words let any VM have Hera run any text, in her own dictionary -- Zuse's.**
|
||||
`KH-ELEVATE-SEND ( paddr plen -- ok? )` and `KH-BLK-ATTACH-SEND ( paddr plen -- ok? )`
|
||||
(`repl.c`) are registered in every VM (`word_registry.c`), and each sent whatever text it was
|
||||
handed to Hera as a kernel-Hermes message, which Hera interprets. From a WIREBIND identity's
|
||||
console: `S" 777 ." KH-ELEVATE-SEND .` and `S" 778 ." KH-BLK-ATTACH-SEND .` -- Hera printed
|
||||
`777` and `778` (`logs/20261014-105930`, `-110937`). A line holding `"` is run on the identity's
|
||||
console VM instead of relayed (`repl.c`'s own v1 limitation), which is what reached them.
|
||||
|
||||
**2. One message could run twice.** `sk_hermes_drain_checkpoint()` popped a message only after
|
||||
running it; a payload that runs a colon word reaches the checkpoint in `execute_colon_word()`,
|
||||
which drains the same VM again -- and found the same message at the head. A relayed `T3`
|
||||
(`: T3 333 . ;`) printed `333 333`; `778` above printed twice (`logs/20261014-110937`).
|
||||
|
||||
**3. Elevation itself: not needed (Captain Bob, 2026-10-14).** Asked whether it was even a
|
||||
necessary capability, given (1): privilege comes from the drive -- Zuse's, or the personality an
|
||||
identity is minted with -- and a runtime request-and-grant channel only adds attack surface.
|
||||
`ELEVATE-GRANT` granted on eligibility-list membership alone (no human approves), into Hera's own
|
||||
dictionary (never the requester's), and could never reach a FORTH-79-locked identity's words (all
|
||||
pinned; pins are one-way). Its only caller had been gone since 2026-09-22 and nothing missed it.
|
||||
`FABRIC-3.7.md` is closed as not needed.
|
||||
|
||||
**Fixes.**
|
||||
- Removed: `KH-ELEVATE-SEND`; message type 8 (retired, not reused); `capsules/zuse-eligibility.4th`
|
||||
(`ELEVATE-GRANT`, blocks 4021-4022) and its `EXEC` in `init.4th`; the C words `ZUSE-ELIGIBLE?`,
|
||||
`ZUSE-ELIGIBILITY-ADD`, `ELEVATE-PUBKEY-UNPACK`; the eligibility list (`zuse_eligibility.c`,
|
||||
`zuse_eligibility.h`, `zuse_eligibility_list.h`); FABRIC-3.7 Part B's gate on
|
||||
`ZUSE-ELIGIBILITY-ADD` in `zuse.4th`. `devblock_from_top` 1-63 on Artemis's disk stay reserved,
|
||||
unused (his ruling). `NAME>XT` stays: general-purpose.
|
||||
- `KH-BLK-ATTACH-SEND` is now `( dev-addr ok? -- sent? )`, refused unless Artemis calls it; the
|
||||
kernel writes `<dev-addr> <0|1> BLK-ATTACH-ACK` itself. Artemis's `HERA-BLK-ATTACH-REQ` is now
|
||||
`DUP BLK-ATTACH KH-BLK-ATTACH-SEND DROP` (its text builder is gone, and with it Artemis's one
|
||||
"Unterminated comment" warning, a nested-paren comment).
|
||||
- `BLK-ATTACH-ACK` is refused unless Hera runs it.
|
||||
- The drain pops a message before running it; the message, and so its payload, is still held
|
||||
until released after.
|
||||
|
||||
**Verified.** The same session after the fix (`logs/20261014-112514`): `333` once,
|
||||
`KH-BLK-ATTACH-SEND: refused -- only Artemis replies to a storage attach`, `UNKNOWN WORD:
|
||||
'KH-ELEVATE-SEND'`, identity `00` attaches. Five identities hot-plugged at the prompt all attach
|
||||
(`logs/20261014-113615`). Standard acceptance, all three ISAs: `zuse@Hera`, POST 1052 passed, no
|
||||
unknown word, **`PARITY:M7.1a word_count=523 ... hash=0xb73b58052d591638` -- a deliberate new
|
||||
baseline** (was 530 / `0x08873e0f44b7cb2a`: the four C words and `zuse-eligibility.4th`'s
|
||||
definitions are gone from Hera's dictionary) (`logs/20261014-113112`, `-113232`, `-113450`). A first attempt (`-111859`) broke
|
||||
attach two ways, both mine: nested parens in the new capsule comment, and `%lld`, which the
|
||||
kernel's freestanding `snprintf` does not do.
|
||||
|
||||
**Found, not fixed (pre-existing, unrelated):** Hera prints two and Hestia three `( Unterminated
|
||||
comment` warnings at every boot, in logs from before this work too.
|
||||
|
||||
Reference in New Issue
Block a user