Watch
1
0
Fork
You've already forked SouveraineOS
0
SouveraineOS/docs/souveraine-components/README.md
Fimeg fc0ee4e1ed components: add Souveraine Rebuilt tiered inventory; update queue
INVENTORY.md seeds the eventual project reorg: authority substrate,
agent substrate, boot/session surfaces, rebuilt apps, platform. Queue
doc: lockscreen recreation done, three new named wants.
2026-07-17 07:12:15 -04:00

50 lines
2.5 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# 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](INVENTORY.md), organized in tiers. This page stays
authority-only.
## Members
| Binary | Tier | Owns | Page |
| --- | --- | --- | --- |
| `souveraine-machined` | system | machine Ed25519 seed | [machined.md](machined.md) |
| `souveraine-secrets` | user (session) | `org.freedesktop.secrets` backed by the seed lineage | [secrets.md](secrets.md) |
| `souveraine-sessiond` | user (session) | ext-session-lock; the unlock verb | [sessiond.md](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](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.