Threat model

This page is the security model of SpaceOS: what each boundary protects, what enforces it, and what it does not cover.

Local development runs are outside this model. Do not use a local run as evidence that a flight release, association key, or node trust root was admitted.

Assets

The controls in this model protect these assets:

• the integrity and publisher identity of release bytes and build evidence;
• the authority assigned to each project, partition, and service;
• the integrity and freshness of capability and release metadata;
• the isolation of the node control plane from an untrusted workload;
• the integrity, source identity, and freshness of frame and bundle traffic;
• the availability of the runner and of workloads outside a failed service;
• private signing, association, and workload keys.

Mission payload confidentiality is also an asset. The ground paths do not protect it today, and the section on link and bundle traffic below marks that where the claim is made.

Trust boundaries

Boundary	Untrusted side	Trusted side	Enforcement
Release store to admission	OCI content, metadata, and transport	Pinned publisher and TUF root keys	Digest checks, signed statements, target path and length checks, and metadata version floors
Capability to runner	Requested identity, artifact, interfaces, storage, and secrets	Pinned capability issuers and the runner	Signed capability, artifact digest binding, rollback floor, and subset checks
Workload to node	Workload process and guest-written data	Runner, node kernel, hypervisor, and device backends	The selected isolation backend and narrow host interfaces
Workload to frame bus	Frames supplied by one service socket	space-net router	Socket-derived service identity, source APID range, and destination allow-list
Ground link to relay	Received frames	Relay association state and key	Frame authentication and anti-replay checks
Bundle transport to DTN service	Received bundles	BPSec integrity key and replay state	BIB verification, integrity scope, age, and replay checks
Operator to node	None	Node operator and platform administrator	The operator is trusted by this model

A tag in the local store selects the trust chain the first row is enforced against, and a tag is a mutable pointer. Signing and verification states what that bounds and what it does not.

The isolation backend changes the workload boundary:

• runc shares the node kernel. The runner applies a user namespace, seccomp, dropped capabilities, no-new-privileges, cgroups, a read-only root filesystem, and separate network namespaces under the default policy.
• Solo5 SPT is a kernel-process boundary with seccomp, dropped capabilities, no-new-privileges, and a read-only image. It has no user namespace or cgroup boundary.
• Solo5 HVT, Firecracker, and QEMU use a hardware-virtualisation boundary. They still trust the host kernel, tender or virtual machine monitor, and hardware virtualisation implementation.
• Host execution has no workload isolation boundary. It is limited to targets that explicitly allow it and is not a tenant security mechanism.
• The trusted host-network exception weakens the normal container boundary. It is for trusted platform services, not tenant workloads.

Read the boundary a workload runs behind

Read which row of that list applies to a given workload. Do not assume the backend. space status reports every workload the runner supervises with its lifecycle state, its isolation backend, and its image digest. The backend column names the boundary. The command queries the live runner and mutates nothing: it starts no daemon, no image and no virtual machine, and on a machine with no local runner it says so and exits zero.

$ space status

--json prints the same report as canonical JSON, which is the form to assert against in a test.

Adversaries

This model considers:

• an attacker who can replace or modify release and capability bytes but does not hold an accepted signing key;
• an attacker who can inject, modify, or replay link traffic but does not hold the association or bundle integrity key;
• a compromised workload that can use all authority granted to its service and can send malformed data through every interface it owns;
• a compromised container process that attempts to reach the shared node kernel or other workloads;
• an operator error that grants more authority than intended.

This model does not defend against a malicious node operator, a compromised publisher with an accepted key, compromised firmware or hypervisor, physical attacks, hardware side channels, or denial of service by an administrator.

Threats and mitigations

Modified release or build evidence

The source implementation verifies digest-valued SBOM and provenance annotations, the referenced blobs, in-toto statements, detached SCITT statements, and their subjects. The launch-trust verifier checks a signed TUF chain and matches the authorised target path, byte length, and SHA-256 digest.

