Secure Boot für eigene Kernel-Module: Signierung, MOK-Workflow und Verteilungsstrategie

Secure Boot für eigene Kernel-Module ist für Betreiber moderner Linux- und Kubernetes-Infrastrukturen ein zentraler Sicherheits- und Betriebsaspekt. In diesem Leitfaden finden Sie praxisorientierte Anleitungen: welche Komponenten eine Rolle spielen, wie Sie Module sicher signieren, wie der MOK-Workflow (Machine Owner Key) operationalisiert wird, welche Verteilungsstrategien in Flotten Sinn machen, wie DKMS integriert wird und welche speziellen Vorsichtsmaßnahmen Kubernetes-Cluster benötigen. Ziel ist ein reproduzierbarer Betrieb, klare Prüfschritte und eine belastbare Rückfallstrategie.

Warum werden eigene Module bei Secure Boot blockiert?

UEFI Secure Boot validiert die Integrität von Bootloadern und Kernels durch eine Kette von Zertifikaten. shim ist ein vom Distributionsteam signierter Boot-Stub, der den Kernel laden darf und zugleich Mechanismen (z. B. MOK) für Betreiber bereitstellt, eigene Zertifikate zu registrieren. Sobald der Kernel den Lockdown-Modus aktiviert hat, prüft er nachgeladene Kernel-Module (.ko) auf gültige Signaturen. Fehlt eine vertrauenswürdige Signatur oder das passende Zertifikat, wird das Laden abgelehnt und Treiber, Storage-Plugins oder Netzwerkfunktionen können ausfallen.

Begriffsklärung: PK, KEK, db und MOK

PK steht für Platform Key (Firmware-Oberhauptschlüssel), KEK sind Key Exchange Keys (zur Signaturverwaltung) und db ist die Firmware-Datenbank mit vertrauenswürdigen Zertifikaten. MOK (Machine Owner Key) ist ein Mechanismus in shim, mit dem Betreiber eigene Zertifikate eintragen können, ohne die Firmware-PK/KEK/db zu ändern. Im Kernel werden akzeptierte Zertifikate in Keyrings verwaltet — fehlen sie dort, scheitert die Verifikation.

Vorbereitende System-Checks

Bevor Sie Prozesse oder Pipelines anpassen, ermitteln Sie den Status pro System. Prüfen Sie Secure-Boot-, Lockdown- und Werkzeugstatus.

# Basischecks
sudo mokutil --sb-state 2>/dev/null || echo "mokutil fehlt oder Secure Boot nicht aktiv"
sudo mokutil --list-enrolled 2>/dev/null || echo "Keine enrolled MOKs oder mokutil nicht vorhanden"
cat /sys/kernel/security/lockdown 2>/dev/null || echo "Lockdown-Status nicht verfügbar"
dmesg | egrep -i "module verification failed|Required key not available|lockdown" | tail -n 50

Wenn dmesg Meldungen wie „module verification failed“ zeigt, ist das ein klarer Indikator für Signatur- oder Key-Probleme.

Signierung: Konzept, Schlüsselschutz und Verfahren

Ein Kernel-Modul wird mit einer PKCS#7-Signatur versehen, die der Kernel beim Laden verifiziert. Formal benötigen Sie zwei Artefakte: einen privaten Signierschlüssel (zum Erstellen der Signatur) und das begleitende Zertifikat (öffentlich), das auf Zielsystemen als vertrauenswürdig registriert wird. Der wichtigste Betriebsgrundsatz: Der private Schlüssel darf nicht in die Hände vieler Server gelangen.

Schlüsselerzeugung (sicheres Beispiel)

mkdir -p /root/module-signing && cd /root/module-signing
# Privaten RSA-Schlüssel + Self-Signed-Zertifikat erzeugen
openssl req -new -x509 -newkey rsa:4096 -sha256 -days 3650 -nodes 
  -subj "/CN=Kernel Module Signing (MOK)/" 
  -keyout MOK.priv -out MOK.pem
# Konvertieren ins DER-Format für mokutil/import
openssl x509 -in MOK.pem -outform DER -out MOK.der
chmod 600 MOK.priv
chmod 644 MOK.pem MOK.der

Hinweis: Das Flag -nodes entfernt die Passphrase; das erlaubt automatisiertes Signieren, erhöht aber die Schutzanforderung für den Speicherort des Schlüssels (HSM, sicherer Signing-Server oder CI/CD-Safe).

MOK-Workflow operationalisieren

