Sicheres Linux-Desktop-Betriebssystem

Es soll untersucht werden, welche Technologien bei der Einrichtung eines möglichst sicheren und trotzdem bequem benutzbaren Linux-Desktop-Betriebssystem von Nutzen sein können. Als Referenz wird ein Lenovo ThinkPad aus der E-Serie verwendet. Es soll außerdem evaluiert werden, welchen Nutzen, welche Nachteile und welche Schwachstellen die Technologien haben und gegen welche Angreifer*innenmodelle sie letztendlich schützen.

Sicherheitsfunktionen von Motherboard und BIOS

Ein Blick ins BIOS des vorliegenden Notebooks zeigt, dass bereits hardwareseitig Sicherungstechnologien vorhanden sind. Einerseits ist ein TPM 2.0 Modul verbaut, andererseits wird Intel SGX unterstützt.

Das TPM 2.0 Modul ermöglicht die „Secure Boot“-Funktionalität und die Passwortsperre des BIOS. Es unterstützt ausßerdem das Erzeugen von Zufallswerten, die Generierung und Speicherung von Schlüsseln und das Verschlüsseln und Signieren von Daten. Bei Verwendung aktueller Kernel ist es als /dev/tpm0 eingebunden und kann vom Userspace aus verwendet werden.

Die „Intel SGX“-Technologie ermöglicht das Ausführen sicherheitskritischen Codes in einem abgesicherten Bereich, der von anderem Code abgeschirmt ist. Welche genauen Funktionen das ermöglicht, und ob diese Technologie unter Linux nutzbar ist, wurde hier nicht weiter untersucht.

Des Weiteren kann im BIOS die „Internal Storage Tamper Detection“ aktiviert werden, durch die das Gerät automatisch heruntergefahren wird, wenn sich beim Erwachen aus dem Schlafzustand etwas an den internen Laufwerken geändert hat.

Um das Booten fremder Software zu verhindern, sollten alle Booteinträge, außer das gewünschte Betriebssystem, deaktiviert werden und die BIOS-Einstellungen mit einem Passwort geschützt werden.

BIOS Passwort

Das BIOS des betrachteten Notebooks unterstützt das Festlegen eines Supervisor-Passworts, welches den Zugriff auf bestimmte BIOS-Einstellungen sperrt. Optional kann eingestellt werden, dass es auch die anderen BIOS-Funktionen sperrt, auch die Auswahl von Booteinträgen bzw. sogar das Booten selbst.

Im Netz finden sich viele Anleitungen, ein solches Passwort zurückzusetzen oder sogar zu umgehen. Entweder durch Eingabe eines Masterpasswortes von der Hersteller*in bzw. aus dem Netz oder durch vorübergehendes Entfernen der CMOS-Batterie oder durch Kurzschließen eines Security-Chips auf der Rückseite des Mainboards. Der Lenovo-Support hat, auf Anfrage, versichert, dass es kein Masterpasswort für das betrachtete Gerät gibt, das Entfernen der CMOS Batterie auch nicht funktioniert und das Kurzschließen des Sicherheitschips das Mainboard zerstört.

UEFI Secure Boot

„UEFI Secure Boot“ ist eine, ursprünglich für Microsoft-Betriebssysteme eingeführte, Technologie, die vor dem Booten eines Bootimages dessen Signatur überprüft und das Booten ggf. unterbindet. Microsoft ist dementsprechend die Certificate-Authority, signiert aber auch Software anderer Hersteller*innen.

Linux-Betriebssysteme verwenden häufig einen kleinen Bootloader namens „shim“, der von Microsoft signiert ist, und seinerseits die Signaturen des Kernels und der Kernelmodule prüft. Im shim können auch eigene Public-Keys hinterlegt werden, um selbstsignierte Kernel und Kernelmodule zu verwenden. Diese Public-Keys müssen beim nächsten Bootvorgang erst per Hand von der Nutzer*in bestätigt werden und werden dann vom shim in einen NV-RAM geschrieben, welchen das Betriebssystem nicht selbstständig modifizieren kann.

