So lässt sich Secure Boot unter Gentoo Linux einrichten

Der Sicherheitsforscher Alexander Moch vom Heidelberger IT-Sicherheitsunternehmen ERNW hat sich in einem aktuellen Blogbeitrag mit der Einrichtung von Secure Boot unter Gentoo Linux beschäftigt. Dabei erklärt er nicht nur die Funktionsweise der Technik, sondern beleuchtet auch die Schwächen der Linux-Implementierungen im Vergleich zu Microsoft Windows und Apple macOS.

Während große Linux-Distributionen wie Canonical (Ubuntu), Debian, openSUSE oder Red Hat vor allem auf ein möglichst sofort einsatzbereites System setzen, stößt die Umsetzung von Secure Boot in der Praxis häufig an Grenzen. Gründe dafür sind unter anderem proprietäre Treiber, die außerhalb des Linux-Kernels gepflegt werden, oder Lizenzprobleme, die eine einfache Integration erschweren. Für Endnutzer kann das bedeuten, dass nicht alle benötigten Treiber zum Booten des Systems verfügbar sind.

Gentoo Linux nimmt in dieser Diskussion eine besondere Rolle ein. Als sogenannte Meta-Distribution überlässt sie viele Entscheidungen den Anwendern – inklusive der kompletten Gestaltung der Boot-Kette. „Der Vorteil ist, dass man nicht gegen die Vorgaben eines Distributors arbeiten muss, sondern das System nach eigenen Vorstellungen absichern kann“, schreibt Moch. Genau aus diesem Grund habe er Gentoo als Beispielplattform für die praktische Demonstration gewählt.

Auf einem gehärteten System sollte Secure Boot stets in Kombination mit einer vollständigen Festplattenverschlüsselung eingesetzt werden – nur so lasse sich ein wirklich hohes Sicherheitsniveau erreichen.

Sicherer Start

Der sichere Start erzwingt eine Hierarchie von Schlüsseln und Hashwerten mit dem Ziel, EFI-Ausführungsdateien zu überprüfen und zu laden. Im einfachsten Fall handelt es sich bei dieser Ausführungsdatei um den Bootloader. Vor der Ausführung werden seine Signatur oder sein Hashwert mit den bereitgestellten Werten verglichen.

Gute Informationsquellen zum Thema UEFI Secure Boot finden Sie in der UEFI-Spezifikation, in der Erklärung von Oracle zu UEFI Secure Boot, in James Bottomleys Blogbeitrag „The Meaning of all the UEFI Keys“ oder in @depletionsmodes Blogbeitrag „Understanding modern UEFI-based platform boot“.

Im Gegensatz zu den meisten anderen Anleitungen erklären wir diese Hierarchie von unten nach oben.

• Signaturdatenbank (db): Die Signaturdatenbank enthält öffentliche Schlüssel, digitale Signaturen oder Hashes von ausführbaren Dateien. Wenn eine EFI-Binärdatei geladen wird, wird sie mit den Einträgen in db verglichen und darf ausgeführt werden, wenn eine Übereinstimmung gefunden wird.
• Verbotene Signaturdatenbank (dbx): Die dbx funktioniert ähnlich wie die Signaturdatenbank, dient jedoch dem gegenteiligen Zweck. Sie enthält öffentliche Schlüssel, Signaturen oder Hashes, die ausdrücklich verboten sind. Wenn eine ausführbare Datei mit einem Eintrag in der dbxübereinstimmt, wird die Ausführung blockiert, auch wenn sie ansonsten gültig wäre.
• Schlüsselaustauschschlüssel (KEK): KEKs werden verwendet, um Aktualisierungen der db und dbxzu signieren und zu autorisieren. Es können mehrere KEKs vorhanden sein, sodass verschiedene Stellen (z. B. Microsoft oder der Plattformanbieter) die Signaturdatenbanken verwalten können.
• Plattformschlüssel (PK): Der Plattformschlüssel ist die Vertrauensbasis. Er gehört dem Plattformbesitzer (d. h. in der Regel dem Anbieter), kann jedoch durch einen benutzerdefinierten PK ersetzt werden, der pro Gerät, Benutzer oder Organisation generiert wird. Der PK wird zum Signieren von KEKs und zum Autorisieren seines eigenen Ersatzes verwendet.

