Nach einem kontrovers diskuttierten Vorschlag von Debian/Ubuntu-Entwickler Julian Andres Klode, der unter anderem auch den Paketmanager APT betreut, soll für 26.10 Secure Boot mit GRUB vereinfacht werden, um den Angriffsvektor zu verkleinern. Dazu sollen bestimmte Funktionen aus den signierten GRUB‑Bauarten entfernt werden.
Bereinigter GRUB
Dazu gehören die Dateisysteme btrfs, hfsplus, xfs und zfs; behalten bleiben sollen ext4, fat und iso9660 sowie squashfs für Snaps. Auch die Image-Formate jpeg und png sollen aus signierten GRUB‑Builds raus, da Bilder im Boot‑Menü ein Sicherheitsrisiko darstellen könnten; grafische Themes der Ubuntu‑Flavours wären dann nur noch ohne Secure Boot nutzbar. Die Unterstützung für /boot auf komplexen Set‑Ups wie LVM, md‑RAID außer RAID1 und LUKS‑verschlüsseltem /boot soll in den signierten GRUB‑Builds ebenfalls entfallen. Stattdessen soll /boot auf einer ext4‑Partition – separat oder innerhalb von / – auf GPT- oder MBR‑Platten liegen.
Weniger Sicherheitslücken
Durch die Einschränkung des Angriffsvektors will Klode die kontinuierlich auftretenden Sicherheitslücken in GRUB dezimieren. Die Verschlüsselung von /boot wird als security by obscurity kritisiert; echte Integrität soll über TPM‑basierte Full‑Disk‑Encryption‑Lösungen gewährleistet werden. Die Änderungen sollen auch den künftigen Einstieg in neue Boot‑Architekturen erleichtern.
Kontroverse Diskussion
Naturgemäß wird dieser Vorschlag kontrovers diskutiert. Viele Server‑ und Power‑User kritisieren, dass md‑RAID (auch RAID1) und LVM für /boot entfallen sollen. Es gibt zudem Bedenken, ob die Entfernung von LUKS2‑Support für /boot mit Sicherheitsstandards wie in der EU‑Org‑Infrastruktur vereinbar ist, wo Full‑Disk‑Encryption vorgeschrieben ist.
Mehrere Kommentatoren plädieren dafür, bald auf systemd‑boot zu wechseln, was aber derzeit noch nicht praktikabel ist, da systemd‑boot nur EFI unterstützt, während GRUB auch BIOS und andere Architekturen bedient.
Was bedeutet dies für Nutzer ohne Secure Boot?
Sollte dieser Vorschlag umgesetzt werden, unterstützt Canonical Konfigurationen ohne Secure Boot nicht mehr mit Security‑Support, weil sie außerhalb der Secure‑Boot‑Kette sind. Für Systeme, die bewusst ohne Secure Boot eingesetzt werden und dies auch nicht ändern wollen, bedeutet der Vorschlag: Sie können weiterhin LVM, LUKS‑verschlüsseltes /boot, ZFS etc. nutzen, da sie auf dem nicht signierten GRUB‑Build laufen. Dafür erhalten sie aber keinen Security‑Support seitens Ubuntu im Boot‑Pfad und riskieren, dass diese Konfigurationen langfristig weniger gewartet und in offiziellen Upgrade‑Pfaden weniger berücksichtigt werden.
Ich verstehe gut den Hintergedanken.
Auch wenn ich wirklich SEHR traurig wäre bzgl der grafischen Elemente.
Denn für mich persönlich wäre es ein Rückschritt in Sachen Design.
Wo MS mit seinem eigenen Bootloader Design realisieren kann, wäre GRUB dann beschnitten. Plymouth und Co hätten keinen smoothen Übergang mehr…
Ich verstehe es und würde mich dem deswegen beugen. Aber ich werde den Rückschritt im Bereich Design bedauern. 😀
Die Diskussion um die Vereinfachung von Secure Boot in Ubuntu 26.10 ist ein spannender Schritt in Richtung größerer Systemsicherheit. Während die Entfernung bestimmter Dateisysteme und Funktionen in signierten GRUB Builds zunächst Einschränkungen mit sich bringt, bietet dies doch eine bedeutende Chance, Sicherheitslücken zu minimieren und den Bootprozess zuverlässiger zu gestalten. Es ist positiv, dass sich das Team hinter dieser Entscheidung für eine proaktivere Sicherheitspolitik entschieden hat, auch wenn dies möglicherweise zunächst einige Anpassungen bei den Nutzern erfordert. Langfristig kann diese Änderung zu stabileren und sichereren Systemen beitragen, was sowohl für Heimnutzer als auch für Unternehmen von Vorteil ist.
Mal wieder ein KI-Kommentar, der außer Worthülsen nichts enthält. Wir behalten uns vor, solche Kommentare künftig zu löschen.
Deine Reaktion finde ich völlig unverständlich.
Bitte was ist an dem Kommentar falsch, wo sind die Worthülsen versteckt?
Ich sehe da eine neutrale Meinungsäußerung, nicht mehr und nicht weniger.
Ich habe nicht gesagt, der Kommentar sei falsch. Ich mag einfach keine offensichtlich von einer KI erstellte Kommentare. Die häufen sich hier leider in letzter Zeit.
Ich bin übrigens nicht der einzige, der das so sieht. Kommentar auf Mastodon: Ich habe mir heute ein paar Artikel bei @linuxnews (https://linuxnews.de) durchgelesen, da ich in den letzten Wochen viele aus Zeitgründen übersprungen habe. Die offensichtlich #KI / #LLM generierten Kommentare nerven extrem.
Ich frage mich, was die Motivation der Menschen ist, die sowas schreiben (lassen). Die haben doch keinen Mehrwert dadurch, vor allem da die Kommentare ziemlich inhaltslos sind.
Ich verstehe das Argument gegen systemd‑boot nicht.
Secure Boot ist ohnehin nur zusammen mit UEFI einsetzbar.