UEFI Secure Boot: Nun meldet sich die Free Software Foundation (FSF) zu Wort und ist nicht zimperlich

6 Kommentare Autor: Jürgen (jdo)

FSF - Free Software Foundation Logo 150x150Wenn sich nun Dieter Bohlen noch zu UEFI Secure Boot äußert, haben wir alle durch, oder? 🙂 Im Ernst, wenn einer dazu was sagen sollte, dann natürlich die Free Software Foundation, die sich seit Monaten entschieden gegen UEFI Secure Boot ausspricht. Diesen Standpunkt machen Sie in einer neuen Ankündigung noch einmal mit Nachdruck deutlich: UEFI Secure Boot sei eine massive Gefahr für Benutzer-Freiheit, Software-Ideale und die Adaptierung von freier Software. Unter dem Deckmantel der Sicherheit würde man Rechner einsperren und könnte lediglich Betriebssysteme starten, die vorher dafür zertifiziert wurden. Dem Nutzer würde dadurch die Kontrolle über den Rechner genommen.

Wer wenig Zeit hat und sich die ganze Litanei nicht durchlesen möchte, hier eine schnelle Zusammenfassung:

  • Microsoft macht es schwerer, freie Software auf den eigenen Rechner zu installieren und könnte das Deaktivieren von Secure Boot mit “Du beraubst Dich gerade der Sicherheit Deines Rechners” Panik machen.
  • Unter dem Mantel der Sicherheit wolle Microsoft die Anwender einsperren.
  • Fedoras Ansatz ist sympatischer als Canonical und funktioniert zwar, ist aber alles andere als ideal.
  • Ubuntus Befürchtungen, den privaten Schlüssel enthüllen zu müssen ist Quatsch außerdem stärke Ubuntus Weg “Restricted Boot” den Rücken und man habe wohl die GPLv3 nicht verstanden (hochoffizielle Rüge!)
  • Man darf Microsoft so ein Verhalten nicht durchgehen lassen.

Um die Freiheit der Anwender zu sichern, müssen laut FSF die Hardware-Hersteller einen Weg zur Verfügung stellen, diese Boot-Beschränkungen aufzuheben – zumindest muss sichergestellt sein, dass der Anwender ein Betriebssystem seiner Wahl installieren kann. Hersteller unfreier Betriebssysteme nutzen das Schlagwort “Sicherheit” und nur mit zertifizierten Software-Produkten können sie den Anwender schützen.

Die Free Software Foundation ist allerdings der Meinung, dass wir Anwender vor diesen Herstellern geschützt werden müssen. Man wolle wohl kaum eine Maschine habe, auf der nur Software von den digitalen Diktatoren läuft. Darüber wolle der Anwender selbst entscheiden. Die FSF geht sogar so weit und bezeichnet Software, die solche Restriktionen forciert als Malware. Firmen wie Microsoft hätte eine furchtbare Statistik in Sachen Sicherheit und die Plattitüden über Sicherheit zu unserem Wohl seien unehrliches Phrasen-Gedresche.

Wenn man Secure Boot richtig einsetzt, würde der Anwender die Kontrolle über seinen Rechner behalten. Microsoft mag besorgt sein, dass Malware die Herrschaft über Windows-Rechner übernimmt. Allerdings bezeichnet die FSF Windows selbst als Malware und will es tunlichst vom Rechner haben. Man kann ja aber den Microsoft-Schlüssel aus der Boot-Firmware entfernen und einen eigenen Schlüssel einsetzen.

Wo ist also das Problem der FSF?

Theoretisch hat die FSF gar kein Problem mit Secure Boot. Praktisch sei die Situation aber viel komplizierter. Es sei schon schlimm genug, dass fast alle Rechner mit Windows vorinstalliert ausgeliefert werden. Secure Boot mache nun aber die Adaption freier Software komplizierter. Neulinge freier Software müssen nun einen Schritt extra einlegen, um freie Betriebssysteme auf ihren Rechnern zu installieren. Die proprietären Software-Firmen können diesen Schritt aber mit “Du deaktivierst die Sicherheit auf Deinem Rechner” bewerben und somit potentielle neue Anwender freier Software in die Irre führen. Den Punkt muss man der Free Software Foundation auf jeden Fall uneingeschränkt lassen.