A signature proves which accepted key authorised the bytes. It does not prove that the source code is correct, that the build host was clean, or that the publisher intended a safe change.

Replayed release or capability

The release verifier compares submitted root and targets versions with retained versions. The capability verifier rejects a rollback index below the retained floor. These checks depend on durable, authentic retained state.

Capability escalation

The runner binds a capability to the project, partition, and exact launch digest. It rejects requested credentials, APIDs, routes, bridges, host ports, and data links that are not subsets of the signed capability.

This control cannot correct an over-broad capability. The issuer must grant the minimum required authority.

Frame-bus spoofing and lateral movement

Each frame-bus service receives its own Unix socket. The router derives the service identity from that socket. It checks the frame’s source APID against the service range and applies the service’s send_to list to local destinations. An empty list denies local service-to-service delivery.

APIDs are routing labels. They are not credentials.

Link and bundle tampering or replay

The SDLS relay authenticates frames and checks its sequence window. The BPSec receiver requires a BIB over the payload, verifies its integrity scope, and rejects wrong-key, stale, and replayed bundles.

WIP: payload confidentiality

The relay opens its association with authentication on and encryption off, and the outgoing BPSec producer adds a Block Integrity Block and never a Block Confidentiality Block. Both paths therefore give integrity and source authentication and no payload secrecy, and no configuration turns secrecy on. What works today is the integrity half: a receiver detects a modified, replayed or wrong-key frame or bundle and refuses it. Encrypt sensitive payloads at the application layer, above SpaceOS, until this row changes.

Malformed supervision data

A compromised guest can write any byte in its shared supervision page. The runner treats guest status and health as untrusted. It reads the health field with a fixed bound and evaluates heartbeat progress against the host clock. A stalled heartbeat can trigger workload recovery. It does not prove that a responsive workload is correct.

Workload escape

The runner reports runc as a kernel-process boundary and the virtual-machine backends as hardware-virtualisation boundaries. A container escape can attack the shared node kernel. A virtual-machine escape can attack the hypervisor or host. Neither boundary protects a workload from the node operator.

Resource exhaustion

The runc configuration applies memory, CPU, and process limits. Supervision can restart or park a workload whose process exits or heartbeat stalls. These controls reduce interference from one service. They do not guarantee node or mission availability under every workload, kernel, storage, or traffic fault.

Credential access

The runner checks requested credential identifiers against the signed capability. For runc, it refuses missing files, symlink sources, malformed container paths, and ownership that the workload user namespace cannot read. Credentials are mounted read-only into the named service.

The node operator and node kernel remain inside this trust boundary.

Assumptions

The controls above require all of the following:

• accepted public keys are provisioned through an independent trusted channel;
• private keys remain secret and are rotated after suspected compromise;
• cryptographic implementations and random-number sources work as specified;
• retained rollback state cannot be deleted or replaced by an attacker;
• the node kernel, runner, firmware, hypervisor, and hardware enforce their documented boundaries;
• the selected backend is available and matches the admitted launch plan;
• release and capability issuers apply least privilege;
• operational monitoring notices repeated refusals, restarts, and resource pressure.

Residual risks

• The current ground paths do not provide payload confidentiality.
• A trusted publisher can sign a malicious release.
• A broad but valid capability authorises broad access.
• A runc workload shares the node kernel. A kernel vulnerability can cross the container boundary.
• Hardware-virtualisation backends depend on the host, hypervisor, tender, and CPU isolation implementation.
• Host execution and the trusted host-network exception weaken workload isolation by design.
• Heartbeat monitoring detects lack of progress, not incorrect output.
• Resource controls do not prevent every denial-of-service condition.
• Local development execution is not evidence of flight admission or link protection.
• Tests exercise specific behaviours. They are not a formal proof of the complete system.

Outside this model

Four areas have their own boundaries and are not analysed here: board secure boot, physical protection of the spacecraft and the ground station, mission command policy, and incident response. Each needs its own threat model, and a control on this page never stands in for one of them.