Der klassische Flow: Sie importieren das öffentliche Zertifikat (DER-Format) mit mokutil –import. Das erzeugt eine Pending-Enrollment-Anforderung, die beim nächsten Boot in der grafischen/firmware-basierten Shim-Oberfläche bestätigt werden muss. Das ist der Punkt, an dem Rollouts häufig scheitern: das Confirmieren erfordert Konsole/Display oder seriellen Zugriff.

# Zertifikat importieren (erzeugt Enrollment-Request)
sudo mokutil --import /root/module-signing/MOK.der
# Nach Reboot: enrolled keys auflisten
sudo mokutil --list-enrolled

Operations-Optionen für große Flotten:

• Pre-baked Images: Image bereits mit MOKs versehen (für VM- und Cloud-Umgebungen, wenn die Cloud-Provider das erlaubt).
• Remote-Konsole/Serial-Automation: Nutzen Sie iKVM oder Consoleredirection-APIs für automatisierte Confirmation.
• Firmware-Management: Bei physischen Hosts kann der OEM/Hosting-Provider Schlüssel zentral in der Firmware DB verwalten.

Eine universelle, non-interaktive Standard-Methode zur MOK-Einschreibung auf beliebigen Firmware-Implementierungen gibt es nicht; das erfordert deshalb präzise Inventarisierung und Prozessdesign.

Module signieren und in CI/CD integrieren

Signieren muss zum Standard-Schritt in Ihrer Build-/Release-Pipeline werden. Dafür eignet sich entweder ein dedizierter Signier-Container/Host in der CI oder ein Signierdienst mit abgesichertem Geheimnisspeicher (HSM, Vault). Wichtige Prinzipien:

• Signatur als letzter Build-Schritt vor Packaging.
• Signier-Schlüssel niemals direkt in Zielpaketen oder auf Produktivsystemen speichern.
• Module nach dem Signieren mit modinfo prüfen (Signer, sig_key, sig_hash).

Beispiel: GitLab-CI-Job zum Signieren

stages:
  - build
  - sign

build_module:
  stage: build
  script:
    - make -C src
    - cp src/mydriver.ko artifacts/
  artifacts:
    paths:
      - artifacts/

sign_module:
  stage: sign
  dependencies:
    - build_module
  image: ubuntu:22.04
  variables:
    SIGN_KEY_PATH: /buildsecrets/MOK.priv
    SIGN_CERT_PATH: /buildsecrets/MOK.pem
  script:
    - apt-get update && apt-get install -y openssl linux-headers-$(uname -r)
    - /usr/src/linux-headers-$(uname -r)/scripts/sign-file sha256 "$SIGN_KEY_PATH" "$SIGN_CERT_PATH" artifacts/mydriver.ko
  artifacts:
    paths:
      - artifacts/mydriver.ko

In CI speichern Sie den privaten Schlüssel in einem geschützten Secret-Store (GitLab CI/CD Variables mit Masking oder HashiCorp Vault). Der Runner führt das Signieren in einer kontrollierten Umgebung durch.

DKMS-Integration: Hooks und Automatisierung

DKMS baut Module bei Kernel-Updates neu. Ohne Hook produziert DKMS oft unsignierte Module, die nach einem Kernel-Upgrade nicht geladen werden. Fügen Sie DKMS-Skripte hinzu, die nach jedem Build signieren.

Example: DKMS post-install Hook

# /usr/src//2.0/dkms.conf
# In dkms.conf
POST_BUILD="/usr/src//2.0/dkms-sign.sh"

# /usr/src//2.0/dkms-sign.sh
#!/bin/bash
set -euo pipefail
MODULE_PATH="$1/$2"
SIGN_KEY="/etc/secure-signing/MOK.priv"
SIGN_CERT="/etc/secure-signing/MOK.pem"

if [ -f "$MODULE_PATH" ]; then
  /usr/src/linux-headers-$(uname -r)/scripts/sign-file sha256 "$SIGN_KEY" "$SIGN_CERT" "$MODULE_PATH"
  echo "Signed $MODULE_PATH"
else
  echo "Module $MODULE_PATH not found"
fi

Sichern Sie die Signierschlüssel auf einem dedizierten Signierhost oder in einem geschützten Pfad mit eingeschränktem Zugriff. Auf Zielhosts verteilen Sie nur das öffentliche Zertifikat zur Enrollment-Phase.

Verteilungsstrategie für Flotten

Ein robustes Zielbild umfasst:

• Zentrales Signing in CI/CD oder einem dedizierten Signier-Service.
• Verteilen des öffentlichen Zertifikats (MOK.der) kontrolliert per Image, Paket oder Configuration Management (z. B. Ansible/AWX), aber das Enrollment erfordert noch Reboot+Console.
• Paketierte Auslieferung (DEB/RPM) statt Einzeldatei-Kopien; Post-Install-Skripte führen depmod und initramfs-Aktualisierungen durch.
• Canary-Rollouts: erst wenige Hosts, Validierung dann großflächig.

