Castle Wall macOS fresh-binary re-drill, 2026-06-16

This document was authored BEFORE the drill ran. The criteria in the tables below were transcribed verbatim from the prior authoritative evidence doc (castle-wall-macos-boot-survival-drill-2026-06-14.md) and the per-uid allow/deny drill (castle-wall-macos-allow-deny-drill-2026-06-11.md). A criterion invented after results does not count. Result columns read PENDING until the Erik-present hardware run fills them; the coordinator independently verifies the captured evidence before any public claim moves (the operator PASS is provisional).

Why this drill exists (the one gap it closes)

The prior boot-survival pass (06-14/15, signed build v774, git_sha 8c8efe68) proved A1 boot-survival 5/5 and A2 per-uid allow/deny N=3 on the drilled source. That source was rebased onto main and merged as PR #450 (7732f4d5); the rebase was verified behavior-preserving (clean codex, frozen-surface guard, byte-identical core boot files). But, in the prior doc’s own words:

a fresh signed build produced from main’s exact tree was not independently reboot-drilled. The reboot evidence is from the v774 binary built at 8c8efe68. … that is an inference from the rebase verification, not a second on-hardware drill of main’s exact binary.

This drill removes that inference. It builds a fresh signed binary from origin/main’s exact tree, proves the freshly-signed binary is the one actually running, and re-runs the pre-declared criteria on it. It additionally closes the two criteria that were unit-covered-only last run (C6, C7) on hardware, and populates the boot-time audit chain (empty last run) plus verifies it under the recovered master.

What landing this unlocks (and what it does NOT): the honest public macOS claim can become “enforces a signed operator policy with a clean per-uid allow/deny demo that survives reboot,” proven on main’s exact binary. It remains NOT “audited per-rule per-flow” - the producer-signed per-flow rule-attributed audit trail (C4) is an unbuilt future build, carried forward honestly below. Nothing public changes from this document; the coordinator drafts any claim change for Erik after verifying the captured evidence.

Build provenance (Step 1/2 - CAPTURED 2026-06-15/16)

New-binary-is-running proof (Step 2, to fill)

The stale-extension trap (a rebuilt ext does not replace the running one unless CFBundleVersion increases AND the host app re-submits activation) must be closed and shown:

• systemextensionsctl list shows 0.1.0/807 [activated enabled] and 0.1.0/774 [terminated waiting to uninstall on reboot]. PASS.
• sha256 of the ACTIVATED extension bundle binary = 26e3c0cef466faa464f4f58e320b15859183d3c44985b52866c05a404cc5e7b7 - exact match to the freshly-built+signed+notarized artifact. PASS.
• activated sha 26e3c0ce… != prior 5fae8f4bdbf659424b11a200f391ada4af70b4916c3d2a9066651482c84d1159 (v774). The stale-extension trap is closed (version bumped 774→807 AND host app re-submitted activation, per the #480 fix in autoArmProtection). PASS.
• host-app git_sha = 053093963dbf (from --headless status build block), recorded separately and NOT used as the extension-version proof. PASS.

Activation mechanism: the 807 host app auto-resubmits an OSSystemExtensionRequest.activationRequest on launch; macOS saw 807 > 774, returned .replace from actionForReplacingExtension, and switched the active binary without a GUI approval prompt (the team was already approved for v774). No reboot was required for activation (the 774 binary is queued to uninstall on the next reboot, which is harmless).

A1 - F1 boot-survival, fresh binary, 5/5 reboot reps (pre-declared)

Each rep is a real reboot of the armed machine. Recovery levers pre-staged BEFORE rep 1 (see “Recovery levers”). Drill-acceptance rule: N>=5 for boot-reliability.

Each rep also verified that the per-uid allow/deny enforcement survived the reboot (agent 502 blocked on 1.1.1.1, allowed to anthropic; operator 501 unaffected) - a stronger result than the prior drill, which verified armed+reachable but ran A2 in a separate window. Reps captured 2026-06-15.

A1 verdict: 5/5 PASS. Every reboot: real fresh boot (uptime 38-53s), safe-mode boot daemon came up, operator reachable (never deny-all bricked), and the persisted drill manifest kept enforcing per-uid (agent blocked, allow lane open, operator unaffected) on the freshly-built 807 binary (activated ext sha 26e3c0ce…).

Pre-declared per-criterion verdicts (verbatim criteria from the prior doc; prior status in brackets):

C6 / C7 hardware sub-tests (closed this run)

Boot-time audit chain (TARGET - was empty last run)

A2 - per-uid allow/deny enforcement demo, fresh binary, N>=3 (pre-declared)

Armed window enforcing the drill manifest. Same destination blocked for the agent uid, reachable for the operator uid (per-uid differential, not a blanket block). Drill-acceptance rule: N>=3 deterministic.

Armed via: GUI host app enabled the NE content filter (Tahoe headless arm wedged on loadFromPreferences, W7-1 - confirmed again here); the dead-man lease was armed by the running safe-mode boot daemon’s heartbeat after a clean daemon restart (launchctl kickstart) re-broadcast armed:true (a stale prior disable had left the lease disarmed). Provider os_log re-binds manifest_received=true arm_lease_received=true every 5s throughout. Captured 2026-06-15.

What this does NOT prove (carried forward honestly - do not claim)

• No UNFORGEABLE per-flow audit trail (the “C4 gap”). The allow/deny differential is genuine external behavioral evidence. A per-rule-attributed read-out DOES exist on the drilled tree (corrected after independent verification): every egress_allowed/egress_blocked entry stamps the deciding rule_id (server/src/castle-wall/runtime/macos-flow-events.ts), and server/src/castle-wall/audit/per-rule-report.ts is CLI-wired (sanctuary castle-wall audit-dump --by-rule / --rule <id>). BUT that read-out is NOT tamper-evidence: the producer-signed / unforgeable per-flow audit activation is a separate, currently-inert capability. So the genuine C4 gap is unforgeability, not rule-attribution. Do NOT describe this work as “audited per-rule per-flow” or “tamper-evident per-flow audit.” (The most you may say about legibility: the operator can read which rule decided each recorded flow - without implying that record is tamper-proof.) Note: the safe-mode boot-audit segment captured only lifecycle events (filter_started/filter_stopped), no per-flow egress_* events, so for the boot segment specifically “lifecycle, not per-flow verdicts” still holds.
• Claim attaches to the drilled tree 053093963dbf, NOT today’s origin/main. As of the drill close, origin/main is 5 commits ahead (bb673e72): AGENTS.md (#591) + the layer-rename PRs #592-595, which rename castle-wall symbols/dirs/import-paths and touch macos-daemon.ts + per-rule-report.ts (2-line renames each). Those are not re-drilled. Do not silently re-attach “survives reboot” to “current main” without re-confirming the rename is behavior-preserving (the same inference-not-drill caveat the prior doc was careful about).
• One host, one OS version. Single-machine proof on macOS Tahoe 26.5.1.
• Not a performance claim. No overhead numbers captured.
• Not bit-reproducible. Built on the MBA’s Swift 6.3.2, not Mini1’s CLT 6.1.2 - the invariant is byte-identical source, not toolchain-reproducible output.

DEFECT found during the drill - host app launch crash (does NOT affect enforcement)

Reported by the operator (Erik) at the console: on reboots 1, 4, and 5, a macOS “Sanctuary quit unexpectedly” dialog appeared (the GUI host app CastleWallHostApp crashed on launch). No crash dialog on reboots 2 and 3. On reboots 4 and 5 the operator did not reopen the app - and enforcement still held (agent blocked, operator reachable per the SSH probes), which is the proof that enforcement is independent of the GUI app.

Crash signature (from ~/Library/Logs/DiagnosticReports/CastleWallHostApp-2026-06-15-225551.ips): EXC_CRASH / SIGABRT (Abort trap: 6) → AG::precondition_failure → AG::Graph::value_set(... AGSwiftMetadata ...). This is a SwiftUI AttributeGraph precondition failure in the host app’s UI layer - almost certainly autoArmProtection() / ensureSignerHelper() mutating @Published/observable state during the initial view render in .onAppear (a publishing-changes-within-view-update race, which fires nondeterministically with boot timing - hence 1/4/5 but not 2/3).

Severity / scope: real GUI-stability + UX defect in the fresh 807 build (user sees a crash dialog after some reboots). It is in CastleWallHostApp (SwiftUI), NOT in the enforcement daemon or the system extension, both of which enforce independently of the app - so it does not invalidate the A1 boot-survival or A2 allow/deny results (verified out-of-band via SSH). It SHOULD be fixed before any “polished product” claim. Tracked for a follow-up fix (move the .onAppear arm/helper side-effects off the synchronous render path - .task{} or an async dispatch). Not a security-enforcement regression.

Recovery levers (pre-staged BEFORE the first reboot - all confirmed)

• Console disarm - proven recovery lever (Erik at the Mini1 console); used for C5 part 2.
• Settings > VPN & Filters toggle-off - operator toggled OFF at drill end (definitive disarm).
• Off-host recovery key present (~/.sanctuary-drill-0611b/recovery-key.txt, 526 bytes) + ~/.cw-drill-pass.
• Drill-fortress passphrase confirmed available (~/.sanctuary-drill-0611b-passphrase.txt, 17 bytes; used to verify the boot-audit chain).
• Second admin path confirmed: Tailscale (mini1 100.77.78.104, MBA, iPhone on the tailnet) - independent of the LAN.

Known dead-ends (do not re-attempt)

• SE-at-boot is impossible (a root daemon cannot use the Secure Enclave before login); the boot key is software/FileVault/hybrid, not SE-bound.
• Headless arming on Tahoe hangs for exec’d binaries - arm via the Settings/console path.
• The manifest digest must be computed over RECEIVED BYTES, not a re-encoded struct - if a ruleDigestMismatch recurs, that is the first suspect.

IPC-frame verification aid (Step 3.5)

Review/Sanctuary/drill-harnesses/capture-ipc-frames.ts (coordinator workspace) is THROWAWAY scaffolding last exercised on the obsolete drill/f1-lean-2026-06-14 tree. Decision for this drill: SKIPPED, not needed. The core criteria (A1 5/5, A2 N=3, C6, C7, boot-audit) all passed via direct behavioral probes + the provider os_log; the IPC-frame capture would only have been needed to debug a ruleDigestMismatch, and there were none.

End state (box restored safe)

• Filter disarmed: CLI dead-man lease-revoke (C5 part 1) + operator GUI VPN & Filters toggle-off (C5 part 2). Verified: agent 502 → 1.1.1.1 = 301 and operator 501 → 1.1.1.1 = 301 (both reachable; no enforcement).
• Boot service left installed (harmless with the filter off; returns on next reboot as designed).
• Real ~/.sanctuary never touched; drill ran entirely on ~/.sanctuary-drill-0611b (global pin c3f22755).
• Credential stashes (~/.cw-sudopw, ~/.cw-asp) removed from Mini1 at drill close; the arm-lease.cjs helper removed. The notary profile sanctuary-notary-profile remains in the MBA keychain (operator may revoke at appleid.apple.com).

One-line verdict per criterion

• Step 1 build-from-main / signed / notarized: PASS
• Step 2 fresh binary proven running (sha 26e3c0ce ≠ prior 5fae8f4b): PASS
• A2 per-uid allow/deny N=3: PASS (3/3)
• A1 boot-survival 5/5 (+ enforcement held across all reboots): PASS (5/5)
• C1, C2, C3, C5: PASS; C4 (helper-signing): IMPLICIT
• C6 absent-boot-token fail-closed: PASS
• C7 KeepAlive recovery: PASS
• Boot-audit populated + verifies under master: PASS
• Host app SwiftUI launch crash on some boots: DEFECT (logged; does not affect enforcement; fix tracked)
• Carried-forward NOT-proven: per-flow rule-attributed audit (C4 gap); one host/one OS; no perf.

HALT / coordinator verification

When results are filled: report the evidence doc path + one-line PASS/FAIL per criterion. Do NOT edit ASSURANCE_MATRIX.md, README, or any public copy. The coordinator independently verifies the captured evidence (operator PASS is provisional) and only then drafts the public-claim change for Erik.