Security Model

Security Model

XAIOS is experimental. Security behavior is exercised under QEMU, but the project is not ready for untrusted production deployment or physical-hardware security claims.

Current model

• Processes receive explicit capability masks. Every syscall is mapped to a required capability.
• Syscall request structures, nested pointers, ranges, permissions, transfer sizes, and narrowing conversions are validated before use.
• VFS descriptors and network sockets are process-owned and reclaimed with the owning process.
• Mutable user payloads are copied into bounded kernel-owned snapshots before policy checks or asynchronous subsystem use.
• Filesystem, workspace, sandbox, administrative role, replay, rollback, and development update-signature policies have focused self-tests.
• Administrative keys, revocations, configuration transactions, host-key rotation, and audit records use typed operations with explicit role and capability checks.
• Credential-like material is rejected from protected logging and persistence paths.
• Active xaiFS packages are immutable; publication uses verified, crash-consistent state transitions.

Sensitive source areas

• kernel/user/syscall.c
• kernel/include/xaios/syscall.h
• kernel/runtime/security.c
• kernel/runtime/admin_control.c
• kernel/runtime/control_protocol.c
• kernel/runtime/update.c
• kernel/runtime/persistence.c
• kernel/runtime/sandbox.c
• kernel/fs/
• kernel/net/
• userspace/sshd/

Changes in these areas require focused review for ownership, bounds, failure atomicity, replay, cleanup, and secret exposure.

SSH administration

Release images do not contain a built-in password or authorized key. The default development image contains the public admin / xaios credential for isolated QEMU and Fusion use; it must not be exposed on a bridged or public network. Set XAIOS_SSH_PASSWORD_AUTH=0 for a key-only development image. Release mode rejects every password-enabled build. The QEMU acceptance suite checks valid and invalid keys, valid and invalid passwords in development mode, malformed credential files, entropy failure, host identity persistence and rotation, revocation, rekey, session limits, reconnects, SFTP isolation, and secret redaction. The local serial console follows the same policy: it authenticates against the PBKDF2 database in the default development image, while key-only and release images remain locally locked and direct operators to SSH public-key authentication. Password input is not echoed, failed login does not create a shell session, and logout requires authentication again.

These tests do not replace an independent cryptographic implementation audit, hostile-network review, side-channel analysis, or production key-management design.

Updates and persistence

With tls=required the update client uses TLS 1.2 and validates the certificate chain against compiled-in ISRG roots, or an exact operator RSA-key pin instead for a private origin; the shipped configuration currently sets tls=off and fetches over plain HTTP, so signed catalogs and per-artifact hashes carry authenticity on their own until TLS is restored. Signed trust records provide monotonic Ed25519 release-root rotation and revocation; a separate pinned offline key authorizes recovery, and interrupted trust/catalog activation restores the previous verified pair. Checked-in TLS and signing keys are public QEMU fixtures, not production trust roots. Production key generation, custody, authorization, and compromise-response procedures remain open.

System-slot metadata and xaiFS use redundant or copy-on-write publication where implemented. QEMU crash gates test selected interruption points, not all physical power-loss, controller-cache, firmware, or storage-device behavior.

Required validation

Security-sensitive changes must run at least:

make compile-check
make code-scanning-contract
make qemu-security-gate
make qemu-smoke

The CI workflow's top-level grant is read access to repository contents and nothing more. One job raises it: publish-wiki takes contents: write so it can push wiki/ to the separate Wiki repository, and it runs only after the documentation contract passes, on a push to main in this repository. The local code-scanning contract prevents resolved workflow-permission, wildcard-bind, sensitive-diagnostic, and integer-width findings from returning; GitHub CodeQL remains the authoritative whole-repository scanner after push.

Every action the workflow uses is pinned to a full commit SHA rather than to a tag, because a tag is a mutable pointer and the workflow runs with this repository's token: whoever can move the tag decides what executes, including in the job that holds contents: write. .github/dependabot.yml moves those pins forward weekly, because a pin that nothing moves rots into the opposite problem -- a security fix that cannot reach the runner at all.

Update, storage, SSH, administration, or network changes also require their focused gates and the external interoperability suites described in Testing XAIOS.

Secret handling

Never commit credentials, access tokens, API keys, private keys, SSH keys, passwords, production signing material, or benchmark artifacts containing secrets. Revoke and rotate an exposed credential before continuing work.

Non-claims

• QEMU validation is not a security certification.
• The x86_64 QEMU image integrates the common security, process, SSH, filesystem, networking, AI Cell and telemetry services, but this is not an independent security review or approval for physical Internet exposure.
• Development keys and fixture credentials are not production trust roots.
• Physical DMA isolation, firmware trust, side channels, thermal/fault behavior, and supply-chain controls require separate validation.

See Current Limitations and Project Tracker.