ubuntuusers.de

Fedora 18 „umgeht“ Secure-Boot mithilfe von Microsoft-Signatur

linux.png

UEFI mit Secure Boot, das für Windows 8 zur Voraussetzung für zahlreiche Hardware wird, zieht weitere Kreise um sich. Matthew Garrett hat sich zu der Problemlösung für Fedora 18 geäußert.

Nachdem Microsoft schon im Herbst letzten Jahres ankündigte, dass Secure Boot eine Voraussetzung für Windows 8 wird, hagelte es große Kritik und Bedenken durch die Open Source-Community. Dabei ging es vor allem um die Frage, ob man Linux noch auf Mainboards mit UEFI 2.3.1 installieren kann. Denn durch Secure Boot wird standardmäßig nur zertifizierte Software gestartet.

Fedora_logo_200px.png
Fedoralogo

Matthew Garrett, Mitarbeiter von RedHat, hat sich jetzt in seinem Blog über eine Lösung des Problems in Fedora 18 geäußert 🇬🇧. Eines nimmt er gleich vorweg: x86 Hardware wird die Möglichkeit besitzen, Secure Boot zu deaktivieren beziehungsweise einen eigenen Schlüssel hinzuzufügen, aber beides will Garrett den Benutzern nicht zumuten.

Einerseits sei deshalb über Red Hat die Möglichkeit gegeben, einen eigenen generischen Schlüssel in die meiste Hardware zu integrieren. Das hätte zur Folge, dass nur Fedora davon profitiert. Alternativ bräuchte man eine eigene, dabei teure und aufwendige, Zertifizierungs-Infrastruktur für Linux-Distributionen.

Daher schlägt Garrett vor, den offiziellen „Zertifizierungsservice“ von VeriSign für ein Entgelt von 99 US-Dollar (umgerechnet circa 80 Euro) zu nutzen. Mit diesem Schlüssel ist es dann möglich, beliebig viel Software zu markieren. In Fedora 18 wird aber nur ein spezieller und kleiner Bootloader zertifiziert, der wiederum zum Beispiel GRUB 2 lädt. So will man mehr Unabhängigkeit erreichen, da ansonsten bei jedem Update von GRUB eine neue Zertifizierung nötig sei. Zusätzlich dazu müsse jegliche Möglichkeit, die es erlaubt „beliebige“ Software zu starten, deaktiviert werden. Beispielsweise soll GRUB in dem Maße verändert werden, dass man nur noch zertifizierte Kernel booten kann, wobei der Schlüssel natürlich auf Richtigkeit überprüft werden muss.

Darüber hinaus hat das auch Auswirkungen auf den Linux-Kernel an sich. Denn jeder Teil dessen, der vom User space direkt auf die Hardware zugreifen kann, muss dadurch entfernt werden. Resultierend wird es in Zukunft, so Garrett, zum Beispiel keine Graphikkartentreiber mehr geben, die im User space ausführbar sind. Als weiteres Szenario führt er einen signierten Kernel, der wiederum ein unsigniertes Modul lädt, auf. Dieses Modul täusche dann eine neue UEFI-Umgebung vor und bindet sich in den Bootloader ein. Danach würde man noch einen initramfs benötigen, das wiederum Malware in Form eines Moduls nachlädt. Das verzögere den Start zwar um ein paar Sekunden, sei aber prinzipiell möglich. Deshalb ergibt sich die Notwendigkeit, dass auch alle Kernelmodule zertifiziert werden müssen. Bei Modulen aus dem Fedora-Repository wird das passieren, problematisch könnte es hier wieder bei fremden Modulen werden – eine distributionsunabhängige Lösung steht noch aus. Ansonsten könnte es seiner Meinung nach zu einem „Treiber-Chaos“ zwischen den einzelnen Distributionen kommen. Aber auch hier weist er nochmals explizit darauf hin, dass diese Einschränkungen durch Deaktivieren von Secure Boot nicht mehr greifen.

Wenn dies alles nicht passiert, hätte man den Nutzen, also den Schutz vor Malware, von Secure Boot umgangen. Somit könnte man diese Funktion direkt vom Benutzer deaktivieren lassen, was, wie weiter oben bereits erwähnt, problematisch ist. Zusätzlich werfe dies kein gutes Licht auf Linux.

Für kleine Distributionen oder „Kernelkompilierer“ findet er die 99 US-Dollar für ein Zertifikat angemessen. Die weiteren Tools werden außerdem für jeden zugänglich und nutzbar sein. So gibt es den Quellcode des kleinen Bootloaders auf github 🇬🇧. Anderweitig weist er auf die Freiheit hin, die UEFI-Schlüssel beliebig anzupassen und zu erstellen. Man kann also bestimmen, welche Software man verwenden will, und so beispielsweise auch Windows „aussperren“.

Bei ARM-Hardware ist es komplizierter, weil Microsoft nicht die Möglichkeit vorsieht, Secure Boot zu deaktivieren oder die Schlüssel beliebig anzupassen. Fedora wird deshalb diese Geräte nicht unterstützen. Wobei das Problem seiner Ansicht nach nicht so groß sein wird, bedingt durch die geringere Verbreitung von Windows auf ARM-Hardware.

Matthew Garrett sieht dies als die momentan beste Lösung an, fügt gleichzeitig jedoch hinzu: „dies ist nicht in Stein gemeißelt“. In den Kommentaren wird aber wieder sehr deutlich klar: Das Thema wird weiterhin hitzig diskutiert und wird uns wohl noch einige Zeit beschäftigen – unabhängig von Fedora.

Quellen: Golem, heise, Pro-Linux, Matthew Garrett 🇬🇧 , PC World 🇬🇧