Security Decisions

Four decisions that make Nexus security fundamentally different from POSIX.

S1: Capability Algebra

Status: Accepted

Context

POSIX security is based on ambient authority: if you're root, you can do anything. If your script runs as root, your script can do anything. ACLs add complexity but don't solve the confused deputy problem. Every year brings new CVEs caused by ambient privilege.

Decision

Every fiber spawns with an empty capability set (principle of least authority). Access requires explicit capability tokens:

7 Primitive Verbs:

Verb	Cost	Purpose
SPAWN	500J	Create a new fiber
SEND	5J	Write to an ION Ring channel
RECV	2J	Read from an ION Ring channel
MAP	10J	Map a memory region
MASK	3J	Restrict a capability (narrow permissions)
TICK	1J	Read the timer
GRANT	20J	Delegate a capability to another fiber

Each capability is an unforgeable token with permission bits and bounds. Capabilities degrade over time and delegation depth (Law of Decay). Revocation is instant via epoch-based bit flip.

Alternatives Rejected

Option	Why Not
POSIX UID/GID	Ambient authority: one security hole = full system compromise
SELinux/AppArmor	Policy is complex, brittle, false sense of security
Fine-grained POSIX ACLs	Still token-less, still vulnerable to confused deputy

Consequences

• No ambient authority (attack surface massively reduced)
• Revocation is instant (no need to kill the fiber)
• Delegation is explicit and auditable via ProvChain
• Formal verification of capability properties is possible
• Applications must be redesigned around capabilities (Membrane translates for POSIX apps)

---

S2: Pledge and Unveil Over Seccomp

Status: Accepted

Context

Linux Seccomp filters syscalls by number and arguments — a reactive approach with a complex BPF policy language. OpenBSD's Pledge declares upfront what resources a process needs. The kernel enforces at runtime with zero per-syscall overhead.

Decision

Nexus implements a Pledge/Unveil model inspired by OpenBSD:

• Pledge: Declare resource classes at spawn time — "net", "stdio", "rw", "storage", "spawn", "audio", "video", "gpu"
• Unveil: Whitelist specific filesystem paths — everything else is invisible
• One-way ratchet: Can only tighten pledges, never loosen
• Hardware enforcement: PMP (RISC-V), MPU (ARM), page tables (x86) back the software pledge

Alternatives Rejected

Option	Why Not
Seccomp BPF	Complex policy DSL, per-syscall filtering overhead, fragile on kernel changes
No sandboxing (capabilities only)	Capabilities control access but don't restrict resource classes
VM-based isolation (for everything)	10-100x overhead for isolating individual applications

Consequences

• Human-readable security intent (pledge("net stdio") is self-documenting)
• No per-syscall filtering overhead
• Smaller attack surface (unpledged resources don't exist for the fiber)
• Pledges must be declared at spawn time — no runtime modification
• Applications must know their own resource requirements upfront

Rumpk vs. OpenBSD

Rumpk's pledge goes further than OpenBSD in two ways:

1. Hardware-backed: PMP registers on RISC-V physically prevent memory access, not just software checks
2. Dual-layer: When RumKV is present, pledges are enforced at both hypervisor (Stage-2 tables) and kernel (capabilities) level

---

S3: Kinetic Economy

Status: Accepted

Context

Rate limiting is traditionally done with token buckets (bandwidth) or CPU time slicing (fairness). Neither captures the cost diversity of different operations — a memory map is more expensive than reading a timer, but token buckets treat them equally.

Decision

Energy-based budgeting: Every fiber has an energy budget (u32). Each verb costs energy. Budget depletion freezes the fiber until the next refill cycle.

Verb	Cost	Budget Impact
TICK	1J	Near-free
RECV	2J	Cheap read
MASK	3J	Restriction narrowing
SEND	5J	Data production
MAP	10J	Memory allocation
GRANT	20J	Delegation
SPAWN	500J	Fiber creation

Typical budget: 2000J per refill. Refill rate depends on Spectrum tier:

• Photon (real-time): Refilled every 8ms
• Matter (interactive): Refilled every 16ms
• Gravity (batch): Refilled every 100ms
• Void (idle): Refilled every 1s

Alternatives Rejected

Option	Why Not
Token buckets	Fine for bandwidth; doesn't capture verb cost diversity
CPU time slicing	Hard to measure accurately; overshooting wastes cycles
Message queue depth limits	Unbounded latency when queue fills
No rate limiting	Fork bombs and intent flooding crash the system

Consequences

• Fork bombs capped naturally: SPAWN=500J, budget=2000J = max 4 spawns per refill
• Intent flooding prevented: SEND=5J, 2000J budget = 400 messages per refill
• Spectrum fairness: real-time fibers get energy faster than batch
• No complex admission control needed
• Applications experience rate limiting as variable latency (not errors)
• Constants (costs, refill rates) need tuning per workload class

---

S4: TOFU+ Over PKI

Status: Accepted

Context

PKI requires trust anchors, certificate authorities, revocation lists, and ongoing infrastructure maintenance. SSH's Trust On First Use (TOFU) is simpler but vulnerable to man-in-the-middle on first connection. Nexus nodes operate in environments ranging from data centers to satellite links — PKI infrastructure isn't always available.

Decision

TOFU+ (Trust On First Use with binding):

1. First connection to a peer: accept their SipHash-128 CellID, store the binding
2. Subsequent connections: verify peer matches stored binding
3. Binding revocation requires either explicit administrator action or mutual consent (peer announces new key)
4. No global CA, no revocation lists, no certificate expiry

Alternatives Rejected

Option	Why Not
X.509 PKI	Requires root CA (centralized trust), certificate management, revocation infrastructure
Pure TOFU (SSH model)	Vulnerable to MITM on every first use
Self-signed certificates	Same trust friction as PKI without the infrastructure benefit
Pre-shared keys	Doesn't scale, key distribution is its own problem

Consequences

• Zero infrastructure needed (no CA servers, no cert stores, no OCSP responders)
• Instant bootstrap: first packet establishes identity
• Offline operation: no revocation lookups required
• Vulnerable to MITM on first contact (out-of-band verification needed for critical peers)
• Binding revocation is manual (no automatic key expiry)
• Suitable for mesh/satellite/air-gapped networks where PKI is impractical