017: a pin the kernel can enforce

[jlgore]

Opened because 016's last VM case could not be written. Writing it uncovered why: a scanner grant was uninstallable under enforcement, so bee's whole external-scanner tier only ever ran under --host.

The gap

An exec.allow entry prefixed ! grants a file, not a path. 016 built the external tier on exactly that — a binary merely on PATH is not a grant; only a pinned entry is (FR-008). But crates/userspace/plan.rs refused any policy containing a pin, because the in-kernel exec allowlist matches resolved paths and cannot express identity.

Measured on the 6.8 BPF-LSM VM:

Policy	Result
exec.allow = ["!…/opengrep"]	infra_error: eBPF backend cannot enforce inode-pinned executable — episode never starts, in enforce and observe
exec.allow = ["…/opengrep"]	episode runs; scan reports did not run: … is not granted to this episode

Mutually exclusive. And the layers disagreed silently: 016's the_compiled_exec_surface_is_bee_plus_the_granted_scanner_and_nothing_else passes, asserting every compiled entry is pinned — the kernel then refused that same policy. Only a live case could show it.

What this does

The hook decides on identity. bprm_check_security reads file → f_inode → {i_ino, i_sb → s_dev} — three direct loads off a pointer it already holds, the same mechanism f_mode uses — and a pinned rule matches on (ino, dev) alone. The path rides along for the audit line and does not participate: a pin that also matched its own path would degrade to a path rule the moment the file it named was replaced, which is the one thing a pin exists to prevent.

That is stronger than the check it replaces. Stat-then-exec-by-path is a TOCTOU window. Deciding at bprm_check_security is a decision about the very image being loaded.

The offsets join the boot-time BTF guard, so a kernel whose layout disagrees refuses to enforce rather than reading a wrong field.

PlanError::UnsupportedInodePin is gone, replaced by UnidentifiedPin — a pin that arrives with no resolved identity is refused, never installed as a loose path rule.

The second half of the grant

Making the pin installable was not enough, and the matrix said so: with the grant in place the scan still failed with cannot read …: Permission denied. :project_root/.bee is a default protection — bee's own state is denied to tool children — and the two-child pipeline exchanges its SARIF report inside it. Child 1's write and child 2's read were both refused, invisibly under --host where nothing enforces the deny.

So a resolved scanner grant now widens the policy by exactly :project_root/.bee/scan, in the same place and the same way a skill grant does. More-specific-wins carves out scan/; .bee/findings — the ledger and its human verdicts — stays denied.

Proof

Matrix 38/38 (was 35/35), 2026-07-28:

• exec-pin-allow — pinned image runs, unpinned sibling denied
• exec-pin-swapped-denied — the granted image runs, an mv replaces it mid-episode, the same path is then refused. The original is proven to run first, so the case cannot pass by breaking its own setup
• scanner-escape-denied — 016's T068, finally: an enforcing scan episode's scanner child is refused an out-of-scope read, with a control run that leaks the same value when nothing forbids it

Two findings from building that last case are recorded in the spec's Edge Cases rather than papered over: /dev/null is an unlisted write in any scope that declares a write grant (the stand-in's own 2>/dev/null failed, which reads as a failed read); and nothing grants bee itself, so an enforcing scan policy must carry bee's entry beside the scanner's — true since 016, but --host never needed it.

cargo fmt/clippy -D warnings clean; full workspace suite green.

🤖 Generated with Claude Code