Secure Boot per moduli kernel proprietari: firma, flusso di lavoro MOK e strategia di distribuzione

Secure Boot per i propri moduli del kernel è un aspetto centrale di sicurezza e operatività per gli operatori di moderne Linux- e Kubernetes-infrastrutture. In questa guida troverete istruzioni pratiche: quali componenti intervengono, come firmare i moduli in modo sicuro, come il workflow MOK (Machine Owner Key) viene operationalizzato, quali strategie di distribuzione hanno senso su flotte, come integrare DKMS e quali precauzioni specifiche richiedono i cluster Kubernetes. L’obiettivo è un’operatività riproducibile, passaggi di verifica chiari e una strategia di fallback robusta.

Perché i moduli propri vengono bloccati da Secure Boot?

UEFI Secure Boot valida l’integrità di bootloader e kernel tramite una catena di certificati. shim è un boot-stub firmato dal team della distribuzione che è autorizzato a caricare il kernel e che al contempo fornisce agli operatori meccanismi (p.es. MOK) per registrare certificati propri. Una volta che il kernel ha attivato la modalità Lockdown, verifica le firme dei moduli del kernel (.ko) caricati successivamente. Se manca una firma attendibile o il certificato appropriato, il caricamento viene rifiutato e driver, plugin di storage o funzionalità di rete possono non funzionare.

Chiarimento dei termini: PK, KEK, db e MOK

PK indica Platform Key (chiave principale della firmware), KEK sono i Key Exchange Keys (per la gestione delle firme) e db è il database della firmware con i certificati attendibili. MOK (Machine Owner Key) è un meccanismo in shim che permette agli operatori di inserire certificati propri senza modificare PK/KEK/db della firmware. Nel kernel i certificati accettati sono gestiti in keyring — se non sono presenti lì, la verifica fallisce.

Controlli di sistema preliminari

Prima di adattare processi o pipeline, determinate lo stato per ciascun sistema. Controllate lo stato di Secure Boot, Lockdown e degli strumenti.

# 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

Se dmesg mostra messaggi come «module verification failed», è un chiaro indicatore di problemi di firma o di chiavi.

Firma: concetto, protezione delle chiavi e procedure

Un modulo del kernel viene dotato di una firma PKCS#7 che il kernel verifica al momento del caricamento. Formalmente sono necessari due artefatti: una chiave privata per la firma (per creare la firma) e il certificato corrispondente (pubblico), che deve essere registrato come attendibile sui sistemi target. Il principio operativo più importante: la chiave privata non deve finire nelle mani di molti server.

Generazione della chiave (esempio sicuro)

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

Nota: il flag -nodes rimuove la passphrase; questo consente la firma automatizzata, ma aumenta i requisiti di protezione per il luogo di memorizzazione della chiave (HSM, server di signing sicuro o deposito CI/CD).

Operationalizzare il workflow MOK

Il flusso classico: si importa il certificato pubblico (formato DER) con mokutil –import. Questo genera una richiesta di enrollment pendente che dovrà essere confermata al successivo boot nell’interfaccia Shim basata su firmware/grafica. Questo è il punto in cui i rollout falliscono frequentemente: la conferma richiede console/display o accesso seriale.

# 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: immagine già provvista di MOKs (per ambienti VM e cloud, se i provider cloud lo consentono).
• Remote-Konsole/Serial-Automation: utilizzate iKVM o API di console redirection per la conferma automatizzata.
• Firmware-Management: su host fisici l’OEM/il provider di hosting può gestire centralmente le chiavi nel database del firmware.

Non esiste un metodo standard universale e non interattivo per l’iscrizione dei MOK su ogni implementazione firmware; ciò richiede pertanto un inventario preciso e una progettazione del processo.

Firma dei moduli e integrazione nella CI/CD

La firma deve diventare un passaggio standard nella vostra pipeline di build/release. A tal fine è adatto un container/host di firma dedicato nella CI oppure un servizio di firma con un archivio segreto protetto (HSM, Vault). Principi importanti:

• La firma come ultimo step di build prima del packaging.
• Non conservare mai le chiavi di firma direttamente nei pacchetti di destinazione o sui sistemi di produzione.
• Controllare i moduli dopo la firma con modinfo (Signer, sig_key, sig_hash).

Esempio: job GitLab-CI per la firma

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 conservate la chiave privata in un Secret-Store protetto (GitLab CI/CD Variables con masking o HashiCorp Vault). Il runner esegue la firma in un ambiente controllato.

Integrazione DKMS: hook e automazione

DKMS ricompila i moduli durante gli aggiornamenti del kernel. Senza hook DKMS spesso produce moduli non firmati che non vengono caricati dopo un upgrade del kernel. Aggiungete script DKMS che firmino dopo ogni build.

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

Conservate le chiavi di firma su un host di firma dedicato o in un percorso protetto con accesso ristretto. Sui host di destinazione distribuite solo il certificato pubblico per la fase di enrollment.

Strategia di distribuzione per flotte

Un obiettivo solido comprende:

• Firma centralizzata in CI/CD o in un servizio di firma dedicato.
• Distribuzione del certificato pubblico (MOK.der) in modo controllato tramite image, pacchetto o Configuration Management (z. B. Ansible/AWX), ma l’enrollment richiede ancora riavvio e accesso console.
• Distribuzione pacchettizzata (DEB/RPM) invece di copie di singoli file; gli script post-install eseguono depmod e aggiornamenti di initramfs.
• Canary-Rollouts: prima pochi host, convalidare poi su larga scala.

Evitate di distribuire la chiave privata o di disabilitare Secure Boot in modo indiscriminato.

Kubernetes-Perspektive: Worker-Operationen und Best Practices

In Kubernetes i worker node sono punti operativi diretti: moduli mancanti per CNI (rete), CSI (storage) o driver hardware causano pod che non si avviano o errori di storage. Perciò dovRESTe differenziare chiaramente strategie infrastrutturali e di cluster.

Strategien für Cluster-Betreiber

• Immutable Node Images: costruite immagini dei node (AMI/VM-Templates) con i moduli già firmati — in questo modo si elimina il DKMS-Build sui node di produzione.
• Rolling Upgrade mit Canary-Pool: testate le nuove immagini innanzitutto su test-node dedicati.
• Node-Batching: mai riavviare tutti i worker contemporaneamente; rispettate i PodDisruptionBudgets.
• Preflight-Gates: controlli automatizzati prima del riavvio per verificare che i moduli firmati siano presenti per il kernel di destinazione.

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

Potete impiegare un DaemonSet privilegiato che su ogni node esegue modinfo e riporta i campi di firma (Attenzione: implicazioni di sicurezza dovute ai privilegi).

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

Il checker fornisce indicatori sul fatto che moduli critici siano firmati; tuttavia non dovrebbe sostituire l’istanza di fiducia primaria.

Key-Rotation, Revocation und Notfallplanung

La Key-Rotation è un’attività organizzativa: pianificate una fase di transizione in cui chiavi vecchie e nuove sono accettate in parallelo.

1. Generate una nuova coppia di chiavi e pubblicate il nuovo certificato (MOK) per la fase di enrollment.
2. Registrate il nuovo certificato su tutti gli host (Canary → Batch).
3. Firmate progressivamente i nuovi moduli con la nuova chiave e distribuiteli.
4. Dopo un periodo di osservazione rimuovete la chiave vecchia.

Per la revoca (p.es. chiave privata compromessa) è necessario verificare i meccanismi firmware o kernel per il blocco (dbx o policy locale); documentare i processi Break-Glass e il protocollo di comunicazione.

Monitoraggio, test e CI-Preflight-Checks

I test automatizzati sono determinanti: la CI dovrebbe verificare prima del rilascio che un modulo, dopo la firma, riporti con modinfo una componente di firma. In produzione monitorare le voci di dmesg e le metriche di Node-Readiness. Esempio di controllo 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"

Strategia di fallback (Break-Glass) — passo passo

Se un rollout causa interruzioni:

• Verificare tramite console gli errori di dmesg e modprobe.
• Se possibile, eseguire il boot su un kernel precedente dal Bootmenu.
• Se l’enrollment è difettoso: eseguire manualmente il MOK-Enrollment tramite la console (in caso di accesso fisico) oppure utilizzare procedure di console remoto pianificate.
• Come ultima misura e solo temporaneamente: disattivare Secure Boot (firmware) per salvare sistemi critici — e successivamente eseguire un’analisi forense della causa.

Ogni caso Break-Glass deve essere documentato, valutato e il processo successivamente modificato in modo da escludere la ripetizione.

Breve checklist operativa prima di un ampio Rollout

• Inventario: host con Secure Boot, varianti firmware e opzioni di console.
• Modello di firma: chiave privata protetta, certificato pubblico distribuito.
• CI/CD: firma automatizzata; Preflight-Checks implementati.
• DKMS: utilizzare hook o immagini precompilate.
• Kubernetes: strategia per le immagini dei nodi, Canary-Rollout, script di Drain/Uncordon.
• Monitoraggio: pattern dmesg, Node-Readiness, Alerting.
• Rollback: backup di boot/kernel, procedure di console, contatti amministrativi.

Conclusione

Secure Boot protegge la catena di avvio e aumenta la sicurezza nel data center, ma ha senso operativo solo se i processi di firma, la gestione delle chiavi e l’enrollment sono organizzati correttamente. Basandosi su un modello centrale di signing, sulla firma automatizzata in CI/DKMS-Hooks, sulla distribuzione impacchettata e su Canary-Rollout accurati, è possibile gestire Secure Boot in modo affidabile in ambienti eterogenei Linux e Kubernetes. Pianificate i percorsi di enrollment, testate i Preflight-Checks e definite procedure Break-Glass chiare — così Secure Boot resta attivo e i vostri moduli kernel proprietari rimangono disponibili e manutenibili durante gli aggiornamenti del kernel.

Secure Boot per i propri moduli kernel: rischi operativi e alternative architetturali

Oltre alla firma e al MOK-Enrollment dovreste considerare l’architettura operativa e i possibili rischi di single point. Decisivi sono tre ambiti: custodia delle chiavi, percorso di distribuzione ed enrollment e osservabilità. Pattern architetturali consolidati minimizzano la superficie d’attacco e il rischio di interruzione.

Modello architetturale consigliato:

• Servizio centrale di signing con HSM o Vault: la chiave privata rimane in un servizio protetto, CI/CD riceve solo token autorizzati a breve termine. In questo modo si evita la distribuzione di chiavi private sugli host di destinazione.
• Metadati di firma nei pacchetti: integrate DEB/RPM con informazioni sul firmatario e sulla provenance delle checksum, in modo che gli strumenti di deployment possano prendere decisioni di preflight.
• Strategie di enrollment separate per classi di host: Cloud‑VMs, Bare‑Metal e Bare‑Metal con console limitata richiedono workflow di enrollment diversi (image con MOK in anticipo, iKVM/serial per gli enrollments, modifiche firmware del provider per host critici).

Precauzioni operative:

• Inventario: implementazione del firmware, console disponibile?, funzionalità supportate (shim, mokutil).
• Pool canary con telemetria: convalidare i caricamenti dei moduli, la readiness dei nodi e gli errori dmesg prima di un ampio rollout.
• Monitoring: centralizzare pattern di Journald/Dmesg per „module verification failed“ e configurare alerting con SLO.

Percorso d’emergenza: definite procedure Break‑Glass chiare e testate (kernel di fallback, piano per console remota, disattivazione temporanea di Secure Boot solo come ultima opzione) e documentate le responsabilità. In questo modo collegate i requisiti di sicurezza a un modello operativo robusto per ambienti aziendali e cluster personalizzati.

Per questo tema sono importanti anche la firma dei moduli kernel e il Machine Owner Key (Mok). L’articolo inquadra questi aspetti in modo chiaro e mostra cosa conta nella pratica quotidiana.