Sicheres Linux-Desktop-Betriebssystem

Es soll untersucht werden, welche Technologien bei der Einrichtung eines möglichst sicheren und trotzdem bequem Nutzbaren Linux-Desktop-Betriebssystem von Nutzen sein können. Es soll außerdem evaluiert werden, welchen genauen Nutzen, welche Nachteile und welche Schwachstellen die Technologien haben und gegen welche Angreifermodelle sie letztendlich schützen.

Sicheres Installationsmedium

• Vertrauen in alle beteiligte Hardware nötig
• Vertrauen in Betriebssystem nötig, das Installationsimage lädt bzw. prüft
• Absicherungsidee
  • Installationsimage auf USB-Stick mit Schreibschutz-Switch laden
  • Schreibschutz aktivieren
  • Auf unabhängigen Rechnern SHA512-Checksumme herunterladen und gegen USB-Stick prüfen
  • Es muss nur einer der Rechner „die Wahrheit“ sagen damit ein falsches Image auffällt

BIOS

• TPM 2.0 Modul
  • Erlaubt Secure Boot
  • Schlüsselgenerierung und -speicher
  • Verschlüssellung und Signatur
  • Random Noise Generator
  • Von aktuellen Kernels unterstützt und unter /dev/tpm0 eingebunden
• Intel SGX: abgesicherter Bereich für Sicherheitskritische Ausführung
• Internal Storage Tamper Detection: Fährt herunter, wenn Drive während Schlafmodus entfernt
• UEFI only und überflüssige Booteinträge entfernen

BIOS Passwort

• Supervisor Passwort sperrt Zugriff auf bestimmte BIOS Einstellungen
  • Optional auf alle BIOS-Änderungen und Auswahl von Booteinträgen
  • Booten kann auch durch Passwort geschützt werden
  • Passwort für SSD Hardwareverschlüsselung (siehe Verschlüsselung)
• Kann vor Manipulation der Einstellungen und der Booteinträge schützen
• Sicherheitslücken:
  • Viele Hersteller haben Masterpasswörter um das BIOS bei dreifacher Falscheingabe zu entsperren
  • Kurzschluss an Kontakten eines Security Chips auf der Rückseite des Mainboards erlaubt angeblich, das Passwort zu umgehen
  • CMOS-Batterie vorübergehend entfernen um BIOS zurückzusetzen
• Laut Lenovo-Support verhindert die TPM-Technologie all diese Möglichkeiten
  • Mainboard ausbauen und flashen nötig

UEFI Secure Boot

• Kleiner Bootloader names „shim“ ist von Microsoft signiert
  • Überprüft ob Kernel und Module signiert und startet Kernel dann
  • Kernelmodule sind auch signiert und eigene Public-Keys können in shim enrolled werden
  • Eigene Public-Keys müssen während des Bootprozesses explizit vom Nutzer genehmigt werden
    • Shim schreibt sie dann in einen NVRAM in den aus dem Betriebssystem nicht ohne weiteres geschrieben werden kann
    • Wer den Rechner in die Finger bekommt und Root-Zugriff auf ein gebootetes System hat, kann den Kernel trotz Secure Boot modifizieren
    • Wenn ohne BIOS-Passwort nur das verschlüsselte OS gebootet werden kann, sollten wir sicher sein

Readonly-Laufwerk

• Falls anderes OS gebooted werden kann, könnte unverschlüsselte Bootpartition infiziert werden
  • Da Microsoft selbst die CA für Secure Boot ist, wäre Windows besonders bedenklich
• Installation der unverschlüsselten Partition auf einem USB-Stick mit Schreibschutz-Switch
  • Ist im normalen Betrieb (ggf. mehrerer Betriebssysteme) immer schreibgeschützt
  • Kann nach dem Booten des sicheren OS für Updates vorübergehend entsperrt werden
• USB Stick darf nicht unbemerkt in fremde Hände fallen
  • Ggf. schwerer zu sichern als die Notebook-Hardware (geht schnell, kein Werkzeug nötig)
• Für Notebook nicht sinnvoll, aber ggf. für Dualboot PC zu Hause

Verschlüssellung

Hardwareverschlüssellung der SSD

• Viele moderne SSDs verschlüsseln die gespeicherten Daten mit AES-256
• Schlüssel in SSD persistiert, kann aber vom BIOS mit Passwort verschlüsselt werden
  • Verschlüssellungsverfahren ist BIOS-Hersteller-abhängig
  • Kann nicht ohne weiteres an anderem Rechner verwendet werden
  • Verfahren ist bekannt und bietet keine besondere Sicherheit
