orcharhino und SecureBoot
Heutzutage ist Sicherheit in der IT ein Muss. Obwohl orcharhino hauptsächlich für das Lifecycle Management von Servern entwickelt wurde, benötigen immer mehr Kunden die unbeaufsichtigte Provisionierung und das Lifecycle Management von Laptopsystemen. Dies bedeutet oft, dass SecureBoot aktiviert werden soll.
In diesem Artikel möchten wir SecureBoot kurz vorstellen und erklären, warum es schwierig ist, die Welten von orcharhinos unbeaufsichtigter Provisionierung und SecureBoot zu kombinieren.
Was ist SecureBoot?
SecureBoot ist Teil des Unified Extensible Firmware Interface (UEFI). Dabei handelt es sich um eine Erweiterung des Extensible Firmware Interface (EFI), das erstmals 1998 für Intels Itanium-64-Bit-Architektur entwickelt wurde [1]. UEFI ist die zentrale Schnittstelle zwischen dem Betriebssystem (OS) und der Plattform-Firmware. Es wurde als BIOS-Nachfolger eingeführt und hat sich als Standard für die heutigen Hardwareplattformen durchgesetzt.
SecureBoot stellt die Authentizität der Software, die von der Firmware geladen und ausgeführt wird, mit Hilfe von kryptografischen Mechanismen sicher. Das vertrauenswürdige Linux-System stellt nur das letzte Glied in einer Kette von Softwarekomponenten dar. Eine typische Vertrauenskette besteht aus Firmware, Bootloader, Linux-Kernel und Kernel-Modulen.
Die Verifizierung erfolgt mit denselben grundlegenden Konzepten, die wir von Websitezertifikaten kennen, die Paare von öffentlichen und privaten Schlüsseln verwenden. Mit dem privaten Schlüssel wird ein Hash des Datenobjekts verschlüsselt: die Signatur. Diese wird an das Datenobjekt angehängt. Zur Überprüfung auf der Zielhardware entschlüsselt UEFI die Signatur mit dem öffentlichen Schlüssel, der in der Firmware vorhanden sein muss (siehe später). Das Ergebnis ist wieder ein Hash. Wenn der entschlüsselte Signatur-Hash und der selbst berechnete Hash des Datenobjekts übereinstimmen, ist die Authentizität bewiesen. Das Datenobjekt wurde von der Instanz, die den öffentlichen Schlüssel bereitgestellt hat, mit dem entsprechenden privaten Schlüssel signiert. Wer einen privaten Schlüssel besitzt, wird als Authority bezeichnet.
Übrigens können Sie selbst überprüfen, ob Ihr System mit aktiviertem SecureBoot läuft, indem Sie mokutil --sb-state ausführen.
Wie es funktioniert
Normalerweise ist die Firmware Teil des Mainboards. Auf dem integrierten Speicher, auch als nichtflüchtiger Direktzugriffsspeicher bzw. Non-Volatile Random Access Memory (NVRAM) bezeichnet, befinden sich mehrere Signaturdatenbanken. Die gespeicherten Daten bestehen in der Regel aus Zertifikaten mit öffentlichen Schlüsseln, Signaturen oder Hashes von Binärdateien. Das Betriebssystem kann auf diesen Speicher nicht ohne Weiteres schreibend zugreifen.
Zu den Signaturdatenbanken gehören die Platform Key (PK) Database, die Key Exchange Key (KEK) Database, eine Signature Database (db) und eine Forbidden Signature Database (dbx). Die PK Database enthält normalerweise das OEM-Zertifikat [2]. Dieses wird benötigt, um Objekte in der KEK Database zu aktualisieren. KEK wiederum verifiziert Aktualisierungen in db und dbx. Standardmäßig enthält db ein Microsoft-Zertifikat, das viele Mainboard-Hersteller bereits mit ausliefern und das von Microsoft signierte Binärdateien verifizieren kann. Infolgedessen sind Mainboard OEMs, ihre Vertretungen und Microsoft die einzigen vertrauenswürdigen Zertifizierungsstellen (Certificate Authorities, CAs) in einer solchen Standardkonfiguration.
Und was ist mit Linux? Die wichtigsten Linux-Distributionen nutzen einen Signierungsprozess, bei dem sie eine von Microsoft signierte EFI-Binärdatei, genannt shim [4], erhalten. shim ist die allererste Binärdatei, die von der Firmware geladen und ausgeführt wird. Das shim jeder Distribution ist mit einer zusätzlichen Vendor Database ausgestattet, die das eigene Zertifikat der Distribution enthält. shim lädt, verifiziert und führt den Bootloader (z.B. GRUB2) aus, der dann vom Distributor signiert ist. Der Bootloader lädt schließlich den distributionssignierten Linux-Kernel, ruft shim zur Verifizierung auf und startet ihn, wenn die Verifizierung erfolgreich ist.
Die Verwendung einer bekannten Linux-Distribution mit entsprechendem Kernel und Kernel-Modulen, die über das offizielle Paket-Repository installiert und aktualisiert werden, funktioniert recht gut. Übrigens wird shim immer ausgeführt, auch wenn SecureBoot deaktiviert ist. Es lädt einfach den Bootloader und führt ihn aus, ohne dass eine Überprüfung stattfindet.
Außer Kontrolle?
Vielleicht denken Sie sich jetzt: „Moment mal, kann ich meine eigene Software überhaupt noch auf meiner eigenen Hardware ausführen?“ Dies wirft die Frage auf, ob es eine gute Idee ist, Microsoft als einzige CA darüber entscheiden zu lassen, ob ein System booten darf oder nicht. Neben der Möglichkeit, SecureBoot zu deaktivieren, gibt es noch zwei weitere Optionen:
Erstens erlauben die meisten Firmwares den Usern, in einen Anpassungs- oder Setupmodus zu wechseln, in dem selbst erstellte Zertifikate für PK, KEK und db installiert werden können. Dies bedeutet, dass der Bootloader, der Kernel und alle Kernel-Module bei jeder Aktualisierung signiert werden müssen. Auch Komponenten, die bereits von einem Distributor signiert wurden, müssen mit dem entsprechenden eigenen Schlüssel neu signiert werden.
Zweitens gibt es eine Einrichtung namens Machine Owner Key (MOK) Manager. Mit dieser von der Distribution signierten EFI-Binärdatei können User interaktiv zusätzliche öffentliche Schlüssel beim Booten dauerhaft im NVRAM hinzufügen oder entfernen. Mit dem MOK kann man zum Beispiel ein selbst erstelltes Zertifikat für einen selbst kompilierten Kernel vor einem Neustart importieren. Nach dem Reboot startet shim den MOK Manager, wo die Schlüsselregistrierung von Usern interaktiv bestätigt werden muss.
Als Kompromiss zwischen Aufwand und Sicherheit wird der zweite Weg meist von einzelnen End-Usern und vielen Unternehmen gewählt. Beide Wege erfordern die physische Anwesenheit der User vor dem System, da grundlegende Änderungen bezogen auf SecureBoot ohne Interaktion nicht möglich sind.
Was gewinnen wir an Sicherheit?
Wenn SecureBoot aktiviert ist, können Sie zumindest bis zu einem gewissen Grad sicher sein, dass Sie einen vertrauenswürdigen Linux-Kernel haben. Das Risiko, dass sich Bootkits und Rootkits einnisten, wird minimiert. Typische Angriffsvektoren, wie z.B. das Ersetzen eines bösartigen Linux-Kernels aus der Ferne, können verhindert werden. User können Komponenten mit bekannten Sicherheitslücken über dbx-Einträge vom Booten ausschließen.
Dennoch bleibt das Risiko bestehen, dass User durch Social Engineering dazu gebracht werden, bösartige Schlüssel einzutragen; vorhandene Schlüssel können gestohlen oder kompromittiert werden. Darüber hinaus ist das initramfs, das vom Linux-Kernel ganz zu Beginn des Bootvorgangs ausgeführt wird und für das Einhängen des Root-Dateisystems zuständig ist, nicht ohne Weiteres von der SecureBoot-Maßnahme abgedeckt.
Allerdings rät selbst die NSA ihren Administratoren in einem technischen Bericht von Ende 2020 [3], auf SecureBoot-fähige Systeme umzusteigen.
orcharhino und SecureBoot
Wie in der Einleitung erläutert, wird die Bereitstellung von Laptops zu einer immer wichtigeren Anforderung. orcharhino bietet verschiedene Möglichkeiten der Provisionierung an, die jedoch deutlich im Grad der Automatisierung variieren. Je nach Anzahl der Laptops kann dies entscheidend sein.
Nehmen wir folgendes Szenario an: Sie haben einen neuen Laptop, SecureBoot ist deaktiviert und Sie möchten ein aktuelles Ubuntu Linux provisionieren. Wenn Sie den Aufwand gering halten wollen, schließen Sie das Netzwerkkabel an, schalten den Laptop ein und booten über das Netzwerk. Die Automatisierung beginnt hier: Wenn das Discovery Plug-in in orcharhino aktiviert ist, holt sich der Laptop ein CentOS shim und GRUB über das Netzwerk und beginnt zu booten.
GRUB bezieht das standardmäßige Foreman Discovery Image (FDI) auf Basis von CentOS aus dem Netzwerk, startet es und meldet die Facts des Laptops an orcharhino. In der Benutzeroberfläche finden Sie das System unter Hosts -> Discovered Hosts. Wenn die konfigurierten Discovery Rules zutreffen, wird die gewünschte Ubuntu-Linux-Installation automatisch gestartet, zum Beispiel direkt über kexec ohne Neustart. Der letzte Schritt bei der Installation ist das Anmelden des Systems am orcharhino Server. Danach startet das System neu und bootet das installierte Ubuntu Linux von der Festplatte.
Das gleiche Szenario mit eingeschaltetem SecureBoot funktioniert nicht ohne Weiteres. Das Verhalten ist das gleiche, auch das FDI meldet die Facts an orcharhino. Der anschließende Start der Ubuntu-Installation über kexec schlägt jedoch fehl. Das Problem liegt in der Beschränkung auf eine Distribution durch das anfänglich geladene shim. Zur Erinnerung: Es basiert auf CentOS, also sind nur mit dem CentOS-Schlüssel signierte Kernel erlaubt. shim und das aktivierte SecureBoot versetzen alle weiteren Bootloader und Kernel in einen Lockdown.
Das Booten von signierten Binärdateien, die weder von db (da diese standardmäßig nur das Microsoft-Zertifikat enthält), der Vendor Database von shim (die nur das Zertifikat der jeweiligen Distribution enthält) noch der Database von MOK (die standardmäßig leer ist) verifiziert werden können, ist bis zum nächsten Neustart nicht mehr möglich.
Mögliche Lösungsansätze
Wir möchten Ihnen einen kurzen Überblick über mögliche Lösungen geben, die von den kundenspezifischen Anforderungen und Bedingungen sowie von der Kompromissbereitschaft der User abhängen. Jede Lösung macht Abstriche in Bezug auf den Automatisierungsgrad, die Möglichkeit der Neuinstallation und die Vielfalt der Distributionen, die bereitgestellt werden können.
-
Bereitstellungsprozess mit deaktiviertem SecureBoot laufen lassen und es anschließend aktivieren. Dies ist die pragmatischste Lösung, da neben der manuellen Interaktion nach der Installation keine weiteren Anpassungen oder Anstrengungen erforderlich sind. Entsprechende Komponenten der Ziel-Linux-Distribution sind distributionssigniert und shim wird ohnehin installiert. Jede Neuinstallation würde ein interaktives Ein- und Ausschalten des SecureBoot-Modus erfordern.
-
Beschränkung auf eine Distribution und Verwendung eines FDI, das auf der Zieldistribution basiert. Wenn Sie sich für diesen Ansatz entscheiden, müssen Sie alle beteiligten Komponenten mit Versionen ersetzen, die von der gewünschten Zieldistribution bereitgestellt werden. Dies sind Netzwerk-shim und -GRUB auf dem orcharhino Server sowie das FDI. Das individualisierte FDI erlaubt es Usern, jede beliebige Komponente auszuführen, solange sie von der gleichen Distribution stammt. Die Erstellung eines geeigneten FDI ist jedoch eine anspruchsvolle Aufgabe.
-
Erweiterung von orcharhino, um eine Netzwerk-Boot-Konfiguration pro Host zu ermöglichen. orcharhinos Art, das Booten über Netzwerk bereitzustellen, ist aktuell limitiert. Jedes System wird mit ein und demselben shim und/oder GRUB versorgt (siehe vorheriger Abschnitt). Von dem Moment an, in dem ein Rechner in den Build-Modus geht, müssen DHCP und TFTP so konfiguriert werden, dass sie auf die entsprechenden von der Distribution signierten Komponenten verweisen und diese bereitstellen. Dies entspricht dem zweiten Ansatz, jedoch ohne dass FDIs nötig sind, die auf der Zieldistribution basieren, und mit der Option, kexec in FDI zu verwenden (Lockdown).
-
Erstellung eines shim, das die Zertifikate der bekanntesten Distributionen enthält. Ein shim, das alle wichtigen Distributionen erfolgreich verifiziert, würde das Problem der Festlegung auf eine Distribution beseitigen. Zumindest mit einem über das Netzwerk gebooteten GRUB könnte ein beliebiger Linux-Kernel für die Installation gebootet werden. Ein technischer Nachweis des Konzepts ist vorhanden und ATIX evaluiert diesen Ansatz derzeit. Abgesehen von den Problemen mit (Bootloader) Chain Loading und dem Wartungsaufwand besteht das Risiko, dass dieser Ansatz aufgrund von Einwänden der zuständigen CA den offiziellen Prüfprozess nicht bestehen wird.
Schlussfolgerung
SecureBoot wurde entwickelt, um die Sicherheit von Systemen zu erhöhen. Allerdings gibt es einige Kontroversen. Ein Vorfall namens BootHole im Jahr 2020 (CVE-2020-10713) ermöglichte genau das, was SecureBoot verhindern sollte: die Einschleusung von bösartigem Code [5]. Dieser Vorfall hat gezeigt, dass SecureBoot an einigen Stellen noch verbessert werden muss (und bereits verbessert wurde [6]).
orcharhino ist in der Lage, Hosts auch mit aktiviertem SecureBoot zu provisionieren. Durch eine erste Evaluierung der Prozesse von Unternehmen, für die wir arbeiten, wissen wir, welche Lösung wir wählen müssen. Die Arbeitsabläufe beim Desktop und Notebook Management unterliegen jedoch gewissen Einschränkungen.
Das könnte Sie auch interessieren:
Jan Löser
Neueste Artikel von Jan Löser (alle ansehen)
- Custom Discovery Images für SecureBoot - 5. März 2024
- orcharhino und SecureBoot - 14. Februar 2023
