Lennart Poettering hat einen Vorschlag zur Modernisierung des Boot-Prozesses für Linux-Distributionen veröffentlicht, der darauf abzielt, bestehende Probleme zu lösen und die Organisation eines vollständig verifizierten Boot-Vorgangs zu vereinfachen, der die Zuverlässigkeit des Kernels und der zugrunde liegenden Systemumgebung bestätigt. Die zur Implementierung der neuen Architektur erforderlichen Änderungen sind bereits in der Systemd-Codebasis enthalten und betreffen Komponenten wie systemd-stub, systemd-measure, systemd-cryptenroll, systemd-cryptsetup, systemd-pcrphase und systemd-creds.
Die vorgeschlagenen Änderungen laufen darauf hinaus, ein einziges universelles UKI-Image (Unified Kernel Image) zu erstellen, das das Linux-Kernel-Image, einen Handler zum Laden des Kernels aus UEFI (UEFI-Boot-Stub) und die in den Speicher geladene initrd-Systemumgebung kombiniert, die für verwendet wird Erstinitialisierung in der Phase vor dem Mounten des Root-FS. Anstelle eines initrd-RAM-Disk-Images kann das gesamte System in UKI gepackt werden, wodurch Sie vollständig verifizierte Systemumgebungen erstellen können, die in den RAM geladen werden. Das UKI-Image ist als ausführbare Datei im PE-Format formatiert, die nicht nur mit herkömmlichen Bootloadern geladen, sondern auch direkt von der UEFI-Firmware aufgerufen werden kann.
Durch die Möglichkeit, über UEFI aufzurufen, können Sie eine Integritätsprüfung für digitale Signaturen verwenden, die nicht nur den Kernel, sondern auch den Inhalt der initrd abdeckt. Gleichzeitig können Sie durch die Unterstützung des Aufrufs von herkömmlichen Bootloadern Funktionen wie die Bereitstellung mehrerer Versionen des Kernels und das automatische Rollback auf einen funktionierenden Kernel beibehalten, wenn nach der Installation des Updates Probleme mit dem neuen Kernel festgestellt werden.
Derzeit verwendet der Initialisierungsprozess in den meisten Linux-Distributionen die Kette „Firmware → digital signierter Microsoft-Shim-Layer → GRUB-Bootloader, digital signiert von der Distribution → digital signierter Linux-Kernel → nicht signierte initrd-Umgebung → Root-FS“. Die fehlende initrd-Verifizierung in herkömmlichen Distributionen führt zu Sicherheitsproblemen, da in dieser Umgebung unter anderem die Schlüssel zum Entschlüsseln des Root-Dateisystems abgerufen werden.
Die Überprüfung des initrd-Images wird nicht unterstützt, da diese Datei auf dem lokalen System des Benutzers generiert wird und nicht mit einer digitalen Signatur des Distributionskits zertifiziert werden kann, was die Organisation der Überprüfung bei Verwendung des SecureBoot-Modus erheblich erschwert (zur Überprüfung der initrd, der Der Benutzer muss seine eigenen Schlüssel generieren und diese in die UEFI-Firmware laden. Darüber hinaus erlaubt die aktuelle Boot-Organisation nicht die Verwendung von Informationen aus den TPM-PCR-Registern (Platform Configuration Register), um die Integrität anderer User-Space-Komponenten als Shim, Grub und den Kernel zu kontrollieren. Zu den bestehenden Problemen zählen auch die Komplexität der Aktualisierung des Bootloaders und die Unfähigkeit, den Zugriff auf Schlüssel im TPM für ältere Versionen des Betriebssystems einzuschränken, die nach der Installation des Updates irrelevant geworden sind.
Die Hauptziele der Einführung der neuen Ladearchitektur sind:
- Bereitstellung eines vollständig verifizierten Startvorgangs, der von der Firmware bis zum Benutzerbereich reicht und die Gültigkeit und Integrität der zu startenden Komponenten bestätigt.
- Verknüpfung kontrollierter Ressourcen mit TPM-PCR-Registern, getrennt nach Besitzer.
- Möglichkeit zur Vorabberechnung von PCR-Werten basierend auf dem Kernel, der Initrd, der Konfiguration und der lokalen System-ID, die beim Booten verwendet werden.
- Schutz vor Rollback-Angriffen im Zusammenhang mit dem Rollback auf eine frühere anfällige Version des Systems.
- Vereinfachen und erhöhen Sie die Zuverlässigkeit von Updates.
- Unterstützung für Betriebssystemaktualisierungen, die keine erneute Anwendung oder lokale Bereitstellung von TPM-geschützten Ressourcen erfordern.
- Das System ist für die Fernzertifizierung bereit, um die Richtigkeit des geladenen Betriebssystems und der Einstellungen zu bestätigen.
- Die Möglichkeit, sensible Daten an bestimmte Startphasen anzuhängen, beispielsweise das Extrahieren von Verschlüsselungsschlüsseln für das Root-Dateisystem aus dem TPM.
- Bereitstellung eines sicheren, automatischen und benutzerfreien Prozesses zum Entsperren von Schlüsseln zum Entschlüsseln eines Root-Partitionslaufwerks.
- Verwendung von Chips, die die TPM 2.0-Spezifikation unterstützen, mit der Möglichkeit eines Rollbacks auf Systeme ohne TPM.
Source: opennet.ru