UEFI Secure Boot Saga: Nun meldet sich Red Hats Vize-Präsident zu Wort

12 Juni 2012 6 Kommentare Autor: Jürgen (jdo)

Red Hat Logo 150x150Red Hats Matthew Garret hatte ja verraten, wie man bei Fedora 18 das UEFI Secure Boot Problem beheben möchte. Dabei hat man sich vorerst zu einem Pakt mit dem Teufel entschieden und will den Schlüssel von der Microsoft-Zertifikats-Stelle ausstellen lassen. Das kostet dann einmalig 99 US-Dollar Gebühr und man kann sich so viele Schlüssel geben lassen, wie man möchte.

Das Ganze wird so funktionieren, dass man einen Mini-Bootloader zertifizieren wird, der dann den Haupt-Bootloader initiiert. Eine andere Möglichkeit ist natürlich, Secure Boot im Bios zu deaktivieren.

Mit dieser Entscheidung sind aber nicht alle glücklich. Also wenn man sich so durch das Netz wühlt, sind eigentlich die meisten Linuxer davon gar nicht begeistert. Das Credo ist eindeutig: Microsoft den Boot-Prozess zu überlassen, wird für eine unglaublich schlechte Idee gehalten.

Ebenso kommen immer wieder Argumente, dass Microsoft sein Quasi-Monopol ausnutze und man Red Hat lieber klagen als zahlen sehen würde. Viele Anwender zeigen sich einfach enttäuscht. Deswegen hat sich letzte Woche sogar der Vize-Präsident, Tim Burke, von Red Hat zu der Sache geäußert. Somit ist das Thema wohl offiziell Chefsache geworden.

Er selbst findet es zunächst richtig, den Boot-Prozess so früh wie möglich abzusichern. Das sei wichtig, weil es in der jungen Vergangenheit immer wieder Angriffe darauf gab. Schadcode, der den Bootcode verändert hat, riss Sicherheitslücken im Betriebssystem auf.

Genau dies würde UEFI Secure Boot eben verhindern. Red Hat habe viele Monate mit der Industrie, der Linux Foundation, Microsoft und Hardware-Partnern zusammengearbeitet, um einen Mechanismus für UEFI Secure Boot zu entwickeln, der für den Anwender einfach zu verwenden ist. Red Hats Ziel sei dabei, dem Anwender alle Freiheiten zu gewähren – und das nicht nur für Fedora und Red Hat. Wie Garrett in seinem letzten Artikel anmerkte, sei es unfair, wenn Red Hat seine besseren Beziehungen zu Hardware-Herstellern ausspiele und dafür viele kleinere Linux-Distributionen außen vor lasse. Das sei nicht im Sinne des Erfinders und auch eingens gebaute Linux-Distributionen sollen eine Chance bekommen, neuere Hardware mit UEFI Secure Boot noch starten zu können.

Wer also zum Beispiel eine Distribution auf Fedora-Basis ausgeben möchte, müsste dann die einmalige Boot-Steuer von 99 US-Dollar bezahlen. Anwender, die selbst am installierten System schrauben möchten, können einen vertrauenswürdigen Schlüssel kostenlos registrieren. Wer das nicht möchte, könne immer noch UEFI Secure Boot im BIOS deaktivieren – zumindest auf dem PC, bei ARM macht Microsoft den Apple und wer Windows ausliefern möchte, darf Secure Boot nicht deaktivieren.

Tim Burke sagt auch, dass die Verschwörungs-Theoretiker hier etwas zu kreativ waren. Red Hat würde dieses Modell nicht akzeptieren, wenn man nicht glaube, dass dies alles mit rechten Dingen zugehe und eine gute Initiative ist.

Voraussichtlich ist Fedora 18 die erste Distribution aus dem eigenen Haus, die mit UEFI Secure Boot umgehen kann. Basierend auf den Erfahrungen wird man diese dann in Red Hat Enterprise Linux einbinden.

So weit Tim Burke, der das Modell verteidigt. Wenn ich mir die Aussagen von Matthew Garrett und Tim Burke so durchlese, ist das fast wie ein Widerspruch. Burke redet das Thema gut und es sei eine gute Sache, während Garrett vom geringsten Übel spricht, mit dem er zwa nicht glücklich ist, aber es derzeit einfach keine Alternative gibt.

Ich finde es dennoch falsch, Red Hat den Schwarzen Peter in die Schuhe zu schieben. Schließlich hat man sich Gedanken gemacht, wie man eben mit dem geringstmöglichen Aufwand aus dem Microsoft-Gefängnis Freigang erhält. Die eigentlichen Verräter sind die Hardware-Hersteller. Die sind vor Microsoft eingeknickt. Wer UEFI Secure Boot nicht per Standard aktiviert, darf nämlich kein Windows-8-Label tragen. Nur ein Wunschtraum: Was hätte Microsoft denn gemacht, wenn hier alle Hardware-Hersteller „Nö, machen wir nicht“ gesagt hätten? Amazon?

