UEFI: Zweifel an Secure-Boot-Lösung von Red Hat wachsen
Die von Matthew Garrett präsentierte Lösung für die Signierung für Secure Boot stößt inzwischen auf Kritik. Garretts Lösung sieht vor(öffnet im neuen Fenster) , dass Red Hat beziehungsweise Fedora den Signierdienst von Microsoft in Anspruch nimmt, um einen ersten Bootloader mit einem Schlüssel zu versehen. Dieser soll dann Grub2 laden, der wiederum einen Schlüssel von Red Hat oder Fedora enthält und so Secure Boot auf die Linux-Distribution erweitert.
Kartellklage gegen Microsoft?
Allerdings müssten sämtliche Linux-Distributionen ebenfalls einen Schlüssel von Microsoft erwerben, der einmalig 99 US-Dollar kostet. Das Geld geht jedoch nicht an Microsoft, sondern an Versign, das den Schlüssel bereitstellt. Außerdem fürchten zahlreiche Linux-Entwickler weiterhin eine Zusammenarbeit mit Microsoft. Ein Leser auf Slashdot schlug bereits eine Kartellklage(öffnet im neuen Fenster) gegen Microsoft vor.
Garret vertritt die Ansicht, dass ein Microsoft-Schlüssel die einfachste Lösung sei, damit Linux auch auf Hardware mit aktiviertem Secure Boot installiert und genutzt werden könne. Red Hats Vizechef für die Linux-Entwicklung, Tim Burke(öffnet im neuen Fenster) , hat Garretts Idee inzwischen gutgeheißen und will sie auch für Red Hat umsetzen.
Secure Boot auch für Linux sinnvoll
Burke betont, dass Secure Boot für Linux eine sinnvolle Funktion sei und wesentlich zur Sicherheit beitragen kann. Secure Boot zu deaktivieren, sei keine Alternative, schreibt Burke. Es gehe dabei um eine sorgfältige Abwägung zwischen Sicherheit und der Freiheit des Anwenders. Selbst Linus Torvalds hatte sich positiv zu Secure Boot geäußert(öffnet im neuen Fenster) .
Zwar müsse jede Linux-Distribution einen eigenen Schlüssel erwerben, Red Hat und Fedora würden die minimalen Kosten jedoch nicht an den Anwender weitergeben, schreibt Burke. Große Distributionen könnten sich die geringe einmalige Gebühr leisten. Kleinere Distributionen würden sicherlich den Betrag durch Spenden finanzieren können. Das gelte auch für Anwender, die ihre eigene installierbare Fedora-Version zusammenstellen wollten. Sie müssten lediglich den Schlüssel von Microsoft erwerben, die Schlüssel von Fedora würden kostenlos bleiben. Für persönliche Änderungen an Fedora, etwa die Lokalisierung, sind keine neuen Schlüssel erforderlich.
Red Hat vertraut Microsoft
Gleichzeitig rechtfertigt Burke die Zusammenarbeit mit Microsoft: Red Hat habe lange sowohl mit der Linux Foundation und mit Hardwareherstellern als auch mit Microsoft selbst darüber verhandelt und würde nicht auf eine solche Lösung zurückgreifen, wenn eine böse Absicht dahinterstecke, schreibt Burke.
Ob sich sämtliche - vor allem die kleineren - Linux-Distributionen mit Microsofts Signierdienst einlassen, bleibt indes fraglich. Zwar soll der Erwerb des Schlüssels weitgehend problemlos sein, allerdings bedeutet er auch eine Einschränkung einer der Grundsätze der Open-Source-Bewegung: die komplette Freiheit über die erworbene Hardware. Außerdem ist Microsoft nicht dazu verpflichtet, den Schlüssel auszustellen und könnte sich beispielsweise bei unliebsamen Hackerdistributionen querstellen.
Einschränkungen auch bei Linux
Damit die Kette von signiertem Code beim Boot bis zur grafischen Oberfläche nicht unterbrochen werden kann, müssen auch Linux-Entwickler einige Funktionen beschränken. So sollen Nutzer künftig etwa keine Module mehr in Grub2 laden können und dessen Kommandozeile soll keine Kernel-Befehle mehr entgegennehmen können, die Angreifer ausnutzen könnten.
Auch werde der Linux-Kernel selbst eingeschränkt, schreibt Garrett. So müssen etwa sämtliche verwendeten Treiber signiert sein und in den Kernel geladen werden. Der Umgang mit Modulen, die das Fedora-Team nicht selbst anbietet, wird also schwieriger.
UEFI ist unsicher
Immerhin lässt sich notfalls Secure Boot ausschalten. Microsoft hatte bereits versichert, dass ein parallel installiertes Windows 8 trotzdem starten würde und seine Vorgänger sowieso. Nur auf ARM-basierter Hardware muss für den Betrieb von Microsofts neuer Windows-Version Secure Boot zwingend aktiviert sein.
Allerdings ist UEFI unsicherer als das bisher verwendete Bios. Denn darüber können beispielsweise Hardwaretreiber geladen werden, auf die später auch das gestartete Betriebssystem zugreift. Sie liegen auf beschreibbaren UEFI-Partitionen. Damit lässt sich Malware einfacher einschmuggeln als zuvor.