Diese Funktion des shim ermöglicht es Angreifer*innen natürlich, trotz Secure-Boot Schadcode zu injizieren, wenn sie Schreibzugriff auf die Bootpartition bekommen und kurzzeitig auf die Hardware zugreifen können. Dieser Schreibzugriff sollte allerdings durch die Beschränkung auf einen Booteintrag und die Passwortsicherung des BIOS verhindert werden, sofern die Angreifer*in das Gerät nicht aufschraubt.

Sicheres Installationsmedium

Bei der Installation des Betriebssystems ist Vertrauen in alle Hardware nötig. Es muss aber auch dem Betriebssystem vertraut werden, von dem aus das Installationsmedium geladen, bzw. geprüft wird, da es sonst bereits Schadcode injizieren kann, bevor das neue System installiert wurde. Um nicht einem einzigen Rechner vertrauen zu müssen bietet sich folgendes Vorgehen an, falls ein USB-Stick mit Schreibschutzschalter zur Verfügung steht:

Der Schreibschutz wird deaktiviert und das Installationsimage wird auf den USB-Stick geladen. Im Anschluss wird der Schreibschutz aktiviert und eine Prüfsumme über die geschriebene Partition gebildet. Diese Prüfsumme wird mit der Referenzprüfsumme von der Website der Betriebssystementwickler*innen verglichen. Das Berechnen und Vergleichen der Prüfsumme kann nun auf beliebig vielen Maschienen wiederholt werden. Wegen des Schreibschutzes können diese das Installationsimage nicht modifizieren. Wenn am Ende nur eine der Maschienen vertrauenswürdig ist, und die Prüfsumme auf allen Maschienen bestätigt wird, muss der Installer intakt sein.

Readonly-Laufwerk

Ein Laufwerk mit Schreibschutzschalter könnte auch für die Installation der unverschlüsselten Bootpartition des Betriebssystems verwendet werden. Das wäre insbesondere bei einem Dualboot mit einem Microsoft-Betriebssystem sinnvoll, da Microsoft die CA für Secure-Boot ist und dem entsprechend unbemerkt Modifikationen am Linux-Bootimage vornehmen könnte. Der Schreibschutz dieses Laufwerks könnte immer aktiviert sein und könnte temporär deaktiviert werden, wenn das vertrauenswürdige Linux-System Updates des Bootloaders durchführt.

Für das Notebook ist die Verwendung des vorhandenen USB-Sticks mit Schreibschutz bedenklich, da es einfacher sein könnte, den USB-Stick unbemerkt zu entwenden und zu infizieren, als das Notebook unbemerkt aufzuschrauben und zu modifizieren.

Verschlüssellung

Self-Encrypting-Drives

Viele moderne SSDs haben AES-Verschlüssellung bereits in ihrer Hardware integriert. Das bietet einerseits die Möglichkeit, die Daten vor Zugriff durch Fremde zu schützen. Andererseits ermöglicht es auch das schnelle und zuverlässige Löschen der gesammten SSD durch überschreiben des Schlüssels. Das BIOS des vorliegenden Gerätes bietet die Möglichkeit, Passwörter für die eingebauten SSDs festzulegen. Die entsprechende SSD wird dann per ATA angewiesen, den AES-Schlüssel mit dem Passwort zu verschlüsseln. Der AES-Schlüssel verlässt dabei niemals die SSD. Da das gewählte Passwort Hersteller*innenabhängig umgewandelt wird, bevor es an die SSD übertragen wird, ist es nicht ohne weiteres Möglich, die SSD dann in einem anderen System zu verwenden. Das Umwandlungsverfahren ist (im Fall des vorliegenden Gerätes) bekannt und bietet somit keine zusätzliche Sicherheit.

