102 lines
4.7 KiB
Markdown
102 lines
4.7 KiB
Markdown
# ROOT_SSH_GATE — Privilegierter Zugriff (Root/SSH) Vertrag
|
|
|
|
> **Geltungsbereich:** Red Queen Autonomous Engineering System v1
|
|
> **Status:** Verbindlicher Gate-Vertrag für privilegierte Aktionen (Root/SSH)
|
|
> **Sprache:** Deutsch (verbindlich)
|
|
> **Verwandt:** SAFETY_CONTRACT.md, EXTERNAL_REVIEW_CONTRACT.md, SELF_IMPROVEMENT_POLICY.md
|
|
|
|
---
|
|
|
|
## 1. Grundsatz
|
|
|
|
**Root ist KEIN Standardmodus.** Red Queen und alle Sub-Agenten arbeiten standardmäßig
|
|
als unprivilegierter Runtime-User. Jede privilegierte Aktion (Root-Befehl, SSH-Zugriff,
|
|
Sudo) ist ein **Ausnahmefall** und unterliegt einem obligatorischen Gate.
|
|
|
|
Privilegierte Operationen dürfen **nie automatisch, ungeprüft oder als Nebeneffekt**
|
|
ausgeführt werden.
|
|
|
|
## 2. Klassifikation
|
|
|
|
| Kategorie | Beschreibung | Autonomie |
|
|
|---|---|---|
|
|
| **READ-ONLY Diagnose** | Zustand prüfen ohne Mutation (z. B. `df`, `ps`, Lese-Zugriff auf Config) | **Autonom erlaubt**, sofern selbst keine Änderung verursacht und keine Secret-Ausgabe |
|
|
| **Privilegierte Mutation** | Irgendeine Zustandsänderung über Root/SSH/Sudo | **Gate-Pflicht** (Abschnitt 3) |
|
|
|
|
READ-ONLY-Diagnose darf autonom erfolgen, **wenn** sie (a) selbst keinen Zustand ändert,
|
|
(b) keine Secrets druckt und (c) auf den konkreten Diagnose-Zweck begrenzt ist. Bei
|
|
Unsicherheit, ob eine Aktion read-only ist → als Mutation behandeln.
|
|
|
|
---
|
|
|
|
## 3. Gate vor jeder privilegierten Mutation
|
|
|
|
Vor **jeder** privilegierten Mutation (Root/SSH) MÜSSEN alle Pflichtfelder erfüllt sein:
|
|
|
|
| Pflichtfeld | Definition | Beispiel |
|
|
|---|---|---|
|
|
| **WHY** | Zweck, Problem/Anforderung, die nur privilegiert lösbar ist | "Config-Datei anpassen, die nur root lesen kann" |
|
|
| **WHAT** | Exakt welche Aktion/Änderung (eine logische Änderung) | "Eine Zeile in `<file>` ergänzen" |
|
|
| **IMPACT** | Erwartete Auswirkung (Zustand vorher → nachher), Risiko | "Betroffene Dienste, keine Downtime erwartet" |
|
|
| **DEPENDENCIES** | Was muss vorhanden sein (Backups, Abhängigkeiten, Reihenfolge) | "Backup liegt vor; Dienst stoppt sauber" |
|
|
| **BACKUP** | Belegbarer Rollback-Bezug (Snapshot/Backup vorhanden) | "Config unter `<backup>` gesichert" |
|
|
| **ROLLBACK** | Konkrete Rückabwicklung bei Fehlschlag | "Zeile wieder entfernen / Config restore" |
|
|
| **TEST** | Verifikation des Erfolgs nach der Änderung | "Dienst startet, Konfigurationsprüfung OK" |
|
|
|
|
Regel: **EINE logische Änderung → VALIDIEREN → TESTEN → erst dann weiter.**
|
|
|
|
- **Ein** Commit/Eine Aktion pro Gate-Durchlauf.
|
|
- Nach der Änderung zwingend **VALIDIEREN** (ist das erwartete Ergebnis da?).
|
|
- Danach **TESTEN** (Verifikation aus TEST-Feld).
|
|
- Erst nach erfolgreicher Validierung darf die nächste Änderung beginnen.
|
|
|
|
---
|
|
|
|
## 4. Kritische Bereiche (erhöhte Gate-Stufe)
|
|
|
|
Folgende Bereiche erfordern **zusätzlich** zur obigen Gate **Christian/Approval**:
|
|
|
|
- SSH / Remote-Zugriff
|
|
- Firewall / Networking
|
|
- Docker / Container-Infrastruktur
|
|
- Reverse Proxy
|
|
- Authentication / Authorization
|
|
- Secrets / Credential-Verwaltung
|
|
- Recovery Access (Backup-Zugang)
|
|
- Forgejo Security
|
|
- Ollama Core-Infrastruktur
|
|
- Red Queens eigener Container
|
|
- Hermes Runtime
|
|
- Zentrale Persistenz (state.db, Kanban, Cron)
|
|
- Circuit Breaker / Approval-Gates selbst
|
|
|
|
Für diese Bereiche: **Gate = Pflichtfelder (3) + Christian-Approval** — KEINE autonome
|
|
privilegierte Mutation.
|
|
|
|
---
|
|
|
|
## 5. Zuständigkeit (WHO / WHEN / STOPP)
|
|
|
|
| Rolle | Darf |
|
|
|---|---|
|
|
| **Red Queen (Orchestrator)** | READ-ONLY-Diagnose autonom; privilegierte Mutation nur mit Gate (3); kritische Bereiche nur mit Christian-Approval |
|
|
| **Sub-Agenten (Maker/Checker/Debugger/Tester/Knowledge)** | **NIE** selbst Root/SSH-Mutationen. Nur nach ausdrücklicher Freigabe durch Red Queen/Christian mit präzisem, begrenztem Scope |
|
|
| **Rain** | **NIE** Root/SSH-Aufträge von Red Queen (siehe EXTERNAL_REVIEW_CONTRACT.md); nur Christian entscheidet über Rain-Einsatz |
|
|
| **Christian** | einzige Instanz für kritische Gate-Freigaben |
|
|
|
|
**STOPP-Bedingungen (Break):**
|
|
- Ein Pflichtfeld aus Abschnitt 3 fehlt oder ist vage → **STOPP**, keine Mutation.
|
|
- Unerwartete Berechtigungsänderung / Identity-Mismatch → **STOPP**, Circuit Breaker.
|
|
- Kritischer Bereich ohne Christian-Approval → **STOPP**.
|
|
- SECRET / Credential wird sichtbar → **STOPP**, Sicherheits-Vorfall.
|
|
|
|
**REMAIN-Verstärkung:** Bestehende `safe-root-engineering` / `safe-change-management`
|
|
Regeln werden durch diesen Vertrag **nicht abgeschwächt**, sondern übernommen.
|
|
|
|
---
|
|
|
|
## 6. Verhältnis zu anderen Contracts
|
|
|
|
- **SAFETY_CONTRACT.md** — Retry/Loop/Circuit Breaker (privilegierte Aktion fällt unter dessen Regeln).
|
|
- **SELF_IMPROVEMENT_POLICY.md** — Änderungen an Root/SSH-Policy = **SI-3 (Human/External Gate)**.
|
|
- **EXTERNAL_REVIEW_CONTRACT.md** — Rain erhält nie Root/SSH-Aufträge von Red Queen.
|