Software::Kernel
UEFI-Secure-Boot: Garrett ordnet die Fakten
Nachdem sich Linus Torvalds zuletzt lautstark gegen einen Patch des Red Hat-Entwicklers David Howells ausgesprochen hatte, der einem im UEFI-Secure-Boot-Modus laufenden Kernel die Möglichkeit zum Hinzufügen neuer Schlüssel einräumt, scheinen sich die Gemüter wieder beruhigt zu haben und Matthew Garrett fasst den gegenwärtigen Status der Diskussion noch einmal zusammen.
Michael Kofler
UEFI-Bootmenü
Laut Garrett gelingt das Starten einer Linux-Distribution mit aktiviertem UEFI-Secure-Boot derzeit relativ problemlos, wenn der Anwender einen digital signierten Bootloader wie den von Garrett entwickelten Shim oder den der Linux Foundation benutzt. Sitzt der Endanwender physisch vor dem Rechner, kann er einfach seinen Schlüssel hinzufügen und muss sich keine weiteren Gedanken um Microsoft machen.
Garrett stellt dann aber die Frage in den Raum, wie eine Distribution starten könne, ohne dass der Anwender einen Schlüssel installiert, egal aus welchem Grund. Szenarien dafür seien durchaus vorstellbar, etwa beim Booten vom Netzwerk oder einfach nur aus Bequemlichkeit. Immerhin ließen sich solche Systeme theoretisch auch nutzen, eine Windows-Installation anzugreifen. Zwar sei so etwa bisher noch nicht passiert, Microsoft könne aber durchaus auf die Idee kommen, einen solchen Schlüssel auf eine schwarze Liste setzen, sodass die Distribution auf Systemen mit UEFI-Secure-Boot nicht mehr starte.
Auf Howells Patch Bezug nehmend ist Garrett der Ansicht, man könne das von ihm skizzierte Szenario verhindern, indem man etwa den Kernel dazu bringe, sämtliche Module zu signieren. Das sei für die in den Distributionen enthaltenen Module einfach realisierbar, allerdings nicht für Module von Drittanbietern. Hier bieten sich nach Garrets Ansicht drei Möglichkeiten an, einem solchen Szenario zu begegnen: Keine Module von Drittanbietern unterstützen, Signieren durch die Distribution und Signieren durch den Hersteller.
Laut Garrett kommt ersteres kaum in Betracht, weil es die Anwender verärgere. Signieren durch die Distribution verursache möglicherweise Lizenz-Probleme. Ignoriere man diese, müsse irgend jemand entscheiden, welche Treiber überhaupt signiert würden. Es sei nicht einfach und mitunter auch teuer, die Identität von jemandem zu verifizieren. Mit der letzten Möglichkeit würde die Verantwortung schlicht in andere Hände gelegt, doch auch diesen müsse man vertrauen können.
Eine Alternative könne darin bestehen, dass man von Anfang an Schlüsseln vertraue, die mit einem vertrauenswürdigen Schlüssel signiert wurden. So ein Schlüssel existiere zwar, doch der gehöre Microsoft. Hierbei sei aber nicht klar, ob der Kernel ein Modul passieren lassen soll, das mit dem gleichen Schlüssel signiert wurde wie der Bootloader. Garrett weist darauf hin, dass der Patch nämlich nicht den Schlüsselsatz ändert, dem der Kernel sowieso schon vertraut.
Garrett fasst in seinem Blog auch Torvalds' Ansicht zu der Idee zusammen. Laut Torvalds würde der Kernel dadurch komplexer, denn man bräuchte einen Parser für das beschriebene Szenario. Es gäbe zudem bereits eine solche Schnittstelle, allerdings für X.509-Zertifikate, die Microsoft nicht signiert. Leider gibt es auch keine Möglichkeit, PE/COFF-Signaturen in eine X.509-Signatur umzuwandeln. Irgend jemand müsste dann wieder die Schlüssel signieren. Wünschenswert wäre ein automatisches Verfahren, das PE/COFF-Zertifkate auf eine gültige Microsoft-Signatur überprüft, den Schlüssel extrahiert und daraus wieder ein X.509-Zertifikat macht. Das würde dann auch neuen Code im Kernel überflüssig machen. Der »dritte Mann« könnte dann zum Beispiel die Linux Foundation sein. Allerdings gibt es Stimmen in der Linux Foundation, die ein Signieren von Modulen für unnötig halten. Immerhin bestünde bei der Linux Foundation kein Risiko, dass Microsoft die Signatur auf seine schwarze Liste setzt.
Laut Garrett könne die gegenwärtige Situation auch dazu führen, dass die Distributionen den Patch eigenständig einführen. Einige Distributions-Hersteller würden es aber sicher auch ablehnen, zu viel Vertrauen in Microsoft zu legen. Garrett betont aber auch, dass man, wenn die Firmware Microsoft vertraut, ohnehin Microsoft vertraut. Garrett glaubt, dass wahrscheinlich so lange gar nichts passiert, bis ein Angreifer ein signiertes Linux-System für einen Angriff auf Windows benutzt und malt abschließend wieder das Gespenst von Microsofts Antwort an die Wand.
Aus diesem Blickwinkel ist auch Torvalds' Haltung nachvollziehbar, Microsoft schlicht und einfach zu ignorieren. Das Szenario, ein Windows aus einem signierten Linux-System anzugreifen, scheint doch sehr weit hergeholt. Da dazu physischer Zugang zum Rechner erforderlich ist, könnte ein Angreifer auch gleich eine Distribution basteln, die das parallel installierte Windows mit einem Rootkit »versorgt«.
){kind=small}
