2 Commits

Include renames

Author	SHA1	Message	Date
Robert Allan JamesandClaude Sonnet 5	3c2daf50d1	Extend BIRTH/CAPSULE-BIRTH to all VMs symmetrically; flag a real std79 lockdown gap (FABRIC-3.md §XXV) ... Scoping the workload-into-factorial design's placement-mode factor led to a real architectural improvement: rather than EXEC-ing a workload capsule into an already-running, ACL-locked identity's own persistent dictionary (filesystem-shaped, doesn't dodge the block- collision exposure just traced in §XXIV), a workload now runs as a fresh ephemeral child VM, BIRTH'd per trial and reaped after -- matching the project's own stated principle of automanagement over imposed policy. CAPSULE-BIRTH already passes vm->stadium_vm_id (who is birthing this VM) as the new child's parent, not a hardcoded Hera constant, confirmed by reading the C -- so a workload trial genuinely inherits the specific identity's own lineage when that identity does the birthing. Which surfaced a real premise: only Hera could call BIRTH/ CAPSULE-BIRTH at all (registered only in register_mama_forth_words(), confirmed directly, not part of the earlier §XX messaging-symmetry fix which deliberately kept this as one of her remaining privileges). Extended symmetrically now, agreed explicitly before touching code: - mama_forth_words.c: BIRTH and CAPSULE-BIRTH added to register_child_vm_words(), matching §XX's own pattern. - acl-std79.4th: ' BIRTH , ' CAPSULE-BIRTH , added to ACL-STD79-LIST (new block 4048) -- a deliberate, explicit, named exception to the lockdown's own "standard words only" guarantee, not a silent one. Symmetric registration alone can't weaken any lockdown on its own: ACL-LOCKDOWN-STD79 is allowlist-based, deny-by-default, so a newly registered word is auto-denied there unless explicitly added. Verified: clean build on all 3 architectures, zero new warnings. Hera's own dict_hash unchanged (expected); Hermes/Artemis show the same new dict_hash on all 3 architectures. Live-tested against a real attached std79-locked identity: CAPSULE-BIRTH executes correctly (returns vm_uuid_none() for a deliberately out-of-range capsule-id, zero fault, zero ACL denial). Found, and explicitly stopped short of fixing, a separate pre- existing gap while verifying the above: MSG-STATUS and MSG-K (messaging.4th words, not on the std79 allowlist) execute for a locked identity instead of being denied. ACL-LOCKDOWN-STD79 is confirmed to actually run; something more specific isn't reaching messaging.4th's dictionary entries. Root cause not traced -- needs its own investigation into vm_core.c's dictionary-link mechanics and whichever capsule actually loads messaging for these identities. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EXieurDfDSsDFdnSyusuWo	2026-09-12 22:31:52 -04:00
Robert Allan JamesandClaude Sonnet 5	f4ded3e1a8	MINT: add a FORTH-79/83-standard-words-only lockdown personality ... Captain Bob, 2026-09-07: "starting with that 00 user we created, we're going to give access only to FORTH 79 and 83 standard words. everything else is locked down." New capsules/acl-std79.4th (blocks 4023-4047): walks a VM's own dictionary (>LINK/LINK> traversal, same as ACL-INIT-PRIMITIVES/WORDS already use) and permanently denies+pins every word not on an explicit FORTH-79/83 allowlist, extracted from the real registered word set (stack_words.c through control_words.c), not recited from memory. Deliberately excludes, beyond plain non-standard words: BYE (100% ACL bypass to the emergency console -- "needs more discussion, exclude for now"), COLD/WARM/REBOOT/SAVE-SYSTEM (system lifecycle), the block/screen editor L/S/SHOW/EDIT/UPDATE/SAVE-BUFFERS (lets a session rewrite persistent block/capsule content, defeating the lockdown even though nominally standard), BLK-ACL-*/BLK-OWNER@ (StarForth-specific), and FORGET/FENCE (flagged as an unrestricted superpower word, 2026-09-03 audit). Keeps WORDS/VLIST/SEE (introspection only -- ACL is enforced per-target-word at execution time regardless of how an XT was obtained) and the parenthesized control-flow runtime primitives ((BRANCH) etc. -- IF/DO/LOOP compile calls to these; denying them breaks ordinary control flow, not security). MintPersonality enum (capsule_mint.h) lets capsule_mint_identity() select which personality-source template gets written to a new identity's devblock -- MINT_PERSONALITY_DEFAULT (unchanged) or MINT_PERSONALITY_STD79_LOCKDOWN (EXECs acl-std79.4th then ACL-LOCKDOWN-STD79 as the VM's own last bootstrap step). The actual restriction logic stays entirely in FORTH per .claude/CLAUDE.md's Word-Level ACL System rules ("ACL policy belongs in ACL.4th, never in C") -- capsule_mint.c only picks which few-line bootstrap stub to write. MINT's own stack signature gains a trailing restrict? flag; capsule_zuse_boot.c's genesis mint (Zuse herself) explicitly passes MINT_PERSONALITY_DEFAULT -- the superuser is never restricted. Two real bugs found and fixed live during testing, both the same class of self-referential fault: ACL-LOCKDOWN-STD79's own walk loop calls ACL-STD79-ALLOWED?/ACL-STD79-LIST/ACL-ALLOW!/ACL-PIN on every single iteration to do its job -- none of those are FORTH-79/83 standard words, so the walk was denying its own load-bearing infrastructure partway through and then faulting the next time it tried to call it ("VM fault -- emergency console disabled; halting", reproduced twice live). Fixed by explicitly protecting all four in the allowlist (block 4047) -- they must stay allowed for the walk to finish, not because they belong on a "standard words" list. Verified live end-to-end: minted a throwaway test identity with the restrict? flag, confirmed her WIREBIND birth completes cleanly (no faults, no shadow conflicts) on a single real attach, then USE'd into her VM and confirmed standard arithmetic and user-defined words work (1 2 + . -> 3; : X 5 5 * . ; X -> 25) while KILL is entirely unknown to her dictionary and VM-EXEC is denied. One real, non-fatal side effect found and left as-is (not asked to fix): the fleet's inter-VM messaging pump (MSG-ARENA) is also denied by the lockdown, logging a harmless per-idle-tick warning -- a fully locked-down VM doesn't participate in message routing. Not yet applied to the real identity 00 -- this commit is the mechanism, verified against a disposable test identity only. Three-arch clean qemu acceptance (single Zuse device, standard regression case) passed on amd64, aarch64, and riscv64. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014Ec88YKxxhZGG1RNnune78	2026-09-07 15:41:56 -04:00