Watch
1
0
Fork
You've already forked SouveraineOS
0
SouveraineOS/docs/souveraine-components
Repository files (latest commit first)
Filename Latest commit message Latest commit date
Fimeg 341a2fe060 docs: take the lockscreen out of casey's uid
The current user unit wins the boot race but still runs as the human whose Personal key the lock is meant to evict. Record the target souveraine-session principal, its narrow Wayland/PAM/data reach, and the fact that the rich shell is presentation—not release authority.
2026-08-17 12:43:45 -04:00
..
audit-status.md docs: put agent identity behind a real uid 2026-08-17 12:36:45 -04:00
INVENTORY.md docs: put agent identity behind a real uid 2026-08-17 12:36:45 -04:00
machined.md docs: put agent identity behind a real uid 2026-08-17 12:36:45 -04:00
README.md components: add Souveraine Rebuilt tiered inventory; update queue 2026-07-17 07:12:15 -04:00
secrets.md deprecate chatty/libcmatrix/qtpim, clean stale refs 2026-07-21 13:51:14 -04:00
sessiond.md docs: take the lockscreen out of casey's uid 2026-08-17 12:43:45 -04:00

Souveraine components — substrate binaries

One page per secure Rust binary in the Souveraine substrate. These are the system- and user-tier daemons that hold authority the shell and agents never touch directly: machine identity, the secret service, and the session authority. Each page names what the binary owns, what crosses its boundary, and the open gaps before it reaches the RedFlag security bar.

The family is small on purpose. Adding a binary here means it holds authority no other component should hold — signing keys, unlock verbs, secret material. If a daemon does not meet that bar, it is not a component, it is a library.

The full "Souveraine Rebuilt" inventory — agent substrate, boot/session surfaces, rebuilt applications, platform — lives in INVENTORY.md, organized in tiers. This page stays authority-only.

Members

Binary Tier Owns Page
souveraine-machined system machine Ed25519 seed machined.md
souveraine-secrets user (session) org.freedesktop.secrets backed by the seed lineage secrets.md
souveraine-sessiond user (session) ext-session-lock; the unlock verb sessiond.md

The security bar these are built toward

Every component is on a path to the same posture RedFlag already embodies (SESSION-AUTHORITY-DOCTRINE §10/§11, SECURITY-AUDIT P1P7):

  • Binaries verify each other. A component that asks another for an authority action (sign, unlock, release a secret) must present an attestation the target checks — a hash or capability token resolved over a closure, not a name in a config file.
  • Capability tokens, not installation. Authority rides the federated seed identity (P7), not "this binary is in /usr/local/bin." The kernel stops are defense-in-depth, not the gate (RedFlag constraint #5).
  • One authority. Session authority and binary authority are the same authority (§11). sessiond verifies capability tokens on the things that ask it to unlock or step up; machined signs them; secrets releases against them.
  • Seeds are preconditions. No daemon creates identity. A missing seed fails loudly; generation is a deliberate, guarded CLI action.

Where a component has not yet reached that bar, the gap is recorded in its page under Audit gaps and rolled up in audit-status.md. The intent is that the audit doc is the live tracker: when a gap closes, the line moves there, and the component page's Audit gaps section is updated to match.