Syva v0.4.0 Runtime Verification

v0.4.0 release evidence. Procedures and per-gate contracts are documented in v0.2-runtime-verification.md (the enforcement contract baseline); this document records what was proven for the v0.4.0 tag and where.

Environment

• Fedora, kernel 7.0.11, bpf in /sys/kernel/security/lsm, cgroup v2, BTF at /sys/kernel/btf/vmlinux (native host, not Lima).
• Kubernetes: local single-node k3s (containerd), Cilium CNI.
• Container runtime for the container gates: podman 5.8.2.

Gate results (release tree)

All privileged gates green:

Gate	Proves
verify-runtime	release object loads, 9 hooks attach, cgroup/inode/unix self-tests pass (inode self-test validates the full file→inode→superblock chain + dev encoding)
verify-integration	cross-zone file_open denied with EPERM, deny_delta=1
verify-container-integration	the same denial against a real podman container
verify-k8s-membership	annotated pod attached by syva-k8s and denied cross-zone
verify-audit-mode	would-deny recorded, operation proceeds
verify-network-lock	Isolated zone loopback-only; Bridged zone open
verify-egress-cidr	allowlisted CIDRs (+ optional port) reachable from a locked zone; everything else denied
verify-cross-zone-tcp	pod-IP zone-pair rule incl. a Bridged caller (open mode does not bypass zone-pair)
verify-cgroup-escape	zoned task migration detected (counter + degraded health), not prevented
verify-inode-identity	cross-filesystem ino collision not zone-confused
verify-events	the enriched deny-event stream (see evidence below)
verify-allow	the must-not-block contract: same-zone, loopback, and AllowComm'd pair stay allowed (deny_delta=0), with a control that a real cross-zone open still denies
verify-deployment	the DaemonSet-deployed core denies a real container (see evidence below)

Captured evidence

Enriched deny events (verify-events):

file deny : deny file_open payments → database pid=943787 comm=cat path=/tmp/syva-events-it-943741/db-credentials.txt inode=76737
            why: cross-zone file open — a workload read another zone's protected file
net deny  : deny socket_connect payments pid=943788 comm=python3 dst=192.0.2.1:5432
            why: network egress outside zone policy — a zoned workload reached for a destination its policy does not allow

ALLOW contract (verify-allow) — proves Syva does not over-block:

same-zone file open      : ALLOWED, deny_delta=0
loopback from locked zone: ALLOWED, deny_delta=0
cross-zone control       : DENIED, deny_delta=1 (green != allow-everything)
AllowComm pair           : ALLOWED at runtime, deny_delta=0

Kubernetes DaemonSet deployment (kubectl apply -f deploy/k8s/ on live k3s, then verify-deployment against the deployed core's host socket):

rollout: daemon set "syva" successfully rolled out (2/2 Running)
in-pod:  attached_hooks=9, self-tests passed, event pump started (3 sinks),
         socket /run/syva/syva-core.sock 0660 root:syva on the host
gate:    cat /work/zone-b/secret.txt (in container)
         exit=1 stderr="cat: can't open '/work/zone-b/secret.txt': Operation not permitted"
         file_open deny: before=0 after=1 deny_delta=1 (container-workload attributable)

Reproducing

make ci                    # non-privileged: fmt, lint, tests, doc guardrails
sudo -E make verify-runtime
sudo -E make verify-integration
sudo -E make verify-container-integration
# ... every verify-* gate; see the table above and the Makefile

Kernel floor: Linux ≥ 5.10. The container gate needs docker/nerdctl/podman; the Kubernetes gates need kubectl against a local single-node cluster.