Security at the
execution boundary.
NØNOS is a Rust-based operating system built around signed application capsules, separate process memory and explicit authority. Explore the controls that define each workload’s security boundary.
ONE SECURITY FOUNDATION. A WIDER DEVICE FUTURE.
Your hardware.
A stronger boundary.
Explore how the NØNOS security model comes to life across laptops, desktops and future mobile integrations. Select a device to see its deployment path.
Development hardware
A trusted session. Wherever you work.
Explore a bootable NØNOS environment on selected x86_64 laptops, with application identity, separate process memory and explicit authority at the core.
- 01Check the platform
Confirm firmware and hardware compatibility for the development build.
- 02Prepare a live environment
Follow the project’s image and boot guidance on suitable test hardware.
- 03Run within boundaries
Evaluate signed capsules, isolated memory and capability checks.
EXPLORE THE SECURITY LAYERS
Verify a capsule’s publisher identity, executable integrity and signed manifest before admitting the process.
Start with selected x86_64 development platforms. Mobile is a planned integration path. The current installer does not install NØNOS to an internal disk, and no Android or iOS boot image is documented.
An application.
An identity.
A defined boundary.
A capsule packages an executable, an identity certificate and a signed manifest. It runs as a user-mode process with its own virtual address space. It is neither a complete virtual machine nor a Linux container.
Its manifest declares the authority it requires. Admission checks validate the package before a process is created; privileged operations pass through kernel-controlled interfaces.
Inspect the verified-spawn path ↗Four layers of control.
01 / Verify identity
Check the publisher certificate, executable integrity and signed manifest against trusted roots.
02 / Separate memory
Create a private user address space while keeping shared kernel mappings supervisor-only.
03 / Bound authority
Install declared capabilities within the certificate ceiling. Reject system requests without valid authority.
04 / Manage lifecycle
Treat boot identity, expiry, revocation and teardown as part of the security boundary.
A process cannot simply
read its neighbour.
Page tables define which memory a capsule can address. Another capsule’s private pages are not mapped into its user space. Access to system services is mediated rather than inherited automatically.
This is logical memory isolation. It does not mean each process owns a separate RAM chip, nor does it imply universal protection against hardware flaws, side channels or a compromised kernel.
Inspect address-space creation ↗What Rust contributes
Safe Rust helps prevent common memory corruption bugs such as use-after-free and out-of-bounds access in code that follows its guarantees.
The kernel still has unsafe operations, assembly and hardware interfaces. Those boundaries require separate review and testing.
A capability is a permission with limits.
At system-call dispatch, the resolver checks the token, boot session, address-space binding, revocation epoch and permission for the requested operation. Failed resolution returns a permission error.
In the v0.9.2 source, required permissions must fit the publisher certificate ceiling. Optional permissions are granted selectively. Required permissions cannot simply be removed while admitting a capsule that needs them; a restrictive policy must reject an incompatible workload.
Fine-grained restrictions, such as approved destinations, specific files or transaction amounts, also need explicit broker and application interfaces. A broad network capability is not equivalent to a destination allowlist.
Capability grant semantics ↗ · Runtime permission resolution ↗Verify what is admitted.
Enrolled system capsules take an attestation path that binds measurements and policy context. Publisher capsules follow certificate and manifest validation; the v0.9.2 source permits this path without a STARK trailer.
A signature or proof of admission is not a guarantee that the program’s behaviour is harmless.
Publisher gate evidence ↗Reduce residual state.
The design keeps sessions in RAM and includes teardown paths that wipe process memory, caches and keys. This reduces the intended persistence of local session data.
Power loss may bypass graceful teardown. Firmware, remote logs and explicitly exported data remain separate concerns.
Session teardown evidence ↗Put the model to the test.
Contain the blast radius.
AI agent capsule
Untrusted content input
Finance capsule
Private process memory
Signing capsule
Separate key authority
[policy] Agent has no authority over finance memory or signing keys.
The compromised agent retains its own data and any explicitly shared memory. Hardware and kernel flaws remain outside this simplified model.
Educational animation of intended boundaries, not a live exploit test or proof of NONOS deployment readiness. The model assumes correctly implemented isolation and a correctly configured policy.
The next era needs
a stronger foundation.
Explore the technology. Evaluate a pilot. Discuss a partnership.