Vertrauen auf allen Ebenen: Wie versiegelte Images die Betriebssystemintegrität vom Boot-Vorgang bis zur Runtime erweitern

Nehmen wir ein medizinisches Gerät in einem Krankenhaus, auf dem Linux ausgeführt wird. Es verarbeitet Patientendaten, passt die Dosierung an und übermittelt Berichte an klinische Systeme. Oder ein Geldautomat an einer Straßenecke, der rund um die Uhr Transaktionen verarbeitet. Oder ein Gateway-Gerät am Edge eines Fertigungsnetzwerks, das Sensordaten aus der Werkshalle weiterleitet. Das Betriebssystem wurde bei der Installation überprüft. Sind die Binärdateien und die Library jedoch immer noch genau das, was erstellt wurde? Wenn Sie diese Garantie für ein Gerät in einem Operationssaal oder in einer Werkshalle fordern würden, warum sollten Sie nicht dasselbe von den Servern erwarten, auf denen Ihr Unternehmen läuft?

Die Lücke in Ihrer Boot-Kette

In der Regel ist eine generische Standardinstallation des Betriebssystems „entsperrt“, sodass Sie als Root auf Ihrem Computer dauerhafte Änderungen vornehmen können. Während eine generische Installation von Red Hat Enterprise Linux (RHEL) oder Debian Secure Boot unterstützt, ist in der Regel nur der Kernel signiert. Die kryptografische Vertrauenskette der Firmware deckt das Root-Dateisystem oder Apps nicht ab. Organisationen, die „Appliances“ bereitstellen möchten, können die Sicherheit jedoch erhöhen, indem sie eine Kette vom Secure Boot bis zur Integrität des Betriebssystems mithilfe benutzerdefinierter Signaturen bilden.

Von Container-Workflows zur Betriebssystemintegrität

Die meisten Unternehmen erstellen, signieren und liefern Container Images bereits über CI/CD-Pipelines. Jeder Container-Abruf verifiziert einen kryptografischen Digest. Bei jedem Start eines neuen Containers bestätigt die Runtime, dass das Image mit der Signatur übereinstimmt. Unternehmen vertrauen bereits bei ihren Anwendungen auf dieses Modell.

Der Image-Modus für RHEL bringt denselben Container Workflow auf das Betriebssystem. Anstatt ein Betriebssystem manuell oder über Skripte zu installieren und zu konfigurieren, definieren Sie es in einem Containerfile (oder einem anderen kompatiblen OCI-Build-System), erstellen es als Container Image und stellen es mit bootc bereit. Das Betriebssystem wird zu einem versionierten, reproduzierbaren Artefakt, das dieselbe Pipeline wie Ihre Anwendungen durchläuft. Updates sind atomar. Rollback ist integriert. Alle bereitgestellten Systeme führen das von Ihnen erstellte Image aus, und Sie können dieses Image bis zum Build-System zurückverfolgen, das es erstellt hat.

Der Image-Modus ermöglicht versiegelte Images, die noch einen Schritt weiter gehen. Die Firmware verifiziert das von Ihnen erstellte und signierte Betriebssystem-Image nun kryptografisch bis zur Runtime. Sie führen keinen neuen Prozess ein. Sie erweitern einen Prozess, dem Sie bereits vertrauen, von Ihren Anwendungen auf die Betriebssystemschicht.

Funktionsweise

Secure Boot und ein signiertes Unified Kernel Image verifizieren bereits die Boot-Kette: Bootloader, Kernel, Initramfs. Versiegelte Images weiten die Verifizierung mit dateigenauer Präzision auf das unveränderliche Betriebssystem-Image aus. Mithilfe von composefs und fs-verity betten Sie einen kryptografischen Digest des Container Images des Betriebssystems zum Zeitpunkt der Erstellung direkt in das signierte UKI ein. Zur Runtime verifiziert das System die Dateien einzeln anhand dieses Digests, die Sie oder Ihr Team zu diesem Image hinzugefügt haben. Das System lehnt das Laden von Betriebssystemdateien ab, die nicht übereinstimmen. Falls nach der Erstellung des Images Änderungen, Beschädigungen oder Ersetzungen vorgenommen wurden, gibt der Kernel einen I/O-Fehler zurück. Das System stellt die Datei nicht bereit. Keine Protokollierung und Bereitstellung, keine Kennzeichnung und Bereitstellung. Sie ist schlichtweg nicht lesbar. Der manipulierte Inhalt ist faktisch nicht mehr vorhanden, sodass der Kernel diesen nicht an die Prozesse weitergibt.

Was das für Ihre Infrastruktur bedeutet

Die Signaturkette unterliegt Ihrer Kontrolle. Sie generieren die Schlüssel, signieren die Images und entscheiden selbst, worauf Ihre Systeme vertrauen. In Ihrer Sicherheitskette ist kein externer Anbieter erforderlich.

Hochsicherheitsorganisationen in Behörden, im Finanzwesen und im Gesundheitswesen fordern dieses Maß an Betriebssystemintegrität seit Jahren. Versiegelte Images bieten dies und stehen Organisationen zur Verfügung, die dies wünschen. Sie müssen nicht in einer regulierten Branche tätig sein, um von dem Wissen zu profitieren, dass Ihr Betriebssystem genau das ist, was Sie erstellt haben.

Es lohnt sich, genau zu definieren, was versiegelte Images abdecken. Das Siegel schützt die Dateien im unveränderlichen Betriebssystem-Image: das Basis-Betriebssystem und die darauf aufsetzende Software. Ihre Monitoring-Agenten, Ihre Sicherheitstools, Ihre Anwendungs-Binärdateien und die spezifischen Pakete, die Ihr Team dem Basis-Image hinzugefügt hat. Diese Komponenten sind versiegelt. Dies deckt die beschreibbare Konfiguration in /etc oder den Laufzeitstatus in /var nicht ab. Diese Unterscheidung ist beabsichtigt. Das Siegel schützt das Betriebssystem, das Sie erstellt haben. Ihre Tools für Konfigurationsmanagement und Runtime-Sicherheit unterstützen den Schutz der restlichen Komponenten.

Am Anfang dieses Artikels habe ich ein medizinisches Gerät und einen Geldautomaten erwähnt, aber dieses Prinzip geht über diese Beispiele hinaus. Stellen Sie sich ein Rechenzentrum, eine Edge-Flotte oder eine Fertigung vor. Ein Containerfile definiert das Betriebssystem. Eine Pipeline erstellt, signiert und versiegelt diese. Sie stellen dasselbe versiegelte Image auf Bare Metal, VMs und Cloud-Instanzen bereit. Die gleiche Integrität bleibt durchgängig erhalten. Dies ist keine Nischenfunktion für einen begrenzten Use Case. So sollte Betriebssystemintegrität aussehen.

Erste Schritte

Versiegelte Images sind als Technology Preview in RHEL 10.2 verfügbar. Die Lösung basiert auf Upstream-Linux-Technologien, einschließlich wichtiger Komponenten des systemd-Projekts sowie bestehender Tools für Secure Boot und composefs. Diese bieten eine flexible und effiziente Integrität, wie sie dm-verity bietet, jedoch mit der Flexibilität eines dateisystembasierten Ansatzes. In diese Richtung entwickelt sich das Betriebssystemmanagement. Die Technology Preview ist verfügbar und die Tools sind bereits einsatzfähig. In den kommenden Wochen veröffentlichen wir im Red Hat Developer Blog eine Schritt-für-Schritt-Reihe. So erfahren Sie, wie die Entwicklung und Verifizierung von Systemen in der Praxis erfolgt.