Die Selbstverschlüssellung steht teilweise wegen achtlosen Implementierungen mit Sicherheitslücken und wegen der Möglichkeit, bewusster Backdoors, in der Kritik. Letztere könnten auch durch Regierung vorgeschrieben sein. Es ist also besser, sich auf quelloffene Verschlüssellungssoftware wie LUKS zu verlassen.

Zumindest für das Löschen alter Daten, kann es nicht schaden, die Funktionen der SSD trotzdem zu verwenden, sofern sich nicht darauf verlassen wird. Um die SSD anzuweisen, alle Daten zu löschen, wird eine „Physical Security Identification“-Nummer benötigt, die auf der SSD-Hardware zu finden ist. Diese muss korrekt an die SSD übertragen werden. Sonst verweigert sie das Generieren eines neuen AES-Schlüssels. Unter Linux kann das Werkzeug „sedutil“ verwendet werden. Der konkrete Befehl lautet sudo sedutil-cli --yesIreallywanttoERASEALLmydatausingthePSID <PSID> <Drive>. Damit dieser funktioniert, muss bereits ein Passwort gesetzt sein, was sich mit sudo sedutil-cli --initialsetup <Password> <Drive> und einem Reboot bewerkstelligen lässt.

Linux Unified Key Setup

LUKS bietet einfache Verschlüssellung von Laufwerken oder Partitionen unter Linux. Es verwendet dafür das „dm-crypt“-Kernelmodul, welches eine transparente Verschlüssellungsschicht unter dem Dateisystem zur Verfügung stelt. LUKS Partitionen/Laufwerke bestehen aus einem Header und den verschlüsselten Daten. Im Header befindet sich ein Masterkey für die Entschlüssellung, welcher mit einem (oder mehreren) Passwörtern verschlüsselt ist. Ohne den Header ist der Rest der Daten unbrauchbar. Es bieten sich also extra Backups des Headers an. Bei SSDs ist zu beachten, dass überschriebene Header nicht unbedingt physisch gelöscht werden, sondern ggf. nur auf eine Liste freigegebener Blöcke verschoben werden. Es darf also nicht davon ausgegangen werden, dass die Daten mit Hilfe alter Passwörter nicht mehr entschlüsselt werden können. Um dieses Problem zu umgeben, könnte der LUKS-Header auf eine HDD ausgelagert werden, die dann zuverlässig überschrieben werden kann.

Distribution und Softwarequellen

Es gibt spezielle Linux-Distributionen, deren Hauptziel es ist, ihren Benutzer*innen möglichst viel Sicherheit und Anonymität zu bieten.

Qubes OS

Ein solches Betriebssystem ist Qubes OS. In Qubes laufen alle Anwendungen in virtuellen Maschienen und sind somit von Anwendungen aus anderen VMs abgekapselt. Die virtuellen Maschienen können dabei unterschiedliche Betriebssysteme bewirten. Sowohl Unixartige als auch Windows. Auf dem Desktop werden die Fenster aus unterschiedlichen VMs durch unterschiedliche Rahmenfarben unterschieden. Sogenannte „Disposable VMs“ ermöglichen es, Programme in einer Umgebung laufen zu lassen, die nach der Ausführung komplett verworfen wird. Für jede VM kann separat eingestellt werden, ob sie eine Netzwerkverbindung bekommt und ob sie durch das Tor-Netzwerk bzw. ein VPN getunnelt wird. Für USB-Geräte muss explizit eingestellt werden, welcher VM sie zur Verfügung stehen. Für das Austauschen von Dateien und kopierten Daten in der Zwischenablage zwischen VMs bietet Qubes eigene Funktionen an.

Letzendlich bestehen aber auch immer Möglichkeiten, aus einer VM auszubrechen und das Hostsystem zu infizieren. Diese ausfindig zu machen und auszunutzen ist allerdings eine erhebliche Hürde, sodass die Virtualisierung durchaus von Nutzen ist. Insgesammt bietet Qubes OS zwar viele Sicherheitsmechanismen, ist aber auch mit zusätzlichem Verwaltungsaufwand und CPU- und RAM-Belastung verbunden.

Debian