Beachten Sie, dass es jeweils nur einen Plattformschlüssel gibt, aber mehrere KEKs und Datenbankeinträge vorhanden sein können.

Letztendlich entscheiden die Datenbanken db und dbx darüber, ob eine Binärdatei ausgeführt werden kann. Diese Datenbanken werden von den KEKs signiert und daher auch von diesen verwaltet. Der Plattformbesitzer kontrolliert über den PK, welche KEKs vertrauenswürdig sind, indem er sie signiert.

In einer typischen Werkseinstellung (z. B. auf einem Notebook) wird der PK vom Anbieter festgelegt. In der Regel sind zwei KEKs installiert und vom Anbieter signiert:

• Eine Hersteller-KEK, die zum Signieren von Datenbanken mit Firmware-Updates oder herstellerspezifischen Wiederherstellungseinträgen verwendet wird.
• Eine Microsoft-KEK, die es Windows Update ermöglicht, Secure Boot-Datenbanken zu verwalten.

Die entsprechenden privaten Schlüssel sind nur ihren Besitzern bekannt. Beachten Sie, dass KEKs nicht bereichsbezogen sind: Jeder, der Zugriff auf den entsprechenden privaten Schlüssel hat, kann beliebige Binärdateien (Firmware, Kernel, Treiber usw.) zur db hinzufügen und ihnen damit effektiv Secure Boot-Vertrauen gewähren.

Shim-Lader und Maschinenbesitzer-Schlüssel

Große Distributionen möchten sicherstellen, dass ihre Systeme sofort einsatzbereit sind. Sie verfügen jedoch weder über eigene Schlüssel, die in der UEFI-Firmware vorinstalliert sind, noch besitzen sie die privaten Schlüssel des Plattformanbieters oder von Microsoft. Um diese Lücke zu schließen, wird ein Shim Loader verwendet.

Shim wird von Microsoft signiert und enthält den öffentlichen Schlüssel der Distribution. Während des Bootvorgangs wird Shim von der UEFI-Firmware geladen und verwendet seinen integrierten Schlüssel, um die nachfolgenden Phasen des Bootvorgangs zu überprüfen.

Zunächst überprüft shim GRUB und lädt es. Anschließend kann der Benutzer über GRUB einen Boot-Eintrag auswählen. GRUB überprüft das Kernel-Image vor dem Laden mithilfe der Validierungsinfrastruktur von shim. Wenn die Überprüfung erfolgreich ist, wird die Kontrolle an den ausgewählten Eintrag übertragen, bei dem es sich in der Regel um den Linux-Kernel handelt. Nach dem Start ist der Kernel für die Überprüfung der Kernel-Module beim Laden verantwortlich.

Linux steht vor Herausforderungen mit Kernel-Modulen von Drittanbietern und außerhalb des Baums (d. h. Treibern). Diese Module sind möglicherweise nicht im Lieferumfang der Distribution enthalten und werden häufig bei einem Kernel-Update mit DKMS auf dem Host-System erstellt. Da der private Schlüssel der Distribution jedoch nicht auf dem Host vorhanden ist, können diese Module nicht mit einem vertrauenswürdigen Schlüssel signiert werden, der shim oder dem Kernel bereits bekannt ist.

Um dieses Problem zu lösen, werden Machine Owner Keys (MOKs) verwendet. Diese Schlüssel werden auf dem Hostsystem generiert und beim nächsten Neustart in den UEFI-NVRAM eingetragen.

MOKs sind nicht Teil der offiziellen UEFI-Secure-Boot-Spezifikation, werden jedoch von shim und dem Linux-Kernel erkannt. Wenn ein Kernel-Modul eines Drittanbieters oder außerhalb des Baums neu erstellt wird, kann es mit dem MOK signiert werden, sodass es ohne Verletzung der Secure-Boot-Richtlinien geladen werden kann.

Initiales RAM-Dateisystem und einheitliche Kernel-Images

