
Canonical plant umstrittene GRUB-Änderungen für Ubuntu 26.10 Secure Boot
Canonical plant Änderungen am Secure-Boot-GRUB in Ubuntu 26.10, wodurch die Unterstützung für LUKS, LVM, ZFS und andere Funktionen wegfällt.
Eine Übersetzung von 🇬🇧 Linuxiac.com
Canonical hat für Ubuntu 26.10 eine wesentliche Änderung am Secure Boot vorgeschlagen, mit dem Ziel, den Funktionsumfang des GRUB-Bootloaders in signierten Konfigurationen zu reduzieren.
Der Vorschlag mit dem Titel Streamlining secure boot for 26.10, der vom Canonical-Ingenieur Julian Klode auf Ubuntus Discourse veröffentlicht wurde, empfiehlt die Bereitstellung einer minimalen GRUB-Version für Secure-Boot-Systeme, um den in der privilegierten Pre-Boot-Umgebung ausgeführten Code zu reduzieren.
Der vorgeschlagene signierte GRUB für Secure Boot würde die Unterstützung für Funktionen wie LUKS-Festplattenverschlüsselung, LVM, die meisten md-raid-Modi, ZFS, Btrfs sowie verschiedene Funktionen zur Analyse von Dateisystemen und Images entfernen. Es wird erwartet, dass Systeme von einem einfacheren Layout booten, typischerweise einer einfachen ext4-/boot-Partition auf GPT oder MBR.
Laut Canonical dient dies alles der Sicherheit. GRUB analysiert Dateisysteme, Festplattenformate und andere Strukturen, bevor das Betriebssystem geladen wird. Jedes unterstützte Format vergrößert die Angriffsfläche, daher soll die Reduzierung dieses Umfangs das Risiko von Schwachstellen in der Secure-Boot-Kette verringern.
Diese Funktionen würden auf Systemen, die Secure Boot nicht nutzen oder nicht signierte GRUB-Builds verwenden, weiterhin verfügbar sein. Diese Konfigurationen würden jedoch nicht von den Schutzmaßnahmen von Secure Boot profitieren.
Und jetzt wird es interessant. Systeme, die auf nicht unterstützte Funktionen im Secure-Boot-Pfad angewiesen sind, könnten mit dem Standard-Release-Upgrader kein Upgrade auf Ubuntu 26.10 durchführen. Canonical gibt an, dass diese Systeme auf Ubuntu 26.04 LTS verbleiben würden, sofern sie nicht neu konfiguriert werden.
Wie erwartet hat der Vorschlag in Community-Diskussionen erhebliche Bedenken ausgelöst. Viele Ubuntu-Installationen, insbesondere auf Servern, basieren auf verschlüsselten Volumes mit LVM. Nutzer weisen darauf hin, dass die Entfernung der Unterstützung im Secure-Boot-Pfad Änderungen an etablierten Bereitstellungsmodellen erfordern würde.
Auch Nutzer von ZFS und Btrfs äußern ähnliche Bedenken. Diese Dateisysteme werden häufig für Snapshot-basierte Arbeitsabläufe oder komplexe Speicherkonfigurationen verwendet. Die Forderung nach einer separaten ext4-Partition für das Boot-Verzeichnis verändert die Art und Weise, wie diese Systeme aufgebaut sind und gewartet werden.
Ein weiteres großes Problem sind Störungen bei Upgrades. Da Upgrades für betroffene Systeme blockiert werden, bleiben den Nutzern nur wenige Optionen, wie beispielsweise eine Neuinstallation, die Neukonfiguration der Speicherlayouts oder die Deaktivierung von Secure Boot.
Nicht zuletzt bleiben Fragen zur RAID-Unterstützung offen, insbesondere hinsichtlich des Umfangs der beibehaltenen md-raid-Funktionalität. Vor diesem Hintergrund ist in einigen Aspekten des Vorschlags unklar, wie gespiegelte Boot-Konfigurationen unter dem neuen Modell funktionieren würden.
Um das Bild abzurunden, sieht der Vorschlag außerdem vor, die Unterstützung für Bildformate wie PNG und JPEG in signierten GRUB-Builds zu entfernen, die zur Darstellung von GRUB-Themes verwendet werden, darunter Hintergrundbilder, Symbole und andere visuelle Elemente im Startmenü. Canonical argumentiert, dass die Beibehaltung von Code zur Bilddekodierung im Secure-Boot-Pfad eine unnötige Angriffsfläche schafft.
Zum jetzigen Zeitpunkt handelt es sich bei der Änderung noch um einen Vorschlag für Ubuntu 26.10. Es wurden noch keine endgültigen Details zur Umsetzung oder Entscheidungen bekannt gegeben. Angesichts des Umfangs der vorgeschlagenen Änderungen und der Reaktionen der Community wird erwartet, dass die Diskussion weitergeht, während Canonical seinen Ansatz verfeinert.
Spendieren Sie Bobby einen ☕ Ko-fi
s3n🧩net wünscht viel Vergnügen















Comments