• Sicherheitsbedenken wegen Backdoors, gesetztlicher Vorgaben, achtloser Implementierung
• Zumindest für billiges Wipen der SSD vor Installation nutzbar
  • Benötigt sog. „Physical Security Identification“-Nummer
  • Erst sperren mit sudo sedutil-cli --initialsetup debug <Drive> und rebooten
  • sudo sedutil-cli --yesIreallywanttoERASEALLmydatausingthePSID <PSID> <Drive>
  • Vertrauenswürdigkeit wird bezweifelt

LUKS

• LUKS nutzt dm-crypt Kernelmodul für transparente Verschlüsselungsschichten
• Header enthält mit Passwort(en) verschlüsselten Masterkey (ohne den ist alles futsch)
• Bei SSDs bleiben alte LUKS-Header in ungenutzen Blöcken erhalten
  • Daten können mit altem, deaktiviertem Passwort entschlüsselt werden
  • LUKS-Header kann auf HDD ausgelagert werden
• Das „cryptsetup“ CLI hat explizite „luksHeaderBackup“-Funktionalität
• initrd bereitet Zugriff (insbesondere entschlüssellung) auf Kernel vor und lädt treiber
  • Erlaubt in bestimmten Debian-Versionen Zugriff auf root-rescue-shell
    • Noch aktuell? Wie lösbar? Bootparameter?

Distribution und Softwarequellen

• Qubes OS
  • Alle Applikationen laufen in virtuellen Maschienen
  • Mehrere Betriebssysteme auf einem Desktop (einschließlich Windows)
  • „Disposable VMs“ die nur für die Laufzeit eines Programms existieren
  • Netzwerkzugriff und Tor-Tunnelling pro VM einstellbar
  • Explizite Einstellung von USB-Passthrough zu VMs nötig
  • Zusätzliche CPU- und RAM-Belastung und Verwaltungsaufwand
  • Weitere sicherheitszentrierte Distributionen vorhanden
  • Für mich aktuell zu umständlich
• Debian und CentOS sind zwei der stabilsten Linuxdistros
  • CentOS ist etwas stabiler
  • Debian hat mehr und aktuellere Software und bessere Hardwareunterstützung

Debian

• Alle Bug-Reports sind sofort öffentlich einsehbar, Probleme werden nicht „versteckt“
• „Security Audit“-Team sucht aktiv nach Sicherheitsbugs im Softwarearchiv
  • Untersucht nicht alle Pakete
• Debian Security Announce-Mailingliste
• Ausführliches Security Manual (2012) zu allen Möglichen Themen
  • Etwas veraltet und zu lang um alles zu lesen
  • Auswahl notwendiger Services, Rechtevergabe, Schadensbegrenzung bei Kompromittierung, …
  • Empfehlungen zu speziefischeren Ressourcen
  • Möglichst sicheres Netzwerk während Installation (Ethernet-Kabel, Wifi aus)
  • Root shell in GRUB deaktivieren?
  • Root account deaktivieren (nur über sudo)
  • Firewall (in meinem Fall GUFW)
  • SysRq einschränken?
  • Regelmäßige Integritätschecks von Binaries
