Lennart Poettering schlug eine neue Architektur für den verifizierten Linux-Start vor

Lennart Poettering hat einen Vorschlag zur Modernisierung des Bootprozesses von Linux-Distributionen veröffentlicht, der darauf abzielt, bestehende Probleme zu lösen und die Organisation eines vollwertigen, verifizierten Bootvorgangs zu vereinfachen, der die Integrität des Kernels und der grundlegenden Systemumgebung bestätigt. Die für die Implementierung der neuen Architektur notwendigen Änderungen sind bereits im Code von systemd enthalten und betreffen Komponenten wie systemd-stub, systemd-measure, systemd-cryptenroll, systemd-cryptsetup, systemd-pcrphase und systemd-creds.

Die vorgeschlagenen Änderungen zielen darauf ab, ein einheitliches, universelles UKI-Image (Unified Kernel Image) zu schaffen, das das Linux-Kernel-Image, einen Handler zum Laden des Kernels aus UEFI (UEFI boot stub) und das in den Arbeitsspeicher geladene Systemumfeld initrd kombiniert, das für die initiale Initialisierung in der Phase vor dem Mounten des Root-Dateisystems verwendet wird. Statt des RAM-Image initrd kann im UKI auch das gesamte System verpackt werden, was die Erstellung vollständig verifizierter Systemumgebungen ermöglicht, die in den Arbeitsspeicher geladen werden. Das UKI-Image wird als ausführbare Datei im PE-Format gestaltet, die nicht nur mit traditionellen Bootloaders geladen werden kann, sondern auch direkt aus der UEFI-Firmware aufgerufen werden kann.

Die Möglichkeit des Aufrufs aus UEFI ermöglicht die Verwendung einer Integritäts- und Echtheitsprüfung durch digitale Signaturen, die nicht nur den Kernel, sondern auch den Inhalt von initrd abdecken. Gleichzeitig ermöglicht die Unterstützung des Aufrufs aus traditionellen Bootloaders die Beibehaltung solcher Möglichkeiten wie das Bereitstellen mehrerer Kernelversionen und das automatische Zurückrollen auf den funktionierenden Kernel im Falle von Problemen mit dem neuen Kernel nach einem Update.

Derzeit wird in den meisten Linux-Distributionen im Initialisierungsprozess eine Kette verwendet: "Firmware → von Microsoft signierte shim-Schicht → von der Distribution signierter Bootloader GRUB → von der Distribution signierter Linux-Kernel → nicht signierte Umgebung initrd → Root-Dateisystem". Das Fehlen einer Verifizierung von initrd in traditionellen Distributionen schafft Sicherheitsprobleme, da in dieser Umgebung unter anderem Schlüssel zum Entschlüsseln des Root-Dateisystems extrahiert werden.

Die Verifizierung des initrd-Images wird nicht unterstützt, da diese Datei auf dem lokalen System des Benutzers erstellt wird und nicht mit einer digitalen Signatur des Distributors versehen werden kann, was die Organisation der Überprüfung im SecureBoot-Modus erheblich erschwert (um das initrd zu signieren, muss der Benutzer seine Schlüssel generieren und in die UEFI-Firmware hochladen). Darüber hinaus erlaubt die derzeitige Boot-Organisation nicht, Informationen aus den TPM PCR-Registern (Platform Configuration Register) zur Überwachung der Integrität der Komponenten im Benutzerspeicher zu verwenden, abgesehen von shim, grub und dem Kernel. Zu den bestehenden Problemen gehört auch die Schwierigkeit bei der Aktualisierung des Bootloaders und die fehlende Möglichkeit, den Zugriff auf die Schlüssel im TPM für ältere Betriebssystemversionen, die nach der Installation des Updates nicht mehr aktuell sind, einzuschränken.

Die Hauptziele der Einführung einer neuen Boot-Architektur:

• Bereitstellung eines vollständig verifizierten Boot-Prozesses, der alle Phasen von der Firmware bis zum Benutzerspeicher umfasst und die Authentizität und Integrität der geladenen Komponenten bestätigt.
• Bindung kontrollierter Ressourcen an die TPM PCR-Register mit Trennung nach Eigentümern.
• Möglichkeit der Vorberechnung der PCR-Werte basierend auf den bei der Booten verwendeten Kernel-, initrd-, Konfigurations- und lokalen System-ID.
• Schutz vor Rollback-Angriffen, die mit einem Zurücksetzen auf eine frühere verwundbare Version des Systems verbunden sind.
• Vereinfachung und Erhöhung der Zuverlässigkeit von Updates.
• Unterstützung von Betriebssystem-Updates, die keine erneute Anwendung oder lokale Vorbereitung der durch TPM geschützten Ressourcen erfordern.
• Bereitschaft des Systems zur Durchführung von Remote-Attestierungen zur Bestätigung der Korrektheit des geladenen Betriebssystems und der Einstellungen.
• Möglichkeit, vertrauliche Daten an bestimmten Phasen des Bootvorgangs anzuhängen, z. B. das Abrufen von Verschlüsselungsschlüsseln für das Root-Dateisystem aus dem TPM.
• Bereitstellung eines sicheren, automatischen und benutzerunabhängigen Prozesses zur Entsperrung von Schlüsseln für die Entschlüsselung des jeweiligen Root-Disk.
• Verwendung von Chips, die die TPM 2.0-Spezifikation unterstützen, mit der Möglichkeit, auf Systeme ohne TPM zurückzugreifen.

Quelle: opennet.ru