Dies sei eine Hürde, die man ganz und gar nicht brauchen kann und auch in Frage gestellt werden könne. Secure Boot bringe mehr Schwierigkeiten mit sich, als die Software lösen würde. Es verhindere, dass sich Anwender um ihre eigene Sicherheit kümmern, indem sie Microsoft Windows den Laufpass geben. Linus Torvalds sieht die Kernel Entwicklung von UEFI Secure Boot nicht gefährdet und er überlegt sich, einen eigenen Schlüssel zu holen. Aber auch der Linux-Vater stellt das Sicherheits-Argument in Frage.

Die FSF geht auch auf das Problem ein, dass das “Windows 8 Logo Programm” das deaktivieren von UEFI Secure Boot auf ARM-Geräten untersagt. Aber hier sind sich viele einig, dass Microsoft auf ARM derzeit einfach keine Rolle spielt, wie es auch ein sehr schöner Artikel von Chris Hall zeigt. Nun geht die Free Software Foundation auf die Lösungs-Ansätze von Fedora / Red Hat und Ubuntu ein.

Fedoras Herangehensweise

Wie bereits auf BITblokes.de erwähnt, hat Red Hats Matthew Garret angekündigt, dass man einen Microsoft-Schlüssel verwenden will. Zumindest so lange, bis eine bessere Lösung gefunden ist. Dazu wird ein eigener und kleiner Bootloader (mit Namen Shim) entwickelt, der dann mit dem Microsoft-Schlüssel signiert ist und danach den eigentlichen Bootloader startet. Da Fedoras Ansatz das Microsoft-Zertifikat verwendet, wird es auch von fast jeder Firmware auf den Desktops und Notebooks erkannt werden.

Der FSF gefällt im Prinzip Fedoras Denkweise, weil man auch anderen die Möglichkeit gibt, diesen Weg zu gehen und die eigene Distribution unter UEFI Secure Boot laufen zu lassen. Auch wenn die Lösung mit der Lizenz von GRUB 2 und der GPLv3 konform ist, sieht die Free Software Foundation dennoch 2 größere Probleme mit diesem Ansatz.

  • Anwender, die Secure Boot nutzen möchte, müssen Microsoft vertrauen. Derzeit würde nur eine Signatur pro Binärdatei erlaubt sein. Somit kann Fedoras Shim nur mit dem Microsoft-Schlüssel unterschrieben werden. Sobald ein Anwender den Microsoft-Schlüssel entfernt, wird Fedora nicht mehr länger starten, solange Secure Boot aktiviert ist.
  • Außerdem sei ein Anschluss an das Microsoft Entwickler-Programm nicht empfehlenswert. Darüber hinaus würden die 99 US-Dollar Gebühr eine Hürde für viele Leute um den Erdball verteilt darstellen. Außerdem müsse man diverse Anträge ausfüllen und sich dazu bereit erklären, “Werbung und periodische Mitglieds-E-Mails von Microsoft” zu akzeptieren. Ebenso seien ein Identitätsnachweis und eine Kreditkarte notwendig.

Diese Bedingungen seien für das Modifizieren und Benutzen eines Betriebssystems nicht akzeptabel. Vielmehr sollte man verfolgen, die von Fedora bereitgestellten Tools zu benutzen, eigene Schlüssel einzusetzen.

Software mit eigen kreierten Schlüsseln würden ohne einige Extra-Schritte allerdings nicht auf der Mehrzahl der Computers aus dem Laden laufen. Das sei zwar ein Problem, aber man werde so lange gegen Hersteller mobil machen, bis diese eine Dokumentation zur Verfügung stellen, die diesen Prozess vereinfacht. Schließlich gehe es darum, dass der Installation freier Software Steine in den Weg gelegt würden. Entwickler freier Software und Anwender ans Herz zu legen, dass sie Microsoft vertrauen sollten, sei keine akzeptable Lösung.

Vor wenigen Tagen gab es ein Gerücht, dass Gummiboot der neue Fedora-Loader für UEFI Secure Boot ist – das hat sich allerdings als falsch herausgestellt.

Ubuntus Herangehensweise

Ubuntu hat ja bekanntlich ebenfalls einen Plan.

  • Als “Ubuntu Certified” ausgezeichnete und mit Ubuntu vorinstallierte Hardware, wird einen Ubuntu-spezifischen Schlüssel enthalten, der von Canonical generiert wurde.
  • Auf den ausgelieferten CDs, die ohne Hardware kommen, wird man ebenfalls auf einen Microsoft-Schlüssel setzen.
  • Ubuntu Bootloader-Abbilder, die durch die Ubuntu-Archive online verfügbar sind, werden ebenfalls Ubuntus eigenes Zertifikat tragen.