Vermeiden Sie, den privaten Schlüssel zu verbreiten oder Secure Boot pauschal abzuschalten.

Kubernetes-Perspektive: Worker-Operationen und Best Practices

In Kubernetes sind Worker-Nodes direkte Betriebspunkte: fehlende Module für CNI (Netzwerk), CSI (Storage), oder Hardware-Treiber führen zu nicht startenden Pods oder Storage-Fehlern. Deshalb sollten Sie Infrastruktur- und Cluster-Strategien klar differenzieren.

Strategien für Cluster-Betreiber

• Immutable Node Images: Bauen Sie Node-Images (AMI/VM-Templates) mit bereits signierten Modulen vor — so entfällt DKMS-Build auf Produktivnodes.
• Rolling Upgrade mit Canary-Pool: Testen Sie neue Images zuerst auf exklusiven Test-Nodes.
• Node-Batching: Nie alle Worker gleichzeitig rebooten; beachten Sie PodDisruptionBudgets.
• Preflight-Gates: Automatisierte Checks vor Reboot, ob signierte Module für den Zielkernel vorhanden sind.

Beispiel: Reboot-Prozess für einen Node

# Drain Node
kubectl drain node-01 --ignore-daemonsets --delete-emptydir-data --timeout=10m
# Reboot und Healthcheck
ssh root@node-01 'reboot'
# Nach Reboot: Node wieder in Betrieb nehmen
kubectl uncordon node-01
kubectl get nodes --selector=kubernetes.io/hostname=node-01 -o wide

DaemonSet zur Preflight-Prüfung von Modulen

Sie können einen privilegierten DaemonSet einsetzen, der auf jedem Node modinfo prüft und Signaturfelder meldet (Achtung: Sicherheitsimplikationen durch Privilegien).

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: module-signature-check
  namespace: kube-system
spec:
  selector:
    matchLabels:
      name: module-signature-check
  template:
    metadata:
      labels:
        name: module-signature-check
    spec:
      hostPID: true
      hostNetwork: true
      containers:
      - name: checker
        image: busybox
        securityContext:
          privileged: true
        command: ["/bin/sh", "-c"]
        args:
          - for m in /lib/modules/$(uname -r)/**/*.ko; do if [ -f "$m" ]; then modinfo "$m" | egrep -i "signer|sig_key|sig_hash|vermagic" || echo "$m: no sig info"; fi; done; sleep 3600
      tolerations:
      - operator: "Exists"
      restartPolicy: Always

Der Checker liefert Hinweise, ob kritische Module signiert sind; er darf aber nicht die primäre Vertrauensinstanz ersetzen.

Key-Rotation, Revocation und Notfallplanung

Key-Rotation ist eine organisatorische Aufgabe: planen Sie eine Übergangsphase, in der alte und neue Schlüssel parallel akzeptiert werden.

1. Erzeugen Sie neues Schlüsselpaar und veröffentlichen Sie das neue Zertifikat (MOK) zur Enrollment-Phase.
2. Enrollen Sie das neue Zertifikat auf allen Hosts (Canary → Batch).
3. Signieren Sie nach und nach neue Module mit dem neuen Schlüssel und verteilen diese.
4. Nach einer Beobachtungsphase entfernen Sie den alten Schlüssel.

Für Revocation (z. B. kompromittierter privater Schlüssel) müssen Sie Firmware- bzw. Kernel-Mechanismen zur Absperrung (dbx oder lokale Policy) prüfen; dokumentieren Sie Break-Glass-Prozesse und das Kommunikationsprotokoll.

Monitoring, Tests und CI-Preflight-Checks

Automatisierte Tests sind entscheidend: CI sollte vor Release prüfen, dass ein Modul nach Signierung mit modinfo eine Signaturkomponente meldet. In Produktion überwachen Sie dmesg-Einträge und Node-Readiness-Metriken. Beispiel-Check in CI:

# CI Preflight
modinfo artifacts/mydriver.ko | egrep -i "signer|sig_key|sig_hash" || (echo "ERROR: Modul nicht signiert" && exit 1)
# Simulierter modprobe (falls sicherheitsseitig erlaubt)
sudo modprobe -v artifacts/mydriver.ko || true
sudo dmesg | tail -n 50 | egrep -i "module verification failed|Required key not available" && exit 1 || echo "Preflight OK"

Rückfallstrategie (Break-Glass) — Schrittweise

