{"id":105384,"date":"2022-10-26T15:36:38","date_gmt":"2022-10-26T13:36:38","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/lennart-pottering-predlozhil-novuyu-arhitekturu-verificzirovannoj-zagruzki-linux"},"modified":"2022-10-26T15:36:38","modified_gmt":"2022-10-26T13:36:38","slug":"lennart-pottering-predlozhil-novuyu-arhitekturu-verificzirovannoj-zagruzki-linux","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/novosti-interneta\/lennart-pottering-predlozhil-novuyu-arhitekturu-verificzirovannoj-zagruzki-linux","title":{"rendered":"Lennart Poettering hat eine neue Architektur f\u00fcr die verifiziertes Booten von Linux vorgeschlagen.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Lennart Poettering hat einen Vorschlag zur Modernisierung des Bootprozesses von Linux-Distributionen ver\u00f6ffentlicht, der darauf abzielt, bestehende Probleme zu l\u00f6sen und die Organisation eines vollst\u00e4ndigen, verifizierten Bootvorgangs zu vereinfachen, der die Integrit\u00e4t des Kernels und der grundlegenden Systemumgebung best\u00e4tigt. Die erforderlichen \u00c4nderungen f\u00fcr 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. <\/p>\n
Die vorgeschlagenen \u00c4nderungen zielen darauf ab, ein einheitliches, universelles UKI-Format (Unified Kernel Image) zu schaffen, das das Linux-Kernel-Image, einen Bootloader f\u00fcr den Kernel aus UEFI (UEFI Boot Stub) und das in den Speicher geladene Initrd-Systemumfeld kombiniert, das f\u00fcr 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\u00e4ndig verifizierter Systemumgebungen erm\u00f6glicht, die in den Arbeitsspeicher geladen werden. Das UKI-Image wird in Form einer ausf\u00fchrbaren Datei im PE-Format bereitgestellt, die nicht nur mit traditionellen Bootloadern geladen, sondern auch direkt aus der UEFI-Firmware aufgerufen werden kann. <\/p>\n
Die M\u00f6glichkeit, aus UEFI aufgerufen zu werden, erm\u00f6glicht die \u00dcberpr\u00fcfung der Integrit\u00e4t und Authentizit\u00e4t durch digitale Signaturen, die nicht nur den Kernel, sondern auch den Inhalt von Initrd abdecken. Gleichzeitig erm\u00f6glicht die Unterst\u00fctzung des Aufrufs durch traditionelle Bootloader, Funktionen wie die Bereitstellung mehrerer Kernel-Versionen und das automatische Zur\u00fcckrollen auf den stabilen Kernel im Falle von Problemen mit dem neuen Kernel nach der Aktualisierung zu bewahren. <\/p>\n
In den meisten Linux-Distributionen wird w\u00e4hrend des Initialisierungsprozesses eine Kette verwendet: \u201eFirmware \u2192 Microsoft-zertifizierte Shim-Schicht \u2192 vom Distribution zertifizierter Bootloader GRUB \u2192 vom Distribution zertifizierter Linux-Kernel \u2192 nicht zertifiziertes Initrd-Umfeld \u2192 Root-Dateisystem\u201c. Die fehlende Verifizierung von Initrd in herk\u00f6mmlichen Distributionen f\u00fchrt zu Sicherheitsproblemen, da in dieser Umgebung unter anderem Schl\u00fcssel f\u00fcr die Entschl\u00fcsselung des Root-Dateisystems extrahiert werden. <\/p>\n
Die Verifizierung des initrd-Images wird nicht unterst\u00fctzt, 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 \u00dcberpr\u00fcfung im SecureBoot-Modus erheblich (um initrd zu signieren, muss der Benutzer seine eigenen Schl\u00fcssel generieren und in die UEFI-Firmware hochladen). Dar\u00fcber hinaus erlaubt die derzeitige Boot-Organisation nicht, Informationen aus den TPM PCR-Registren (Platform Configuration Register) zu verwenden, um die Integrit\u00e4t der Benutzerdatenkomponenten, abgesehen von shim, grub und dem Kernel, zu kontrollieren. Zu den bestehenden Problemen geh\u00f6rt auch die Komplexit\u00e4t des Upgrades des Bootloaders und das Fehlen der M\u00f6glichkeit, den Zugriff auf Schl\u00fcssel im TPM f\u00fcr veraltete Betriebssystemversionen einzuschr\u00e4nken, die nach einem Upgrade nicht mehr relevant sind. <\/p>\n
Die Hauptziele der Einf\u00fchrung einer neuen Boot-Architektur: <\/p>\n
\n
Bereitstellung eines vollst\u00e4ndig verifizierten Bootprozesses, der alle Phasen von der Firmware bis zum Benutzerraum abdeckt und die Authentizit\u00e4t sowie Integrit\u00e4t der geladenen Komponenten best\u00e4tigt.\n
Bindung der kontrollierten Ressourcen an die TPM PCR-Register mit einer Trennung nach Eigent\u00fcmern.\n
M\u00f6glichkeit zur Vorabkalkulation der PCR-Werte basierend auf den verwendeten Kernel-, Initrd-, Konfigurations- und Systemidentifikatoren.\n
Schutz vor Rollback-Angriffen, die durch das Zur\u00fcckkehren zu einer fr\u00fcheren verwundbaren Systemversion verursacht werden.\n
Vereinfachung und Steigerung der Zuverl\u00e4ssigkeit von Updates.\n
Unterst\u00fctzung von OS-Updates, die keine erneute Anwendung oder lokale Vorbereitung von durch TPM gesch\u00fctzten Ressourcen erfordern.\n
Bereitschaft des Systems zur Durchf\u00fchrung einer Remote-Zertifizierung zur Best\u00e4tigung der Korrektheit des geladenen OS und der Einstellungen.\n
M\u00f6glichkeit, vertrauliche Daten bestimmten Phasen des Bootvorgangs zuzuordnen, z. B. das Extrahieren von Verschl\u00fcsselungsschl\u00fcsseln aus dem TPM f\u00fcr das Root-Dateisystem.\n
Bereitstellung eines sicheren, automatischen und benutzerunabh\u00e4ngigen Prozesses zur Entsperrung von Schl\u00fcsseln zur Entschl\u00fcsselung des Datentr\u00e4gers mit der Root-Partition.\n
Verwendung von Chips, die die TPM 2.0-Spezifikation unterst\u00fctzen, mit der M\u00f6glichkeit, auf Systeme ohne TPM zur\u00fcckzugreifen. <\/ul>\n