Auch hier gebe es Probleme, wie bei Fedora – der Microsoft-Schlüssel. Genau wie bei Fedora gelte auch, das Anwender den eigenen Schlüssel oder den Ubuntu-Schlüssel einsetzen können – sofern Secure Boot richtig implementiert ist.

Das Hauptproblem mit dem Ubuntu-Ansatz habe man, dass sich Canonical GRUB 2 nicht mehr einsetzen möchte. Die Firma fürchtet, mit der GPLv3 in Konflikt zu kommen und im schlimmsten Fall den privaten Schlüssel herausgeben müssen.

Diese Furcht ist laut Aussage der FSF komplett unbegründete und Canonical würde die GPLv3 nicht richtig verstehen. Man könne sich kein Szenario vorstellen, bei dem Ubuntu gezwungen wäre, den privaten Schlüssel zu enthüllen, weil ein Drittanbieter oder Distributor Ubuntu auf einer Secure-Boot-Maschine ausgeliefert hat. In so einem Fall sei der Computer-Distributor und nicht Canonical für die Herausgabe der entsprechenden Informationen zuständig, um modifizierte Versionen der Software laufen zu lassen.

Ebenso sei die Bedrohung durch Secure Boot mit der Schwächung der Bootloader-Lizenz zu bekämpfen, ein Schritt zurück. Anstelle die Hersteller zu zwingen, dass Secure Boot “richtig” implementiert wird, hätte Ubuntu eine Weg gewählt, der explizit das “Eingeschränkte Starten” erlaubt.

Die FSF zeigt sich nicht darüber erfreut, dass sich niemand von Canonical mit den Befürchtungen gemeldet hat. Schließlich habe man die Lizenz in Frage gestellt, von der die FSF Besitzer ist und ebenfalls sei halte man auch Copyright an GRUB 2.

Dennoch sei es nicht zu spät noch einzulenken und die Free Software Foundation fordert Canonical auf, die Entscheidung zurückzunehmen. Die FSF bietet Hilfe an, um die Lizenzbefürchtunge aufzuarbeiten und aus der Welt zu schaffen. Man hofft, dass Canonical den Fedora-Weg einschlägt und Anwender dazu ermutigt, eigene Schlüssel zu erstellen.

Wie geht es weiter?

Zunächst einmal will sich die FSF einsetzen, dass sich die Wahrheit über Restricted Boot weiter verbreitet. Es hätte bereits 31.000 Menschen und 25 organisationen unterschrieben und werben dafür, keinen Computer zu kaufen, der das Installieren eines freien Betriebssystems unmöglich macht. Man freue sich, Debian GNU/Linux als offiziellen Unterstützer für diese Kampagne gewonnen zu haben. Jeder kann hier unterschreiben.

Weiterhin wolle man gegen Microsoft vorgehen, um den Secure-Boot-Zwang auf ARM-Geräten (Smartphones und Tablets) zu unterbinden. Außerdem werde man Microsoft mit Argusaugen beobachten, ob die Firma den Zwang auf andere Geräte ausweiten möchte.

Ebenso wolle man mit Herstellern zusammenarbeiten und Anwendern so gut wie möglich erklären, wie man mit Secure Boot umgeht, es deaktiviert, eigene Schlüssel erstellt und so weiter.

Ebenso wolle man mit Fragen und Antworten bezüglich Bedenken im Zusammenhang mit der GPLv3 zur Verfügung stehen. Ebenso will die FSF weiter mit Firmen wie Lemote, Freedom Included, ZaReason, ThinkPenguin, Los Alamos Computers, Garlach44 und InaTux zusammenarbeiten, um Computer mit vorinstallierten und komplett freien Linux-Distributionen auszuliefern. Ebenso wolle man Anwender aufklären, welche Rechner am kompatiblesten mit freier Software sind und auch Menschen über Restricted Boot aufklären. Viele dieser Informationen befinden sich auf http://h-node.org.

Persönlich finde ich es weiterhin einen Wahnsinn, dass die Hardware-Hersteller das mitmachen, was Microsoft ihnen vorschreibt. Man stelle sich nur einmal vor, dass alle gleichzeitig “Nee, Microsoft – so nicht!” sagen würden. Und dann? Stell Dir vor Windows 8 kommt raus und keiner geht hin … wer würde wohl dann einlenken?

