From faa06a51fc2a557f93a4ebcf03f83e9bf8b54901 Mon Sep 17 00:00:00 2001 From: Thomas Stallinger Date: Wed, 12 Aug 2026 21:47:02 +0200 Subject: [PATCH] docs: Gegenlese aller 15 ADRs - sicherheitsrelevanten Widerspruch behoben MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Wichtigster Fund: 13-live-provisioning-boot.md widersprach sich selbst zum GRUB-Standardeintrag - ein noch nicht korrigierter Abschnitt ('Auto-Eintrag ist Index 0 und damit Standardauswahl') stand neben der bereits vorhandenen Korrektur weiter oben im selben Dokument ('Standard ist von lokaler Festplatte booten', Erkenntnis vom 01.08.2026). Ein Reader des älteren Abschnitts hätte das sicherheitsrelevante Verhalten bei destruktiven Installationen falsch verstanden. Jetzt konsistent, mit Verweis auf die Korrektur. ADR-0003 (Ursprungsentscheidung, dort unkorrigiert) bekam denselben Nachtrag. Kleinere Korrekturen: zwei Anführungszeichen-Inkonsistenzen (ADR-0009, ADR-0011) - gerade Anführungszeichen für eigene Zusammenfassungen des Autors statt der sonst durchgängigen „..."-Form, während echte wörtliche Zitate (Terminal-Fehlermeldungen, Anaconda-Doku) unangetastet bleiben, weil die Originalschreibweise dort bewusst erhalten werden soll. Alle ADR-Querverweise (0001-0015) auf Gültigkeit geprüft, keine toten Verweise gefunden. Co-Authored-By: Claude Sonnet 5 --- adr/0003-live-provisioning-boot.md | 2 ++ adr/0009-anaconda-live-kickstart-verworfen.md | 4 ++-- adr/0011-kundenplattform-getrennter-dienst.md | 2 +- architecture/13-live-provisioning-boot.md | 4 +++- 4 files changed, 8 insertions(+), 4 deletions(-) diff --git a/adr/0003-live-provisioning-boot.md b/adr/0003-live-provisioning-boot.md index 01d8030..1979e73 100644 --- a/adr/0003-live-provisioning-boot.md +++ b/adr/0003-live-provisioning-boot.md @@ -27,6 +27,8 @@ Ein Standardeintrag mit Countdown, der bei Nichtstun automatisch in den unbeaufs Ein manuell auswählbarer zweiter Eintrag für den interaktiven, gebrandeten Ablauf. +**Korrigiert (01.08.2026, siehe ADR-0009-Update vom selben Tag):** Welcher der beiden Einträge bei Nichtstun (Countdown-Ablauf) automatisch ausgewählt wird, wurde hier zunächst falsch entschieden — nicht der unbeaufsichtigte Ablauf, sondern „von lokaler Festplatte booten" ist der Standard. Die destruktive, unbeaufsichtigte Installation erfordert eine aktive, bewusste Auswahl aus dem Menü, kein bloßes Verstreichenlassen eines Zeitfensters. Umgesetzt in `architecture/13-live-provisioning-boot.md`. + Der unbeaufsichtigte Ablauf ist ausschließlich für bereits registrierte Geräte zulässig, erkennbar an `device.registration_status == "existing"` in der Antwort von `POST /api/v1/activate`. Bei einem unbekannten Gerät (`registration_status == "registered"`) bricht der unbeaufsichtigte Ablauf kontrolliert ab (Fail-Closed) und verweist auf den interaktiven Ablauf mit expliziter Geräteaufnahme-Bestätigung gemäß `11-device-enrollment.md`. Dass ein bereits registriertes Gerät ohne erneute interaktive Rückfrage automatisiert neu installiert werden kann, wird explizit Bestandteil der Bedingungen, denen bei der Geräteregistrierung zugestimmt wird. diff --git a/adr/0009-anaconda-live-kickstart-verworfen.md b/adr/0009-anaconda-live-kickstart-verworfen.md index e4bb4fa..2251e40 100644 --- a/adr/0009-anaconda-live-kickstart-verworfen.md +++ b/adr/0009-anaconda-live-kickstart-verworfen.md @@ -13,7 +13,7 @@ Vor der Implementierung wurde recherchiert und real getestet, ob das funktionier Der `liveinst`-Wrapper (`/usr/bin/liveinst`, Teil des `anaconda`-Pakets) lehnt `ks=`/`kickstart=`-Argumente laut eigenem Quellcode aktiv ab und erzwingt stattdessen den interaktiven Modus — Zitat aus der Anaconda-Projektdokumentation: *"anaconda developers really, really do not want to support kickstart from liveinst!"*. Auch die eigene `anaconda --help`-Ausgabe dokumentiert `--kickstart KICKSTART_PATH` explizit als *"not supported for live installations"*. -Direkter Test am Wrapper vorbei (`anaconda --liveinst --kickstart=`, auf echtem Fedora 44 / Anaconda 44.30-2.fc44) bestätigte das empirisch, mit einer noch ungünstigeren Fehlerart als "klar abgelehnt": +Direkter Test am Wrapper vorbei (`anaconda --liveinst --kickstart=`, auf echtem Fedora 44 / Anaconda 44.30-2.fc44) bestätigte das empirisch, mit einer noch ungünstigeren Fehlerart als „klar abgelehnt": - **Mit `-T` (Text-Modus):** Anaconda startet, übernimmt Sprache/Zeitzone/Partitionierungsart (`autopart`) korrekt aus der Kickstart-Datei, ignoriert aber `rootpw` und `user` **kommentarlos** — beide Felder mussten vollständig manuell nachgetragen werden ("Root-Konto ist deaktiviert", "Es wird kein Benutzer erstellt", trotz korrekter Kickstart-Zeilen). Kein Fehler, keine Warnung — nur eine leise, unvollständige Übernahme. - **Mit `-C` (Cmdline-Modus, laut Hilfetext für nicht-interaktive Automatisierung gedacht):** sauberer, aber ebenso eindeutiger Abbruch, Exit-Code 1, mit explizitem Log-Eintrag: @@ -36,7 +36,7 @@ Ausdrücklich **nicht** gewählt: Anaconda umgehen und Partitionierung/Dateisyst ## Konsequenzen - `13-live-provisioning-boot.md` (Abschnitt "Nativer Installer aus der Live-Sitzung") muss überarbeitet werden, sobald der tatsächliche Weg feststeht — noch nicht Teil dieser Entscheidung. -- Betroffene Anaconda-Version zur Einordnung: 44.30-2.fc44 ("bluesky", Pre-Release, neue WebUI-basierte Oberfläche) — die "Kickstart auf Live-Medien nicht unterstützt"-Haltung selbst ist aber laut Anaconda-Projektdokumentation langjährig und nicht auf diese Version beschränkt. +- Betroffene Anaconda-Version zur Einordnung: 44.30-2.fc44 ("bluesky", Pre-Release, neue WebUI-basierte Oberfläche) — die „Kickstart auf Live-Medien nicht unterstützt"-Haltung selbst ist aber laut Anaconda-Projektdokumentation langjährig und nicht auf diese Version beschränkt. ## Update (23.07.2026): Muster erkannt, verfeinerter Prüfplan diff --git a/adr/0011-kundenplattform-getrennter-dienst.md b/adr/0011-kundenplattform-getrennter-dienst.md index e063484..c7ea65f 100644 --- a/adr/0011-kundenplattform-getrennter-dienst.md +++ b/adr/0011-kundenplattform-getrennter-dienst.md @@ -13,7 +13,7 @@ Eine menschliche, sitzungsbasierte Kunden-Login-Oberfläche im selben Prozess/de 2. **Mehrmandantenfähigkeit:** Der bestehende `TUXFLOTTE_ADMIN_TOKEN` ist ein einzelnes globales Betreiber-Secret, keine pro-Organisation skalierende Authentifizierung. Ein echtes Kunden-Login braucht Accounts, die einer Organisation zugeordnet sind und nur deren eigene Geräte sehen dürfen. 3. **Verfügbarkeit:** Anode muss zuverlässig für die Geräte-Flotte erreichbar bleiben. UI-Traffic (z.B. viele gleichzeitig eingeloggte Kunden) sollte diese Zuverlässigkeit nicht gefährden können. -Im Repo existiert noch kein Benutzerkonto-Konzept (nur Maschinen-Secrets für Geräte, siehe `devices.agent_secret_hash`) und keine bestehende "Kundenplattform"-Dokumentation — nur vereinzelte Prosa-Erwähnungen einer künftigen "Verwaltungsoberfläche"/eines "Self-Service-Portals" (u.a. ADR-0008, das bereits eine Neugeräte-Bestätigung über eine solche künftige Oberfläche vorsieht, dort aber nicht spezifiziert). +Im Repo existiert noch kein Benutzerkonto-Konzept (nur Maschinen-Secrets für Geräte, siehe `devices.agent_secret_hash`) und keine bestehende „Kundenplattform"-Dokumentation — nur vereinzelte Prosa-Erwähnungen einer künftigen „Verwaltungsoberfläche"/eines „Self-Service-Portals" (u.a. ADR-0008, das bereits eine Neugeräte-Bestätigung über eine solche künftige Oberfläche vorsieht, dort aber nicht spezifiziert). ## Entscheidung diff --git a/architecture/13-live-provisioning-boot.md b/architecture/13-live-provisioning-boot.md index 942ae5f..7cd9f3d 100644 --- a/architecture/13-live-provisioning-boot.md +++ b/architecture/13-live-provisioning-boot.md @@ -178,7 +178,9 @@ Ein eigenes, schlankeres Live-System anstelle des Fedora-Live-Images wurde gepr Das in der Boot-Ablauf-Grafik oben genannte Kernel-Cmdline-Flag heißt konkret `tuxflotte.mode` und wird als `tuxflotte.mode=auto` beziehungsweise `tuxflotte.mode=interactive` an den Kernel übergeben, zusätzlich zu den vom Live-Medium ohnehin benötigten Parametern (`root=live:CDLABEL=TUXFLOTTE rd.live.image`) sowie `vconsole.keymap=de`. `installer.sh` soll den gewählten Modus zur Laufzeit aus `/proc/cmdline` lesen (siehe „Noch nicht umgesetzt" unten) — aktuell durchläuft es unabhängig vom Flag immer den vollständigen interaktiven Ablauf. -Das GRUB-Menü verwendet einen Countdown von 10 Sekunden; der Auto-Eintrag ist Index 0 und damit Standardauswahl. Ein dritter Menüpunkt zum Booten des bereits installierten lokalen Systems bleibt erhalten (vormals in `01-layered-provisioning.md` als Anforderung an das Bootmenü genannt). +Das GRUB-Menü verwendet einen Countdown von 10 Sekunden. Ein dritter Menüpunkt zum Booten des bereits installierten lokalen Systems bleibt erhalten (vormals in `01-layered-provisioning.md` als Anforderung an das Bootmenü genannt). + +**Korrigiert (01.08.2026, siehe ADR-0009-Update vom selben Tag):** Der Auto-Eintrag ist entgegen der ursprünglichen Angabe hier **nicht** Index 0/Standardauswahl. Bei Nichtstun (Ablauf des Countdowns) bootet stattdessen „von lokaler Festplatte" — die destruktive Installation muss aktiv aus dem Menü ausgewählt werden, kein Zeitfenster zum Abbrechen. Siehe auch die zusammenfassende Erwähnung weiter oben im Abschnitt „WLAN-Zugangsdaten"/Auto-Modus-Gate. `scripts/build.sh` und `scripts/extract.sh` extrahieren die Quell-ISO über `xorriso -osirrox` statt über einen Loop-Mount und benötigen dadurch keine Root-Rechte mehr für den Build selbst.