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.

Übersicht

…

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

• Wake on LAN: Auf ersten Blick nicht bedenklich. Aber sicher ist sicher.
• 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
• „Boot Order Lock“-Option ohne verständliche Beschreibung

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 um Passwort zu umgehen
  • CMOS-Batterie vorübergehend entfernen um BIOS zurückzusetzen
• Laut Lenovo-Support verhindert die TPM-Technologie das zurücksetzen
  • 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 Zertifikate 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 (sedutil)

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
• ATA „secure erase“ nicht unbedingt vertrauenswürdig
• 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
• Signierte Binaries aus Repos? Sicherheitsanforderungen?
• Snap? pip? rpm?

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

• AppArmor
• Firejail
  • Checkpoints (ggf. git repository)

Weitere Ideen

• Kontrolle über USB-Geräte?
• Sicherheitsstrategie für VIM-Plugins
• Git-Repository mit Konfigurationsdateien (~/.bashrc, ~/.profile, .tmux.conf, …)
  • Schnelles und sichereres Einrichten neuer Linux-Accounts

Weitere Themen

• 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?