Secure Boot und Linux

Der Red-Hat- und Fedora-Entwickler Matthew Garrett gibt in einem Blog-Beitrag einen Überblick über den Stand der Secure-Boot-Unterstützung in Linux.

In Pocket speichern vorlesen Druckansicht 179 Kommentare lesen
Lesezeit: 3 Min.
Von
  • Dr. Oliver Diedrich

Der Red-Hat- und Fedora-Entwickler Matthew Garrett gibt in einem Blog-Beitrag einen Überblick über den Stand der Secure-Boot-Unterstützung in Linux. Start der Boot-Kette ist der neu geschriebene UEFI-Bootloader Shim, der von Microsoft signiert ist und daher auf allen x86-Rechnern startet, die Windows im Secure-Boot-Modus booten können – das dürften nahezu alle PCs und Notebooks sein. Um ein UEFI-Programm von Microsoft signieren zu lassen, benötigt man ein Verisign-Zertifikat und einen Entwickler-Account bei Microsoft. Secure Boot auf ARM-Geräten wird Linux zumindest auf absehbare Zeit nicht unterstützen.

Shim enthält einen distributionsspezifischen Schlüssel und tut nicht mehr, als ein Binary nachzuladen, das entweder mit diesem Schlüssel oder einem der Schlüssel signiert ist, die in der Firmware des Rechners gespeichert sind. Das nachgeladene Binary wird in der Regel der Standard-Bootmanager Grub oder der Linux-Kernel sein. Über den Shim-Trick ist es möglich, Boot-Manager und Kernel zu aktualisieren, ohne jedes Update erneut von Microsoft signieren zu lassen.

Um eine vertrauliche Boot-Kette sicherzustellen, müssen Boot-Manager und Kernel ebenfalls signiert sein. Außerdem, erklärt Garrett, sei es erforderlich, direkte Hardwarezugriffe aus dem Userspace zu verhindern, nur signierte Kernel-Module zu laden und den Kernel an einigen Stellen zu modifizieren, damit ein Angreifer nicht beispielsweise im gebooteten System einen manipulierten Kernel starten kann. Für externe Kernelmodule, die nicht mit der Distribution geliefert werden, beschreibt Garrett zwei Lösungsansätze. Ubuntu verzichtet ganz auf die Signierung von Kernelmodulen.

Für Windows zertifizierte Secure-Boot-Hardware muss es dem User ermöglichen, einen eigenen Schlüssel in die Firmware aufzunehmen; allerdings ist damit zu rechnen, dass die entsprechende Funktion in jeder Firmware anders implementiert wird. Suse-Entwickler haben daher einen Mechanismus erarbeitet, über den sich die Firmware mit Hilfe von Shim aus einem laufenden System heraus relativ einfach um einen neuen Schlüssel ergänzen lässt. Zudem kann der Anwender die Signaturüberprüfung in Shim abschalten, damit beispielsweise Kernelentwickler nicht jeden neu übersetzten Kernel signieren müssen.

Distributionen, die Shim nicht mit einem eigenen Schlüssel ausstatten und von Microsoft zertifizieren lassen wollen, können den Standard-Shim beispielsweise von Fedora nehmen. Wenn der merkt, dass der zu Boot-Manager des Installationssystems nicht mit dem in Shim eingebauten Fedora-Schlüssel signiert ist, bietet er dem Anwender die Möglichkeit, einen Schlüssel von dem Installationsmedium zu installieren. (odi)