refactor(isolation)!: make confirmation backend-neutral

[drew]

Summary

Replace Linux- and driver-specific confirmation schemas in the shared isolation interface with backend-neutral enforcement properties. The common contract describes the guarantees every backend must establish. The component that owns an enforcement mechanism also owns and validates its native evidence.

Related Issue

Closes #3361

Changes

• Add backend-neutral filesystem confinement, egress interception, request attribution, and privilege-floor properties to the isolation interface.
• Replace the shared Docker/Podman/Kubernetes/VM fence enum with normalized outer-fence guarantees: default-deny egress, no unmanaged egress path, generation binding, verified revocation, and fail-closed controller loss.
• Require the outer-fence enforcement owner to project its validated native evidence into individual guarantees; non-empty evidence never promotes itself.
• Use the compute driver as the enforcement owner for the current Docker, Podman, Kubernetes, and VM placements, while allowing a delegated isolation backend to own the fence in another placement.
• Bind each projection to its sandbox generation and enforcement-owner evidence with a SHA-256 digest.
• Keep Docker, Podman, Kubernetes, and VM evidence schemas and validation in their respective driver crates.
• Keep native Linux capability, seccomp-notify, Landlock, and network-probe audit evidence in the OpenShell sandbox backend.
• Verify that common properties exactly match backend-validated evidence before the boundary can become ready or credential monitoring starts.
• Add assembled-path negative tests for invalid audit evidence, property drift, generation drift, and evidence-digest drift.
• Update conformance tests and sandbox architecture documentation for the backend-neutral model.

Operator impact

This is an intentional serialized-state break. BoundaryConfig and SandboxRuntimeDescriptor now use outer_fence projections rather than the earlier driver_fence representation, so state created by older builds cannot be decoded. Operators must stop and recreate affected sandboxes after upgrading.

Testing

• mise run pre-commit
• cargo test -p openshell-isolation-interface --test backend_conformance
• cargo test -p openshell-sandbox-backend
• Isolation tests for the Docker, Podman, Kubernetes, and VM drivers
• Workspace-wide Clippy through pre-commit
• E2E tests not applicable: runtime mechanisms and observable behavior are unchanged

Checklist

• Follows Conventional Commits
• Commits are signed off (DCO)
• Architecture docs updated

[mayawang]

This works for us. The four properties are all things we can report honestly from a gVisor or microVM backend, and moving the Landlock and seccomp detail into the sandbox backend behind an opaque backend_audit is a cleaner split than what I suggested in the issue. Thanks for turning it around so quickly!

[elezar]

The backend-neutral direction looks right, and the host-side revalidation preserves the important fail-closed behavior. I would like to see the following addressed before merge:

1. Please make the evidence-to-guarantee mapping explicit. OuterFenceGuarantees::confirmed currently turns any non-empty native evidence into all four guarantees, including revocation verification and fail-closed controller loss. The Docker, Podman, Kubernetes, and VM evidence validators check narrower configuration facts. Please either document and test why those facts establish every projected guarantee, or represent and validate the additional native evidence explicitly. This avoids allowing future drivers to accidentally promote weak evidence into stronger common claims.

2. Please add negative tests around RemoteBound::confirm, which is the new security-critical trust boundary. At minimum, exercise invalid backend audit evidence, a property projection that does not match valid audit evidence, and mismatched outer-fence generation/digest. Each case should demonstrate that confirmation fails before Ready is constructed or the credential monitor starts. The existing component-level validation tests do not exercise this assembled path.

3. This changes persisted and serialized BoundaryConfig and SandboxRuntimeDescriptor data from driver_fence to outer_fence. Protocol compatibility is not required here, but the responsible commit must use a Conventional Commit breaking marker/footer and state the operator impact: sandbox state created by earlier versions cannot be decoded and affected sandboxes must be recreated after upgrade.

Non-blocking: OpenShellSandboxAuditEvidence is specifically the native-Linux seccomp/Landlock evidence schema. NativeLinuxSandboxAuditEvidence in a Linux/native adapter module would make the intended ownership clearer as gVisor and other adapters are added.

The OpenShift capability/seccomp contradiction remains separate follow-up work; this PR correctly moves that restriction out of the shared interface but does not resolve it for the native Linux backend.

[drew]

Addressed the requested changes in 228f644fe:

• OuterFenceGuarantees::from_driver_evidence now requires an explicit per-guarantee projection; each Docker, Podman, Kubernetes, and VM adapter maps and tests its own native facts, and the architecture guide documents those mappings.
• RemoteBound::confirm now has assembled-path negative tests for invalid native audit evidence, property mismatch, outer-fence generation mismatch, and evidence-digest mismatch. Credential monitoring starts only after ConfirmedBoundary::try_new succeeds.
• The commit and PR title use the breaking marker, the commit includes a BREAKING CHANGE footer, and the PR documents that pre-change sandbox state must be recreated after upgrade.
• Renamed the mechanism-specific schema to NativeLinuxSandboxAuditEvidence.

Validation: mise run pre-commit, the full sandbox-backend suite, isolation-interface conformance, and focused isolation tests for all four drivers pass.

[mayawang]

The per-guarantee projection is better than what it replaced, and the negative tests on confirm are the part I would have worried about most.

One question before this settles, because it decides something on our side. OuterFenceGuarantees is driver-owned and validate requires all four. The four adapters that exist read facts from a control plane the driver owns: the Docker daemon, the Kubernetes API, the VM device model. That works when the outer fence and the isolation boundary belong to the same driver.

Less clear to me is the delegated case in #3362, where the backend brings its own boundary and its own egress enforcement. Is the outer fence still the compute driver's, with the backend reporting only the four properties? Or would a backend that owns the network path be expected to establish the outer fence guarantees itself?

It changes which of the four we have to prove and where the evidence comes from, so I would rather build against the answer than guess.

[drew]

@mayawang

Is the outer fence still the compute driver’s?

I think we can be flexible here. Today all our compute drivers own the network fence.

Or would a backend that owns the network path be expected to establish the outer fence guarantees itself?

Yes. If Substrate for example, owns the network path, a substrate backend must establish and prove all four guarantees.

The supervisor only cares that all four guarantees are proven and bound to the sandbox generation. It should not care whether that evidence came from a compute driver or a delegated backend. The current driver-owned wording is too narrow, so I’ll update it.

Does this work for you? I don't have a strong opinion here yet. If we find that there is a better stance to take we can update the thinking.

[drew]

Clarified the ownership model in 22b1529c4:

• The component that enforces the outer network fence owns and validates its native evidence.
• In the current Docker, Podman, Kubernetes, and VM placements, that component is the compute driver.
• A delegated isolation backend may own the fence in another placement.
• The shared isolation interface only receives normalized, generation-bound guarantees; it does not interpret driver- or backend-specific evidence.

I also renamed from_driver_evidence to from_enforcement_evidence so the API reflects that distinction.