Der Sinn eines verifizierten Systemstart (engl. „verified boot“) ist sicherzustellen, dass beim Start Komponenten aus vertrauenswürdigen Quellen geladen werden und es Angreifern nicht gelingt, manipulativ in den Prozess einzugreifen. Grundsätzlich ist vieles davon Linux nicht fremd, aber wird zum Teil aktiv unterlaufen.
Einordnung und Kontext
Die Themen verifizierte Systemstart, Secure Boot und TPM beschäftigen mich momentan. Befasst man sich mit vollständig verschlüsselten Systemen, der zusätzlichen Bindung an TPM bzw. Secure Boot, zusätzlich gegeneinander durch Verschlüsselung abgeschirmten Home-Verzeichnissen und weiterführenden Fragen, wie der Sicherheit biometrischer Verfahren und welche zusätzlichen Schutzmaßnahmen durch zusätzliche Hardware-Tokes wie FIDO2 (YubiKey) möglich sind, dann ist der verifizierte Systemstart letztlich ein logisches weiteres Puzzlestück.
Natürlich handelt es sich dabei um „advanced“ Sachen. Wer sein System nicht verschlüsselt, andauernd irgendwelche Programme von Dritten herrunter lädt und sich Kernel aus irgendwelchen PPAs installiert, der hat dadurch überhaupt keinen Sicherheitsgewinn. Ich respektiere es auch, wenn man solche „Trusted Computing“-Konzepte ablehnt oder ihnen zumindest misstraut. Ich ermuntere dennoch dazu, hier nicht einfach irgendwas nachzuplappern, weil (insbesondere in der deutschen Community?) in dem Bereich viele urbane Legenden kursieren. Neben abstrakten Informationsquellen ist meine konkrete Arbeitsgrundlage für viele Experimente das Arch Linux-Wiki und das ist nun wirklich kein Vertreter von „Corporate Linux“.
Der Blick über den Tellerrand
Der verifizierte Systemstart ist dabei keinesfalls irgendwie exotisch. Systeme wie iOS oder Android haben das ebenso implementiert, wie Windows 11 oder macOS. Das Prinzip ist einfach: Es wird eine vollständige Vertrauenskette aufgebaut. Angefangen von einer vertrauenswürdigen (Hardware-)Wurzel, bei der jeweils eine geladene Stufe die nächste authentifiziert. Also von der Hardware, über den Bootloader zu den entsprechenden Systempartitionen bis hin zu den Benutzerdaten. Das entsprechende Verfahren kann z. B. hier für Android nachgelesen oder ist hier sehr anschaulich viel Windows 11 (vor allem Abbildung 1 für Leser ohne Lust auf langwierige technische Inhalte) dargestellt. Solche Verfahren können noch mit einem Rollback-Schutz und anderen Sachen kombiniert werden, aber das führt jetzt hier zu weit.
Was kann Linux theoretisch?
Folgende Boot-Abfolge kann Linux bzw professionelle Linux-Distributionen momentan theoretisch bieten:
- UEFI startet shim (was letztlich nur eine Zertifikatesammlung mit Signatur von Microsoft ist). Das kann in das s. g. „TPM boot measure“ (keine Ahnung, wie man das gut übersetzt?) einbezogen werden.
- Shim ruft den Bootloader (i. d. R. GRUB) auf, der mit einem Schlüssel des Distributors signiert ist. GRUB kann theoretisch in das „TPM boot measure“ einbezogen werden.
- Alternativ ist theoretisch der direkte Start über ein Unified Kernel Image möglich.
- Der Bootloader ruft den Kernel auf und übergibt initrd. Der Kernel ist durch den Distributor signiert, initrd ist nicht signiert oder validiert. Kernel und initrd können theoretisch in „TPM boot measure“ einbezogen werden.
- Bei verschlüsselten Systemen fragt initrd nun nach dem Passwort für die verschlüsselte Root-Partition. Es erfolgt keine Verifikation, ob initrd manipuliert oder ähnliches wurde. Es erfolgt der Übergang ins Root-Dateisystem. Die per LUKS verschlüsselte root-Partition kann an den TPM Secure Boot Status gebunden werden.
- Abschließend erfolgt eine Anmeldung des Benutzers in der Loginmaske der Desktopumgebung. Die Daten sind bereits vorher entschlüsselt, sofern der Administrator nicht eine individuelle Konfiguration mit systemd-homed, eCryptFS oder separaten LUKS-Partitionen pro Benutzer eingerichtet hat.
Was macht Linux faktisch?
- Secure Boot wurde deaktiviert, weil man irgendwo gelesen hat, dass man das tun sollte.
- TPM ist ebenfalls deaktiviert, auf der Modul-Blacklist oder wird einfach nur nicht beachtet. Selbst wenn TPM nicht deaktiviert ist, macht eine Einbeziehung in GRUB oder initrd momentan wegen des unzureichenden Implementierungsgrades keinen Sinn.
- GRUB lädt ein nicht signiertes initrd und einen nicht signierten Kernel.
- Bei verschlüsselten Systemen fragt initrd nun nach dem Passwort für die verschlüsselte Root-Partition. Es erfolgt keine Verifikation, ob initrd manipuliert oder ähnliches wurde. Es erfolgt der Übergang ins Root-Dateisystem.
- Abschließend erfolgt eine Anmeldung des Benutzers in der Loginmaske der Desktopumgebung. Die Anmeldung ist Makulatur, da die Daten bereits vorher entschlüsselt wurden, daher erfolgt oft ein einfacher Autologin.
Ist das ein Problem?
Das hängt wie bereits oben geschildert, von der Frage ab, welches Sicherungsbedürfnis man hat. Nutzt man sowieso keine Verschlüsselung, braucht man weitere Schutzmaßnahmen eh nicht. Insbesondere auf Entwicklungssystemen ohne schutzwürdige Daten verzichtet man häufiger auf Verschlüsselung. Hier kann man dann also auch nach Belieben mit nicht signierten Kernel, selbst gebauten Modulen etc. arbeiten.
Nutzt man eine Verschlüsselung nur, um Gelegenheitsblicke von neugierigen Kollegen, Freunden oder Familienmitgliedern zu entgehen, dann benötigt man weiterführende Maßnahmen ebenso eher nicht. Es sei denn man hat eine Tochter, die gerade an einer Bewerbung für den Geheimdienst als Hackerin arbeitet.
Hat man aber ein Schutzbedürfnis für sich selbst erkannt und nutzt ein vollständig verschlüsseltes Betriebssystem, um seine Daten sicher vor den Blicken professioneller Angreifer zu schützen, dann hat der aktuelle Zustand erhebliche Schwachstellen und einige zumindest seltsame Aspekte:
- Man startet ein verschlüsseltes System von einer i.d.R. unverschlüsselten boot-Partition, ohne zu prüfen, was eigentlich mit initrd und Kernel passiert ist und gibt dort das Passwort ein. Dieses Problem wird aktuell gelöst durch eine verschlüsselte Boot-Partition, was aber GRUB immer mehr aufbläht und noch unwartbarer macht als es eh schon ist.
- Das System lässt sich einfach kopieren und danach mit Brute Force so lange „quälen“ bis man drin ist. Die Verschlüsselung mit LUKS kennt dagegen keine Schutzmaßnahmen und verhindert das auch nicht.
- Man gibt ein Passwort beim Start ein, um das Betriebssystem zu entschlüsseln und entschlüsselt nebenbei die Benutzerdaten. Der eigentliche Benutzerlogin ist nur Makulatur und weil das den meisten Anwendern klar ist, überspringen sie oft auch den Benutzerlogin per Autologin.
- Benutzerdaten sind bei Multiuser-Systemen nur mit den UNIX-Rechten gegeneinander abgeschirmt und je nach Distribution nicht mal das.
Schlussbemerkung
Das Thema ist perspektivisch kein „Entweder-Oder“, sondern ein „Und“. So wie in der Vergangenheit immer die Möglichkeit bestand, nicht verschlüsselte Systeme zu nutzen, obwohl die Distributionen die LUKS-Verschlüsselung zunehmend prominenter in den Installationsroutinen platzierten, so wird auch der verifizierte Startvorgang Einzug halten für jene, die es benötigen oder dies zumindest glauben bzw. wohl eher fürchten. Alle anderen können, aber müssen dies nicht nutzen. Unstrittig ist jedoch, dass man aktuell ein bisschen hinter den anderen Betriebssystemen her rennt und nicht mal die Möglichkeiten ausreizt, die man schon hat. Spannend dürfte sein, was Enterprise-Distributionen wie SUSE Linux oder Red Hat Enterprise Linux hier in den nächsten Jahren umsetzen. Bei beiden Firmen ist man an den Themen dran.
Das war (voraussichtlich) der letzte Artikel zu diesem Thema für die nächste Zeit. Alle, die von Secure Boot, TPM, GRUB, verified Boot & Co schon genervt sind, können also entspannt in die Zukunft schauen 😉
Von welchem Hersteller ist eigentlich Dein TPM-Chip? Kannst Du dazu mal ein Tutorial machen? Dass fänd ich toll. Mich würde sehr interessieren wie man Hersteller & Modell herausfindet und dazu noch die Versionsnummer des aktuell genutzten Microcodes. Das wäre ja wichtig für Updates der TPM-Chip-Firmware, damit’s uns nicht beißt wie damals 2017 bei Infineon. Wo bekommt man Updates? Und wie spielt man die ein? Gerne Betriebssystemübergreifend! Vielen Dank. Übrigens: tolle Posts!
Das kannst du doch einfach dem Datenblatt deines Geräts entnehmen? Ich habe ein Infineon SLB9670. Deine Anspielung auf 2017 bezieht sich auf die Lücke CVE-2017-15361?
HP bietet ein TPM-Konfigurations-Tool für Windows. Updates für die Firmware des gesamten Gerätes kann man im HP UEFI einspielen. Nicht optimal, aber wenn wir anfangen uns über die Firmware in unseren Geräten Gedanken zu machen, können wir gleich einpacken.
„Nicht optimal, aber wenn wir anfangen uns über die Firmware in unseren Geräten Gedanken zu machen, können wir gleich einpacken.“
Gegeben dein Gerät wird von LVFS unterstützt sieht das auf Linux gar nicht schlecht aus. Mein Lenovo T470 wird dadurch schön auf aktuellem Stand gehalten.
LVFS ist toll, aber hat nichts mit FOSS zu tun. Die darüber verteilte Firmware ist meist trotzdem Closed Source.
Mich würde ja das Thema Verifikation ohne Verschlüsselung auf z.B. rootfs interessieren, d.h. um festzustellen, ob die Partition seit dem letzten Einhängen im System unautorisiert geändert wurde.
Dafür wurden bisher zwei Lösungen entwickelt: dm-verity und dm-integrity – abhängig davon, wie die root-Partition eingehängt wird. Richtig Sinn ergibt das aber erst, wenn wir bei root-Partitionen in den Bereich von „immutable“ Systemen wechseln, aber das ist ja bei einigen Distributionen gegenwärtig in Arbeit. Beide Verfahren profitieren von Vorarbeiten im Android-Bereich und werden gegenwärtig für Linux adaptiert.
Du könntest die Nutzerdaten (pro User) auf eine eigene verschlüsselte Partition auslagern. Dann werden die Nutzerdaten erst durch Pammount beim Login entschlüsselt (sofern Du das entsprechend konfigurierst). Damit wäre dann Userpassword= Luks Passwort der Nutzer Partition.
Viele Grüße
Christian
Ja, das ist theoretisch möglich, aber praktisch so durch keine Distribution ootb implementiert, oder? Aber du hast recht und ich habe den Vergleich zwischen Möglichkeiten und Ist-Zustand oben noch mal angepasst.
Hi
nein ootb habe ich das bisher nicht gefunden: Ich habe zwei SSDs in meinem System: Eine fürs OS,eine für meine Daten. Ein Setup mit zwei Verschlüsselungen unterstützt kein System direkt.
Es war schon schwierig, die zweite SSD bei der Installation zu berücksichtigen….
Hallo Gerrit, ich stimme Dir voll zu, dass in diesem Bereich auf der Linuxseite mehr passieren muss. Ich hatte beruflich dauernd mit heikleren persönlichen Daten anderer Menschen zu tun, bei denen klar war, dass diese Informationen niemanden etwas angehen. Diese Arbeitssituation hat man überall, wo mit Menschen gearbeitet wird. Es gab eine Zeit, in der die höhere Sicherheit von Linux-Betriebssystemen ein Argument war … Wenn dieses Argument weg fällt, wird Linux zum Spielzeug. Bisher konnte die fehlende Kapital- und Marktmacht damit ausgeglichen werden. Sollte sich in den Köpfen festsetzen, Linux sei das unsicherste System, dann war es das.
Du hast bei “was kann Linux theoretisch” die Unified Kernel Images übersehen. Damit wird die signaturlücke bei initrd geschlossen, und Grub braucht man auch nicht mehr, da Linux direkt von der Efi-Firmware gestartet werden kann. In der Praxis ist mir noch keine Distri bekannt, die dies einrichtet.
Ich hatte den Eindruck, dass es sich dabei eher um tote Zweige der Entwicklung handelt. Irgendwie scheinen sich Lösungen, die Grub ersetzen wollen, einfach nicht flächendeckend durchzusetzen, sondern es braucht immer Varianten, die Grub einbeziehen.
Nichtsdestoweniger hast du natürlich recht und es gehört in die Katergorie „Kann Linux theoretisch“.
Und da entsteht bei mir die Frage, warum so etwas wie die erwähnten Unified Kernel Images nicht sofort eingepflegt werden, falls sie die Sicherheit erhöhen …
Mir wird beim Lesen noch eine andere Sache klar: Jahrelang habe ich passiv verstehend bei Veränderungen im Linux-Bereich mithalten können. Mittlerweile ertappe ich mich immer öfter bei einem inneren Stöhnen, wenn ich von neuen Entwicklungen lese „Was ist denn des nun schon wieder! Braucht man das?“ So auch bei Dirks Erwähnung von Unified Kernel Images . Ich wollte schon schreien: Bitte eine Erklärung auf dem Niveau für Neunjährige, doch nein, ich schaue erst einmal bei Wikipedia nach.
„andauernd irgendwelche Programme von Dritten herrunter lädt und sich Kernel aus irgendwelchen PPAs installiert, der hat dadurch überhaupt keinen Sicherheitsgewinn.“
Da hast du mich aber erwischt!
Ich finde den Beitrag sehr spannend, gut begründet und weiterführende Quellen geben dem ganzen noch das i-Tüpfelchen. Super Blog-Beitrag!