fix(det-init): a hung sample must not discard the whole event feed - #981

… DNS — boots+detonates on KVM (#194)

Proven end-to-end on x86 KVM (spike1-nestedvirt): det-init boots as pid-1,
enters the rootfs via minimald's embedded guest lib, stands up the observer
(16/16 LSM hooks), runs the sample as nobody, and verdicts BLOCK on a malicious
honeytoken-read / PASS on a benign run.

Changes from the initial scaffold, each earned by a boot iteration:
- emit the READY vsock beacon (guest::emit_simple_ready_marker) right after
  entering the rootfs — the minvmd supervisor waits for it (~5s) and tears the
  guest down otherwise; it must fire before the observer-ready wait (up to 10s).
- emit the drained feed on stdout so a host collecting via the guest console
  (the boot harness) gets it without a vsock listener.
- file sink only: drop --vsock-port from the observer spawn. It made the
  observer BLOCK connecting its sink to an absent host vsock listener, so it
  never signalled ready and the one-shot boot stalled.
- gate the DNS-collector repoint on egress being up: with no network the
  bind-mount is pointless AND showed up as a spurious pid-1 Mount the verdict
  read as a container-escape false-positive on an otherwise-benign run.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

…iner-escape FP on stock minvmd (#194)

Booting on minvmd built from main (which, unlike the fork binary, sets up the
own-ip vsock shuttle so egress reports up) surfaced that det-init's own
resolv.conf BIND-MOUNT — done as pid-1 — is captured as an sb_mount event the
verdict scores as a container-escape, false-blocking an otherwise-benign run.

Repoint /etc/resolv.conf with a plain write instead (matching the legacy
detonate.sh runner). On a read-only rootfs it fails EROFS and degrades to "DNS
names unobserved" rather than mounting. Full DNS-name capture on a RO rootfs (a
writable /etc overlay) is a networked-detonation follow-up; the robust fix is
verdict-side process-subtree scoping so pid-1 infrastructure never counts toward
the sample verdict.

PROVEN on STOCK-main minvmd (built from origin/main, no MINVMD_KERNEL_FORMAT
override — main auto-picks ImageGz for x86_64 — attaching the #672 /dev/vdb
volume): malicious honeytoken-read -> BLOCK, benign -> PASS. The whole substrate
is now stock main minimald + stock main minvmd + the BPF-LSM kernel + det-init,
no fork.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

…tion hole (#194)

The readiness audit (gominimal/minimal-detonation#194) found a trust-boundary
regression: det-init emits the drained JSONL feed on the guest console and the
worker collects it by scanning the console for `{`-lines, but the untrusted
`nobody` sample's stdout/stderr were INHERITED onto that same console — so a
sample could print forged `{"event":…}` lines that the worker accepts as real
events, voiding the core invariant "a `nobody` sample cannot write the feed"
(e.g. a forged NetworkDns re-contextualizing a real C2 connect → a signed
BLOCK→PASS). The fork closed this deliberately (`1>&2` in detonate.sh); the
initial det-init port dropped it.

Fix: run the sample with stdout+stderr = Stdio::null() (was inherit). The console
is root-owned, so nulling the sample's only inherited path to it means the feed
on the console is written solely by pid-1 (det-init) and stays trustworthy.
Corrected the false "nothing to corrupt" comment. Robust follow-up (noted):
drain the root-0400 /run/det-events.jsonl fully out-of-band (/dev/vdb or vsock).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

…not a number

`minimald = { version = "0.0.1", path = "../minimald" }` broke the build the
moment the workspace bumped to 0.5.0-rc1. Nothing about the API changed: all six
`guest::` functions det-init calls still have byte-identical signatures, and
guest.rs is additive-only since this branch's base. The pin was a self-inflicted
drift trap — it failed on a version NUMBER while the thing it nominally protected
(compatibility) was entirely fine.

A bare path dep resolves to whatever is in the tree, so version bumps can never
break us again. The API surface is what actually matters and the compiler already
checks it; a hand-maintained version string is a second, weaker check that fails
for the wrong reasons.

Also inherits version.workspace = true, matching every sibling crate.

Rebased onto current main (121 commits): the only conflict was the workspace
members list, where upstream added crates/diagnostics and we add crates/det-init.

Refs gominimal/minimal-detonation#194

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

The feed is drained AFTER the sample returns (step 8), so a sample that never
returns takes the ENTIRE feed with it: the host reaps the VM at its timeout,
drain_monitor and emit_feed_to_stdout never run, and a run that should have been
BLOCK is reported as "substrate_failed: empty observer capture". The observer had
captured everything — honeytoken reads included — and simply never shipped it.

Found by a corpus run, not by inspection. Two executions of the SAME poisoned
sample, differing only in whether the C2 connect was bounded:

  unbounded (/dev/tcp to a blackholed IP)  -> ERROR, empty capture
  bounded   (timeout 5 curl --max-time 4)  -> BLOCK, complete, signed

This is not an exotic input. A poisoned package whose C2 is unreachable —
sinkholed, taken down, firewalled, or a documentation-range IP — blocks on
connect() exactly like this. The perverse consequence is that the better the
network defense, the more likely the entire feed is lost, because the hang is
caused by the connection NOT succeeding. It is also a one-line evasion: append a
sleep after the payload and BLOCK degrades to ERROR once the damage is done.

Bounds the sample at SAMPLE_DEADLINE (90s, deliberately under the host's 120s VM
timeout) via try_wait polling, SIGKILLs on expiry, reaps, and falls through to the
normal drain. SIGKILL rather than SIGTERM because this is untrusted code that
already declined to finish and can trap the softer signal into the same hang.

Killing at the deadline costs only what the sample would have done AFTER it;
keeping the events it already produced is strictly better than losing all of them.
The timeout is logged on the console the host collects, so a hang is
distinguishable in triage from a genuine boot/attach failure — the old message
blamed the substrate for something the substrate did correctly.

NOT addressed here, deliberately: a timed-out run yields a partial feed, which
arguably should cap the verdict at REVIEW as a coverage-honesty signal rather than
producing a confident verdict over truncated evidence. That needs an event/schema
change and belongs in its own PR.

Refs gominimal/minimal-detonation#272

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>