Sie schlagen vor, den Linux-Boot-Prozess zu modernisieren

Der neue Linux-Boot wird bis weit in die Zukunft hinein funktionieren, wobei der Schwerpunkt auf Robustheit und Einfachheit liegt.

Lennart Pöttering (der Schöpfer von Systemd) enthüllt vor kurzem ein Vorschlag zur Modernisierung des Boot-Prozesses der Verteilungen von Linux, mit dem Ziel bestehende Probleme zu lösen und vereinfachen die Organisation eines vollständig verifizierten Bootvorgangs, der die Authentizität des Kernels und der zugrunde liegenden Systemumgebung bestätigt.

Vorgeschlagenen Änderungen sind reduziert auf Erstellung eines einzigen universellen UKI-Images (Einheitliches Kernel-Image) die das Kernel-Image zusammenführt Linux-Treiber zum Laden des Kernels von UEFI (UEFI-Boot-Stub) und die Systemumgebung initrd in den Speicher geladen, wird für die anfängliche Initialisierung in der Phase vor dem Mounten des FS verwendet.

Anstelle eines Ramdisk-Images initrd, das ganze System kann im UKI verpackt werden, wodurch die Erstellung vollständig verifizierter Systemumgebungen ermöglicht wird, die in den Arbeitsspeicher geladen werden. Das UKI-Image ist als ausführbare Datei im PE-Format verpackt, die nicht nur mit herkömmlichen Bootloadern geladen, sondern auch direkt aus der UEFI-Firmware aufgerufen werden kann.

Die Möglichkeit, von UEFI aus anzurufen, ermöglicht die Verwendung einer Gültigkeits- und Integritätsprüfung für digitale Signaturen die nicht nur den Kernel, sondern auch den Inhalt der initrd abdeckt. Gleichzeitig ermöglicht die Unterstützung für Aufrufe von herkömmlichen Bootloadern das Speichern von Funktionen wie das Bereitstellen mehrerer Kernel-Versionen und das automatische Zurücksetzen auf einen funktionierenden Kernel, falls nach der Installation der neuesten Version Probleme mit dem neuen Kernel erkannt werden.

Derzeit die meisten Linux-Distributionen verwenden Kette "Firmware → digital signierte Microsoft-Shim-Schicht → digital signierter Distributions-GRUB-Bootloader → digital signierter Distributions-Linux-Kernel → unsignierte initrd-Umgebung → FS-Root" im Initialisierungsprozess. Fehlende initrd-Prüfung in traditionellen Distributionen schafft Sicherheitsprobleme, da diese Umgebung unter anderem Schlüssel extrahiert, um die FS-Root zu entschlüsseln.

Die Überprüfung des initrd-Image wird nicht unterstützt, da diese Datei auf dem lokalen System des Benutzers generiert wird und nicht durch die digitale Signatur der Distribution zertifiziert werden kann, was es sehr schwierig macht, die Überprüfung zu organisieren, wenn der SecureBoot-Modus verwendet wird (um die initrd zu überprüfen, muss der Benutzer Ihre Schlüssel generieren und in die UEFI-Firmware).

Zusätzlich Die vorhandene Boot-Organisation lässt die Verwendung von Informationen aus den TPM-PCR-Registern nicht zu (Platform Configuration Registry), um die Integrität anderer Userspace-Komponenten als Shim, Grub und Kernel zu kontrollieren. Unter den bestehenden Problemen werden auch die Komplikation der Aktualisierung des Bootloaders und die fehlende Möglichkeit, den Zugriff auf Schlüssel im TPM für ältere Versionen des Betriebssystems einzuschränken, die nach der Installation des Updates irrelevant geworden sind, genannt.

Die Hauptziele der Umsetzung die neue Boot-Architektur:

• Bereitstellung eines vollständig verifizierten Download-Prozesses, der alle Phasen von der Firmware bis zum Benutzerbereich abdeckt und die Gültigkeit und Integrität der heruntergeladenen Komponenten bestätigt.
• Verknüpfung kontrollierter Ressourcen mit TPM-PCR-Registern mit Trennung nach Eigentümern.
• Möglichkeit, PCR-Werte basierend auf Kernel-Boot, initrd, Konfiguration und lokaler System-ID vorzuberechnen.
• Schutz vor Rollback-Angriffen im Zusammenhang mit der Wiederherstellung der vorherigen anfälligen Version des Systems.
• Vereinfachen und verbessern Sie die Zuverlässigkeit von Updates.
• Unterstützung für Betriebssystem-Upgrades, die keine erneute Anwendung oder lokale Bereitstellung von TPM-geschützten Ressourcen erfordern.
• Vorbereiten des Systems für die Remote-Zertifizierung, um die Korrektheit des Betriebssystems und der Startkonfiguration zu bestätigen.
• Die Möglichkeit, vertrauliche Daten an bestimmte Startphasen anzuhängen, beispielsweise durch Extrahieren von Verschlüsselungsschlüsseln für den FS-Stamm aus dem TPM.
• Bieten Sie einen sicheren, automatischen und unbeaufsichtigten Prozess zum Entsperren von Schlüsseln zum Entschlüsseln eines Laufwerks mit einer Root-Partition.
• Die Verwendung von Chips, die die TPM 2.0-Spezifikation unterstützen, mit der Möglichkeit, auf Systeme ohne TPM zurückzugreifen.

Die notwendigen Änderungen um die neue Architektur zu implementieren sind bereits in der Systemd-Codebasis enthalten und beeinflussen Komponenten wie systemd-stub, systemd-measure, systemd-cryptenroll, systemd-cryptsetup, systemd-pcrphase und systemd-creds.

Schließlich wenn Sie mehr darüber wissen möchtenkönnen Sie die Details in der überprüfen folgenden Link