Wenn ein Rollout zu Ausfällen führt:

• Ermitteln Sie per Konsole dmesg- und modprobe-Fehler.
• Booten Sie falls möglich auf einen früheren Kernel im Bootmenu.
• Wenn Enrollment fehlerhaft ist: führen Sie MOK-Enrollment über die Console manuell durch (bei physischem Zugriff) oder nutzen Sie vorgeplante Remote-Konsole-Prozesse.
• Als letzter Schritt und nur temporär: Secure Boot deaktivieren (Firmware), um kritische Systeme zu retten — und danach forensisch die Ursache analysieren.

Jeder Break-Glass-Fall muss dokumentiert, bewertet und anschließend der Prozess so geändert werden, dass Wiederholung ausgeschlossen wird.

Kurze Betriebs-Checkliste vor großem Rollout

• Inventarisierung: Hosts mit Secure Boot, Firmware-Varianten und Console-Optionen.
• Signiermodell: Privater Schlüssel sicher, öffentliches Zertifikat verteilt.
• CI/CD: Signierung automatisiert; Preflight-Checks implemented.
• DKMS: Hooks oder gebaute Images verwenden.
• Kubernetes: Node-Image-Strategie, Canary-Rollout, Drain-/Uncordon-Skripte.
• Monitoring: dmesg-Pattern, Node-Readiness, Alerting.
• Rollback: Boot-Backups/Kernel, Console-Procedures, administrative Kontakte.

Fazit

Secure Boot schützt die Bootkette und erhöht die Sicherheit im Rechenzentrum, ist aber nur dann betrieblich sinnvoll, wenn Signierprozesse, Schlüsselmanagement und Enrollment sauber organisiert sind. Aufbauend auf einem zentralen Signing-Modell, automatisierter Signierung in CI/DKMS-Hooks, paketierter Auslieferung und sorgfältigen Canary-Rollouts lässt sich Secure Boot in heterogenen Linux- und Kubernetes-Umgebungen zuverlässig betreiben. Planen Sie die Enrollment-Pfade, testen Sie Preflight-Checks und definieren Sie klare Break-Glass-Prozeduren — so bleibt Secure Boot aktiv und Ihre eigenen Kernel-Module bleiben verfügbar und wartbar über Kernel-Updates hinweg.

Secure Boot für eigene Kernel-Module: Betriebsrisiken und Architektur‑Alternativen

Neben Signierung und MOK-Enrollment sollten Sie die Betriebsarchitektur und mögliche Single‑Point‑Risiken betrachten. Entscheidend sind drei Bereiche: Schlüsselhaltung, Verteilungs‑ und Enrollment‑Pfad sowie Observability. Bewährte Architekturmuster minimieren Angriffsfläche und Ausfallrisiko.

Empfohlenes Architekturmodell:

• Zentrales Signier‑Service mit HSM oder Vault: Der private Schlüssel bleibt in einem gesicherten Service, CI/CD bekommt nur kurzfristig autorisierte Tokens. So vermeiden Sie die Verteilung privater Schlüssel auf Zielhosts.
• Signatur‑Metadaten in Paketen: Ergänzen Sie DEB/RPM um Signer‑Infos und Checksum‑Provenance, damit Deployment‑Tools Preflight‑Entscheidungen treffen können.
• Enrollment‑Strategien getrennt nach Host‑Klassen: Cloud‑VMs, Bare‑Metal und Bare‑Metal mit eingeschränkter Konsole brauchen unterschiedliche Enrollment‑Workflows (Image mit MOK vorab, iKVM/serial für Enrollments, Provider‑Firmware‑Änderungen für kritische Hosts).

Betriebliche Vorsichtsmaßnahmen:

• Inventar: Firmware‑Implementierung, Konsole verfügbar?, Unterstützte Mächtigkeiten (shim, mokutil).
• Canary‑Pool mit Telemetrie: Validieren Sie Modul‑Loads, Node‑Readiness und dmesg‑Fehler vor großem Rollout.
• Monitoring: Journald/Dmesg‑Pattern für „module verification failed“ centralisieren und Alerting mit SLOs einrichten.

Notfallpfad: Definieren Sie klare, getestete Break‑Glass‑Prozeduren (Fallback‑Kernel, Remote‑Console‑Plan, temporäres Abschalten von Secure Boot nur als letzte Option) und dokumentieren Sie Verantwortlichkeiten. So verbinden Sie Sicherheitsvorgaben mit einem robusten Betriebsmodell für individuelle Unternehmens‑ und Cluster‑Umgebungen.

Für dieses Thema sind auch Kernel-Modul Signieren und Machine Owner Key (Mok) wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.