[Kucell]

Summary

Implements M-044 / MS-002 — managed caller proof: a dedicated, non-detached supervisor
process that holds the supervised child's OS process handle plus a filename-less inherited
bidirectional IPC channel, and derives the caller's identity from those two facts alone.

Origin Story

The upstream M-053 / MS-008 R3 coordination contract lists "handle mis-inheritance and
explicit handle transfer" as mandatory negative cases (VC-044-005) but does not give a
mechanism by which they are rejected.

This implementation measured that gap on the target platform and found it real:

• Node's fork + stdio: [..., 'ipc'] channel lives on fd 3 in the child, and that fd
  can be deliberately handed to a descendant via spawn(..., { stdio: [..., 3] }).
• The descendant then reads the coordinator's requests and writes forged responses onto
  the parent's channel. Reproduced locally — the coordinator received a forged
  result: { forged: true } before the genuine answer.
• A nonce handshake does not stop this. The nonce travels on the very channel that is
  transferable, so the descendant sees it too, and it can replay it.

The fix separates the two channels: the session secret travels only on a second,
independent pipe (fd 4 in the child), and every response carries an HMAC-SHA256 over the
request identity. A descendant that inherited only the IPC handle has no secret, so it cannot
produce a valid MAC. Two further layers detect rather than merely blunt the attack:
the socket's holder set is audited for handle transfer, and a pid + process-start-time token
detects PID reuse.

The relay attack — found by the first independent review

The first independent review of this PR (against 590efbc4) returned FAIL, and it found a
hole the secret-on-a-second-channel fix does not close.

The coordinator's _dispatchInbound never verified the MAC of an inbound request, and the
coordinator signed its own answer to that inbound request with its own key. A descendant
holding the transferred handle could therefore:

1. read the coordinator's outbound REQUEST off the shared handle,
2. replay it back as an inbound REQUEST with an attacker-chosen payload,
3. receive the coordinator's legitimately signed answer to that payload, and
4. feed it straight back into the coordinator's pending slot.

The coordinator then accepted a response its supervised child never sent, computed from a
payload the attacker chose. The reviewer reproduced it 3/3 on the pristine commit:

[!!! REQUEST SUCCEEDED WITHOUT THE EXECUTOR ANSWERING !!!]
[COORD HANDLER PAYLOAD] = {"attackerControlled":true,"target":"/etc/shadow"}

The fix is direction binding. The signed kind now separates the two directions —
request-out / request-out-response / request-in / request-in-response — and the four are
not interchangeable. The coordinator accepts only an answer signed as request-out-response,
and it executes an inbound request only after that request verifies under request-in. The
coordinator therefore never signs an answer to an unauthenticated inbound request, so there is
no signed material left for an attacker to relay. The response MAC additionally binds the
request payload digest, so a signed answer cannot be moved to a different payload.

Two further findings from the same review were fixed in the same round:

• The negative cases were not reaching the coordinator. A frame written straight onto the
  socket arrives with Node's IPC envelope intact, and the coordinator was discarding the whole
  envelope instead of routing the payload — so the "forged response" fixtures had never
  actually delivered a forgery. The envelope is now unwrapped before routing.
• The audits were never called. auditChannelHolders / auditProcessContinuity existed but
  ran on no request path, and degraded environments reported ok: true. Both now run on the
  request path and fail closed: an unknown socket address or a missing start token refuses
  the dispatch rather than permitting it.

Commits in this PR (oldest first)