Einen Kompromiss bieten herkömmliche Distributionen, die hohen Wert auf Stabilität und Sicherheit legen. Zwei solche Distributionen sind CentOS und Debian. Zwar wird CentOS als geringfügig stabiler erachtet, Debian bietet aber mehr und aktuellere Software und bessere Hardwareunterstützung und ist somit vermutlich besser für ein Desktopsystem geeignet.

In Bezug auf Bugreports fährt Debian eine sehr transparente Strategie. Auch sicherheitskritische Bug-Reports sind sofort öffentlich einsehbar. Probleme werden nicht „versteckt“. Das Security-Team untersucht und behebt sie dann mit höchster Priorität. Über eine „Debian Security Announce“-Mailingliste werden sicherheitsrelevante Informationen an Interessierte verteilt. Ein zusätzliches „Security Audit“-Team durchsucht Debians Softwarearchiv aktiv nach Sicherheitsbugs. Dies beschränkt sich aber auf wichtigere und verbreitetere Pakete und deckt somit nicht alle Pakete ab. Mit dem Werkzeug „debsecan“ lassen sich die installierten Programme auflisten, die von bekannten Sicherheitslücken betroffen sind. In der Testinstallation von Debian 10 sind zum Zeitpunkt des Schreibens alleine 10 installierte Programme von sehr dringenden Sicherheitslücken betroffen, die sich aus der Ferne ausnutzen lassen.

Verschiedene Sicherheitsdokumente geben ausführliche Hinweise und Anleitungen um Debian-Systeme möglichst sicher einzurichten. Dazu gehören die Rechtevergabe, Netzwerkkonfiguration, Kernel-Hardening, Firewalls, spezielle Sicherheitspakete für Integritätschecks und Einstellungsoptimierung und Sandboxing.

Es wird empfohlen, die Netzwerkverbindung erst nach der vollständigen Installation und Einrichtung herzustellen. Ein anderer Rechner kann dazu die aktuellsten Versionen der verwendeten Softwarepakete bereitstellen.

Debian installiert standardmäßig GRUB als Bootloader. Da GRUB die Manipulation von Booteinträgen erlaubt und eine eigene Konsole hat, sollte GRUB ebenfalls mit einem Passwort gesichert werden, was den Bootprozess allerdings noch umständlicher macht. Mit UEFI sollte sich Debian auch ganz ohne Bootloader booten lassen und diese Problematik somit zu umgehen sein. Inwiefern sich komplizierte Bootloader auch bei verschlüsselten Installationen vermeiden lassen, wurde hier nicht weiter untersucht.

OS Konfiguration

Es ist unter Linuxenthusiast*innen üblich, sich das System und die verwendeten Werkzeuge durch Anpassung der Konfigurationsdateien persönlich einzurichten. Es liegt nahe, diese Konfigurationsdateien einfach zum nächsten System herüberzukopieren. Dabei muss beachtet werden, dass viele solche Dateien direkt oder indirekt ausführbaren Code enthalten können und somit auch mit Schadcode infiziert werden können. Ein möglicher Ansatz um mehr Kontrolle und Überblick über Manipulationen an den Konfigurationsdateien zu bekommen, ist das Zusammenfassen all dieser Dateien, in einem Versionsmanager wie git und das pushen auf einen vertrauenswürdigen Server. Es können dann Softlinks auf dieses Repository erstellt werden um die Dateien an den ensprechenden Orten einzusetzen. Dieser Schritt lässt sich natürlich mit einem Bash-Script einfach automatisieren. Somit können Konfigurationsdateien komfortabel zwischen Maschienen synchronisiert werden und Änderungen detailliert nachvollzogen werden.

Sandboxing

