Original-URL des Artikels: https://www.golem.de/news/uefi-zweifel-an-secure-boot-loesung-von-red-hat-wachsen-1206-92355.html    Veröffentlicht: 06.06.2012 17:43    Kurz-URL: https://glm.io/92355

UEFI

Zweifel an Secure-Boot-Lösung von Red Hat wachsen

Nachdem Red Hat und Fedora eine mögliche Lösung für die Verwendung von Linux mit UEFIs Secure Boot präsentiert haben, wächst die Kritik. Denn unabhängige Distributionen müssten den Bootloader ebenfalls von Microsoft signieren lassen.

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, 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 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, 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.

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.  (jt)


Verwandte Artikel:
UEFI Secure Boot: Fedora 18 mit Microsoft-Signatur   
(31.05.2012, https://glm.io/92189 )
Linuxboot: Google und Facebook ersetzen Server-UEFI mit Linux   
(29.01.2018, https://glm.io/132454 )
UEFI: Secure-Boot macht Linux weiter Probleme   
(18.01.2012, https://glm.io/89146 )
Mainboard: Intel will ab 2020 nur noch UEFI statt Bios   
(21.11.2017, https://glm.io/131245 )
Raven Ridge: AMD verschickt CPUs für UEFI-Update   
(16.02.2018, https://glm.io/132821 )

© 1997–2019 Golem.de, https://www.golem.de/