Future hardening: OS-enforced isolation for hostile same-account filesystem processes #72

Decision / release scope

Disposition (Product Owner, 13 October 2026): DEFER to a later revision. The current v0.12.0 State Engine V2 can be evaluated under its documented trusted, exclusively controlled local-runtime boundary; do not represent it as resistant to a hostile concurrent process sharing the same OS account. This is an explicit scope limitation for this revision, not a claim that the security vulnerability is eliminated.

This future hardening is a separate tracked capability, not a requirement to be silently added to DKF120-T04. It must be revisited when scoping the next suitable Development Kit revision; no version is promised here. The previously selected restricted offline restore design (Issue #71 option B) remains a distinct operation and trust boundary.

Why it remains deferred

Portable Node.js pathname and descriptor checks (including lstat, fstat, rename, unlink, and Linux /proc/self/fd) cannot guarantee atomic ledger/commit-journal coupling while a hostile process with the same filesystem write authority can concurrently replace directory entries. Existing fail-closed-on-next-read detection is not an atomic transaction guarantee and cannot recover a displaced event when the journal has been removed.

References:

• T04 hardening PR fix(v0.12 T04): crash-safe event append, process locks and restore confinement #70: fix(v0.12 T04): crash-safe event append, process locks and restore confinement #70
• In-scope T04 recovery blocker Issue v0.12 T04 blocker: isolated restore and crash-recoverable lock/restore transactions #71: v0.12 T04 blocker: isolated restore and crash-recoverable lock/restore transactions #71
• Reproduced race: fix(v0.12 T04): crash-safe event append, process locks and restore confinement #70 (comment)
• Architecture decision: fix(v0.12 T04): crash-safe event append, process locks and restore confinement #70 (comment)

Future engineering requirements

1. Re-evaluate the threat model, host and CI runtime privileges, multi-process sharing, supported operating systems, security boundaries, and deployment environments.
2. Design OS-enforced exclusion/isolation (separate protected identity/ACLs, per-host native directory-handle APIs or isolated helper) instead of using check-then-act filesystem operations or a boolean trust assertion.
3. Preserve canonical events.jsonl, pending journal, derived snapshots/index and acknowledgement semantics through crashes, process termination, directory swaps and attacker-controlled concurrent writes.
4. Provide deterministic adversarial tests on every supported platform. Any unavailable native primitive requires a documented unsupported mode and fail-closed behavior, not an unqualified security guarantee.
5. Evaluate compatibility, performance, migration, local runners, and Windows/macOS/Linux deployment.
6. Complete independent security/architecture/code review with source-bound evidence before enabling the stronger guarantee.

v0.12.0 release boundary

This backlog issue does not confer a T04 ACCEPTED verdict. PR #70 still needs exact-commit Windows/Ubuntu CI, independent code/architecture/security reviews, zero unresolved in-scope blockers, and authenticated deterministic acceptance. The runtime limitation must be clearly disclosed in user documentation and reviewed against the Product Owner's scoped decision. No silent scope change or self-issued approval.

Status: Deferred/backlog; revisit in a later version-planning and security-review cycle.