Startseite » News-Ecke » News zu Linux im Allgemeinen » Zwei Wege zu UEFI Secure Boot mit Linux (Derzeitiger Stand der Entwicklung betreffend UEFI Secure Boot)
| Zwei Wege zu UEFI Secure Boot mit Linux [Beitrag #806] |
Mo, 11 Februar 2013 12:39  |
 |
Na'vi
Beiträge: 422
Registriert: März 2010
|
Senior Member |
|
|
Der derzeitige Stand der Entwicklung bei Secure Boot bietet zwei Bootloader mit zwei verschiedenen Konzepten. Matthew Garrett möchte beide vereinen.
Matthew Garrett beschäftigt sich schon lange mit UEFI und Secure Boot. Eine der beiden oben genannte Lösungen namens Shim stammt von ihm. Die andere ist der »LF-Loader« der Linux Foundation und wurde von James Bottomley, Kernel-Entwickler und Mitglied des Technical Advisory Board der Linux Foundation geschrieben. Die beiden Herangehensweisen unterscheiden sich darin, dass Shim auf signierten Schlüsseln beruht, während der LF-Loader auf kryptografische Hashfunktionen setzt. Laut Garrett ist der größte Nachteil des LF-Loaders, dass, wenn eine Distribution eine neue Version ihres Bootloaders oder einen neuen Kernel anbietet, ein neuer Hashwert dafür in die Liste der erlaubten Binärdateien eingetragen werden muss. Da dieser Vorgang physische Anwesenheit bedingt, sieht Garrett dies als ernsthaften Hinderungsgrund gegen den Einsatz. Für Distributionen, die ihren Nutzern häufig neue Kernel zum Testen anbieten, ist dieser Weg nicht sehr attraktiv.
Der LF-Loader besteht aus den zwei Dateien PreLoader.efi und HashTool.efi und nutzt beispielsweise Gummiboot oder efilinux als Bootloader. Die beiden Dateien erstellen lediglich eine Basis-Bootumgebung. Zum Testen hat Bottomley ein bootbares Image für einen USB-Stick bereitgestellt, das eine EFI-Shell bietet und sich ebenfalls beim Booten auf Gummiboot verlässt. In den Kommentaren zur Vorstellung des LF-Loader und des USB-Stick-Image wird Kritik laut, diese Methode sei derzeit nur für sehr erfahrene Linux-Nutzer gangbar.
Garretts Lösung Shim wird mittlerweile von Fedora, OpenSUSE und Ubuntu eingesetzt. Er selbst sieht den Hauptnachteil seiner Lösung in der Duplizierung von großen Teilen des UEFI-Firmware-Codes, da die UEFI-Spezifikation keine Möglichkeit vorsieht, zusätzliche Authentifikations-Mechanismen hinzuzufügen. Garrett versucht nun, die beiden Wege zum gleichen Ziel in einem Werkzeug zu vereinen, indem er die Nutzeroberfläche und die Sicherheitsfunktionen des LF-Loader in Shim integriert. Wenn die initialen Probleme gelöst sind, wird es bald eine vereinte Lösung mit dem Besten beider Ansätze geben. Damit könnte in absehbarer Zeit das Booten und Installieren von Linux mit Secure Boot so einfach werden, wie eine CD in ein Laufwerk einlegen, so die Hoffnung Bottomleys.
Quelle: Pro-Linux
|
|
|
|
| UEFI Secure Boot: Schlüssel-Signierung vorerst nicht im Linux-Kernel [Beitrag #836 ist eine Antwort auf Beitrag #806] |
Di, 26 Februar 2013 12:39  |
|
Na'vi
Beiträge: 422
Registriert: März 2010
|
Senior Member |
|
|
Linus Torvalds hat einen Patch des Red Hat-Entwicklers David Howells abgelehnt, der einem Kernel, der unter dem UEFI Secure Boot-Modus läuft, die Möglichkeit gibt, neue Schlüssel hinzuzufügen.
Red Hat und die Linux Foundation hatten in der Vergangenheit immer wieder betont, dass UEFI Secure Boot durchaus nützlich sei, auch wenn es einige Schwierigkeiten bereite, beispielsweise die, dass von Microsoft signierter Code der einzige ist, der die Chance hat, von allen Systemen ohne weitere Einstellungen akzeptiert zu werden, und das Verfahren, nach dem Microsoft solche Signaturen ausstellt, komplex ist.
Dass die maßgeblichen Kernel-Entwickler dies ganz anders sehen, wurde noch einmal klar, als David Howells von Red Hat einen Patch vorstellte, der einem Kernel, der unter dem UEFI Secure Boot-Modus läuft, die Möglichkeit gibt, neue Schlüssel hinzuzufügen. Wie Howells schreibt, darf in diesem Modus ein Schlüssel nur hinzugefügt werden, wenn er mit einem bereits bekannten signiert ist. Dies funktioniert bereits mit X.509-Zertifikaten, doch Microsoft signiert nur unter EFI ausführbare Dateien im PE-Format. Daher kamen die Entwickler auf die Idee, einen X.509-Schlüssel in einer PE-Datei unterzubringen und diese signieren zu lassen. Der Patch befasst sich größtenteils damit, den Schlüssel wieder aus der PE-Datei zu extrahieren.
Torvalds lehnte den Patch ab, solange er nicht ausgiebig diskutiert worden sei. Die Schnittstellen, die er erzeugt, seien dumm und übermäßig komplex, und das alles aus völlig schwachsinnigen Gründen. Auf den Einwurf von Matthew Garrett, dass es anders als mit PE-Dateien nicht zu machen sei, antwortete Torvalds: »Das ist hier kein Schwanzlutsch-Wettbewerb«. Torvalds akzeptiert auch Dinge, die ihn selbst nicht interessieren, so hat er auch grundsätzlich nichts gegen das Parsen von PE-Dateien. Nur könne das in einem normalen Anwenderprogramm durchgeführt werden und habe daher nichts im Kernel zu suchen. Im Kernel gebe es bereits X.509, und das sei der Standard für Signaturen.
Torvalds vertrat weiter die Ansicht, dass Red Hat sowieso die proprietären Treiber von AMD und Nvidia signieren werde, was alles mit dem Kernel nichts zu tun habe. Daraufhin stellte Peter Jones von Red Hat klar, dass Red Hat keine Signaturen durchführen werde.
In der weiteren Diskussion wurde klar, dass auch weitere Entwickler UEFI Secure Boot kritisch sehen. Theodore Ts'o bezeichnete das komplette System als geisteskrank. Andere sehen noch zahlreiche technische Probleme, beispielsweise bei der Frage, wie das Zurückziehen von Signaturen korrekt gehandhabt werden kann. Auch besteht noch keine Einigkeit darüber, wie strikt der Kernel den Secure Boot-Modus durchsetzen soll. Die Spannweite reicht dabei von Red Hats Ansicht, dass der Kernel keinerlei unsignierte Module nachladen dürfe, bis zu der Meinung, dass der Systemverwalter nach dem Booten des Kernels freie Hand haben solle. Die Ansicht von Red Hat, vertreten von Garrett, wird dabei von der Befürchtung getrieben, dass Microsoft die Signatur für den Bootloader zurückziehen könnte, sobald über diesen eine infizierte Version von Windows in Umlauf gelangt. Torvalds und andere sehen dies als unrealistisch an.
Die resultierende Diskussion, die von Greg Kroah-Hartman angestoßen wurde, resultierte in einem weiteren Ausbruch von Torvalds in Richtung Garrett: »Hör auf, darüber zu diskutieren, was MS will. Das ist uns egal. Wir kümmern uns um die Anwender. [...] Das einzige, was zählt, ist, was unsere Benutzer von uns wollen, und ihre Rechte zu schützen.«
Quelle: Pro-Linux
|
|
|
|
| UEFI-Secure-Boot: Garrett ordnet die Fakten [Beitrag #843 ist eine Antwort auf Beitrag #836] |
Fr, 01 März 2013 12:34 |
|
Na'vi
Beiträge: 422
Registriert: März 2010
|
Senior Member |
|
|
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.
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«.
Quelle: Pro-Linux
|
|
|
|
Gehe zum Forum:
aktuelle Zeit: Mi Dez 04 09:04:33 CET 2024
Insgesamt benötigte Zeit, um die Seite zu erzeugen: 0.00226 Sekunden
|
Linux Forum Schweiz
Suche
Hilfe
Mitglieder
Registrieren
Anmelden
Startseite
