UEFI Secure Boot für Suse-Linux

Suse will wie Fedora auf einen von Microsoft signierten Boot-Loader Shim setzen, diesen aber erweitern, um die Handhabung von Schlüsseln zur Verifikation zu erleichtern.

In Pocket speichern vorlesen Druckansicht 146 Kommentare lesen
Lesezeit: 4 Min.
Von
  • Thorsten Leemhuis

Suse will bei der Unterstützung für UEFI Secure Boot in Suse Linux Enterprise (SLE) ähnlich vorgehen wie es das Fedora-Projekt für Fedora 18 plant; ferner wollen Entwickler des Nürnberger Linux-Distributors auch dem OpenSuse-Projekt vorschlagen, den Weg zu adaptieren, der erstmals beim dritten Service Pack von SLE 11 genutzt werden soll. Das geht aus zwei Blog-Posts von Suse-Mitarbeiter Olaf Kirch hervor (1, 2). Die Pläne für Suse unterscheiden sich an zwei Stellen aber von denen Fedoras, wie aus einem Eintrag im Suse-Blog hervorgeht, in dem Vojtěch Pavlík Details der vorgesehenen Implementation beschreibt.

Demnach will auch Suse den im Fedora-Umfeld entstandenen Mini-Boot-Loader Shim nutzen. Der soll in zwei Ausführungen beiliegen: Mit einer Signatur des Schlüssels von Microsoft, wie es auch für Fedora und Ubuntu geplant ist, und mit einer Signatur eines Suse-Schlüssels. Eine mit einem eigenen Schlüssel signierte Shim-Variante sieht Fedora dagegen nicht vor. Diese Part des Suse-Plans ähnelt eher einem Teil des Ubuntu-Vorgehens, denn auch Canonical will einen Boot-Loader mitliefern, der mit einem eigenen Schlüssel signiert ist; UEFI-Firmware startet diesem Bootcode bei aktivem Secure Boot allerdings nur, wenn bei ihr ein öffentlicher Schlüssel hinterlegt ist, um die Signatur des jeweiligen Linux-Distributors zu verifizieren.

Shim soll auf eine Datei mit öffentlichen Schlüsseln zurückgreifen können.

(Bild: Suse-Blog )

Der zweite und wichtigere Unterschied zu Fedoras Plänen: Suse will Shim erweitern, damit es die öffentlichen Schlüssel aus eine separat abgelegte Datei beziehen kann, die es zur Verifikation von Grub und Linux-Kernel verwendetet. Bei Fedora sollten diese Schlüssel direkt in das signierten Shim-Binary integriert werden, sodass man keine weiteren hinterlegen kann, ohne Shim neu zu erzeugen und selbst zu signieren.

Die öffentlichen Schlüssel in der Datei bezeichnen die Suse-Entwickler als MOKs (Machine Owner Keys). Durch eine spezielle Tastenkombination soll Shim einem "enrollment process" aufrufen, über den Anwender neue MOKs hinterlegen können. Der Hash-Wert der Datei wird in einer "Boot Services Only"-Variable in den UEFI-Daten gesichert, damit Shim unerlaubte Modifikationen erkennen kann.

Wie bei Fedora soll der Mini-Loader Shim den flexibleren Boot-Loader Grub 2 laden und ausführen, wenn er laut einem der MOKs vertrauenswürdig ist. Shim übergibt Grub dabei die Liste der MOKs. Grub wiederum kann prüfen, ob der ausgewählte Kernel vertrauenswürdig ist, bevor er diesen startet.

Durch Suses geplante Erweiterung sollte es einfacher werden, einen selbst signierten Kernel per Secure Boot zu starten, da man den Schlüssel zur Verifikation lediglich bei Shim hinterlegen muss – man braucht also nicht auch Grub und Shim mit einem eigenen privaten Schlüssel signieren und den zugehörigen öffentlichen Schlüssel über Wege beim der UEFI-Firmware hinterlegen, die sich zwischen UEFI-Systemen unterscheiden. Zudem lassen sich über einen von Shim gelandene Grub die Kernel verschiedener Distributionen starten, da es diese mit den hinterlegten MOKs verifizieren kann. Das kann Anwendern den Umgang erleichtern, untergräbt aber einen der Ansätze von UEFI – das ist nämlich darauf ausgelegt, die Boot-Loader mehrerer Betriebssysteme parallel vorzuhalten und dem Anwender bei Booten eine Auswahl zu ermöglichen.

Red-Hat-Entwickler Matthew Garrett, der die Fedora-Pläne maßgeblich ausgearbeitet hat, bezeichnet den Suse-Ansatz mit der MOK-Datei und ihrer Absicherung über eine UEFI-Boot-Service-Variable eine "wundervoll elegante Lösung". Er nimmt an, das diese Shim-Erweiterung auch in Fedora einfließt, weil es einige Dinge erleichtert; er macht aber keine Angaben, wann das der Fall sein wird. Derweil hat Josh Boyer, der sich bei Fedora um den Kernel kümmert, mit Secure Boot experimentiert und seine Erfahrungen in einem längeren Blog-Eintag zusammengefasst; er bietet einige Einblicke in die Funktionsweise und die Handhabung der Techniken zum Secure Boot, zeigt aber auch, dass es noch allerlei Probleme bei der Linux-Unterstützung gibt.

Zu UEFI Secure Boot siehe auch:

(thl)