Auf der einen Seite wird es nun die Leute geben “Mei, die FSF übertreibt mal wieder wahnsinnig” – die andere Seite wird mit der FSF marschieren. Ich bin auf Seite der FSF, weil man so ein diktatorisches Verhalten von Microsoft einfach nicht tolerieren darf. Für mich schon lange eine Sache der Regulierungsbehörden und gleich noch mal eine saftige Strafe für den Konzern aus Redmond.




 Alle Kommentare als Feed abonnieren

6 Kommentare zu “UEFI Secure Boot: Nun meldet sich die Free Software Foundation (FSF) zu Wort und ist nicht zimperlich”

  1. FERNmann says:

    Sehe ich genauso. Die Installation von Linux auf einem Rechner ist für viele Nutzer ohnehin schon eine schwere Aufgabe, UEFI Secure Boot wäre da ein Showstopper. Mir ist auch nicht ganz klar, welchen Sicherheitsgewinn das bringen soll, wenn sich jeder für 99 US$ einen Schlüssel erzeugen lassen kann, dessen signierter Code dann auf allen Rechnern mit UEFI Secure Boot läuft. Können doch auch die Malware-Autoren machen, entweder sie erstellen selber einen Schlüssel oder nehmen einen geleakten. Oder man findet eine Sicherheitslücke in UEFI Secure Boot, Apple verwendet auf dem iPhone etwas ähnliches, und da war es mal möglich, durch eine Sicherheitslücke in Safari unsignierten Code ausführen und dadurch das Gerät zu jailbreaken. Ich denke, die wollen nur andere Systeme aussperren (Microsoft) und Geld mit Zertifikaten verdienen (VeriSign).

  2. PhotonX says:

    Microsoft hat sich angeguckt wie in den USA Politik funktioniert und daraus gelernt. Mal schauen wie es mit Secure Boot weitergeht und ob der Trick auch in der IT Fuß fassen wird...

  3. asdf says:

    Microsfts Windows ist natürlich inzwischen super sicher, und nun darf M$ mit viel Hingabe auch noch die letzen kleinen Sicherheitslückchen wie eben das Booten eines unsignierten OS ausmerzen, schließlich haben die ja sonst keine Sorgen bezüglich Sicherheit ihres Systems...

    Schon ganz schön lächerlich der Deckmantel "Sicherheit"...

  4. Gerald says:

    Warum die HW-Hersteller da mitspielen? Die Frage ist doch so was von einfach zu beantworten!

    Nehmen wir an, eine Windows-Lizenz kostet normal 100 Euro. Der HW-Hersteller bestellt 50.000 OEM-Lizenzen um lediglich 50 Euro bei Microsoft, schlägt aber 70 Euro für die Windows-Lizenz auf jeden Computer auf. Das ist 1 Million Euro leicht verdientes Geld!

    Und das ist genau der Hauptgrund, warum Linux so selten vorinstalliert ist. Die Arbeit ist nämlich dieselbe (nein, ein "nacktes" Windows funktioniert garantiert nicht wie gewünscht auf der entsprechenden HW, oft muss der Hersteller für die Vorinstallationen eigens angepasste Treiber herstellen [lassen]), es gibt aber kein Geld dafür. Denn Linux ist gratis, und niemand würde 20 Euro als Abgeltung für den Installationsaufwand bezahlen wollen.

    • killx says:

      Was denn für ein Aufwand. Bei linux kann man einfach eine Kickstartinstallation basteln die man dann auf alle Geräte aufspielen kann. Somit hat man direkt alles an Standard Software drauf was man gerne hätte. Der Aufwand tendiert also bei Linux gegen 0 meiner meinung nach. Man sollte im nachhinein lediglich nochmals die Logs prüfen.
      Klar könnte man nun sagen das man bei Windows doch auch einfach über ein Image machen kann, jetzt probier das aber mal auf unterschiedlicher Hardware 😉

  5. walther zabel says:

    Das eigentliche Problem ist doch die UEFI-Norm die einen eigenen Mikrocontroller vorscheibt, der unabhängig von der Haupt-Cpu und dem eigentlichen Betriebssystem Zugriff auf alle angeschlossen Kompenenten des System hat (Netzwerk, Ram, Massenspeicher usw.). Das Betriebssystem kann ihn nicht kontrollieren und was das heisst, kann sich jeder ausmahlen. Die meisten die über dieses Thema schreiben haben keine Ahnung, wie tiefgreifend das Problem wirklich ist.