Login
Newsletter
Werbung

Fr, 10. August 2012, 16:19

Software::Distributionen::OpenSuse

Secure Boot: Suse erweitert Fedoras Strategie

Suse plant für seine Unternehmensprodukte, in Hinblick auf UEFI Secure Boot eine auf Fedoras Strategie aufsetzende Lösung zu verwenden und diese geringfügig zu erweitern. Was das Opensuse-Projekt in dieser Frage beabsichtigt, ist noch noch nicht entschieden.

Opensuse

Der Suse-Mitarbeiter Olaf Kirch erläutert den derzeitigen Stand der Diskussion der Nürnberger zum Thema UEFI Secure Boot in einen ausführlichen Blog-Eintrag. Darin spricht Kirch zunächst allgemein über mögliche Probleme, die sich für Linux-Distributoren im Zusammenhang mit UEFI-Secure-Boot ergeben, und stellt dann die von Suse für seine Unternehmensprodukte favorisierte Lösung vor.

Die sieht ebenfalls den Einsatz des von Matthew Garret von Red Hat entwickelten Bootloaders Shim vor, der aller Voraussicht nach über eine Microsoft-Signatur verfügen wird. Das weitere Vorgehen bei Suse unterscheidet sich jedoch in einigen Punkten von Fedoras Plan und trägt in einigen Details auch Züge der von Canonical für Ubuntu geplanten Lösung. Was das bedeutet erläutert der Suse-Entwickler Vojtěch Pavlík in einem weiteren Blog-Eintrag.

Zwar will auch Suse den von Garret entwickelten Mini-Boot-Loader Shim einsetzen, der soll aber in zwei Versionen beiliegen, einmal mit Microsoft-Schlüssel signiert und einmal mit einer Signatur von Suse, womit die Strategie auch Züge der von Canoncial favorisierten Lösung trägt, denn Ubuntu will künftig ebenfalls einen eigenen, selbst signierten Boot-Loader mitliefern. Die Shim-Variante von Suse mit eigener Signatur wird bei Hardware mit UEFI-Firmware und eingeschaltetem Secure Boot nur booten, wenn in der Firmware ein öffentlicher Schlüssel hinterlegt ist, der die Signatur von Suse verifiziert. Im Unterschied zu Fedoras Lösung erweitert Suse Shim derart, dass der die öffentlichen Schlüssel zum Verifizieren von Kernel und Grub in separaten Dateien ablegt, während Fedoras Shim diese Schlüssel in der Binärdatei enthält, was das Hinzufügen weiterer Schlüssel ohne Neuübersetzen und Signieren von Shim verhindert. Suse nennt seine in Dateiform gespeicherten öffentliche Schlüssel MOKs (Machine Owner Keys). Damit Shim unerlaubte Modifikationen erkennen kann, soll der Hash-Wert der Datei in einer sogenannten »Boot Services Only Variable« von UEFI gesichert sein, welche die UEFI-Spezifikationen neben »Authenticated Variables« ebenfalls vorsehen. Im weiteren Verlauf gleicht die sichere Boot-Kette wieder dem Fedora-Verfahren, bei dem Shim den eigentlichen Boot-Loader Grub2 nachlädt und ausführt, sofern dieser vertrauenswürdig ist, was Shim wiederum einem der hinterlegten MOKs entnimmt, die Shim an Grub übergibt. Damit kann Grub seinerseits prüfen, ob der ausgewählte Kernel vertrauenswürdig ist, und diesen dann starten.

Suses Verfahren erlaubt auf einfache Weise das Starten selbst signierter Kernel via Secure Boot, weil der zugehörige Schlüssel nur bei Shim hinterlegt sein muss, während bei Fedoras Verfahren auch Shim und Grub mit privaten Schlüsseln signiert und die zugehörigen öffentlichen Schlüssel in der UEFI-Firmware hinterlegt sein müssen. Pavlík räumt zwar ein, dass sein Verfahren auf dem ersten Blick den UEFI-Spezifikationen sowie den Windows-8-Logo-Anforderungen zu widersprechen scheint, dass es die UEFI Spezifikationen aber erlauben, wenn auch nicht zwingend verlangen, dass eine UEFI-Implementation benutzerautorisierten EFI-Code mit »ungültiger« Signatur mit einem Datei-basierten Schlüssel verifiziert, dessen Hash-Wert in einer Boot Services Only Variable gespeichert ist. Sogar Garret selbst hat sich inzwischen in seinem Blog anerkennend zu Pavlíks Vorschlag geäußert und kann sich vorstellen, die Lösung auch für Fedora zu übernehmen.

Laut Olaf Kirch steht im Moment jedoch lediglich die Überlegung im Raum, die von Pavlík aufgezeigte Lösung für Suse Linux Enterprise 11 Service Pack 3 bei einer Neuinstallation auf Geräten mit Secure-Boot anzubieten. Weitere Details und konkrete Pläne will Kirch erst in den kommenden Tagen in Form weiterer Blog-Einträge rund um das UEFI-Secure-Boot diskutieren und vervollständigen. Das gibt auch der Opensuse-Gemeinschaft die Möglichkeit, über den Vorschlag für ihre eigene Distribution nachzudenken, denn beim Opensuse-Projekt ist in dieser Frage bisher noch keine Entscheidung gefallen.

Werbung
Kommentare (Insgesamt: 16 || Alle anzeigen )
Re: Live USB Stick?? (skinnie, Di, 14. August 2012)
Live USB Stick?? (Linux-Nutzer, So, 12. August 2012)
Re[4]: Zum Kotzen (abcde, So, 12. August 2012)
Re: hmm kernel Entwickler ausgebootet (Samson, So, 12. August 2012)
hmm kernel Entwickler ausgebootet (patrick100, So, 12. August 2012)
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung