Lennart Poettering hat eine neue Architektur für die verifiziertes Booten von Linux vorgeschlagen.

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 vollständigen, verifizierten Bootvorgangs zu vereinfachen, der die Integrität des Kernels und der grundlegenden Systemumgebung bestätigt. Die erforderlichen Änderungen für die Implementierung der neuen Architektur sind bereits in den Quellcode von systemd integriert 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-Format (Unified Kernel Image) zu schaffen, das das Linux-Kernel-Image, einen Bootloader für den Kernel aus UEFI (UEFI Boot Stub) und das in den Speicher geladene Initrd-Systemumfeld kombiniert, das für die initiale Initialisierung vor dem Mounten des Root-Dateisystems verwendet wird. Anstelle des RAM-Disk-Images 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 in Form einer ausführbaren Datei im PE-Format bereitgestellt, die nicht nur mit traditionellen Bootloadern geladen, sondern auch direkt aus der UEFI-Firmware aufgerufen werden kann.

Die Möglichkeit, aus UEFI aufgerufen zu werden, ermöglicht die Überprüfung der Integrität und Authentizität durch digitale Signaturen, die nicht nur den Kernel, sondern auch den Inhalt von Initrd abdecken. Gleichzeitig ermöglicht die Unterstützung des Aufrufs durch traditionelle Bootloader, Funktionen wie die Bereitstellung mehrerer Kernel-Versionen und das automatische Zurückrollen auf den stabilen Kernel im Falle von Problemen mit dem neuen Kernel nach der Aktualisierung zu bewahren.

Derzeit wird in den meisten Linux-Distributionen im Initialisierungsprozess eine Kette verwendet: „Firmware → vom Microsoft-Schutzschild signierte Firmware → vom Distribution signierte GRUB-Bootloader → vom Distribution signierter Linux-Kernel → unsignierte Initrd-Umgebung → Root-FS“. Das Fehlen einer Überprüfung von Initrd in traditionellen Distributionen führt zu Sicherheitsproblemen, da in dieser Umgebung unter anderem Schlüssel zur Entschlüsselung des Root-FS 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 der digitalen Signatur des Distributors signiert werden kann. Dies erschwert die Überprüfung im SecureBoot-Modus erheblich (um initrd zu signieren, muss der Benutzer seine eigenen Schlüssel generieren und in die UEFI-Firmware hochladen). Darüber hinaus erlaubt die derzeitige Boot-Organisation nicht, Informationen aus den TPM PCR-Registren (Platform Configuration Register) zu verwenden, um die Integrität der Benutzerdatenkomponenten, abgesehen von shim, grub und dem Kernel, zu kontrollieren. Zu den bestehenden Problemen gehört auch die Komplexität des Upgrades des Bootloaders und das Fehlen der Möglichkeit, den Zugriff auf Schlüssel im TPM für veraltete Betriebssystemversionen einzuschränken, die nach einem Upgrade nicht mehr relevant sind.

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

• Bereitstellung eines vollständig verifizierten Bootprozesses, der alle Phasen von der Firmware bis zum Benutzerraum abdeckt und die Authentizität sowie Integrität der geladenen Komponenten bestätigt.
• Bindung der kontrollierten Ressourcen an die TPM PCR-Register mit einer Trennung nach Eigentümern.
• Möglichkeit zur Vorabkalkulation der PCR-Werte basierend auf den verwendeten Kernel-, Initrd-, Konfigurations- und Systemidentifikatoren.
• Schutz vor Rollback-Angriffen, die durch das Zurückkehren zu einer früheren verwundbaren Systemversion verursacht werden.
• Vereinfachung und Steigerung der Zuverlässigkeit von Updates.
• Unterstützung von OS-Updates, die keine erneute Anwendung oder lokale Vorbereitung von durch TPM geschützten Ressourcen erfordern.
• Bereitschaft des Systems zur Durchführung einer Remote-Zertifizierung zur Bestätigung der Korrektheit des geladenen OS und der Einstellungen.
• Möglichkeit, vertrauliche Daten bestimmten Phasen des Bootvorgangs zuzuordnen, z. B. das Extrahieren von Verschlüsselungsschlüsseln aus dem TPM für das Root-Dateisystem.
• Bereitstellung eines sicheren, automatischen und benutzerunabhängigen Prozesses zur Entsperrung von Schlüsseln zur Entschlüsselung des Datenträgers mit der Root-Partition.
• Verwendung von Chips, die die TPM 2.0-Spezifikation unterstützen, mit der Möglichkeit, auf Systeme ohne TPM zurückzugreifen.

Quelle: opennet.ru