diff --git a/ops/legacy/ASL SystemRescue Overlay – Intake Schema.md b/ops/legacy/ASL SystemRescue Overlay – Intake Schema.md deleted file mode 100644 index 1fda944..0000000 --- a/ops/legacy/ASL SystemRescue Overlay – Intake Schema.md +++ /dev/null @@ -1,291 +0,0 @@ -Perfect — then let’s be very concrete and **treat the overlay itself as a specification**, not just “put binaries somewhere”. - -Below is a **clean, minimal, opinionated overlay schema** for an **ASL intake / rescue environment**, aligned with everything you’ve defined (ASL, STORE-INDEX, federation, ZFS optional). - -No diagrams, no fluff. - ---- - -# ASL SystemRescue Overlay – Intake Schema - -This overlay defines **what exists at boot**, **where state lives**, and **what is immutable vs runtime**. - ---- - -## 1. High-level intent - -The overlay must: - -* Make ASL tools **always available** -* Be **stateless by default** -* Support **local ZFS intake OR remote ASL intake** -* Keep **semantic state out of the rescue image** -* Be safe on crashed systems - -So the overlay provides: - -* **executables** -* **configuration defaults** -* **service wiring** -* **well-known mount points** - -Nothing else. - ---- - -## 2. Canonical overlay layout - -``` -overlay/ -├── usr/ -│ └── local/ -│ ├── bin/ -│ │ ├── asl-intake -│ │ ├── asl-admin -│ │ └── asl-debug -│ └── lib/ -│ └── libasl.so -│ -├── etc/ -│ └── asl/ -│ ├── asl.conf # mode selection, endpoints -│ ├── federation.conf # domain + peer config -│ └── logging.conf -│ -├── etc/systemd/system/ -│ ├── asl-intake.service -│ └── asl-preflight.service -│ -├── var/ -│ └── lib/ -│ └── asl/ -│ ├── runtime/ # ephemeral runtime state -│ ├── cache/ # optional CAS cache -│ └── locks/ -│ -├── run/ -│ └── asl/ -│ └── sockets/ # if used (optional) -│ -└── mnt/ - └── asl/ - ├── local/ # local ZFS mount target - └── remote/ # optional remote FS -``` - -This is the **entire contract** between SystemRescue and ASL. - ---- - -## 3. What each directory *means* (important) - -### `/usr/local/bin` - -**Immutable tools** - -* `asl-intake` - Primary recovery/intake executable -* `asl-admin` - Inspection, snapshot listing, GC checks -* `asl-debug` - Low-level validation, block/segment inspection - -> These must never write here. - ---- - -### `/etc/asl` - -**Declarative configuration only** - -Example `asl.conf`: - -``` -mode = auto # auto | local | remote -local.mount = /mnt/asl/local -remote.endpoint = https://asl-backend -domain.id = rescue-domain -``` - -Rules: - -* No secrets unless unavoidable -* No mutable state -* Safe to ship in ISO - ---- - -### `/var/lib/asl` - -**All mutable local state** - -This is the *only* place your tools write to by default. - -``` -/var/lib/asl/runtime # PID files, temp metadata -/var/lib/asl/cache # optional local CAS cache -/var/lib/asl/locks # advisory locks -``` - -This may live: - -* in RAM (default) -* on USB persistence -* never on the broken system disk - ---- - -### `/mnt/asl/local` - -**Local ASL backend mount (ZFS)** - -If local intake is possible: - -``` -zpool import rescuepool -zfs mount rescuepool/asl → /mnt/asl/local -``` - -Your tool treats this as: - -``` -/mnt/asl/local/ -├── blocks/ -├── segments/ -├── snapshots/ -└── logs/ -``` - -(Exact internal layout is backend-defined, not overlay-defined.) - ---- - -### `/mnt/asl/remote` - -Optional: - -* NFS -* SSHFS -* Debug mounts - -Not required for normal operation. - ---- - -## 4. systemd services (minimal and safe) - -### `asl-preflight.service` - -Runs once at boot. - -Responsibilities: - -* Detect network -* Detect ZFS availability -* Detect importable pools -* Write decision to `/run/asl/mode` - -No mutations. - ---- - -### `asl-intake.service` - -Starts the tool. - -Example behavior: - -* Reads `/run/asl/mode` -* Chooses: - - * local ZFS backend - * or remote ASL endpoint -* Starts intake loop or waits for operator - -This keeps **policy out of the binary**. - ---- - -## 5. Local vs remote handling (explicit contract) - -### Local ZFS mode - -The overlay guarantees: - -``` -/mnt/asl/local exists -/var/lib/asl writable -/usr/local/bin contains tools -``` - -Your tool guarantees: - -* Never mutate unsealed data -* Never auto-import pools without operator or config approval - ---- - -### Remote ASL mode - -The overlay guarantees: - -* Network tools available -* TLS roots present -* Configurable endpoint - -Your tool guarantees: - -* Snapshot-bounded reads -* Deterministic uploads -* Idempotent retries - ---- - -## 6. What is *explicitly forbidden* in the overlay - -These rules prevent disasters: - -❌ Writing to `/usr`, `/bin`, `/lib` -❌ Storing state in `/etc` -❌ Auto-mounting the crashed system root -❌ Assuming ZFS exists -❌ Assuming network exists - -All assumptions must be **detected, not presumed**. - ---- - -## 7. Why this schema works with your ASL design - -This layout aligns perfectly with your specs because: - -* **ASL-STORE-INDEX** - → persistence lives outside the overlay - -* **Federation** - → domain identity is config, not state - -* **PEL / TGK** - → execution artifacts are handled like any other artifact - -* **Determinism** - → overlay never contains semantic state - -The overlay is **pure capability**, not data. - ---- - -## 8. Summary (the one-paragraph version) - -> The SystemRescue overlay should contain **only tools, config, and wiring**. -> All mutable ASL state lives either in `/var/lib/asl` (ephemeral) or in a mounted backend (`/mnt/asl/local` or remote). -> The overlay never encodes semantic state, snapshots, or artifacts — only the ability to access and produce them. - -If you want, next we can: - -* Turn this into a **formal overlay contract doc** -* Define a **preflight decision table** -* Or map this schema directly onto your ASL backend spec - -But this layout is already “correct by construction.” - diff --git a/ops/legacy/ASL-AUTH-HOST Configuration.md b/ops/legacy/ASL-AUTH-HOST Configuration.md deleted file mode 100644 index 3d5aca4..0000000 --- a/ops/legacy/ASL-AUTH-HOST Configuration.md +++ /dev/null @@ -1,116 +0,0 @@ -Perfect! Here’s an example `config.yaml` for your `asl-auth-host`. This integrates domains, courtesy leases, snapshots, and SOPS bundle paths in a way that your host can start in “ready-for-pickup” mode or perform a rescue. - ---- - -## `/etc/asl-auth-host/config.yaml` - -```yaml -# ASL-AUTH-HOST Configuration -# Defines domains, policies, and SOPS bundles for bootstrap or rescue - -host: - name: "asl-auth-host-01" - version: "0.1" - mode: "rescue" # modes: "rescue" | "admission" | "normal" - -domains: - common: - id: "00000000-0000-0000-0000-000000000001" # Courtesy/common domain - type: "courtesy" - description: "Shared courtesy domain for new users or bootstrapped material" - path: "/var/lib/asl/common" - snapshot_retention: 30d - allowed_operations: - - read - - write - - append - courtesy_lease: 7d # Default grace period for newcomers - personal: - id: "00000000-0000-0000-0000-000000000002" # Personal private domain - type: "private" - description: "Private domain for rescued material or user-owned data" - path: "/var/lib/asl/personal" - snapshot_retention: 90d - allowed_operations: - - read - - write - - append - - seal - - gc - -certificates: - root_offline_path: "/var/lib/asl/certs/root-offline" - domain_authority_path: "/var/lib/asl/certs/domain-authority" - sops_bundle_path: "/var/lib/asl/certs/sops" - -policy: - hash_file: "/etc/asl-auth-host/policy.hash" - description: "Offline policy hash used to verify compliance before admission or rescue" - -logging: - path: "/var/log/asl-auth-host.log" - level: "INFO" - -store: - type: "zfs" # or "posix" - pools: - - name: "common_pool" - mount_point: "/var/lib/asl/common" - - name: "personal_pool" - mount_point: "/var/lib/asl/personal" - enable_snapshotting: true - snapshot_prefix: "asl_snap" - -# Optional hooks for init scripts -hooks: - pre_start: "/bin/init-asl-host.sh" - post_start: "/bin/helper-mount.sh" -``` - ---- - -### Notes: - -1. **`host.mode`**: - - * `"rescue"` → SystemRescue boot with ready-for-pickup for old material. - * `"admission"` → Host expects to receive a DAM and SOPS bundle for new personal domain. - * `"normal"` → Standard operation with personal domain active. - -2. **Domains**: - - * **Common**: Courtesy domain, short-term leases for newcomers. - * **Personal**: Private domain, snapshots and sealing enabled. - -3. **Certificates**: - - * Paths to offline root certs, DAM bundles, and SOPS bundles. - -4. **Policy hash**: - - * Offline verification ensures host doesn’t act on incompatible policies. - -5. **Store config**: - - * Can be POSIX or ZFS-based. - * Supports snapshotting for deterministic recovery. - -6. **Hooks**: - - * Allows you to initialize ZFS pools, mount overlays, or start ASL binaries. - ---- - -This config gives you a **bootable, ready-for-pickup SystemRescue node** that can handle: - -* Receiving old data -* Creating your personal domain -* Storing material safely in courtesy/common domain -* Verifying offline DAM bundles before admission - ---- - -I can also **draft the accompanying init script (`init-asl-host.sh`)** that reads this config, sets up domains, mounts pools, and prepares the store for immediate rescue or admission. - -Do you want me to do that next? - diff --git a/ops/legacy/ASL-AUTH-HOST ISO + Overlay Directory Layout.md b/ops/legacy/ASL-AUTH-HOST ISO + Overlay Directory Layout.md deleted file mode 100644 index a364737..0000000 --- a/ops/legacy/ASL-AUTH-HOST ISO + Overlay Directory Layout.md +++ /dev/null @@ -1,112 +0,0 @@ -Perfect! Here’s a **concrete directory layout blueprint** for your `asl-auth-host` ISO + overlay, ready to drop in binaries, certificates, and configuration. This integrates the concepts we discussed: domains, certificates, personal/common datasets, and the overlay structure. - ---- - -## ASL-AUTH-HOST ISO + Overlay Directory Layout - -``` -/iso_root/ # Root of ISO filesystem (from debootstrap) -/bin/ # Executables - asl-auth-host # Main host binary - asl-rescue # Rescue binary - init-asl-host.sh # Init script to bootstrap datasets & services - helper-mount.sh # Optional helper scripts -/etc/ - asl-auth-host/ - config.yaml # Host config (domains, policies, SOPS paths) - policy.hash # Optional policy hash for offline validation -/var/lib/asl/ # ASL storage root - common/ # Courtesy/common domain data - blocks/ # Encrypted blocks or artifacts - index/ # Store index for common domain - snapshots/ # Snapshots for deterministic reconstruction - logs/ # Append-only log - personal/ # Personal domain data - blocks/ # Encrypted personal blocks - index/ - snapshots/ - logs/ - pools/ # Placeholder directories for ZFS datasets if used -/var/lib/asl/certs/ # Certificates and DAM bundles - root-offline/ # Offline root certs - domain-authority/ # Signed DAM bundles - sops/ # Optional SOPS bundles -/var/log/ # Host logs - asl-auth-host.log -``` - ---- - -### Notes - -1. **ISO Root (`/iso_root`)** - - * Populated via debootstrap in Debian container. Overlay merges your binaries and directory structure. - -2. **Binaries (`/bin`)** - - * Place `asl-auth-host` and `asl-rescue` here. - * Init scripts can handle mounting ZFS datasets or preparing `/var/lib/asl` before starting the store. - -3. **Host Configuration (`/etc/asl-auth-host`)** - - * `config.yaml` contains domain IDs, policies, and SOPS bundle paths. - * `policy.hash` allows offline verification of policies before admission. - -4. **ASL Storage (`/var/lib/asl`)** - - * **Common**: Courtesy domain with pre-seeded blocks/artifacts. - * **Personal**: New private domain for rescued material. - * **Pools**: Reserved for mounting ZFS pools when booted. - -5. **Certificates (`/var/lib/asl/certs`)** - - * Offline roots for verifying DAM signatures. - * Domain authority DAM bundles received via SOPS. - -6. **Logging (`/var/log`)** - - * Minimal logs for host activity, index writes, and rescue operations. - ---- - -### Optional: Overlay Sub-structure for Development - -``` -/overlay/ - bin/ - asl-auth-host - asl-rescue - init-asl-host.sh - etc/ - asl-auth-host/config.yaml - asl-auth-host/policy.hash - var/ - lib/ - asl/ - common/ - personal/ - pools/ - certs/ - log/ -``` - -*This overlay merges into `/iso_root` during ISO build.* - ---- - -This layout **supports bootstrapping a personal domain from scratch**, seeding the courtesy/common domain, and later integrating offline DAM bundles. It also keeps your binaries and helper scripts isolated in `/bin` and `/etc` configs clean. - ---- - -I can also **draft an example `config.yaml` for the host** showing: - -* Domain IDs -* Courtesy lease definitions -* Default SOPS bundle paths -* Snapshot/retention policies - -…so your host is ready to pick up a new domain or rescued data. - -Do you want me to draft that next? - diff --git a/ops/legacy/ASL-AUTH-HOST v0-1 - Threat Model.md b/ops/legacy/ASL-AUTH-HOST v0-1 - Threat Model.md deleted file mode 100644 index 28c59b9..0000000 --- a/ops/legacy/ASL-AUTH-HOST v0-1 - Threat Model.md +++ /dev/null @@ -1,291 +0,0 @@ -Absolutely. Below is a **formal threat model write-up** for the system as it now stands. This is **not theoretical**; it is written to match your exact design choices, maturity level, and operational reality. - -I’ll keep it structured, explicit, and grounded. - ---- - -# ASL-AUTH-HOST v0.1 — Threat Model - -## 1. Scope and Assumptions - -### 1.1 In Scope - -This threat model covers: - -* **Offline ASL-AUTH-HOST** -* USB-mediated intake and output -* PEL execution -* Receipt (PER) generation and signing -* Domain admission and rescue bootstrap -* Published artifact creation - -### 1.2 Explicit Assumptions - -1. **Physical access = ultimate trust boundary** - - * The attacker may have physical access to USB media. - * The attacker may *not* have unsupervised access to the auth host hardware. - -2. **Auth host is air-gapped** - - * No network interfaces. - * No radios. - * No background services. - -3. **Offline root keys are uncompromised** - - * Root compromise is **out of scope** (catastrophic). - -4. **Operator is present** - - * Console interaction is intentional and visible. - ---- - -## 2. Assets to Protect - -| Asset | Description | -| ------------------------- | ------------------------------ | -| Root authority keys | Domain trust anchors | -| Domain signing keys | Used to mint DAMs and receipts | -| Execution receipts (PERs) | Portable truth of execution | -| Published artifacts | Immutable outputs | -| Domain identity | Correct domain binding | -| Policy hash | Guarantees semantic compliance | - ---- - -## 3. Adversary Model - -### 3.1 Adversary Capabilities - -The attacker may: - -* Supply malicious USB content -* Replay old requests -* Attempt malformed PEL programs -* Attempt filesystem abuse via USB -* Attempt to confuse domain identity -* Attempt to exfiltrate private artifacts - -The attacker **cannot**: - -* Inject network traffic -* Modify host binaries (unless physical compromise) -* Access signing keys without operator approval - ---- - -## 4. Trust Boundaries - -``` -[ USB ] ────(read-only)────> [ AUTH HOST ] - | - | (PEL execution) - v - [ ASL Store ] - | - └──> (write-only) → [ USB RESPONSE ] -``` - -**Critical principle**: - -> Data flows in one direction per phase, never bidirectional. - ---- - -## 5. Threat Analysis (STRIDE-like) - -### 5.1 Spoofing - -**Threat:** -Fake domain requests or forged admission. - -**Mitigations:** - -* Manifest + signature verification -* Policy hash enforcement -* Offline root verification -* Domain IDs generated and signed by authority - ---- - -### 5.2 Tampering - -**Threat:** -USB content modified to alter inputs or outputs. - -**Mitigations:** - -* Intake is read-only -* Hashes over all inputs -* Response signature covers: - - * Request manifest hash - * Receipt hash - * Published artifact hashes - ---- - -### 5.3 Repudiation - -**Threat:** -Requester denies what was executed. - -**Mitigations:** - -* Receipt includes: - - * Program hash - * Input hashes - * Snapshot ID -* Receipt signed by authority -* Deterministic replay possible - ---- - -### 5.4 Information Disclosure - -**Threat:** -Private data leaks from auth host. - -**Mitigations:** - -* No shell access to arbitrary tools -* No network -* Explicit publish rules -* Unpublished artifacts never leave host -* Encrypted blocks allowed in public domains - ---- - -### 5.5 Denial of Service - -**Threat:** -USB floods, huge inputs, malformed PEL. - -**Mitigations:** - -* Operator-mediated execution -* Explicit size limits in manifest -* Deterministic PEL subset -* No automatic execution - ---- - -### 5.6 Elevation of Privilege - -**Threat:** -PEL program escapes sandbox or invokes host capabilities. - -**Mitigations:** - -* PEL is declarative -* No exec, no syscalls, no I/O primitives -* Host enforces operator whitelist of ops -* Canonical PEL interpreter only - ---- - -## 6. Specific High-Risk Scenarios - -### 6.1 Malicious USB with filesystem exploits - -**Mitigation:** - -* Mount read-only -* No traversal outside `/REQUEST` -* No symlink following -* No execution from USB - ---- - -### 6.2 Replay of old admission request - -**Mitigation:** - -* `request_id` uniqueness -* Receipt records snapshot -* Authority tracks processed request IDs - ---- - -### 6.3 Confused domain attack - -**Threat:** -Attacker attempts to get artifacts bound to wrong domain. - -**Mitigation:** - -* Domain ID assigned by authority -* Domain binding part of receipt hash -* No requester-supplied domain ID is trusted - ---- - -### 6.4 Side-channel via timing or output size - -**Mitigation:** - -* Coarse-grained execution -* Deterministic output -* Optional output padding - -(Residual risk acknowledged but acceptable.) - ---- - -## 7. What This Model Explicitly Does *Not* Protect Against - -| Out of Scope | Reason | -| --------------------------- | -------------- | -| Physical compromise of host | Catastrophic | -| Malicious operator | Social problem | -| Root key exfiltration | Ends trust | -| Covert EM attacks | Beyond scope | - ---- - -## 8. Security Posture Summary - -**Strengths:** - -* Minimal attack surface -* Explicit authority boundaries -* Deterministic execution -* Portable, signed truth (PER) -* No ambient trust - -**Residual risks:** - -* Physical compromise -* Operator error -* Supply-chain attacks on binaries - ---- - -## 9. Alignment With Your Design Philosophy - -This system: - -* Treats **authority as a press, not a server** -* Treats **data as artifacts, not files** -* Treats **execution as a receipt, not a side effect** -* Treats **trust as explicit and finite** - -It is **hard to misuse**, **easy to audit**, and **honest about its limits**. - ---- - -## 10. Recommended Next Documents (in order) - -1. **PEL canonical encoding spec** -2. **Receipt canonicalization & hash rules** -3. **DAM final schema** -4. **Operator checklist (human protocol)** -5. **Minimal reference implementation** - -If you want, next I can write the **operator checklist**, which is often the missing piece that keeps systems like this safe in practice. - -Just say the word. - diff --git a/ops/legacy/ASL-AUTH-HOST v0.1 — Authority Node Profile.md b/ops/legacy/ASL-AUTH-HOST v0.1 — Authority Node Profile.md deleted file mode 100644 index 14f2663..0000000 --- a/ops/legacy/ASL-AUTH-HOST v0.1 — Authority Node Profile.md +++ /dev/null @@ -1,182 +0,0 @@ -Here’s a first draft for **ASL-AUTH-HOST v0.1** — the profile for an authority node that is structurally similar to a SystemRescue node but configured for offline, auditable domain authority operations. - ---- - -# ASL-AUTH-HOST v0.1 — Authority Node Profile - -## 1. Purpose - -Defines the **host-level profile** for a Domain Authority Node (DAN) in the ASL ecosystem. -This profile ensures that the authority node: - -* Operates **offline** -* Maintains an **internal ASL-HOST store** -* Produces **deterministic artifacts and receipts** -* Supports **domain admission and certificate management** -* Can bootstrap **new personal or group domains** - ---- - -## 2. Core Principles - -1. **All authority state is an artifact**: keys, DAM, policies, and environment claims are recorded in ASL. -2. **Offline-first**: no network dependency for core operations. -3. **Deterministic snapshots**: every operation is captured in a snapshot. -4. **Receipt-oriented**: outputs are PER artifacts ready for federation or personal import. -5. **Minimal trusted code**: authority functionality is limited to signing, sealing, and packaging artifacts. - ---- - -## 3. Required Components - -### 3.1 ASL-HOST Store - -``` -/asl-host/ - /domains/ - // - /store/ # block store - /log/ # append-only log - /snapshots/ # snapshot markers - /certs/ # locally stored authority certificates - /policies/ # policy artifacts - /dam/ # Domain Admission Manifests -``` - -* Supports block and index operations according to ASL-STORE semantics. -* No external federation by default. - ---- - -### 3.2 Authority Keys - -* Root keypair generated locally per domain. -* Stored as: - - * Public key artifact - * Private key artifact (encrypted on local storage) -* Optionally rotated with deterministic PEL DAGs. - ---- - -### 3.3 Offline Environment Claim - -* Records: - - * Image hash - * Boot-time environment - * Installed tool versions - * Snapshot of ASL-HOST store -* Stored as **environment claim artifact**. - ---- - -### 3.4 Domain Admission Manifest (DAM) - -* Stored as an artifact. -* Includes: - - * Domain ID - * Root key fingerprint - * Policy hash - * Optional courtesy lease references -* Signed with authority node’s root key. - ---- - -### 3.5 PEL Programs - -* Minimal offline PEL DAGs for: - - * Signing DAMs - * Generating PER receipts - * Packaging SOPS bundles -* Executed **deterministically** from snapshots. - ---- - -## 4. Operation Modes - -| Mode | Description | -| --------------- | ------------------------------------------------------------------------------------ | -| **Genesis** | Create first domain for personal use; generate DAM, root keys, and policy artifacts. | -| **Rescue** | Accept input artifacts (old data, files, or device images) and produce PER receipts. | -| **Admission** | Sign DAMs and package SOPS bundles for new nodes entering the ecosystem. | -| **Maintenance** | Rotate keys, refresh policies, seal snapshots, audit artifacts. | - ---- - -## 5. Snapshot and Logging - -* Every operation produces: - - * New blocks for artifacts - * Append-only log entries - * Snapshot marker capturing CURRENT state -* Snapshots are **immutable** and form the basis for deterministic PER generation. - ---- - -## 6. Authority-Only Constraints - -* No network communication. -* No automatic federation. -* All outputs are artifacts for later import or distribution. -* Garbage collection is disabled; nothing may be deleted from genesis snapshot onward. - ---- - -## 7. Security Considerations - -* Root private keys **must** remain offline. -* Environment claim artifacts allow **proof of image integrity** and operational reproducibility. -* Courtesy leases (optional) allow temporary storage for new personal domains under common domain supervision. - ---- - -## 8. Output Artifacts - -| Artifact Type | Description | -| -------------------------- | ---------------------------------------------------------------- | -| Root key artifact | Public/private keypair for domain signing. | -| DAM artifact | Domain Admission Manifest, signed. | -| Policy artifact | Hash of accepted policies and operational contracts. | -| Environment claim artifact | Immutable claim of offline environment state. | -| PER artifact | Receipt confirming DAM or policy execution. | -| SOPS bundle | Encrypted and portable bundle for admission or personal archive. | - ---- - -## 9. Bootstrapping Flow - -1. Boot ASL-AUTH-HOST image offline. -2. Initialize local ASL-HOST store. -3. Generate root keypair artifact. -4. Create DAM artifact, sign with root key. -5. Produce environment claim artifact. -6. Seal snapshot (`genesis snapshot`). -7. Generate PER receipts for DAM and environment. -8. Optionally export SOPS bundle for new nodes or personal import. - ---- - -## 10. Relationship to SystemRescue Node - -* Uses same OS image base. -* ASL-HOST store layout is identical. -* Only differs in: - - * Authority keys presence - * Offline-only policy - * Deterministic signing and SOPS bundle generation - ---- - -This draft defines the **authority node as a first-class ASL-HOST**, offline, deterministic, and auditable, ready to issue DAMs, PERs, and SOPS bundles for new personal domains or rescue operations. - ---- - -If you want, I can **draft the exact on-disk block layout for ASL-AUTH-HOST**, showing directories, artifact blocks, log files, snapshots, DAMs, and policy files, similar to a precise filesystem blueprint for bootstrapping. This would make it fully tangible for your SystemRescue image. - -Do you want me to do that next? - diff --git a/ops/legacy/ASL-HOST v0-1.md b/ops/legacy/ASL-HOST v0-1.md deleted file mode 100644 index fdc7e08..0000000 --- a/ops/legacy/ASL-HOST v0-1.md +++ /dev/null @@ -1,172 +0,0 @@ -Here’s a clean **v0.1 draft for ASL-HOST**, scoped to what we discussed — minimal, environment-focused, without touching semantics or storage encoding. This is the runtime/host interface layer that bridges ASL-STORE(-INDEX) to a real system. - ---- - -# ASL-HOST v0.1 – Host/Runtime Interface for ASL Stores - -## 1. Purpose - -**ASL-HOST** specifies the **runtime contract** between an ASL store and the host environment. -It defines **what the host must provide** for an ASL store to operate correctly, without imposing: - -* Storage semantics -* Encoding -* Policy -* Security beyond minimal integrity guarantees - -It supports **POSIX filesystems, ZFS, object stores**, or other backing layers. - ---- - -## 2. Core Concepts - -| Concept | Definition | -| ----------------- | ------------------------------------------------------------------------- | -| **StoreHandle** | Opaque reference to a host-provided store instance | -| **StoreLocation** | Host-defined location where a store exists (path, URI, mount point, etc.) | -| **AppendUnit** | Minimum atomic write unit for the append-only log | -| **SnapshotID** | Opaque identifier of a host-provided snapshot | -| **HostClock** | Monotonic counter or timestamp source | -| **HostIdentity** | Unique machine or user identity for signing or domain minting | - ---- - -## 3. Store Instantiation - -### 3.1 Store Creation - -* `CreateStore(location: StoreLocation) → StoreHandle` -* Must guarantee crash-consistent initialization. -* Location may be: - - * POSIX path - * ZFS dataset - * Object store bucket -* StoreHandle is **opaque**, only valid while the store exists on host. - -### 3.2 Store Open - -* `OpenStore(location: StoreLocation) → StoreHandle` -* Host must provide durable, consistent view. -* Opening an existing store must not corrupt previous data. - -### 3.3 Store Close - -* `CloseStore(store: StoreHandle)` -* Ensures all writes are persisted to durable media. -* Optional: triggers host-specific flush or checkpoint. - ---- - -## 4. Atomic Append / Log Operations - -* Host must provide **atomic append** semantics. -* Minimum guarantees: - - * Sequential ordering (logseq monotonicity) - * Crash consistency (partial writes are not visible) -* AppendUnit: - - * Defined by host; could be page-size or object-size - * ASL-STORE must tolerate host’s granularity - ---- - -## 5. Snapshot Management - -* Optional but recommended. -* Host provides: - - * `CreateSnapshot(store: StoreHandle) → SnapshotID` - * `MountSnapshot(store: StoreHandle, id: SnapshotID) → StoreHandle` -* Guarantees: - - * Snapshot captures a consistent view of sealed blocks - * Mounting snapshot produces read-only store handle -* Host may use: - - * ZFS snapshot - * POSIX filesystem copy-on-write overlay - * Object store versioning - ---- - -## 6. Durability & Crash Semantics - -* Host must ensure: - - * Writes are durable after append or flush - * Crash recovery restores store to last durable state - * Open, unsealed blocks may be lost without breaking invariants -* StoreHandle and append-only log are **atomic units** visible to ASL-STORE - ---- - -## 7. Minimal Identity & Logging - -* Host must provide: - - * `HostClock()` → monotonic timestamp / counter - * `HostIdentity()` → machine or user ID for signing / domain minting - * Optional log for debugging or auditing - ---- - -## 8. Error Semantics - -* Operations may return: - - * `STORE_OK` - * `STORE_EXISTS` - * `STORE_NOT_FOUND` - * `STORE_IO_ERROR` - * `STORE_CONCURRENT_MODIFICATION` -* ASL-STORE must handle errors deterministically - ---- - -## 9. Security Considerations - -* ASL-HOST does **not enforce cryptography**. -* Host may provide optional: - - * Encryption at rest - * Access control - * Secure snapshot mechanisms -* Certificates and trust are handled in **ASL-AUTH**, separate layer - ---- - -## 10. Example Implementations - -| Backend | How ASL-HOST maps | -| ---------------- | ---------------------------------------------------------------------------------- | -| POSIX filesystem | StoreLocation = path; append = write+fsync; snapshot = overlayfs copy | -| ZFS dataset | StoreLocation = dataset; append = zfs sync; snapshot = zfs snapshot | -| Object store | StoreLocation = bucket/namespace; append = object PUT; snapshot = versioned bucket | - ---- - -## 11. Versioning - -* Spec version: **0.1** -* Backward incompatible changes must bump major version. -* Minimal compliance: implement store creation/open/close and append guarantees. - ---- - -## 12. Summary - -**ASL-HOST v0.1**: - -* Defines **runtime contract** between ASL store and host -* Provides **store handles, atomic append, snapshots, identity** -* Layered cleanly above ASL-STORE(-INDEX), below system or OS -* Keeps **semantics, encoding, and trust separate** - ---- - -If you like, I can **draft ASL-AUTH v0.1** next, and then show how **SystemRescue could instantiate ASL-HOST with POSIX/ZFS to seed a personal domain**. That would give a complete view for your rescue scenario. - -Do you want me to do that next? - diff --git a/ops/legacy/ASL-HOST v0-2.md b/ops/legacy/ASL-HOST v0-2.md deleted file mode 100644 index 4cdc0cd..0000000 --- a/ops/legacy/ASL-HOST v0-2.md +++ /dev/null @@ -1,317 +0,0 @@ -Good — this is the right integration point. -What follows is a **clean, minimal integration of DAP + DAM + Courtesy Leases into ASL-HOST**, without leaking authority into ASL-CORE or policy into ASL-STORE. - -Think of **ASL-HOST as the membrane** where *authority, storage, and execution meet but do not mix*. - ---- - -# ASL-HOST v0.1 (Integrated with Admission & Authority) - ---- - -## 1. Purpose of ASL-HOST - -**ASL-HOST defines the responsibilities of a node that hosts ASL domains.** - -It is responsible for: - -* Domain lifecycle -* Admission and recognition -* Block and log materialization -* Snapshot discipline -* Resource enforcement -* Separation of authority from storage semantics - -It explicitly does **not** define: - -* Artifact encoding (ASL-CORE) -* Index layout (ENC-ASL-STORE) -* PER or TGK semantics (PEL / TGK layers) -* Cryptographic algorithms (delegated to ASL-AUTH) - ---- - -## 2. ASL-HOST Position in the Stack - -``` -+-------------------------+ -| ASL-AUTH | ← identity, keys, policy -+-------------------------+ -| ASL-HOST | ← THIS SPEC -+-------------------------+ -| ASL-STORE / INDEX | ← blocks, logs, snapshots -+-------------------------+ -| ASL-CORE / PEL / TGK | ← semantics & execution -+-------------------------+ -| Filesystem / ZFS / POSIX| -+-------------------------+ -``` - -ASL-HOST is where **domains become real**. - ---- - -## 3. Domain Lifecycle in ASL-HOST - -### 3.1 Domain States - -```text -UNRECOGNIZED -ADMITTED (COURTESY) -ADMITTED (FULL) -SUSPENDED -REVOKED -``` - -ASL-HOST tracks domain state explicitly. - ---- - -### 3.2 Domain Creation (Local) - -A domain MAY be created locally without admission: - -```text -asl-host domain create -``` - -This creates: - -* DomainID -* Empty storage namespace -* Empty log -* No external recognition - -This domain is **self-contained only**. - ---- - -## 4. Domain Admission Integration (DAP) - -### 4.1 Admission Request Handling - -ASL-HOST MUST provide: - -```c -AdmissionResult asl_host_admit(DAM, signature, request); -``` - -Responsibilities: - -* Validate DAM schema -* Verify signature -* Check policy compatibility -* Decide admission outcome - -ASL-HOST does **not** inspect artifacts. - ---- - -### 4.2 Admission Outcome Effects - -| Outcome | ASL-HOST Behavior | -| ---------------- | --------------------------------------- | -| ACCEPTED | Enable publishing, indexing, federation | -| ACCEPTED_LIMITED | Enable courtesy-only storage | -| DEFERRED | Domain exists but blocked | -| REJECTED | Domain remains isolated | - ---- - -## 5. Courtesy Leases in ASL-HOST - -### 5.1 Courtesy Lease Attachment - -A courtesy lease is **attached to a domain in ASL-HOST**, not to ASL-STORE. - -```text -Domain { - domain_id - admission_state - courtesy_lease? -} -``` - ---- - -### 5.2 Enforcement Responsibilities - -ASL-HOST MUST enforce: - -* Storage limits -* Snapshot count -* Lease expiry -* Encryption-only constraint (if specified) - -ASL-STORE must **not** be aware of courtesy semantics. - ---- - -### 5.3 Courtesy Lease Expiry - -On expiry, ASL-HOST MAY: - -* unpin snapshots -* block new writes -* mark domain as SUSPENDED - -ASL-STORE is not required to preserve data. - ---- - -## 6. StoreHandle Integration - -### 6.1 StoreHandle Is Scoped to a Domain - -ASL-HOST provides: - -```c -StoreHandle *asl_host_open_domain(domain_id); -``` - -The StoreHandle is: - -* domain-scoped -* snapshot-aware -* admission-aware - ---- - -### 6.2 Admission-Gated Capabilities - -Capabilities exposed via StoreHandle depend on admission state: - -| Capability | Courtesy | Full | -| ---------------- | -------- | ---- | -| allocate_block | yes | yes | -| seal_block | yes | yes | -| append_log | yes | yes | -| publish_snapshot | no | yes | -| federate_log | no | yes | - -ASL-CORE and PEL never see this distinction. - ---- - -## 7. Snapshots and CURRENT (ASL-HOST Role) - -ASL-HOST defines: - -* Snapshot creation -* Snapshot pinning -* Snapshot association with log position - -ASL-HOST guarantees: - -```text -CURRENT = snapshot + replay(log) -``` - -This is **host-level truth**, not an ASL-CORE concern. - ---- - -## 8. Block Ownership and Movement - -### 8.1 Block Ownership - -Every block belongs to exactly one domain. - -Block ownership is enforced by: - -* filesystem layout -* StoreHandle scoping -* ASL-HOST policy - ---- - -### 8.2 Block Migration Between Domains - -Block migration is an **ASL-HOST operation**: - -```text -asl-host migrate-block --from A --to B -``` - -Rules: - -* Source block must be sealed -* Destination domain must accept the block -* Policy compatibility enforced -* Provenance preserved - ---- - -## 9. Federation Boundary - -ASL-HOST is the **only layer allowed to federate**. - -It decides: - -* which logs may be exported -* which snapshots may be published -* which foreign roots are trusted - -ASL-STORE and ASL-CORE remain oblivious. - ---- - -## 10. Revocation and Suspension - -ASL-HOST MAY: - -* suspend a domain (stop new writes) -* revoke federation -* invalidate admission - -Already-sealed artifacts remain immutable. - ---- - -## 11. SystemRescue Mapping (Concrete) - -Your patched SystemRescue image now hosts: - -* ASL-HOST runtime -* Local domains (personal, courtesy, common) -* Admission client -* Offline authority material - -On boot, SystemRescue may: - -1. Create a local domain -2. Load DAM + keys -3. Submit admission request -4. Receive courtesy lease -5. Begin sealed ingestion -6. Snapshot and wait - -You are *literally standing ready*. - ---- - -## 12. Why This Integration Is Clean - -✔ ASL-CORE untouched -✔ ASL-STORE unaware of authority -✔ Authority never touches block bytes -✔ Admission precedes trust -✔ Rescue and sovereign modes unified - ---- - -## 13. Mental Model (One Sentence) - -> **ASL-HOST is the constitutional layer that turns storage into a domain, and a domain into a participant.** - ---- - -If you want next, we can: - -* define **ASL-HOST on-disk layout** -* specify **revocation propagation** -* map **PEL execution to admission state** -* or walk a **full rescue → admission → federation scenario end-to-end** - -Just point the direction. - diff --git a/ops/legacy/Bootable ASL-AUTH-HOST.md b/ops/legacy/Bootable ASL-AUTH-HOST.md deleted file mode 100644 index b47802f..0000000 --- a/ops/legacy/Bootable ASL-AUTH-HOST.md +++ /dev/null @@ -1,90 +0,0 @@ -Ah, yes — you’re right! The previous summary focused on ASL, PEL, domains, and blocks, but we also discussed **building an ASL-AUTH-HOST ISO and bootable USB workflow**. Here’s a compact recap integrated with your overall architecture: - ---- - -# Bootable ASL-AUTH-HOST / USB Summary - -## 1. Environment - -* Start from a **minimal Debian root** (via `debootstrap`) inside a container. -* Set up: - - * `$WORKDIR/iso_root` → ISO root filesystem - * `$WORKDIR/overlay` → ASL binaries, scripts, and configuration - -## 2. Overlay contents - -* `bin/` → `asl-auth-host`, `asl-rescue`, helper scripts -* `usr/local/bin/` → optional local tools -* `var/lib/asl/` → datasets, pools, personal/common directories -* `var/log/` → logs -* Bootloader configs (`isolinux/`) - ---- - -## 3. Bootable ISO creation - -* Copy overlay into `$ISO_ROOT` -* Create ZFS-like dataset directories: - - ``` - var/lib/asl/{common,personal,pools} - ``` -* Generate ISO via `xorriso` (or `mkisofs`) with minimal bootloader - ---- - -## 4. ASL Capture Integration - -* **`asl-capture`** can wrap shell or program execution -* Capture occurs **during image creation**: - - * Can log everything in the host root during debootstrap + `apt-get install` - * Produces artifacts (executed commands, receipts) -* Early capture allows **provenance from the very birth of the image** - ---- - -## 5. USB boot workflow - -1. Build ISO (`build_asl_auth_host_iso.sh`) -2. Write ISO to USB (`dd` or `rufus`/`balenaEtcher`) -3. Boot machine → `init-asl-host.sh` (custom init script) - - * Mount ZFS or overlay store - * Initialize domains (Common, personal, rescue) - * Enforce witness authority / DAM at boot - * Run ASL capture to log host state - ---- - -## 6. Storage & persistence on USB - -* Personal domain: local USB store -* Root.alice or Common: mounted network or local store -* Snapshot management ensures deterministic state -* Blocks and artifacts are packed according to store policy -* Index/log replay reconstructs current state at boot - ---- - -## 7. Key insights from discussion - -* You **can capture the host from first boot** to have full provenance. -* Witness authority (DAM) is enforced **before userspace programs run**, even for Common. -* Blocks remain storage-level; artifacts remain semantic and authoritative. -* Publishing to Common happens **via root.alice**; private artifacts remain in `alice` domain. -* Bootable USB + ASL capture = deterministic, auditable host for rescue and auth purposes. - ---- - -If you want, I can **draw a full flow diagram** that shows: - -``` -debootstrap → overlay → ISO → USB → boot → init-asl-host → domains → ASL capture → artifacts/logs -``` - -…including where **root.alice, Common, and personal domains** live, and how **blocks, artifacts, and logs** interact during boot. - -Do you want me to do that diagram next? - diff --git a/ops/legacy/ENC-ASL-AUTH-HOST.md b/ops/legacy/ENC-ASL-AUTH-HOST.md deleted file mode 100644 index efc5d17..0000000 --- a/ops/legacy/ENC-ASL-AUTH-HOST.md +++ /dev/null @@ -1,225 +0,0 @@ -Perfect! Here’s a draft specification for **ENC-ASL-AUTH-HOST v0.1**, the **on-disk layout and encoding** for the authority host. This complements ASL-AUTH-HOST by formalizing **how artifacts, blocks, logs, snapshots, and certificates are stored**. - ---- - -# ENC-ASL-AUTH-HOST v0.1 — On-Disk Layout - -## 1. Purpose - -Defines the **physical and logical layout** of an ASL authority host’s storage. -Ensures: - -* Deterministic artifact placement -* Snapshot-aware storage -* Offline-first operation -* Compatibility with ASL-HOST, PERs, and SOPS bundles - ---- - -## 2. Root Layout - -``` -/asl-auth-host/ -├─ /domains/ -│ ├─ / -│ │ ├─ /store/ -│ │ ├─ /log/ -│ │ ├─ /snapshots/ -│ │ ├─ /certs/ -│ │ ├─ /policies/ -│ │ └─ /dam/ -├─ /tools/ -│ └─ # deterministic, versioned rescue/auth tools -├─ /env-claims/ -│ └─ .claim -└─ /sops-bundles/ - └─ .sops -``` - ---- - -## 3. Domains Directory - -**`/domains//`** contains all **domain-specific storage and authority artifacts**. - -### 3.1 Store - -``` -/domains//store/ -├─ blocks/ -│ ├─ .bin # raw artifact bytes -│ └─ .meta # metadata: size, type_tag, sealed_flag -├─ indices/ -│ ├─ segment-.idx # ASL-STORE index segments -│ └─ bloom-.bf # optional bloom filters -``` - -* Each block is **immutable once sealed** -* Segment indices point to block IDs and offsets -* Encoding follows **ASL-STORE-INDEX + ENC-ASL-STORE(-INDEX)** rules - ---- - -### 3.2 Log - -``` -/domains//log/ -├─ log-.aol # append-only log files -``` - -* Each log record contains: - - * Artifact additions - * DAM signatures - * Snapshot seals - * Tombstone records -* Deterministic replay reconstructs **CURRENT** state - ---- - -### 3.3 Snapshots - -``` -/domains//snapshots/ -├─ snapshot-.meta -├─ snapshot-.blocks # optional reference map -``` - -* Snapshot metadata includes: - - * Logseq boundary - * Sealed segments - * Block references - * Environment claim artifact reference -* Snapshots are **immutable** - ---- - -### 3.4 Certificates - -``` -/domains//certs/ -├─ root.pub # root public key -├─ root.priv.enc # encrypted private key -├─ dam-signer.pub # optional signing key for DAMs -├─ dam-signer.priv.enc -``` - -* All private keys are encrypted and **never leave offline host** -* Public keys are referenced in DAM artifacts - ---- - -### 3.5 Policies - -``` -/domains//policies/ -├─ policy-.json -``` - -* Policy hash stored as artifact -* Policies include: - - * Domain admission rules - * Courtesy leases - * GC / retention rules - ---- - -### 3.6 Domain Admission Manifests (DAM) - -``` -/domains//dam/ -├─ dam-.json.sig # signed DAM artifact -``` - -* Each DAM artifact contains: - - * Domain ID - * Root key fingerprint - * Policy hash - * Courtesy lease info (optional) -* Signed by root key - ---- - -## 4. Tools - -``` -/tools/ -├─ asl-auth-host # main authority binary -├─ asl-rescue # SystemRescue patched tools -└─ sops # for offline bundle creation -``` - -* Versioned, deterministic, immutable binaries -* Executables stored as ASL artifacts if desired - ---- - -## 5. Environment Claims - -``` -/env-claims/ -├─ .claim -``` - -* Contains: - - * OS image hash - * Boot environment info - * Installed tool hashes - * ASL-HOST store checksum at snapshot -* Stored as artifact and optionally signed by root key - ---- - -## 6. SOPS Bundles - -``` -/sops-bundles/ -├─ .sops -``` - -* Encrypted container for DAMs, PER receipts, and optionally policies -* Can be delivered to new nodes for **admission or rescue** -* Includes checksums for integrity - ---- - -## 7. Encoding Conventions - -1. **Blocks**: `.bin` (raw bytes), accompanied by `.meta` -2. **Indices**: segment-based index; segment files immutable after seal -3. **Log**: append-only, each entry: - - * `logseq | artifact_key | block_ref | type_tag | operation | signature` -4. **Snapshots**: snapshot ID derived from hash of CURRENT log + block refs -5. **Certificates**: PEM or ASL-artifact wrapped keys -6. **SOPS Bundles**: standard encrypted JSON/YAML with embedded checksums - ---- - -## 8. Security Notes - -* Private keys must **never be exposed** or included in SOPS bundles unencrypted -* Blocks in store may be encrypted with **per-domain keys** -* Environment claims ensure **proof of offline execution** -* DAMs must be signed to be trusted - ---- - -This layout allows the **authority host** to: - -* Bootstrap personal or group domains -* Accept rescued artifacts -* Produce deterministic PERs and snapshots -* Create SOPS bundles for new nodes -* Operate fully offline - ---- - -If you want, I can **draw a full diagram showing the ENC-ASL-AUTH-HOST tree, block-flow, snapshot integration, and PER generation**, so it’s easier to visualize the data flow during rescue or admission. - -Do you want me to make that diagram next? - diff --git a/ops/legacy/ENC-ASL-HOST.md b/ops/legacy/ENC-ASL-HOST.md deleted file mode 100644 index 5991e79..0000000 --- a/ops/legacy/ENC-ASL-HOST.md +++ /dev/null @@ -1,370 +0,0 @@ -Good — this is the right thing to pin down next. -Below is a **precise, minimal, authority-aware but storage-agnostic ASL-HOST on-disk layout**, designed to work on **ZFS, btrfs, or plain POSIX**, and to survive before ASL-STORE / ASL-CORE are fully implemented. - -This layout defines **where things live**, not **how bytes are encoded**. - ---- - -# ASL-HOST On-Disk Layout — v0.1 - ---- - -## 1. Design Goals (Normative) - -The on-disk layout MUST: - -1. Enforce **domain isolation** -2. Separate **authority, storage, and execution** -3. Support **append-only logs** -4. Support **snapshots as first-class** -5. Allow **courtesy leases and revocation** -6. Remain **forward-compatible** with ASL-STORE and ENC specs - -The layout MUST NOT: - -* Encode artifact semantics -* Encode index formats -* Encode cryptographic algorithms - ---- - -## 2. Root Layout - -```text -/asl-host/ -├── host/ -│ ├── host-id -│ ├── host-policy -│ └── trusted-roots/ -│ -├── domains/ -│ ├── / -│ │ ├── domain.json -│ │ ├── admission/ -│ │ ├── auth/ -│ │ ├── store/ -│ │ ├── index/ -│ │ ├── log/ -│ │ ├── snapshots/ -│ │ ├── leases/ -│ │ └── tmp/ -│ -├── federation/ -│ ├── peers/ -│ ├── exports/ -│ └── imports/ -│ -└── quarantine/ -``` - -Everything below this root is owned by ASL-HOST. - ---- - -## 3. Host-Level Metadata - -### `/asl-host/host/` - -```text -host/ -├── host-id # stable ID for this machine -├── host-policy # local admission & resource policy -└── trusted-roots/ - ├── root-A.pub - ├── root-B.pub - └── ... -``` - -**Notes:** - -* Trusted roots are **offline-established** -* Used for **admission verification** -* Not domain-specific - ---- - -## 4. Domain Directory (Authoritative Boundary) - -Each domain has **one directory**, nothing crosses this boundary implicitly. - -```text -/domains// -``` - -This directory MUST be the **sole owner** of: - -* blocks -* logs -* snapshots -* indexes -* domain-local authority state - ---- - -## 5. Domain Descriptor - -### `/domains//domain.json` - -This is **host-owned metadata**, not part of ASL-CORE. - -```json -{ - "domain_id": "...", - "state": "COURTESY | FULL | SUSPENDED | REVOKED", - "created_at": "...", - "admitted_at": "...", - "root_key_fingerprint": "...", - "policy_hash": "...", - "current_snapshot": "...", - "current_logseq": 12345 -} -``` - -This file is **not signed** — it is derived state. - ---- - -## 6. Admission Records - -### `/domains//admission/` - -```text -admission/ -├── dam.cbor -├── dam.sig -├── admission-request.cbor -├── admission-decision.cbor -└── admission-decision.sig -``` - -This directory contains **immutable records** of how the domain was admitted. - ---- - -## 7. Authority Material (Domain-Local) - -### `/domains//auth/` - -```text -auth/ -├── root.pub -├── operators/ -│ ├── op1.pub -│ └── ... -├── device.pub -└── revocations/ -``` - -**Rules:** - -* Private keys MAY exist only temporarily (e.g. SystemRescue) -* ASL-HOST MUST NOT rely on private keys being present - ---- - -## 8. Store Root (Blocks) - -### `/domains//store/` - -```text -store/ -├── blocks/ -│ ├── open/ -│ ├── sealed/ -│ └── gc/ -├── objects/ # optional future packing -└── encryption/ -``` - -**Notes:** - -* `open/` blocks may be lost -* `sealed/` blocks are immutable -* `gc/` is host-managed -* Encryption metadata is **opaque to ASL-STORE** - ---- - -## 9. Index Area (Semantic-Free) - -### `/domains//index/` - -```text -index/ -├── segments/ -│ ├── seg-000001/ -│ └── ... -├── bloom/ # optional -└── tmp/ -``` - -ASL-HOST only guarantees: - -* sealed segments are immutable -* segments become visible only after seal record - ---- - -## 10. Append-Only Log - -### `/domains//log/` - -```text -log/ -├── append.log -├── checkpoints/ -│ ├── chk-000001/ -│ └── ... -└── seal.log -``` - -**Rules:** - -* append-only -* monotonic -* replayable -* seal.log records segment seals - ---- - -## 11. Snapshots - -### `/domains//snapshots/` - -```text -snapshots/ -├── snap-000001/ -├── snap-000002/ -└── pinned/ - ├── snap-000001 -``` - -**Host responsibility:** - -* mapping snapshots to log positions -* enforcing pinning -* enforcing courtesy limits - ---- - -## 12. Courtesy Leases - -### `/domains//leases/` - -```text -leases/ -├── lease-001.json -├── lease-002.json -└── active -``` - -Each lease file: - -```json -{ - "lease_id": "...", - "granted_by": "...", - "storage_bytes": 1073741824, - "expires_at": "..." -} -``` - -ASL-HOST enforces these. - ---- - -## 13. Temporary / Execution Space - -### `/domains//tmp/` - -Used for: - -* Sedelpress staging -* PEL execution scratch -* unsealed buffers - -**Never snapshot-pinned.** - ---- - -## 14. Federation Area - -### `/asl-host/federation/` - -```text -federation/ -├── peers/ -│ ├── / -│ │ ├── pinned-roots/ -│ │ ├── imported-snapshots/ -│ │ └── replay-state.json -├── exports/ -└── imports/ -``` - -Federation is **explicit and opt-in**. - ---- - -## 15. Quarantine - -### `/asl-host/quarantine/` - -Used for: - -* rejected domains -* policy violations -* forensic inspection - -No domain in quarantine may execute or publish. - ---- - -## 16. ZFS / Snapshot Mapping (Recommended) - -If using ZFS: - -| Path | ZFS Dataset | -| ------------------------- | ------------------- | -| `/domains/` | dataset | -| `/domains//store` | child dataset | -| `/domains//snapshots` | ZFS snapshots | -| `/domains//tmp` | no-snapshot dataset | - -This gives **real snapshot semantics** aligned with ASL rules. - ---- - -## 17. Invariants (Non-Negotiable) - -1. No block crosses domain boundaries implicitly -2. No snapshot without log position -3. No sealed block mutation -4. No admission without DAM -5. No federation without ASL-HOST approval - ---- - -## 18. Why This Works - -✔ Clean separation of concerns -✔ Domain sovereignty enforced by path -✔ Admission-first architecture -✔ Rescue and sovereign flows unified -✔ ASL-STORE can drop in later - ---- - -## 19. One-Sentence Summary - -> **ASL-HOST’s on-disk layout is a constitutional map: it tells every byte who it belongs to, why it exists, and when it may be trusted.** - -If you want, next we can: - -* write a **reference filesystem implementation** -* simulate a **full rescue → admission → publish flow on disk** -* define **revocation propagation on disk** -* or map this directly to **ZFS commands** - -Just say where to push next. - diff --git a/ops/legacy/Rescue Node ASL Deployment.md b/ops/legacy/Rescue Node ASL Deployment.md deleted file mode 100644 index ff32b28..0000000 --- a/ops/legacy/Rescue Node ASL Deployment.md +++ /dev/null @@ -1,172 +0,0 @@ -Perfect. Let’s map out a **Rescue Node ASL Deployment** for your scenario, integrating **personal domain, common domain (Unity/Rakeroot), foreign-domain trust, and ASL layers**. I’ll keep it clear and structured. - ---- - -# Rescue Node ASL Deployment – Conceptual Diagram - -## 1. Overview - -Goal: A rescue node (e.g., old laptop booted with SystemRescue) can: - -* Read old material and register it in a **new personal domain** -* Store **resurrected artifacts** safely -* Interact with **common/shared domains** (Unity / Rakeroot) -* Respect **foreign-domain trust** (read-only imported artifacts) -* Produce **signed PERs** for auditing and traceability - ---- - -## 2. Layered Architecture - -``` -┌───────────────────────────────────────────────────────────────┐ -│ Rescue Node / SystemRescue Runtime │ -│ (ASL-HOST) │ -│ ┌───────────────────────────────────────────────────────────┐ │ -│ │ Store Handles / Filesystems (POSIX/ZFS) │ │ -│ │ - personal domain store │ │ -│ │ - common / Unity store │ │ -│ │ - optional foreign domain caches │ │ -│ └───────────────────────────────────────────────────────────┘ │ -│ ┌───────────────────────────────────────────────────────────┐ │ -│ │ ASL-STORE(-INDEX) │ │ -│ │ - Handles blocks, snapshots, sealed segments │ │ -│ │ - CURRRENT reconstruction, GC │ │ -│ │ - Uses store handles provided by ASL-HOST │ │ -│ └───────────────────────────────────────────────────────────┘ │ -│ ┌───────────────────────────────────────────────────────────┐ │ -│ │ ASL-AUTH │ │ -│ │ - Domain authority (personal / common / foreign) │ │ -│ │ - PER signing and verification │ │ -│ │ - Policy hash and offline root enforcement │ │ -│ └───────────────────────────────────────────────────────────┘ │ -│ ┌───────────────────────────────────────────────────────────┐ │ -│ │ PEL / TGK Execution │ │ -│ │ - Generates PERs from recovered artifacts │ │ -│ │ - TGK edges record provenance │ │ -│ │ - Deterministic DAG execution │ │ -│ └───────────────────────────────────────────────────────────┘ │ -└───────────────────────────────────────────────────────────────┘ -``` - ---- - -## 3. Domains - -| Domain | Purpose | Storage / Backing | -| ------------------------------ | ----------------------------------------------------------- | ------------------------------------------------ | -| **Personal Domain** | Newly minted domain on rescue node; stores rescued material | ZFS dataset or POSIX store, encrypted optionally | -| **Common / Unity Domain** | Group-shared artifacts; Unity / Rakeroot | ZFS dataset shared among users, snapshot-based | -| **Foreign Domains (optional)** | Imported read-only artifacts; pinned by trust | Cache store / ASL-HOST mount | - ---- - -## 4. Domain Initialization - -1. **Personal Domain** - - * Create store: `CreateStore("/mnt/rescue/personal")` - * Generate DA manifest - * Sign manifest with offline root - * Mount snapshot overlay if needed - -2. **Common / Unity Domain** - - * Mount read-only: `OpenStore("/mnt/common")` - * Synchronize snapshot to local host - * Pin trusted foreign domains if group members exist - -3. **Foreign Domains** - - * Configure trust pin: Domain ID + Policy hash - * Mount local cache for imported artifacts - * Access **read-only**, verified via ASL-AUTH - ---- - -## 5. Storage / Filesystem Layout - -``` -/mnt/rescue/ - personal/ <-- personal domain store (ZFS/POSIX) - blocks/ - segments/ - logs/ - common/ <-- Unity / Rakeroot (shared read-only store) - blocks/ - segments/ - logs/ - foreign/ <-- optional cache for foreign domains - domainX/ - blocks/ - segments/ -``` - -* **Blocks**: immutable, sealed by ASL-STORE -* **Segments**: index entries + metadata -* **Logs**: append-only, monotonic ordering - ---- - -## 6. Snapshot Strategy - -* ZFS snapshots (or overlayfs copies) per domain -* Personal domain snapshots allow **deterministic recovery** -* Common domain snapshots define **group-visible CURRENT** -* Foreign domain snapshots pinned by trust - -``` -personal@rescue-snap-2025-12-28 -common@unity-snap-2025-12-28 -foreign-domainX@snap-2025-12-01 -``` - ---- - -## 7. PER Signing & Provenance - -1. PEL executes DAG over rescued artifacts -2. Generates PERs -3. ASL-AUTH signs PERs with: - - * Personal domain authority key - * Policy hash embedded -4. PERs stored in **personal domain**, optionally referencing: - - * Common / Unity artifacts - * Foreign pinned artifacts (read-only) - ---- - -## 8. Optional Encryption / Public Domain Courtesy - -* Blocks from personal domain can be encrypted when storing in **common domain** -* Ensures **privacy while allowing shared indexing** -* Encryption keys managed by **personal DA** - ---- - -## 9. Trust & Governance - -* Offline root(s) provide deterministic trust -* Policy hash enforces publishing and cross-domain rules -* Personal domain can safely publish selected artifacts to Unity / Rakeroot -* Foreign-domain pins enforce **read-only deterministic import** - ---- - -## 10. Summary - -* Rescue node can bootstrap **personal + common + foreign domains** -* Storage handled by ASL-HOST (POSIX/ZFS) -* Indexing, snapshots, sealing by ASL-STORE(-INDEX) -* PER signing and cross-domain trust by ASL-AUTH -* Execution provenance tracked via PEL/TGK -* Flexible architecture for **personal, group, and federated domains** - ---- - -If you want, I can **draw a fully labeled diagram** showing **how artifacts flow from the rescued home directory into personal domain, common domain, and PER generation**, including snapshots, seals, and trust pins. This would be a visual reference for your rescue mission. - -Do you want me to do that next? - diff --git a/ops/legacy/Rescue Node Blueprint v0-1.md b/ops/legacy/Rescue Node Blueprint v0-1.md deleted file mode 100644 index d835fd3..0000000 --- a/ops/legacy/Rescue Node Blueprint v0-1.md +++ /dev/null @@ -1,163 +0,0 @@ -Perfect — this is exactly the “first-person, first-rescue” scenario. I’ll extend the blueprint to reflect **a freshly minted SystemRescue user entering the ecosystem** with old personal data, no prior certificates, and the intention of building both a **personal domain** and seeding the **common / Unity tree**. I’ll tie together **PER generation, ASL blocks, snapshots, and trust setup** from scratch. - ---- - -# Rescue Node Blueprint v0.1 — Fresh Entry Scenario - -``` - ┌───────────────────────────────┐ - │ Legacy Input Material │ - │ - Home directory snapshot │ - │ - App config / old data │ - │ - Intent / contracts │ - └─────────────┬─────────────────┘ - │ - ▼ - ┌───────────────────────────────┐ - │ Sedelpress / PER Engine │ - │ - Deterministic execution │ - │ - TGK edges & provenance │ - │ - Snapshot boundaries │ - │ - Generates initial PER(s) │ - │ - Logs intent + provenance │ - └─────────────┬─────────────────┘ - │ PER + TGK edges - ▼ - ┌───────────────────────────────────────────────┐ - │ Bootstrap in Common / Courtesy Space │ - │ - Encrypted personal blocks │ - │ - ASL-STORE(-INDEX) organizes blocks & logs │ - │ - Snapshot pinned for reproducibility │ - │ - Acts as temporary “personal domain seed” │ - └─────────────┬─────────────────────────────────┘ - │ Optional trust / policy hash - ▼ - ┌───────────────────────────────────────────────┐ - │ Personal Domain (New) │ - │ - Blocks copied from courtesy space │ - │ - Own index segments, snapshots │ - │ - PERs validated and linked to TGK edges │ - │ - Certificates minted (ASL-AUTH) │ - │ - Domain Authority Manifest created │ - │ - Optional publication to Common later │ - └─────────────┬─────────────────────────────────┘ - │ Optional publication - ▼ - ┌───────────────────────────────────────────────┐ - │ Common / Unity Domain │ - │ - Shared artifacts / PERs │ - │ - Read-only pinned snapshots │ - │ - Courtesy recognition of new user │ - │ - Aggregates multiple bootstrap submissions │ - └─────────────┬─────────────────────────────────┘ - │ Cross-domain trust pins - ▼ - ┌───────────────────────────────────────────────┐ - │ Foreign / Other Domains │ - │ - Imported artifacts read-only │ - │ - Trust via offline roots & policy hash │ - │ - Deterministic snapshots reconstructed │ - └───────────────────────────────────────────────┘ -``` - ---- - -## Key Concepts and Steps - -### 1. Legacy Material Intake - -* Old personal data is treated as **raw artifact input**. -* **Sedelpress** ingests everything deterministically, creating **PER(s) for provenance**. -* Intent and contract are encoded alongside data, defining what must be certified. - -### 2. PER Generation - -* **First-class operation**: PERs precede storage. -* TGK edges capture lineage and relationships. -* Snapshots of input material are **recorded for deterministic reconstruction**. - -### 3. Bootstrap Personal Domain via Common - -* **Encrypted blocks** are stored in the Common courtesy space. -* Blocks are **sealed and indexed** (ASL-STORE / ASL-STORE-INDEX). -* Common **pins snapshots** to ensure reproducibility. -* This bootstrap **does not require prior certificates** — Common allows “newcomer courtesy.” - -### 4. Personal Domain Minting - -* After bootstrap, blocks are copied into the new **personal domain**. -* **Certificates (ASL-AUTH)** are minted, forming your **authority root**. -* Domain Authority Manifest (DAM) is created with: - - * Your domain ID - * Seeded artifacts / PERs - * Trust anchors (offline roots) -* PERs are now linked, validated, and can be optionally published to Common. - -### 5. Common / Unity Tree - -* Aggregates shared PERs and artifacts from multiple users. -* Maintains **read-only pinned snapshots**. -* Facilitates **cross-user consistency and cooperation**. -* Your encrypted bootstrap blocks remain private until you choose to publish. - -### 6. Cross-Domain Trust - -* Optional import/export of artifacts to other domains: - - * **Read-only import**: deterministic reconstruction. - * **Policy hash** ensures correctness. - * **Offline roots** verify trust for foreign domains. - ---- - -## Suggested ASL / Filesystem Layout - -| Domain / Layer | Backend / FS | Notes | -| ------------------------- | --------------------- | ----------------------------------------------------------- | -| Legacy Material Intake | POSIX / tmp overlay | Raw input snapshots | -| Sedelpress / PER Engine | Memory + temp storage | Deterministic execution; generates TGK edges | -| Bootstrap Personal Domain | ZFS / ASL-STORE | Courtesy encrypted blocks; pinned snapshot; temporary index | -| Personal Domain (New) | ZFS / ASL-STORE | Full index, sealed blocks, PERs, certificates | -| Common / Unity Domain | ZFS / ASL-STORE | Shared artifacts / PERs; read-only; pinned snapshots | -| Foreign / Other Domains | N/A / imported | Read-only; trust via offline roots & policy hash | - ---- - -### Notes on Certificates / ASL-AUTH - -* **Initial certificate minting** occurs **after bootstrap**. -* Offline root keys are generated on a **secure Debian machine** (offline). -* **Personal Domain Authority** is tied to offline roots. -* PERs in bootstrap space can later be **retrospectively certified** once personal domain is minted. - ---- - -### Snapshot & Sealing Flow - -1. **Legacy snapshot** → PER generation -2. **Seal blocks** in courtesy space -3. **Pin snapshots** in bootstrap space -4. **Copy to personal domain** → seal and index -5. **Create DAM + Certificates** → retrospective trust assignment -6. Optional publication → **Common / Unity tree** - ---- - -This **blueprint supports:** - -* Fresh user / rescue node onboarding -* Deterministic provenance from legacy material -* Personal domain creation without prior certificates -* Courtesy bootstrap in Common for temporary storage -* Safe integration with Common / Unity tree and foreign domains -* PER-first philosophy ensuring traceability and auditability - ---- - -If you want, I can **draw a “layered architecture diagram”**, showing **Sedelpress, ASL blocks, snapshots, PERs, and the hierarchy of domains**, highlighting **bootstrap, personal, common, and foreign layers**. - -It would be a **visual rescue map**, perfect for planning the initial node setup. - -Do you want me to do that next? - diff --git a/ops/legacy/Rescue Operation Architecture.md b/ops/legacy/Rescue Operation Architecture.md deleted file mode 100644 index 5070bce..0000000 --- a/ops/legacy/Rescue Operation Architecture.md +++ /dev/null @@ -1,112 +0,0 @@ -Perfect — that gives us a **clear mission scenario**. Let’s formalize this into a **Rescue Node + Domain Architecture**, showing the **flow from personal rescue → common courtesy space → personal domain establishment**. I’ll also tie in snapshots, sealing, and PER generation. - ---- - -# Rescue Operation Architecture: “Personal Rescue with Common Bootstrap” - -``` - ┌───────────────────────────────┐ - │ Input Material / Intent │ - │ - Home directory snapshot │ - │ - Certificates │ - │ - Rescue intent / contract │ - └─────────────┬─────────────────┘ - │ - ▼ - ┌───────────────────────────────┐ - │ Sedelpress / PER Engine │ - │ - Deterministic execution │ - │ - TGK edges & provenance │ - │ - Snapshot boundaries │ - │ - Generates PER(s) │ - └─────────────┬─────────────────┘ - │ PER + TGK edges - ▼ - ┌───────────────────────────────────────┐ - │ Personal Bootstrap Space (Common) │ - │ - Courtesy space granted by Common │ - │ - Encrypted blocks / sealed segments │ - │ - Indexed via ASL-STORE(-INDEX) │ - │ - Temporary / bootstrapped domain │ - └─────────────┬─────────────────────────┘ - │ Optional trust / policy hash - ▼ - ┌───────────────────────────────────────┐ - │ Personal Domain (User-owned) │ - │ - Blocks copied from bootstrap │ - │ - Own index segments & snapshots │ - │ - PERs stored and validated │ - │ - Full authority and certificate │ - └─────────────┬─────────────────────────┘ - │ Publishing optional - ▼ - ┌───────────────────────────────────────┐ - │ Common / Unity Domain │ - │ - Shared artifacts & PERs │ - │ - Read-only access for users │ - │ - Snapshot pinned / immutable │ - │ - Courtesy bootstrap space recognized │ - └─────────────┬─────────────────────────┘ - │ Cross-domain trust pins - ▼ - ┌───────────────────────────────────────┐ - │ Foreign / External Domains │ - │ - Imported artifacts (read-only) │ - │ - Trust enforced by offline roots │ - │ - Policy hash verification │ - └───────────────────────────────────────┘ -``` - ---- - -### Key Principles for Rescue + Domain Integration - -1. **Bootstrap via Common** - - * A person or system without a pre-existing domain can store **encrypted blocks** in the Common courtesy space. - * Common recognizes the bootstrap, enforces **policy hash**, and pins snapshots. - -2. **PER Generation is Primary** - - * The Sedelpress stamps **everything deterministically**: home dir, certificates, intent. - * Store artifacts are secondary; the **receipt defines authority and provenance**. - -3. **Snapshots & Sealed Blocks** - - * Courtesy space blocks are **encrypted and sealed** for immutability. - * Once personal domain is established, blocks can be **copied or promoted** to private space. - -4. **Domain Authority** - - * Personal domain is **minted post-bootstrap**, with full authority. - * Policy hash ensures cross-domain trust for publishing or importing artifacts. - -5. **Cross-Domain Trust** - - * Common domain pins **read-only copies** of bootstrap artifacts. - * Foreign or other users’ domains require **offline root verification** before accepting artifacts. - ---- - -### Suggested ASL / Store Layout for Rescue Operation - -| Domain | Backend / FS | Notes | -| --------------------------- | ----------------- | -------------------------------------------------------------------- | -| Personal Bootstrap (Common) | ZFS / POSIX + ASL | Courtesy space; blocks encrypted; temporary storage; snapshot pinned | -| Personal Domain | ZFS + ASL | User-owned; full index; sealed blocks; PERs validated | -| Common / Unity | ZFS + ASL | Shared artifacts; read-only; courtesy recognition | -| Foreign Domains | N/A (imported) | Read-only; trust pinned via policy hash and offline roots | - ---- - -If you like, I can **next draft the Rescue Node overlay schema**: - -* How the **personal bootstrap** interacts with Common -* How **PER ingestion and sealing** happens -* How **snapshots + ASL blocks** are laid out on ZFS or POSIX -* How the **courtesy / Unity tree** is seeded - -This would be a **working blueprint for your personal rescue operations**, fully tied to the ASL + PEL ecosystem. - -Do you want me to do that? - diff --git a/ops/legacy/bootable authority host image.md b/ops/legacy/bootable authority host image.md deleted file mode 100644 index b377992..0000000 --- a/ops/legacy/bootable authority host image.md +++ /dev/null @@ -1,131 +0,0 @@ -Absolutely — let's think this through step by step. The goal is a **bootable authority host image** that’s offline, deterministic, and ready to handle domain admission, DAM signing, SOPS bundles, and PER generation. Here's a blueprint for assembling it. - ---- - -## 1. Base OS - -* Choose a **minimal Debian/Ubuntu** or SystemRescue-based environment. - - * Needs basic POSIX tools, filesystem utilities, and networking disabled (offline by default). -* Install **essential tools only**: - - * `bash`, `coreutils`, `tar`, `gzip`, `xz`, `find`, `sha256sum` - * `sops` binary for offline bundle handling - * `git` optional, for versioning tools inside the image -* Disable unnecessary daemons (`sshd`, `cron`) for security. - ---- - -## 2. Filesystem Layout - -Create the **ENC-ASL-AUTH-HOST** structure inside the image: - -``` -/asl-auth-host/ -├─ /domains/ # domain stores -├─ /tools/ # binaries -├─ /env-claims/ # environment snapshot hashes -└─ /sops-bundles/ # encrypted bundles -``` - -* Use **read-only overlay** for system files -* Persistent storage can be mounted as `/domains` or `/store` (ZFS, ext4, or Btrfs) -* Optionally, set up **ZFS pools** for: - - * `/domains//store` - * `/domains//snapshots` -* The image itself is **immutable** — only mounted storage is written to. - ---- - -## 3. Tools to Include - -* **asl-auth-host** binary — main authority program -* **asl-rescue** binary — optional rescue support for SystemRescue-style data intake -* **sops** — offline encryption/decryption of bundles -* Optional helper scripts: - - * `make-dam.sh` — create DAM artifacts - * `sign-bundle.sh` — sign SOPS bundles - * `verify-env.sh` — calculate env-claims - ---- - -## 4. Boot Configuration - -* Boot kernel options: - - * Mount persistent storage for `/domains` (ZFS, ext4, etc.) - * Mount overlay read-only system (`/tools`, `/env-claims`, `/sops-bundles`) -* Auto-start a shell or **interactive prompt** for offline operation. -* Optional: menu for: - - * Create new domain - * Sign DAM / issue certificates - * Prepare SOPS bundle - * Rescue/import artifacts - ---- - -## 5. Domain Initialization - -When first booting: - -1. Generate **root key pair** for the domain. -2. Optionally generate **DAM signer keys**. -3. Create the domain directory: - - ``` - /domains// - ├─ store/ - ├─ log/ - ├─ snapshots/ - ├─ certs/ - ├─ policies/ - └─ dam/ - ``` -4. Initialize **empty log**, empty store, and environment claim file: - - ``` - /env-claims/.claim - ``` -5. Seed the domain with **common domain reference**, if applicable. - ---- - -## 6. Certificates and Policies - -* Root keys must be encrypted at rest. -* DAMs signed using offline authority host root keys. -* Policies included in `/domains//policies/`. -* All signed artifacts stored in `/sops-bundles/` for delivery. - ---- - -## 7. Optional Persistence - -* If you want the host **bootable from USB**: - - * Overlay FS (SquashFS or ISO) for system binaries - * Writable ZFS/Btrfs/EXT4 for `/domains` and `/sops-bundles` -* This allows the system to remain **fully offline** but store persistent artifacts. - ---- - -## 8. Recommended Approach - -* **Immutable image** for the offline host (SquashFS or ISO) -* **Writable storage** for domains (`/mnt/pool`) or USB disk -* Use **ZFS datasets** for: - - * Block storage - * Snapshots of logs & store -* Pre-load binaries for deterministic PER generation, DAM signing, and rescue scripts. -* Environment claims stored and optionally signed before any DAM operation. - ---- - -If you want, I can **write a concrete build script outline** (e.g., Debian-based ISO with overlay + ZFS pools + included binaries + directory structure), so you have a starting point to actually produce the bootable auth host image. - -Do you want me to do that next? -