sha	subject	lineage
06aec2fc	feat(governed): 受管调用者以进程句柄与签名通道证明身份	M-044 / MS-002
590efbc4	test(governed): 覆盖受管调用者的四类反例与身份来源约束	M-044 / MS-002
b80d5ae8	docs(pr): 补 MS-002 受管调用者证明的 PR 说明	M-044 / MS-002
d630b0dd	fix(governed): 让受管调用者的反例在 Linux 与 macOS 上同样成立	M-044 / MS-002
bd4c006c	fix(governed): 封堵受管调用者的中继路径并让身份审计 fail-closed	M-044 / MS-002
c49e7c9e	docs(pr): 补 MS-002 中继路径修复与归因更正的说明	M-044 / MS-002
d44ec284	fix(governed): 让受管调用者的身份审计在两个平台上都精确且 fail-closed	M-044 / MS-002
7dd23d95	fix(governed): 身份槽私有化与 Linux 端点解析修正	M-044 / MS-002
772f4005	fix(governed): 封闭可变审计与凭据入口	M-044 / MS-002

What is in the diff

File	Role
lib/governed/managed-caller-signing.js	HMAC response authentication; MAC covers the direction-bound kind, request id, seq, operation, request payload digest and body
lib/governed/managed-caller-identity.js	OS-level facts: process start token (microsecond on macOS, boot-id qualified on Linux), IPC socket endpoint (inode on Linux, address pair on macOS), socket holder set, command digest
lib/governed/managed-caller-session.js	Session lifecycle, handshake, request/response, direction-bound inbound authentication, read-only identity, holder and continuity audits before dispatch and after the round trip
lib/governed/managed-caller-supervisor.js	Supervisor: non-detached spawn, secret pipe, batch scope, child-side endpoint; the trust-critical stdio/detached keys are not overridable
tests/governed/managed-caller-*.test.js	63 tests across session, signing and identity facts
tests/governed/fixtures/m044-ms002-*.js	Executor fixture (incl. the deliberate handle-transfer and relay cases), grandchild fixture, relay-attacker fixture

What the second independent review found, and this round's fixes

The second independent review (against bd4c006c, by a validator who did not implement
the change) returned PASS on all four criteria — VC-044-003, VC-044-004, VC-044-005 and
VC-044-018 — after reproducing the relay attack with three independent attack chains on both
macOS and Linux. It also recorded one P1 and several P2 observations. Fixes landed across
d44ec284, 7dd23d95, and 772f4005.

The CI failure was a real defect, not a flaky test

Full Test Suite failed on the Linux runner with channel_handle_transferred on a clean
channel. The cause was in the identity audit, not in the test: lsof -U means different
things on the two platforms. macOS prints an address pair (local ->peer), while on Linux the 0x... column
is not a reliable identifier for the socket endpoint. Matching it produced a transferred-handle
report for a clean channel. The earlier inode-hash collision explanation was incorrect; the exact
trigger of the CI failure remains unproven.

The socket is now identified by the socket object itself: on Linux the kernel inode from
/proc/<pid>/fd/3, on macOS the address pair.

Measured on Linux: the two ends of a connection are two distinct socket objects with two
distinct inodes (e.g. child 1866278 / parent 1866277), so the inode does not identify a
connection — it identifies one end of it. That is exactly what the audit needs: a descendant
that inherited the descriptor holds the same socket object, and therefore the same inode, and
it shows up as an extra holder. The transfer is still detected, and the false positive is gone.

One correction to the earlier explanation in this PR: the 0x... column on Linux is not a
hash of the inode. The two ends of a connection carry different 0x values despite having
different inodes, and the same 0x value on a socketpair's two ends despite their inodes
differing — so the column is not a function of the inode at all. The inode is used because it is
precise and agrees with a direct /proc read of the holder set, not because the 0x column was
shown to collide. The exact trigger of the CI failure is therefore not fully explained; the
defect it exposed — matching a socket by a value that does not identify it — is fixed either way.

P1 — the audit ran after the payload had gone out

request() wrote the request frame onto the channel and then ran the identity audit. A
refusal therefore reported "refused to dispatch" while the sensitive payload had already been
written to the channel, where a holder of the transferred handle could read it. The audit now
runs before the frame is written, and a second audit runs after the round trip to cover a
transfer that happens while the request is in flight. A test asserts that a refused request
produces no request frame on the channel.

P2 — the identity slot and the fact source were replaceable

