# UEFI Secure Boot: Die digitale Vertrauenskette

TL;DR / Management Summary Secure Boot ist kein Werkzeug, um Linux zu verhindern, sondern um das System vor Bootkits (Malware im Bootloader) zu schützen. Es stellt sicher, dass nur Software gestartet wird, die eine gültige digitale Signatur trägt. In der Linux-Welt nutzen wir den shim Loader (signiert von Microsoft), um unsere eigenen Distribution-Keys zu validieren. Ein Senior Admin muss wissen, wie er den Machine Owner Key (MOK) nutzt, um selbstgebaute Kernels oder Treiber (z.B. Nvidia) in diese Vertrauenskette zu integrieren.

# 1. Einführung & Architektur

Vom Silizium zum Betriebssystem.

Secure Boot baut eine Kette von Vertrauen (Chain of Trust) auf. Wenn ein Glied in der Kette nicht signiert ist, stoppt die CPU den Bootvorgang.

# Die Vertrauenskette (Mermaid)

graph TD
    A[Hardware: UEFI Firmware] -->|Verify via Microsoft Key| B[Shim Loader: shimx64.efi]
    B -->|Verify via Distro Key| C[Bootloader: GRUB2]
    C -->|Verify via Distro/MOK Key| D[Kernel: vmlinuz]
    D -->|Verify via Key| E[Modules: nvidia.ko / zfs.ko]
    subgraph "Trust Anchor"
        F[NVRAM: Database PK/KEK/db]
    end
    A --- F

# 2. Der Linux-Weg: Der ‘Shim’

Die Brücke zwischen MS und Linux.

Da kaum ein Admin seinen eigenen Key direkt in das Mainboard-BIOS brennen kann, nutzt Linux einen Trick:

1. Shim: Ein winziger Loader, der von Microsoft signiert ist (jedes Mainboard vertraut ihm).
2. MOK (Machine Owner Key): Eine lokale Datenbank auf Ihrem Server, in der Sie Ihren eigenen Schlüsseln vertrauen können.

# 3. Management mit mokutil

Den Wächter steuern.

# Status prüfen

mokutil --sb-state
# Output: SecureBoot enabled

# Eigenen Key importieren (für Custom Kernels)

Wenn Sie einen eigenen Kernel signiert haben (Artikel 365):

# 1. Key bei der MOK-Datenbank anmelden
sudo mokutil --import my_private_key.der
# 2. Passwort vergeben
# 3. Reboot: Im blauen 'MOK Management' Menü das Passwort eingeben und Key bestätigen.

# 4. Day-2 Operations: Signierte Kernel-Module

Nvidia & Co. unter Secure Boot.

Wenn Secure Boot aktiv ist, verweigert der Kernel das Laden von unsignierten Modulen (insmod schlägt fehl).

# Module automatisch signieren (DKMS)

Stellen Sie sicher, dass DKMS (Artikel 366) Ihre Schlüssel nutzt: Datei: /etc/dkms/framework.conf

# Pfad zu Ihren MOK Schlüsseln
mok_signing_key="/var/lib/shim-signed/mok/MOK.key"
mok_certificate="/var/lib/shim-signed/mok/MOK.der"

# 5. Troubleshooting & “War Stories”

Wenn der Server die Arbeit verweigert.

# Story 1: “Der hängende Third-Party Treiber”

Symptom: Nach der Installation des Nvidia-Treibers unter Arch Linux bleibt der Schirm schwarz. lsmod zeigt, dass der Treiber nicht geladen wurde. dmesg meldet: Lockdown: X: Loading of unsigned modules is restricted. Ursache: Secure Boot ist aktiv, aber der Treiber wurde nicht signiert. Lösung: Deaktivieren Sie Secure Boot (temporär) oder signieren Sie das Modul manuell mit kmodsign.

# Story 2: “Das BIOS-Reset Desaster”

Symptom: Nach einem Batteriewechsel auf dem Mainboard bootet der Linux-Server nicht mehr. Ursache: Das BIOS wurde auf Werkseinstellungen zurückgesetzt. Dabei wurde die MOK-Datenbank gelöscht oder Secure Boot in den “Setup Mode” versetzt. Lösung: Importieren Sie Ihre MOK-Keys erneut via Live-System oder stellen Sie das BIOS wieder in den “User Mode”.

# 6. Fazit & Empfehlung

• Sicherheit: Lassen Sie Secure Boot AN. Es ist der einzige Schutz gegen persistente Hardware-Trojaner.
• Wartung: Nutzen Sie Distributionen wie SLES oder RHEL, die den gesamten Signierungs-Workflow (inkl. Patches) automatisiert abwickeln.
• Wahl: Nutzen Sie für eigene Entwicklungen immer den MOK-Workflow. Er ist der sicherste Kompromiss zwischen Kontrolle und Benutzerfreundlichkeit.

# Anhang: Cheatsheet