Security
What it protects against, and where it stops
A summary of the threat model. Each mitigation links to the tests that prove it. The full version, with trust boundaries and residual risks, is in the threat model.
The primary adversary
A malicious or compromised agent running in a governed cgroup: prompt-injected, misaligned or simply buggy, with the agent's own privileges.
| Attack | Mitigation | Evidence |
|---|---|---|
| Connect to a denied address over TCP, UDP, IPv4 or IPv6 | cgroup sock_addr hooks deny it in the kernel | net-enforce-eperm |
| Bypass the connect hooks: raw and packet sockets, io_uring, TCP Fast Open, NAT64 | Each path is hooked or denied | net-bypasses |
| Run an unlisted program through symlinks, replaced binaries, scripts or memfd | Exec decided on file identity (device, inode) | exec-identity |
| Read or modify a protected file under another name | File decisions on inode identity, per access type | file-identity |
| Escape by forking or leaving the cgroup | cgroup v2 inheritance; agents cannot write their cgroup | agent-children |
| Act before governance starts | Placed in its cgroup atomically at creation | agent-first-instruction |
Tamper with the sensor: bpf(), signals, ptrace, removing pins | Self-protection LSM hooks deny it | self-protection |
| Kill the sensor and hope enforcement stops | Pinned programs keep enforcing; a stale heartbeat fails closed | heartbeat-fail-closed |
| Edit the audit log afterwards | Hash chain and Ed25519 signatures; rk audit verify fails | audit_tamper |
Out of scope
- Root on the host, or a compromised kernel. Root can unload programs and edit maps. Kernel lockdown and the hardening guide raise the bar; they do not make root untrusted.
- Ungoverned workloads. Only cgroups bound to a profile are governed; the rest of the host is untouched by design.
- Kernels without BPF LSM enforce network rules only, and
rk doctorsays so. - What an allowed connection carries. A profile that allows a destination allows whatever is sent there.
- Side channels, physical access, and denial of service against the host.
Report a vulnerability
Please do not open a public issue. Report privately through GitHub private vulnerability reporting or by email to security@realitykernel.dev.
| Step | Target |
|---|---|
| Acknowledgement | within 3 business days |
| Initial assessment | within 7 days |
| Fix for a critical issue | within 30 days |
| Coordinated disclosure | within 90 days, or earlier once a fix ships |
Scope, supported versions and safe harbour: SECURITY.md.
Verify what you run
Every release file is signed by the repository's release workflow with Sigstore, and carries SLSA build provenance and an SPDX SBOM. Nothing needs to be trusted in advance.
VERSION=0.1.0
f="reality-kernel_${VERSION}-1_amd64.deb"
cosign verify-blob --bundle "$f.sigstore.json" \
--certificate-identity "https://github.com/Keter-Lab/reality-kernel/.github/workflows/release.yml@refs/tags/v$VERSION" \
--certificate-oidc-issuer https://token.actions.githubusercontent.com "$f"
gh attestation verify "$f" --repo Keter-Lab/reality-kernel
The container image, offline verification and the full procedure: verifying a release.