Ein weit verbreitetes Sandboxing-Werkzeug ist „firejail“. Firejail kann unter anderem mit Hilfe von AppArmor und OverlayFS die Ausführungsumgebungen unterschiedlicher Programme in geeigneter Weise von einander trennen. Mit Hilfe von Xpra können auch X11-Anwendungen von einander separiert werden. Firejail kommt bereits mit Konfigurationsprofilen für viele Anwendungen. Das Firefox-Profil schränkt den Dateizugriff innerhalb des Home-Directories z. B. auf das ~/.mozilla- und das ~/Downloads-Directory ein. Mit OverlayFS lassen sich Anwendungen auch in einem Copy-on-Write-Dateisystem ausführen, welches Schreibzugriffe auf das eigentliche Dateisystem abfängt und die geschriebenen Dateien an einem spezifizierten Ort ablegt. Mit Wrapper-Scripts lassen sich z. B. Programme wie Webbrowser, PDF-Viewer und Office-Programme relativ transparent einkapseln. Selbst das starten einer Root-Shell in einer Sandbox mit OverlayFS ist möglich, sodass die Installation von Programmen oder die Änderung von Konfigurationsdateien getestet werden kann, ohne das eigentliche Dateisystem zu vermüllen. Für eine möglichst sichere Ausführung sollten die zahlreichen Konfigurationsmöglichkeiten im Detail untersucht und verstanden werden. Insbesondere mit Root-Zugriff ist es weiterhin möglich, aus der Sandbox auszubrechen.

Das Kernelmodul AppArmor, welches in Debian 10 standardmäßig aktiviert ist, ermöglicht auch eigenständig die Einschränkung von Netzwerk-, Datei-, Socketzugriff etc.. AppArmor-Profile können in /etc/apparmor.d/ abgelegt werden. Softwarepakete machen das bei ihrer Installation teilweise selbst.

USB Guard

Um mehr Kontrolle über angeschlossene USB-Geräte zu erlangen, kann das Werkzeug „USB Guard“ verwendet werden. Es erlaubt White- und Blacklisting von USB-Geräten und verwendet dafür die USB-Authorisierungsfunktionen des Linux Kernels. Es bietet ein GUI-Frontend für einfache Bedienung, einschließlich eines Popups, welches bei jeder Verbindung eines USB-Gerätes um Erlaubnis fragt, es einzubinden. Im vorliegenden Notebook ist davon auch die eingebaute Webcam betroffen. Eine Funktion die leider noch fehlt, ist die Anzeige und ggf. sogar die Einschränkung des Gerätetyps. Wenn sich ein USB-Stick also z. B. als Tastatur ausgibt, um die Kontrolle über einen Rechner zu übernehmen, hilft der USB-Guard nicht dabei, ihn als solche zu identifizieren.

Verschlüsseltes Backup

Gerade bei Verschlüsselten Laufwerken ist der vollständige Verlusst aller gespeicherten Daten nicht sehr unwahrscheinlich. Alle bekannten Speichermedien haben eine beschränkte Lebzeit. Backups aller wichtigen Daten sind also immer zu empfehlen.

Am besten sollte das gesammte System abgesichert werden, sodass es schnell wieder hergestellt werden kann und keine Neuinstallation bei Datenverlusst nötig wird. Es bietet sich an, Werkzeuge wie Partclone und Gzip zu verwenden, um nur genutze Blöcke zu replizieren und diese zusätzlich zu komprimieren. Bei verschlüsselten Daten ist das allerdings nicht möglich. Es sollte allerdings möglich sein, die Partitionsstruktur abzuspeichern, die unverschlüsselten Partitionen einzeln komprimiert abzulegen und das entsperrte Mapping der verschlüsselten Partition(en) im Klartext komprimiert als Backup zu replizieren. Um auch das Backup zu verschlüsseln können die Backup-Befehle entweder einzeln durch gpg gepipet werden oder auf eine, ihrerseits LUKS-Verschlüsselte, Festplatte abgelegt werden. Um einen Konsistenten Abzug des Festplattenzustandes zu machen, könnte ein kleines Backup-Betriebssystem auf einer separaten Partition zum Einsatz kommen, welches die Partitionen im ungenutzen Zustand kopiert.