Die oben beschriebene Boot-Kette überprüft den Kernel und seine Module. Benutzerkomponenten wie das initiale RAM-Dateisystem (initramfs) werden jedoch in der Regel nicht überprüft. Das initramfs ist ein minimales Root-Dateisystem, das die Benutzerkomponenten enthält, die zum Mounten des echten Root-Dateisystems und zur Übergabe der Kontrolle an das Init-System erforderlich sind.

Unified Kernel Images (UKIs) bündeln den Kernel, initramfs, Befehlszeilenparameter, CPU-Mikrocode und mehr in einer einzigen monolithischen EFI-Binärdatei, die signiert werden kann. UKIs werden als PE-EFI-Binärdateien (Portable Executable) erstellt, dem gleichen Format, das auch von Standard-UEFI-Anwendungen verwendet wird, sodass sie direkt von der UEFI-Firmware oder Shimüberprüft und ausgeführt werden können. Dadurch kann die gesamte frühe Boot-Kette kryptografisch überprüft werden.

Ein UKI kann grundsätzlich direkt von UEFI selbst geladen und überprüft werden, ohne dass ein Bootloader erforderlich ist. Dazu muss der Benutzer jedoch das UKI mit einem in dbregistrierten Schlüssel signieren und somit auch seine eigenen KEK und PKverwalten. Dies bietet zwar vollständige Kontrolle, ist jedoch ein komplexer Prozess, der bei falscher Ausführung dazu führen kann, dass das Gerät nicht mehr bootfähig ist.

Alternativ kann die UKI von einem Bootloader geladen werden, wobei man die Vorteile von shimnutzen kann, das die Überprüfung von mit Machine Owner Keys (MOKs) signierten Binärdateien unterstützt. Dies wirft die Frage auf: Kann shim eine UKI direkt laden?

Theoretisch ja. shim kann jede signierte EFI-Binärdatei, einschließlich einer UKI, überprüfen und starten. In der Praxis ist shim jedoch fest darauf programmiert, GRUB als nächste Stufe zu laden. Um dieses Verhalten anzupassen, muss shim geändert werden, was nur zulässig ist, wenn Sie Ihre eigenen Secure Boot-Schlüssel (PK, KEK, db) kontrollieren.

Daher bleibt in den meisten Fällen die folgende Kette bestehen: UEFI → shim → Bootloader → UKI

Secure Boot unter Gentoo Linux: Moch beschreibt Einrichtungsschritte

Weiterhin schreibt Alexander Moch in seinem Beitrag zur Einrichtung von Secure Boot unter Gentoo Linux: Ziel sei es, die Boot-Kette so zu konfigurieren, dass keine Änderungen an den Secure-Boot-Schlüsseln notwendig sind. Lediglich ein Machine Owner Key (MOK) müsse importiert werden. Während GRUB beim Prüfen eines Unified Kernel Image (UKI) ausschließlich auf die Secure-Boot-Schlüssel zurückgreift und nicht auf den MOK, greifen Distributionen wie Red Hat und Canonical auf eigene Patches zurück. Diese seien jedoch bislang nicht in den offiziellen Code aufgenommen worden. Daher setze Moch auf systemd-boot. Hier übernimmt der systemd-stub innerhalb der UKI die Überprüfung mithilfe der shim-Logik, sodass auch mit dem MOK signierte UKIs akzeptiert werden – ohne Änderungen an PK, KEK oder db.

Gentoo Linux nutzt dabei den von Microsoft signierten shim aus Fedora, der fest verdrahtet auf grubx64.efi verweist. Um stattdessen systemd-boot zu starten, sei ein kleiner Eingriff erforderlich: Die Datei systemd-bootx64.efi müsse in grubx64.efi umbenannt werden.

Vorausgesetzt wird eine FAT32-formatierte EFI-Systempartition (ESP) unter /efi ohne separate /boot-Partition. Zudem empfiehlt Moch die Nutzung des Pakets gentoo-kernel-bin sowie dracut zur Erstellung des initramfs. Getestet wurde die Anleitung auf einem Gentoo-System mit dem Init-System OpenRC. Für Nutzerinnen und Nutzer von systemd sei lediglich die Anpassung erforderlich, in der Konfiguration das Paket systemd-utils durch systemd zu ersetzen.

