Thomas Stallinger
a4cf9590c8
Dokumentiert den tuxflotte-installer-Commit 517c2de: die 01.08.2026- Sicherheitskorrektur (Standard = lokal booten statt Auto-Install, siehe ADR-0009) war nicht vollständig umgesetzt - Fedoras GRUB-Configs (EFI-BOOT-grub.cfg, boot-grub2-grub.cfg) defaulteten weiterhin echt auf den unbeaufsichtigten Install-Eintrag, Mints nicht-EFI-Zweig hatte gar keinen lokalen-Boot-Eintrag (vermutlich unerreichbar, trotzdem abgesichert). Gefunden bei der Live-Gegenlese aller ADRs gegen anode. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
35 lines
4.4 KiB
Markdown
35 lines
4.4 KiB
Markdown
# ADR-0016: GRUB-Standardeintrag — verbliebene Lücken zur bereits getroffenen Sicherheitsentscheidung geschlossen
|
|
|
|
**Status:** Beschlossen
|
|
**Datum:** 12.08.2026
|
|
|
|
## Kontext
|
|
|
|
ADR-0009 stellte am 01.08.2026 fest, dass der GRUB-Standardeintrag (bei Ablauf des Countdowns ohne Nutzereingriff) fälschlich auf den unbeaufsichtigten Auto-Install-Ablauf zeigte, statt auf ein sicheres „von lokaler Festplatte booten" — korrigiert in den Test-Bootmenüs zum damaligen Zeitpunkt (`boot-grub.cfg`/`isolinux-live.cfg`), und in `architecture/13-live-provisioning-boot.md` als geltende Architektur festgehalten.
|
|
|
|
Eine spätere, gezielte Gegenlese aller ADRs live gegen den tatsächlichen Stand auf anode (siehe Chatverlauf, 12.08.2026) deckte auf, dass diese Korrektur nicht überall tatsächlich ankam:
|
|
|
|
1. `13-live-provisioning-boot.md` widersprach sich selbst — ein älterer, nie nachgezogener Abschnitt behauptete weiterhin unkorrigiert das Gegenteil (behoben, siehe Commit vom 12.08.2026, kein eigenes ADR).
|
|
2. Beim Nachschauen der tatsächlichen Boot-Configs in `tuxflotte-installer` zeigte sich: `grub/mint-boot-grub.cfg` hat einen zweiten, für Nicht-EFI-Systeme gedachten Zweig (`grub_platform != efi`) ganz ohne „lokale Festplatte"-Eintrag — `set default="0"` fällt dort auf den ersten, harmlosen Menüeintrag zurück (normaler Live-Boot, nicht der Auto-Install-Eintrag), mit hoher Wahrscheinlichkeit ohnehin unerreichbar, weil `scripts/build.sh` für BIOS-Boot tatsächlich `isolinux` einsetzt, nicht diesen GRUB-Zweig.
|
|
3. Die parallelen Fedora-Bootmenüs (`grub/EFI-BOOT-grub.cfg`, `grub/boot-grub2-grub.cfg`) wurden bei der ursprünglichen Korrektur am 01.08.2026 gar nicht angefasst — beide hatten weiterhin unverändert `set default="0"`, und Index 0 ist dort **„Tuxflotte Provisioning (automatisch)"**, der unbeaufsichtigte Install-Eintrag. Anders als Punkt 2 ist das kein wahrscheinlich unerreichbarer Zweig, sondern die tatsächlich verwendete Konfiguration, sollte das Fedora-Backend (laut ADR-0009 bewusst nicht rückgebaut, für eine mögliche künftige Wiederaufnahme) je wieder aktiviert werden.
|
|
|
|
## Entscheidung
|
|
|
|
Alle vier Boot-Konfigurationsdateien in `tuxflotte-installer/grub/` folgen jetzt einheitlich demselben, bereits in ADR-0009 getroffenen Prinzip: der Standardeintrag bei Countdown-Ablauf ist immer „von lokaler Festplatte/Firmware booten", nie ein Installations- oder Auto-Install-Pfad.
|
|
|
|
- `mint-boot-grub.cfg`: der nicht-EFI-Zweig bekommt denselben „Von lokaler Festplatte booten (Standard)"-Menüeintrag samt `set default` wie der EFI-Zweig, statt sich auf dessen vermutete Nichterreichbarkeit zu verlassen — bewusste Verteidigung in der Tiefe, kein Vertrauen auf eine Annahme über die Boot-Katalog-Struktur.
|
|
- `EFI-BOOT-grub.cfg` (Fedora, EFI): `set default="0"` → `set default="Lokales UEFI-System booten"`.
|
|
- `boot-grub2-grub.cfg` (Fedora, BIOS): `set default="0"` → `set default="Von erster lokaler Festplatte booten"`.
|
|
|
|
Kein Rückbau/keine Entfernung von Einträgen — die Auto-Install-Menüpunkte bleiben bestehen und auswählbar, nur nicht mehr die Standardauswahl bei Nichtstun.
|
|
|
|
Alle vier Dateien mit `grub2-script-check` syntaktisch verifiziert; auf anode per `git pull` deployt (Dateien werden nur zur ISO-Bauzeit gelesen, kein laufender Dienst, kein Neustart nötig) und stichprobenartig gegengeprüft (erwartete Menüeintrags-Namen vorhanden).
|
|
|
|
## Konsequenzen
|
|
|
|
Kein vollständiger, realer Boot-Test (QEMU/Proxmox) dieser Änderung — anders als die ursprüngliche 01.08.2026-Korrektur, die für Mint real verifiziert wurde, sind die Fedora-Configs aktuell unbenutzter, bewusst ruhender Code (kein aktiver Pilotbetrieb auf Fedora). Sollte das Fedora-Backend reaktiviert werden, sollte der korrigierte Standardeintrag Teil der ohnehin nötigen Neuverifikation sein, nicht blind vorausgesetzt werden.
|
|
|
|
Dieses ADR schließt eine Lücke zwischen einer bereits getroffenen Entscheidung (ADR-0009) und ihrer tatsächlichen, vollständigen Umsetzung — keine neue fachliche Entscheidung. Es zeigt zugleich ein wiederkehrbares Muster für dieses Repo: ein sicherheitsrelevanter Fix in einer aktiv genutzten Variante (Mint) deckt nicht automatisch parallele, seltener berührte Varianten (Fedora) ab — bei künftigen sicherheitsrelevanten Korrekturen lohnt sich ein expliziter Check, ob es strukturell ähnliche, aber unabhängig gepflegte Geschwisterdateien gibt.
|
|
|
|
Details zur ursprünglichen Entscheidung: ADR-0009, `13-live-provisioning-boot.md`.
|