Es wird empfohlen, das Backup im Anschluss immer nochmal zu prüfen. Vorher sollten durch den Befehl echo 3 | sudo tee /proc/sys/vm/drop\_caches die Caches geleert werden.

Da häufige Backups der gesammten Festplatte relativ viel Zeit und Ressourcen in Anspruch nehmen, bietet es sich an, stattdessen inkrementelle Backups des Home-Directories anzufertigen und die Backups der gesammte Festplatte nur gelegentlich durchzuführen. Das geht im laufenden Betrieb und dauert nur wenige Minuten. Langfristig kann dann eine Auswahl von Versionen gespeichert werden. Z. B. jeweils eine Version pro Jahr, aus den letzten 12 Monaten, den letzten 4 Wochen und den letzten 7 Tagen.

Sichere Authentifizierung

Die Authentifizierung in einem Linuxsystem erfolgt standardmäßig nur über Passwörter. Die Eingabe von Passwörtern lässt sich auch schon mit günstigen Kameras beobachten und die Passwörter somit entwenden. Ein erster effektiver Schritt, um das Entwenden von Passwörtern zu verhindern ist somit die konsequente verdeckte Eingabe von Passwörtern. Es bietet sich hierfür an, eine entsprechende Einrichtung bereits an der Tastatur oder dem Notebook zu installieren. In diesem Projekt wurden dafür Klappen an den Seiten des Notebook-Bildschirms angebracht. Dieser kann dann bei der Passworteingabe heruntergeklappt werden, sodass die Tastatur nur noch von vorne sichtbar ist. Noch besser wäre ein undurchsichtiger Stoff, der auch von Vorne die Sicht auf die Hände verdeckt.

Statt einfachen Passworten bietet sich natürlich auch Multifaktor-Authentifizierung an. Mangels der dafür nötigen Hardware wurde diese hier nicht weiter betrachtet. Einige Methoden (z. B. biometrische) sind für die Ableitung eines Schlüssels für die Enschlüssellung des Laufwerks weniger gut geeignet oder benötigen ggf. angreifbare Zusatzhardware, um sie für diesen Zweck zu nutzen.

Weitere Themen

Weitere Themen, die in diesem Rahmen hätten betrachtet werden könne, sind sicherheitsstrategien für Plugins (z. B. für neovim), weitere Sicherheitsüberlegungen zu Dual-Boot-Systeme, die Angreifbarkeit der Hardware (z. B. Netzwerkkarte) von außen oder die Sicherheit von Hardwareunterstüzter Verschlüsselung. Diese haben aber nicht mehr in den zeitlichen Rahmen gepasst.

Quellen

• https://www.cocosenor.com/articles/computer/3-ways-to-unlock-bios-password-on-lenovo-thinkpad-laptop.html
• https://www.howtogeek.com/116569/htg-explains-how-windows-8s-secure-boot-feature-works-what-it-means-for-linux/
• https://ubuntu.com/blog/how-to-sign-things-for-secure-boot
• http://cdimage.debian.org/debian-cd/current/amd64/iso-cd/
• https://jbeekman.nl/blog/2015/03/lenovo-thinkpad-hdd-password/
• https://threatpost.com/academics-find-critical-flaws-in-self-encrypting-hardware-drives/115103/
• https://gitlab.com/cryptsetup/cryptsetup
• https://en.wikipedia.org/wiki/Initial_ramdisk
• https://www.cvedetails.com/cve/CVE-2016-4484/
• https://www.youtube.com/watch?v=f4U8YbXKwog
• https://fossbytes.com/secure-linux-distros-privacy-anonymity/
• https://www.educba.com/centos-vs-debian/
• https://www.debian.org/security/audit/
• https://lists.debian.org/debian-security-announce/
• https://www.debian.org/doc/user-manuals#securing
• https://linuxsecurity.com/docs/QuickRefCard.pdf
• https://wiki.debian.org/SetupGuides/SecurePersonalComputer
• https://wiki.debian.org/AppArmor/HowToUse
• https://usbguard.github.io/