childIdentity was exposed through a read-only accessor, but the slot behind it was a plain
writable property. Writing it made the recorded start token match whatever the caller put
there, which defeated the pid-reuse check the continuity audit compares against. The slot and fact readers now use private class fields. The instance and class prototype are
hardened in 772f4005, so their audit methods cannot be replaced through the session surface. The degraded-environment tests were rewritten to simulate
the degradation at its source (the fact reader returns the degraded fact) instead of
overwriting the identity derived from it.

P2 — spawnOptions could detach the supervised child

The caller's spawn options were spread last, so they could replace detached: true and the
stdio layout — the two properties the trust primitive depends on. They are now applied last
and are not overridable. A test asserts the child is not in its own process group even when
the caller asks for detached: true; the test was confirmed to fail against the unfixed code.

P2 — a coarse start token silently degraded pid-reuse detection

When the macOS helper could not be compiled, the start token silently fell back to
ps -o lstart=, which resolves to whole seconds — so every process started in that second
shared a token and a pid reuse between them was undetectable. The coarse token is now marked
(ps-coarse:) and the continuity audit fails closed on it rather than reporting a pass for
a comparison it cannot make.

The negative case was adjusted so it still proves something

With the audit moved before dispatch, the relay fixture was blocked earlier and the inbound-MAC
layer was never reached — the case would have passed for the wrong reason. The relay fixture now
starts its accomplice when the first request arrives, so the handle is transferred while the
request is in flight. The relayed inbound request really reaches the coordinator, where it has
to be refused on authentication grounds.

Validation

• macOS and Linux managed-caller tests: 63/63 each
• Governed scope: 15/15 files
• Strict hermetic suite: 479/479 files
• L3 boundary: 0 violations; template parity: 3/3

Two new regressions failed on the previous implementation. A concurrent first run hit a Linux 30-second file timeout and slowed an unrelated event-bus performance benchmark; serial Linux (63/63), the benchmark (5/5), and the full strict suite (479/479) then passed.

Correction to an earlier attribution

An earlier revision of this PR described the governed/codex-shadow-persist.test.js failure as
"pre-existing — it fails identically with this branch's changes stashed". That attribution was
wrong. The real cause is that this worktree's .agent gitlink is not initialised (the repo has
no .gitmodules, so git submodule status reports fatal: no submodule mapping found), and
lib/governed/codex-shadow-persist.js requires
.agent/skills/context-budget/scripts/minimal-context.js. Supplying that skill makes the file
pass 3/3 and the whole tests/governed/ directory pass 219/219. CI fetches .agent at the pinned
gitlink commit, so CI is unaffected.

Scope boundaries (deliberately not touched)

• lib/governed/launcher.js is unchanged; its existing detached: true + 0600 context
  file behaviour still serves the existing non-sensitive flows and is never used as a
  fallback for sensitive batches (a test asserts the sensitive path contains no
  CORTEX_LAUNCH_CONTEXT, context.json or detached: true)
• lib/coordination/lease*.js untouched (MS-003 scope)
• No third-party dependency; Node built-ins only
• No SamHMI product code, no Windows connection, no Lease requested

Current revision and remaining gate

Head: 772f4005d9142e35d41de504e92b9ce5f7fcc75a (fifth repair).

The fourth frozen source still allowed a holder of the session object to replace the prototype audit methods and dispatch despite a modelled PID reuse. The session also exposed writable secret, child, pending, and handler state. This revision moves trust-critical state to private fields, makes the instance non-extensible, freezes the class prototype and production fact exports, and prevents a second inbound handler from bypassing the fixed-batch policy.

MS-002 remains pending independent sign-off on this exact SHA for VC-044-003/004/005/018. Earlier reviews and their PASS/FAIL findings apply only to the SHAs they inspected. MS-001's threat-model Decision remains open; MS-003 must not start before the Owner decides how to handle same-account state tampering. SamHMI product security stays BLOCK.

Refs: M-044 / MS-002