Neues aus der IT-Welt

28. März 2026

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.

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.

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.

Naturgemäß wird dieser Vorschlag kontrovers diskutiert. Viele Server‑ und Power‑User kritisieren, daß 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, daß diese Konfigurationen langfristig weniger gewartet und in offiziellen Upgrade‑Pfaden weniger berücksichtigt werden.