Resilient Linux bietet ein widerstandsfähiges, persistentes Live-System auf der Festplatte und folgt dabei einem ganz eigenen Partionierungsschema.

Die meisten Linux-Distributionen hängen beim Start des Systems die Root-Partition und eine eventuell vorhandene separate Home-Partition beschreibbar ein. Um das System widerstandsfähiger gegen Fehlbedienungen, zerstörerische Updates und Angriffe von außen zu machen, gehen einige Distributionen einen anderen Weg.

Qubes OS [1] erreicht ein Maximum an möglicher Sicherheit beispielsweise mit verschiedenen virtuellen Maschinen, setzt aber einen geübten Nutzer mit ausreichend Zeit zum Einarbeiten voraus. Fedora Silverblue und Endless OS [2] arbeiten mit Flatpaks, einem nur lesbaren Root-Dateisystem und Updates in Form von Images, die sich zurückrollen lassen.

Resilient Linux basiert auf dem aktuellen Debian GNU/Linux “Buster” und dem Gnome-Desktop. Es will seinem Namen, der für Widerstandsfähigkeit und Ausfallsicherheit steht, unter anderem ebenfalls durch ein nur lesbares Root-Dateisystem gerecht werden. Dabei gleicht es von den erwähnten Systemen am ehesten einer normalen Distribution ohne weitere Maßnahmen zur Härtung (Abbildung 1).

Abbildung 1: Für den Anwender lässt sich oberflächlich nicht erkennen, dass im Hintergrund eine neue Architektur arbeitet. Das System verhält sich wie jedes andere Debian.

Erdacht und realisiert wurde Resilient vom italienischen Entwickler Marco Buratto von der Firma LumIT Innovation Labs. Buratto entwickelte daneben auch die Live-Distribution Secure-K OS und betreibt die Webseite Binary Emotions, die sich mit digitalen Informationssystemen auf der Basis des Raspberry Pi befasst.

Live-System auf der Platte

Die Grundidee zu Resilient Linux stammt von LiveNG [3], einem Konzept zum alternativen Erstellen von Live-Distributionen, das Buratto mit Unterstützung von LumIT ebenfalls entwarf. Dazu gehört ein eigenes Partitionsschema, das ein Update von Kernel und Initrd bei Live-Systemen ermöglicht. Die beiden Komponenten lassen sich bei den üblichen Live-Systemen mit ISO9660-Dateisystem nicht aktualisieren, weswegen sie sich für den Dauereinsatz ohne Installation nicht eignen.

Resilient setzt sein spezielles Partitionsschema für die Installation auf die Festplatten um. Dabei läuft das Betriebssystem selbst auf einer schreibgeschützten Partition mit ISO9660-Dateisystem. Ein weiterer Festplattenbereich, Persistenzpartition genannt, enthält die Unterschiede zum Live-System in Form von Systemaktualisierungen und nachinstallierten Anwendungen sowie die Benutzerdaten. Diese Anordnung bietet einige Vorteile.

Das gesamte System lässt sich sichern, indem Sie die Inhalte der Persistenz-Partition in ein Archiv packen. Ein weiterer Vorteil besteht darin, dass ein Angreifer die Root-Partition des Betriebssystems nicht direkt beschädigen oder kompromittieren kann, da Resilient sie nur lesend einbindet. Ein vorhandenes System lässt sich entsprechend recht einfach duplizieren oder wiederherstellen, indem man Resilient installiert und dann die gesicherte Persistenz-Partition in das neue Betriebssystem kopiert.

Vier Partitionen

Resilient verteilt sich auf insgesamt vier Partitionen. Auf den ersten beiden, auf unserem Testsystem sda1 und sda2, kommt das Dateisystem ISO9660 zum Einsatz. Auf sda1 liegt das schreibgeschützte Betriebssystem in derselben Form wie auf dem Live-Abbild. Auf der kleineren Partition sda2 mit demselben Dateisystem liegen neu installierte Kernel sowie die Initrd. Kernel-Updates überschreiben diese Partition.

Den Grub-Bootloader konfiguriert Resilient so, dass er sowohl auf BIOS- als auch auf UEFI-Systemen von der zweiten Systempartition sda2 bootet: Sie enthält stets die aktuellsten Kernel- und Initrd-Dateien. Die dritte Partition benötigt das System für die UEFI-Konformität und nutzt darauf FAT32 als Dateisystem (Abbildung 2).

Abbildung 2: Erst ein Blick auf Gparted und die Ausgabe des Befehls df -h offenbart, dass im Hintergrund ein angepasstes Live-System läuft.

Die Datenpersistenz erreicht Resilient durch eine vierte Partition (auf unserem Testrechner sda4), in die das System schreibt. Dabei kommt wie bei Live-Systemen und manchen USB-Sticks mit Persistenzfunktion Union Mount [4] zum Einsatz. Damit lassen sich von Live-CDs lokale Dateien (mit Ausnahme des Kernels) ändern. Optional verschlüsseln Sie diese Partition bei der Installation mit LUKS.

In der Praxis

Die Webseite des Projekts [5] erläutert das System ausführlich. Im unteren Bereich finden Sie einen Download-Link für die Desktop-Variante. Eine Version für Thin Clients befindet sich noch in der Entwicklung.

Nach dem Herunterladen des gut 2 GByte großen Abbilds transferieren Sie es wie üblich auf einen USB-Stick. Der Boot-Vorgang unterscheidet sich optisch nicht von jenem bei üblichen Distributionen. Danach steht ein Debian-Live-System ohne Auffälligkeiten in schlichtem Grau bereit (Abbildung 3).

Abbildung 3: Fensterdekorationen und Hintergründe hält das Projekt in schlichtem Grau, was die Konzentration auf die Inhalte fördert.

Alles bleibt wie gewohnt, bis Sie den Installer starten. Da es sich um ein Live-System handelt, arbeitet er anders, als gewohnt. Er besteht lediglich aus einem kleinen Fenster, das Sie zunächst auffordert, ein Passwort einzugeben, das sich persistence secret nennt (Abbildung 4).

Abbildung 4: Der Installer von Resilient schaufelt die Daten innerhalb von einer Minute auf die Festplatte und richtet das Partitionsschema und den Bootloader ein. Die Oberfläche könnte den Anwender allerdings besser durch die kurze Prozedur leiten.

Die Eingabe des Passworts veranlasst Resilient dazu, die Datenpartition (in unserem Fall sda4) mit LUKS zu verschlüsseln. Bleibt das Eingabefeld leer und klicken Sie auf die Schaltfläche write, so nimmt der Installer seine Arbeit auf, ohne zu verschlüsseln. Nach der Warnung, dass der Installer alle Inhalte des Datenspeichers löscht, passiert erst einmal scheinbar nichts – das Fenster mit der Eingabe für das LUKS-Passwort bleibt stehen.

Lediglich die Tatsache, dass der Lüfter unseres Notebooks plötzlich ansprang, ließ uns vermuten, dass im Hintergrund Aktivität herrschte. Die Ungewissheit war schnell beendet, denn bereits nach einer knappen Minute meldete der Installer Vollzug.

Ab diesem Moment lässt sich das System bereits von der Festplatte starten. Was dabei genau passiert, erklärt der Kasten “Installer-Magie”.

Schlankes System

Resilient stellt ein schlankes Basissystem mit lediglich der nötigsten Software bereit. Neben den vorinstallierten Gnome-Apps beschränkt sich die Distribution auf die Zugabe von Firefox ESR und Chromium als Browser. Alles Weitere obliegt Ihnen als Nutzer: Das Debian-Paketarchiv ist nur ein sudo apt install entfernt (Abbildung 5). Für einen routinierten Linux-Anwender stellt das gegenüber Systemen, die zahlreiche Anwendungen “auf Verdacht” einrichten, den besseren Weg dar.

Abbildung 5: Zusätzliche Software installieren Sie mit Apt oder grafisch mit Gnome Software. Letzteres ließ sich bei uns nicht über das Icon in der Gnome-Shell aufrufen. Auf dem Umweg über die Hilfsprogramme startete der Paketmanager dann aber.

Allerdings bekommen manche proprietären Dienste wie Dropbox Probleme mit der Struktur von Resilient: So verlangt diese Software ein Ext4-Dateisystem, sieht aber bei Resilient nur das darüberliegende UnionFS. In diesem Fall hilft die Open-Source-Implementation Maestral Dropbox [7].

Fazit

Das simple, aber effektive Konzept von Resilient Linux vermag voll zu überzeugen. Die Distribution arbeitet als Live-System auf der Festplatte, bei dem sich auch der Kernel aktualisieren lässt. Das nur lesbare Dateisystem und eine auf Wunsch verschlüsselte Datenpartition bieten einen wirksamen Schutz vor Fehlbedienung und Angriffen. Von diesen Maßnahmen bekommt der Anwender jedoch nichts mit, wenn er es nicht möchte: Hinsichtlich der Bedienung unterscheidet sich Resilient nicht von einem normalen Debian.

Der Trick mit einer zweiten Partition mit ISO9660-Dateisystem, von der der jeweils aktuelle Kernel bootet, ermöglicht ein Live-System auf der Festplatte, das nicht veraltet. Als einziger Kritikpunkt sticht der Installer ins Auge, der den Anwender nach dem Start bis zum Abschluss der Einrichtung darüber im Unklaren lässt, ob alles funktioniert oder etwas schiefgegangen ist.