Security

July 18, 2026 · View on GitHub

How NØNOS decides what code may run and what running code may do. Start with the security model: the whole story on one page, the threat model, the end-to-end trust chain, the isolation guarantees, what is machine-checked, and the honest boundaries. This section then divides into two halves of that story: admission, the pipeline that verifies a capsule before it becomes a process, and enforcement, the authority a capsule holds afterward and how every syscall is checked against it. Read the admission pages first, since the capabilities a capsule holds are the output of the admission pipeline.

Admission

Everything that decides whether a capsule is allowed to run, and with what authority, before a single instruction of it executes.

PageWhat it covers
capsules-and-trust.mdThe capsule as an artifact, the baked trust anchor, and the exact ordered verified-spawn pipeline: certificate against the anchor, then manifest against the certificate, then the capability math and the attestation gate.
manifest-schema.mdEvery field of the CapsuleManifest, the fixed sizes, the endpoint and publisher-signature sub-schemas, what the signatures cover, and which verification step reads each field.
certificate-schema.mdEvery field of the NØNOS-ID certificate, the capability ceiling and namespace globs, the publisher keys that sign manifests, and the two signing layers from anchor to certificate to manifest.
trust-anchor.mdThe baked, non-optional anchor policy, its signing keys and their windows, the epoch anti-rollback, the three revocation lists, and exactly what it enforces on a certificate.
attestation.mdThe attestation gate and its two backends: the production transparent post-quantum STARK membership proof and the earlier enrolled-secret proof, their feature gating, the trailer formats, and what the proof binds.

Enforcement

The authority a running capsule holds, how it is authenticated, how it is passed on, and how it is withdrawn.

PageWhat it covers
capabilities-and-tokens.mdThe twenty-two capability bits, the driver-broker layering and the Admin super-grant, the capability token and its bindings, the syscall-to-capability table, and the ordered resolve chain.
signing-and-mac.mdThe per-boot signing key, the 128-byte MAC material and the two-pass keyed BLAKE3, the mint and sign and verify paths, the boot-session nonce, and the constant-time comparison.
delegation.mdThe Delegation structure, the subset and expiry rules enforced at creation, the domain-separated MAC, the three verification entry points, and every error.
revocation.mdThe four scopes of revocation: the per-boot key and nonce, the per-process epoch, the per-token revoked set, and the anchor lists, with where each takes effect.

Reporting

Suspected vulnerabilities go through reporting.md: the private contact, what is in and out of scope, and what to include in a report.

Sources

The code behind this section lives under src/security/ (the capsule manifest, the NØNOS-ID certificate, the trust anchor, and the attestation trailer), src/capabilities/ (the capability bits, tokens, and delegation), src/kernel_core/process_spawn/ (the spawn runner), and src/crypto/ (the signature, hash, and constant-time primitives). Every page is verified against those trees with file:line references.