• Secure Personal Computer-Wikiseite
  • Verständliche aber voreingenommene Anleitung für Einrichtung eines möglichst sicheren Debians
    • „Do try to ignore the KDE fanboi zealotry“
  • BIOS Einstellungen, Partitionierung, Softwareeinstellungen, …
  • GRUB Passwort einstellen
    • Ist dann aber bei jedem Booten nötig
    • Mit UEFI ist eigentlich kein Bootloader nötig
      • Auch mit Verschlüsselung möglich? Keine Zeit mehr :(
  • Kernelparameter in /etc/sysctl.conf für restriktivere Netzwerkeinstellungen
  • Einrichtung einer Firewall
    • Lässt sich beliebig kleinlich verwalten (nur bestimmte Dienste, nur bestimmte Adressen, …)
    • Bei mir zunächst GUFW mit Standardeinstellung (eingehende Verbindungen blockieren)
  • Empfehlung, Netzwerkverbindung erst nach der Installation und Konfiguration herzustellen
    • Habe als Kompromiss Wifi des Routers deaktiviert und mich per Ethernet verbunden
    • Wifi-Firmware dann erst nach der Einrichtung installiert
  • Sandboxing mit firejail
  • Empfehlung mehrer Anti-Malware- und Integritätsprüfungs-Programme
  • „debsecan“ listet installierte Programme mit bekannten Sicherheitslücken
    • Ggf. zu automatisieren um möglichst zeitnah auf neue Sicherheitslücken aufmerksam gemacht zu werden

OS Konfiguration

• Konfigurationsdateien bei neuem OS vom alten zum neuen Betriebssystem kopiert
  • Z. B. ~/.bashrc, ~/.xsessionrc, ~/.tmux.conf, ~/.config/nvim/init.vim, …
  • Git-Repository mit Konfigurationsdateien, die dann entsprechend verlinkt werden
  • Schnelles und sichereres Einrichten neuer Linux-Accounts
  • Änderungen können einfach nachvollzogen und schnell

Sichere Authentifizierung

• Passwörter mit Kamera relativ leicht zu stehlen
  • Multifaktorauthentifizierung für Festplattenentschlüssellung schwierig und riskant
  • Starkes Passwort und Sichtschutz für sichere Eingabe

Verschlüsseltes Backup

• “Stehendes” Backup von anderem Bootmedium (USB oder andere Partition)
  • Z. B. Installation eines minimalen Archlinux mit Autostart von Backupscript
  • Nur genutzte Blöcke betrachten und Komprimierung nutzen mit partclone und gzip
  • Backup muss LUKS-Header, die Partitionsstruktur und alle Partition beinhalten
  • Entweder LUKS-Verschlüssellung der Zielfestplatte oder Verschlüssellung des Backups
• Inkrementelles Backup von $HOME
  • Backup aus dem laufenden OS auf separat verschlüsselte Festplatte mit rsync
  • Z. B. Speicherung jeweils einer Version aus den letzten x Jahren, y Monaten, z Wochen, w Tagen
• Backups sollten möglichst immer nochmal überprüft werden
  • Vorher sollten Caches geleert werden: echo 3 > /proc/sys/vm/drop_caches

Sandboxing

• Firejail
  • Nutzt unter anderem AppArmor und OverlayFS
  • OverlayFS erlaubt ein Copy-on-Write Dateisystem-Overlay
  • Sandboxing von X11-Anwendungen via Xpra um Zugriffe auf andere Fenster vorzubeugen
  • „firefox-esr“ Bash-Script im PATH, welches FireFox in Sandbox startet
    • Nur Zugriff auf Mozilla- und Downloads-Ordner
  • Scripts für PDF-Viewer und LibreOffice geplant
  • Auch Root-Shell in OverlayFS möglich um Programminstallation und -konfiguration zu testen
• AppArmor ab Debian 10 automatisch aktiviert
  • Schränkt Netzwerkzugriff, Datei- und Socketzugriff etc. ein
  • Installierte Pakete platzieren AppArmor-Profile in /etc/apparmor.d/

USB Guard

• USB Guard erlaubt White- und Blacklisting von USB-Geräten
  • Verwendet USB Authorisierungsfunktion des Linux Kernels
  • GUI-Frontend für einfache Bedienung
  • Betrifft auch eingebaute Webcam
  • Popup bei jedem Einstecken von USB-Geräten um Nutzung zu bestätigen
  • Zeigt/beschränkt nicht die Art des Geräts (Böswillige Geräte nicht identifizierbar)
  • Zumindest abgesichertes Laden von USB-Geräten, die nicht mit OS interagieren sollen

Praktische Erfahrung

• Einige BIOS-Einstellungen nicht wirklich verständlich
• UEFI-Booteinträge zunächst nicht persistiert -> System nicht bootbar
  • Zurücksetzen des BIOS und Installation der aktuellsten Firmware-Version
    • Direkt aus Windows möglich oder mit CD-ROM

Weitere Themen

• Sicherheitsstrategie für VIM-Plugins
• Welche Maßnahmen sind auf Dual-Boot-Systeme übertragbar?
• Lassen sich BIOS oder Netzwerkkarte von außen steuern/flashen?
  • Intel-Fernadministrierung/V-Pro?
• RAM-Verschlüsselung auf neuen AMD Ryzen Pro
• Hardwareverschlüsselung vs Softwareverschlüsselung (siehe BitLocker)
• Inwiefern sind die Technologien von der Hardware/dem BIOS abhängig?