[Allgemein]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.

    [Blockierte Grafik: http://www.pro-linux.de/images/NB3/imgdb/n_opensuse-logo.jpg]

    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.


    Aus: Pro-Linux

    ___________________________________________________________________________________
    Zypper Befehlsreferenz

    Für den Inhalt des Beitrages 44807 haftet ausdrücklich der jeweilige Autor: lush