Lange galt der Grundsatz nur eine möglichst vollständige Verschlüsselung, schützt Daten auch wirklich sicher. Lösungen wie eCryptFS wurden daher zugunsten LUKS-basierter Ansätze aufgegeben. Diese Tendenz gipfelte zuletzt im Versuch, GRUB noch weiter aufzubohren, um eine Verschlüsselung der Boot-Partition zu ermöglichen. Doch macht diese Entwicklung Sinn oder ist sie nicht eher eine Sackgasse?
Dazu muss man sich vergegenwärtigen, warum die vollständige Verschlüsselung des kompletten Systems eigentlich als Ideal aufgestellt wurde. Vier wesentliche Faktoren spielten hier eine Rolle:
- Sicherstellen, dass keine sensiblen Daten in unverschlüsselten Bereichen gespeichert werden.
- Verhindern, dass Angreifer die unverschlüsselte Boot-Partition manipulieren.
- Verhindern, dass Angreifer über Einsicht in die Systempartition etwas über das System erfahren.
- Schwer zu lösende Probleme beim Logout und mit der Swap-Partition umgehen.
Im Grunde genommen sollte der Ansatz also vor allem die Unzulänglichkeiten von Linux umgehen. Das offensiv vorgetragene Sicherheitsargument sollte das nur übertünchen. Meiner Ansicht nach ist diese Entwicklung letztlich eine Sackgasse bzw. ein sterbender Entwicklungszweig, den man mittelfristig aufgeben wird. Dazu muss man sich nur ein paar Fragen stellen und nicht von den üblichen Linux-Antworten: „Das war schon immer so“ und „Das sind Unix-Prinzipien“ abspeisen lassen. Denn warum speichert das System eigentlich überhaupt Nutzerdaten außerhalb der Home-Partition ohne Kontrolle des Anwenders, warum gibt es keinen verifizierten Startvorgang, warum enthält die Systempartition durch die Verschränkung von Basissystem und Anwenderkonfiguration eigentlich sensible Informationen über das System?
Sicherheit kann man auch anders erreichen, ohne jedes Problem mit Verschlüsselung gleichsam einem Vorschlaghammer zu erschlagen. Sondern dieses Mittel nur dort einsetzt, wo man sie wirklich benötigt. Android ist da ein interessantes Vorbild – auch weil vieles an der Android-Basis so oder so ähnlich auch für Linux verfügbar ist. Wie das idealerweise bei Android funktioniert, kann man bei Interesse sehr gut erklärt in der GrapheneOS-FAQ nachlesen.
Im Grunde genommen basieren die Systeme auf einer Verschränkung von Verifizierung und Verschlüsselung. Firmware und Systempartition sind einfach nur Kopien der offiziellen Veröffentlichung und ihre Integrität wird lediglich beim Start verifiziert. Weil die Inhalte dieser Images öffentlich bekannt sind, braucht es keine Verschlüsselung. Die Anwendungen und Konfigurationen des Systems – also die Sachen, die ein System unterscheidbar machen – liegen in der Datenpartition. Diese muss natürlich verschlüsselt ein. Die wirklich sensiblen Daten liegen dann in den jeweiligen Nutzerprofilen, die logischerweise ebenso verschlüsselt und gegeneinander abgeschirmt sind.
Ich gehe aktuell davon aus, dass die aktuelle Situation bei Android ein Vorbild dafür ist, wo die Reise für Linux allgemein hingeht. Hierfür muss sich einiges ändern, aber viele grundlegende Umbauten sind schon länger in Arbeit und erreichen vermutlich demnächst relevante Nutzergruppen. Dazu zählt der usrmerge, den viele Distributionen zwischenzeitlich abgeschlossen haben. Unveränderbare Systeme wie SIlverblue, Kinoite, MicroOS etc. sind ebenfalls auf dem Vormarsch und bereiten den Weg für Systemimages, die nicht verschlüsselt werden müssen, weil sie nichts Geheimes enthalten. Beide Vorgänge führen zudem zu mehr Disziplinierung bei den Maintainern, die in der Vergangenheit Konfigurationen gerne außerhalb von /etc ablegten. Containerbasierte Ansätze im Serverbereich, aber auch Sachen wie Flatpak/Snaps am Desktop führen zur Frage, was die klassische Paketverwaltung leisten kann und soll und wie man zukünftig Anwendungen installiert. Zuletzt seien noch die Entwicklungen bei systemd genannt, um Verschlüsselung für Anwenderprofile anders umzusetzen.
Natürlich wird es wieder jene geben, die finden, dass dies alles überflüssig ist und für die das bisherige System ausreichend funktioniert. Diese Veränderung ist aber eine Chance, weil sie hässliche Workarounds beseitigt, mit denen man aktuell Sicherheitsprobleme zu adressieren versucht. Dazu gehören Funktionen in GRUB, die nicht in einen Bootloader gehören und dieses „Monster“ immer unwartbarer machen, aber notwendig aufgrund fehlender Verifizierung und des folglich fehlenden Manipulationsschutzes sind. Dazu gehören hässliche Lösungen, um vollständig verschlüsselte Server so zu starten, dass eine Remote-Passworteingabe möglich ist. Dazu gehören aber auch schlimme Tricks, um vollständig verschlüsselte Systeme Multiuser-tauglich zu machen, indem man 7 LUKS-Passwörter erstellt und anschließend (bestenfalls) die Profile mit eCryptFS gegeneinander schützt, das ebenfalls mehr eine Sammlung unlösbarer Bugs und Limitationen, denn eine ausgegorene Lösung darstellt.
Denkt man diese Entwicklung größer, dann gehören auch solche Sachen wie PolKit (ehm. PolicyKit) und fein austarierte Sudo-Konzepte dazu, welche in immer mehr Distributionen umfassend für die Privilegierung von Aufgaben einsetzt wird und das alte Root-System ablöst, bei dem man alles mit Adminrechten laufen lassen konnte oder gar nichts. Sicherheitsframeworks wie SELinux oder AppArmor sind bereits in den letzten Jahren in nahezu alle Distributionen eingezogen und führen Beschränkungen jenseits klassischer Dateirechte ein. Mit der Abkehr von X.Org zugunsten von Wayland bei wichtigen Distributionen 2022 wird auch dieses Sicherheitsrisiko endgültig in Richtung Abstellgleis geschoben.
Das sind spannende Entwicklungen, am Ende wird Linux deutlich anders aussehen, als es noch vor knapp 5-10 Jahren aussah, bevor diese Entwicklung in Gang kam.
Ich denke, ein großes Problem bei der Ausrichtung der Entwicklung ist nach wie vor die Grundidee ein Linux-Betriebsystem möchte „multi-purpose“ und „multi-user“ sein. Der Einsatz als Server-Betriebssystem hat aber – meiner Meinung nach – andere Schwerpunkte als der Einsatz als Desktop-Betriebssystem. Auch wenn es da sicherlich Überschneidungen gibt. Im Prinzip liegt das Hautaugenmerk immer auf dem sicheren Server-Betrieb, wo Linux halt seine relevanten Marktanteile hat. Der Desktop-Betrieb ist davon ausgehend dann „multi-purpose“ und quasi auch der eigentliche Einsatz, in dem „multi-user“ heute noch relevant ist. Und da gibt es derzeit keine Marktanteile, die eine konzentrierte Entwicklung verlangen. Ist also auch kein Wunder, wo wir heute damit stehen. Bleibt zu hoffen, dass sich da jetzt mal eine klarere Trennung etabliert. Nicht nur zugunsten der Verschlüsselungszenarien, sondern ganz generell.
Eigentlich ist ein Multiusersystem doch hauptsächlich auf dem Server relevant, da dort oft mehrere Admins mit unterschiedlichen Zuständigkeiten und Berechtigungen agieren. Laptops und Desktop-PCs werden hingegen, vor allem im 0815 Privathaushalt, viel öfter alleine benutzt.
Das war völliger Quark von mir … Wollte eigentlich darauf hinaus, dass es für den Desktop-Betrieb mehr Weiterentwicklung (wie systemd-homed) braucht, um tatsächlich wieder als sicheres Mehrbenutzersystem eingesetzt werden zu können. Sinn von sowas wie Fedora Workstation wäre ja, dass Benutzer an beliebigen Geräten mit ihrer Toolbox und ihrem Homeverzeichnis arbeiten könnten, und man nicht mehr an ein Gerät gebunden wäre.
Mir erscheinen da halt die notwendigen Voraussetzungen für die Benutzerverwaltung etwas anders zu sein als für einen Server. Wenn die bisherigen Konzepte für Mehrbenutzersysteme den Sicherheitsanforderungen für den Server-Betrieb nicht mehr erfüllen würden, dann hätten wir da schon eine Neuentwicklung.
Ich hatte mich immer gewundert, warum es /usr/bin und /bin mit unterschiedlichen Programmen gibt und es ist völlig an mir vorbeigegangen, dass das mittlerweile Vergangenheit ist (zumindest auch auf meinem Manjaro)! Dazu musste ich nur erst mal nach „usrmerge“ suchen 😉
Sorry, aber ein System von dem gebootet wird, deren Programme offen liegen, brauchst Du gar nicht zu verschlüsseln, weil schon das Tool für den Integritätscheck, der beim Booten nötig ist, vom Angreifer geändert worden sein kann um seine Änderungen am Bootvorgang zu verbergen. Der wartet dann in Rootkitmanier auf das Dekodieren der Homepartition und greift dann halt die Daten ab.
An der Prämisse kranken alle Ansätze von eCryptFS bis Systemd-HOMED und dafür gibt es keine Lösung.
Um das zu lösen, gibt es ja den Secureboot mit verschlüsselter Bootplatte, damit jemand das nicht ändern kann. Das geht auch mit Linux, aber dazu muß es ein ganz neues System sein, damit der Bootloader signiert ist und es auch kann. Im LegacyBootmode kann man das jedenfalls nicht leisten.
Ich zitiere einfach mal:
„Im Grunde genommen basieren die Systeme auf einer Verschränkung von Verifizierung und Verschlüsselung“
Und nein, bei einer verifizierten Bootkette mit einer vertrauenswürdigen Wurzel muss nicht alles verschlüsselt sein. Die vollständige Verschlüsselung ist lediglich ein Workaround, weil Linux das aktuell noch nicht bieten kann. Die Bausteine sind aber eigentlich alle da und es wird auch fleißig daran gearbeitet.