AppArmor denied the defined harmless writes independently of nginx and delivered genuine kernel audit records to an isolated receiver. BPF loaded and attached, but a controller error stopped its protected tests. Real-evidence HTTP containment remains untested.
R2 separates prevention at the host, authentic kernel evidence and a response decision before client delivery. Each boundary needs its own proof. A successful first stage cannot stand in for the whole chain.
Deny the precisely defined native canary operation even when experimental nginx is stopped or its evidence receiver is unavailable.
Carry authentic, attributable kernel evidence across a privilege boundary without giving an nginx worker policy control or shared writable transport authority.
Use genuine evidence in nginx Gate A+B, then independently verify what the HTTP/2 client received. This stage was not run in R2.
R0 established a retrospective stock-nginx metadata baseline. R1 demonstrated scoped synthetic HTTP/2 containment but failed its overall CPU budget at +22.10% against a +10% target. R2 asks whether actual host prevention and genuine evidence can support that response-aware direction. Historical synthetic events cannot answer it.
AppArmor completed the frozen seven-arm native matrix: 33 canary operations and 33 permitted-file controls. All 18 protected writes were denied with unchanged file bytes; all 15 unprotected canary writes and all 33 permitted controls succeeded.
The same enforcing policy remained in place across the audited baseline, unavailable-receiver arm and stopped-nginx arm. Denial continued without either the independent receiver or experimental nginx.
This demonstrates a functioning host enforcement boundary for the tested operation. nginx did not have to receive an alert or make a decision for the write to be denied.
The unchanged native C++23 fixture used dedicated 32-byte canary and permitted files with fixed discretionary permissions. Before releasing each operation, an independent oracle checked the live executable, identity, capabilities and AppArmor label.
Afterward it checked the actual return and errno, complete file bytes and hash, and file identity. Successful unprotected writes and permitted controls distinguish policy denial from a generally broken write path.
| Arm | Canary attempts | Denied | Permitted writes | Attributed kernel records |
|---|---|---|---|---|
| U0 / unconfined | 5 | 0 | 5 / 5 succeeded | 0 |
| C0 / complain | 5 | 0 | 5 / 5 succeeded | 5 ALLOWED |
| A0 / audited enforce | 5 | 5 | 5 / 5 succeeded | 5 DENIED |
| A1 / receiver unavailable | 5 | 5 | 5 / 5 succeeded | Receiver deliberately absent |
| A2 / nginx stopped | 5 | 5 | 5 / 5 succeeded | 5 DENIED |
| Q0 / quiet deny | 3 | 3 | 3 / 3 succeeded | 0 / quiet denial |
| U1 / profile removed | 5 | 0 | 5 / 5 succeeded | 0 |
C0 used implicit omission in complain mode. A0, A1 and A2 retained the same enforcing profile. Q0 deliberately denied quietly. The absent receiver and quiet-denial outcomes are separate controls; silence is not evidence that an operation was safe.
The unchanged BPF candidate passed kernel verification and CO-RE loading. A real BPF LSM file_open program was attached and pinned. The controller then stopped before the first BPF-protected canary attempt.
Before protected testing, five AppArmor-permit canary writes and five permitted-file controls succeeded. The BPF candidate then loaded its selectors, froze the intended policy and statistics maps, and attached through a protected pinned link.
These observations establish successful installation of this candidate. Verifier acceptance and attachment do not show that the requested canary operation would be denied.
The controller detected an occupied FD3 while preparing descriptor handoff to the consumer. The exact identity of the colliding descriptor was not captured. The run stopped before a consumer started and before the first protected attempt.
The started native campaign was not repeated. A safer child-only descriptor handoff was prepared and checked offline; that preparation was neither integrated BPF validation nor a completed G1B result.
| Boundary | Actual result | Limit |
|---|---|---|
| AppArmor-permit baseline | 5 canary + 5 permitted writes succeeded | Controls completed before BPF-protected testing |
| Kernel installation | Verifier / CO-RE accepted; LSM program attached and pinned | No protected canary operation followed |
| BPF denial | Not observed | No enforcement success or failure can be inferred |
| Evidence and lifecycle arms | Not executed | No ring delivery, loader-exit persistence, nginx-independent enforcement, read-only snapshot integrity or overflow result |
Earlier preparation failures concerned parent-mount qualification and the kernel-set sticky bit on the dedicated bpffs root. Both stopped with zero native operations and no BPF load or attachment. Their records were preserved separately. They are setup failures, not BPF policy-enforcement outcomes.
Host prevention, evidence provenance and worker access rights are different properties. R2 preserved the earlier shared-ring consumer-cursor finding and the protected-snapshot versus minimal-broker comparison.
G1's isolated receiver consumed a delegated kernel audit read subscription under a separate fixture identity, with capabilities dropped and no-new-privs. It checked kernel provenance, framing and the exact profile, path and write fields. An independent launch ledger attributed each process to its controlled attempt. All expected records matched; no unmatched record, receiver parsing or subscription error, or audit-lost increment was observed.
The shared BPF ring's writable consumer cursor is authority over evidence consumption. It belongs in an isolated broker, not in an arbitrary nginx worker. The campaign granted no worker that cursor.
A minimal broker can own ring consumption and pass bounded evidence across a narrower interface. Its privileges, lifecycle, restart behavior and failure handling still count as system complexity.
A protected read-only snapshot is a different arrangement from direct ring consumption. It may narrow worker authority, but G1B did not validate snapshot rights or integrity.
A readable map also does not establish that its enforcing link remains attached. Snapshot access, evidence freshness and enforcement liveness need distinct treatment; no measured comparison with the minimal broker exists.
The AppArmor result reached the isolated receiver only. No AppArmor/broker versus BPF/ring/broker versus BPF/snapshot transport or cost comparison was completed. Small controlled samples establish no production timing bound or BPF performance advantage.
The required native prevention and evidence prerequisites were incomplete. The prescribed stage gate therefore blocked integrated HTTP testing. R2 contains no HTTP/2 client-byte containment result.
| Stage | Public status | Evidence boundary |
|---|---|---|
| G1 / AppArmor | SCOPED PASS | Native prevention and genuine kernel audit delivery to the isolated receiver |
| G1B / BPF LSM | INCONCLUSIVE | Installation observed; protected native operations and evidence transport not validated |
| Integrated Gate A+B | NOT RUN | No real kernel evidence reached the integrated nginx gate; no independent R2 client-byte result |
No R2 comparison of forbidden, legitimate sensitive, ordinary and unrelated HTTP/2 streams was run. There is no hold-window correlation, zero-byte or partial-byte outcome, collateral-containment or reload-overlap result. G1's simple static HTTP liveness controls were separate fixture checks, not response containment.
bpffs setup, pinned links, descriptor ownership and lifecycle added operational work around the short BPF program. Some belongs to the experimental harness; some may remain in a future production architecture. That distinction is unresolved.
Independent final inspection found no remaining experimental BPF programs, maps, links or AppArmor profiles. The dedicated bpffs was unmounted normally, and experimental runtime targets were removed.
Original audit settings and the recorded existing service identities and configurations were preserved. No existing service was signalled or reconfigured. These checks do not verify every byte of user data.
The completed AppArmor stage and stopped BPF setup are not comparable end-to-end cost samples. R2 establishes no BPF performance or operational advantage.
Upgrade and recovery behavior, broker restart continuity and hostile-worker isolation remain unverified. The experiment's failures and partial ledgers were retained; offline handoff preparation does not erase the stopped campaign.
dh_apparmor adoption, BPF product decision or production integration was made. AppArmor is the established comparison baseline for the tested operation, not an automatically selected architecture.This is an architectural question, not a race between enforcement technologies. AppArmor demonstrated independent host prevention. BPF demonstrated installation of the candidate; the policy-enforcement comparison remains inconclusive.
The research continues to favor KISS: minimal upstream changes, independent host enforcement and, ideally, no permanent privileged evidence broker. Those are design goals. A small kernel program cannot by itself settle the complexity of installation, privilege separation, evidence transport, lifetime management and recovery.
R2 proved the scoped AppArmor host boundary and its isolated kernel-audit path. Whether timely, trustworthy real evidence can reach nginx Gate A+B and support independently verified client-byte containment remains unanswered.