Moch verweist außerdem auf eine ähnliche Anleitung von Gabriele Svelto, der jedoch auf GRUB statt systemd-boot setzt und reguläre Kernel-Images mit unsigniertem initramfs verwendet. Diese Methode bringe Nachteile mit sich: Weder initramfs noch Kernel-Befehlszeilen seien signiert, GRUB könne keine mit MOK signierten UKIs starten und alle Module müssten signiert oder als monolithischer „Standalone“-Build vorliegen, der bei jedem Kernel-Update erneuert werden müsse. Dennoch, so Moch, sei sein Beitrag von Sveltos Arbeit inspiriert.

Generieren und Installieren des Maschinenbesitzerschlüssels

Zunächst generieren wir den Maschinenbesitzerschlüssel in /root/secureboot und konvertieren ihn in das DER-Format, das für den Import in den NVRAM erforderlich ist:

root ~ # openssl req -new -nodes -utf8 -sha256 -x509 -outform PEM -out /root/secureboot/MOK.pem -keyout /root/secureboot/MOK.key -subj "/CN=<your name here>/"
root ~ # openssl x509 -in /root/secureboot/MOK.pem -outform DER -out /root/secureboot/MOK.der

USE="... modules-sign secureboot ..."

Stellen Sie außerdem sicher, dass die Variablen für das Zertifikat und den Schlüssel in /etc/portage/make.conf:

SECUREBOOT_SIGN_KEY="/root/secureboot/MOK.key"
SECUREBOOT_SIGN_CERT="/root/secureboot/MOK.pem"
MODULES_SIGN_KEY="/root/secureboot/MOK.key"
MODULES_SIGN_CERT="/root/secureboot/MOK.pem"

uefi_secureboot_cert="/root/secureboot/MOK.pem"
uefi_secureboot_key="/root/secureboot/MOK.key"

ignore-keyring --import /root/secureboot/MOK.der
root ~ # mokutil --ignore-keyring --import /usr/src/linux-<version>-gentoo-dist/certs/signing_key.x509

sys-apps/systemd-utils boot kernel-install secureboot
sys-kernel/installkernel dracut systemd systemd-boot uki

root ~ # emerge systemd-utils shim installkernel

root ~ # bootctl install --no-variables
root ~ # cp /usr/share/shim/BOOTX64.EFI /efi/EFI/systemd/shimx64.efi
root ~ # cp /usr/share/shim/mmx64.efi /efi/EFI/systemd/mmx64.efi
root ~ # cp /efi/EFI/systemd/systemd-bootx64.efi /efi/EFI/systemd/grubx64.efi

root ~ # efibootmgr --disk /dev/vda --part 1 --create --label "Systemd-boot via Shim" --loader '\EFI\systemd\shimx64.efi'

root ~ # emerge --config gentoo-kernel-bin

root ~ # equery -q hasuse modules-sign

root ~ # cat /proc/cmdline
root=zfs:zsystem/ROOT/gentoo rootfstype=zfs rootflags=rw,noatime,xattr,posixacl,casesensitive

kernel_cmdline="root=zfs:zsystem/ROOT/gentoo rootfstype=zfs rootflags=rw,noatime,xattr,posixacl,casesensitive efi=noruntime rd.shell=0 rd.emergency=halt"

root ~ # emerge app-crypt/sbctl

root ~ # sbctl create-keys
Created Owner UUID a016ea31-f309-449a-9b64-6696af5bb218
Creating secure boot keys...✓
Secure boot keys created!

root ~ # sbctl enroll-keys -m
Enrolling keys to EFI variables...
With vendor keys from microsoft...✓
Enrolled keys to the EFI variables!

root ~ # efibootmgr --disk /dev/vda --part 1 --create --label "Gentoo Linux 6.15.4 (UKI)" --loader '\EFI\Linux\gentoo-6.15.4-gentoo-dist.efi'