Du kannst gerne Deinen Senf zu diesem Beitrag geben: Hier geht es zu den Kommentaren




Schreiben macht durstig! Eine kleine Erfrischung kann daher nie schaden. Wem dieser freie Artikel gefallen hat, der darf mir gerne einen frisch gezapften Hopfen-Tee ausgeben (Paypal - der Spenden-Knopf
oder bitcoin - Adresse: 1NacVNwcLLePUVv8uSafu5Ykdwh8QyDfgK). Ich freue mich über jede noch so kleine Spende. Vielen Dank und Prost!
 Alle Kommentare als Feed abonnieren

6 Kommentare zu “UEFI Secure Boot Saga: Nun meldet sich Red Hats Vize-Präsident zu Wort”

  1. nico sagt:

    Ich finde die Initiative von RedHat gut. Ich finde es vor allem gut, dass sie sich für eien Lösung entschieden haben mit der auch andere Distributionen klarkommen können.
    Es scheint mir als wären sie eine der wenigen aktuellen Distributionen, die nicht nur auf ihr eigenes Wohl aus sind, sondern möglichst allen Distributionen etwas "gutes" tun wollen.
    Ich seh kein Problem darin, die Zertifikate von Microsoft zu kaufen, wo sie herkommen ist doch eigentlich egal, hauptsache sie funktionieren.

    • jdo sagt:

      Ich finde es gefährlich, die Zertifikats-Zentrale an einen Software-Hersteller zu geben, der bekanntlich kein Wohltäter ist und vor allem die Hardware-Industrie diktiert.

      Auch wenn das System funktioniert und man Microsoft mit den 99 US-Dollar für den Aufwand entschädigt, müssen trotzdem die Regulierungsbehörden auf der Matte stehen und denen klar machen, dass MS beim geringsten "Schluckauf" eine auf den Deckel bekommt.

  2. Daniel sagt:

    Zumal die 99$ wohl nicht an Microsoft, sondern eine Zertifizierungsstelle (Verisign?) gehen

  3. paladium sagt:

    fragen an die experten:

    wird der signierte minibootloader auch auf den zu secureboot verpflichteten arm-geraeten laufen - bzw. zur verfuegung gestellt?

    wie lange werden zertifikate fuer 99$ garantiert erhaeltlich sein?

    wenn mehrere stellen gueltige signaturen erstellen koennen, warum nicht auch zB. kernel.org oder redhat selber?

    welche sicherheit bietet ein unabschaltbares secureboot, wenn man mittels eines signierten minibootloaders letztlich doch jedes beliebige system booten kann?

    wuerde mich freuen, wenn die eine oder andere frage beantwortet werden koente. vielen dank dafuer.

    gruesse.

    • jdo sagt:

      Hi,

      einige der Fragen kann ich Dir beantworten - man möge mich korrigieren:

      - So weit ich weiß, ist die 99$-Gebühr einmalig und man kann sich so viele Zertifikate ausstellen lassen, wie man möchte - die Gebühr ist wohl Firmen- oder Produkt-abhängig.

      - Microsoft deswegen, weil man es in der Zeit nicht geschafft hätte, das alles unter einen Hut zu bringen. In Blog-Eintrag von Garrett ist zu lesen, dass das mit sehr hohen Kosten verbunden wäre und sich eine zentrale Stelle mit allen Hardware-Herstellern in Verbindung hätte sitzen müssen. Microsoft tut das sowieso und deswegen wird man MS als Zertifizierungs-Dienst verwenden.

      - Ob der Mini-Bootloader auf ARM-Geräten läuft, weiß ich nicht.

      - das mit der Sicherheit ist ja vielen ein Dorn im Auge - deswegen sagen einige, dass auch Secure Boot nicht soooo sicher ist, wie Microsoft das zu verkaufen versucht. Allerdings müssen Bösewichte an den privaten Schlüssel einer Institution kommen, beziehungsweise sich selbst einen besorgen - also so weit ich das verstanden habe ...

  4. Gerald sagt:

    Ich vertraue lieber mir und Opensource als Microsoft und einer proprietären BIOS-Implementierung, die ebenso Lücken enthalten kann (ad Tim Burke).

    Wenn ich den Bootloader absichern wollte, würde ich ihn einfach nach frischer Installation per dd wegsichern und dann per crontab z.B. jede Stunde prüfen. Hat sich was geändert - Tschüss mit ü - drüber mit der Sicherung und laut schreien (per Mail, als Popup auf den Desktop, in die Syslog oder wohin auch immer).

    10 Mal besser als auf die UEFI-Implementierung des Mainboardherstellers vertrauen, die ja nie und nimmer Fehler enthält. Deswegen gibt es ja auch keine Mainboard mit 20+ BIOS-Upgrades, gell...

Antworten