Vedi l'advisory del ricercatore originale su https://copy.fail e l'advisory CERT-EU su https://cert.europa.eu/publications/security-advisories/2026-005/ per i dettagli tecnici completi e la disponibilità delle patch per distribuzione.

Ambito di questo strumento

Questo script copre la configurazione globale del daemon Docker Engine. Per Kubernetes, vedi la sezione Kubernetes qui sotto. Per carichi di lavoro bare-metal o VM (non containerizzati), disabilita invece il modulo del kernel algif_aead:

Questo approccio non ha alcun impatto su dm-crypt/LUKS, kTLS, IPsec/XFRM, OpenSSL, GnuTLS, NSS o SSH.

Come funziona

1. Estrae il profilo seccomp predefinito attivo di Docker ispezionando il HostConfig.SecurityOpt di un container di breve durata. Questo evita qualsiasi dipendenza da un URL remoto e garantisce che il profilo di base corrisponda alla versione di Docker effettivamente installata. Un fetch da GitHub da moby/profiles viene usato come fallback solo se l'ispezione del container non produce risultati.

2. Applica una patch al profilo rimuovendo socket dalla voce allowlist di Docker e riaggiungendolo con un filtro sugli argomenti che consente tutte le famiglie di indirizzi tranne AF_ALG (valore 38) usando SCMP_CMP_NE. Tutto il resto del comportamento seccomp predefinito di Docker viene preservato.

3. Scrive il profilo patchato atomicamente in /etc/seccomp/docker-block-af-alg.json (file temporaneo + rinomina). Viene saltato se il contenuto su disco è già identico.

4. Aggiorna /etc/docker/daemon.json per impostare "seccomp-profile" sul percorso del profilo patchato. Il file originale viene salvato come backup in daemon.json.bak alla prima modifica. Viene saltato se già configurato correttamente.

5. Ricarica dockerd tramite systemctl reload docker (SIGHUP — nessun riavvio richiesto). Viene saltato se nessuno dei due file è cambiato.

6. Verifica che il blocco sia attivo eseguendo una sonda all'interno di un container, indipendentemente dal fatto che siano state apportate modifiche nei passaggi precedenti.

Lo script è idempotente: eseguirlo più volte produce lo stesso risultato e ricarica Docker solo quando qualcosa è effettivamente cambiato.

Nota: i container --privileged bypassano tutti i profili seccomp indipendentemente da questa configurazione. Controlla separatamente i tuoi file Compose e i comandi di esecuzione per i container privilegiati.

Requisiti

• Python 3.12+
• Docker Engine (non Docker Desktop) in esecuzione sull'host
• CLI docker nel PATH
• curl nel PATH (solo fallback)
• systemctl (host systemd)
• Root / sudo per le scritture in /etc/seccomp e /etc/docker, e per systemctl reload docker

Utilizzo

Output previsto (prima esecuzione)

Output previsto (esecuzioni successive)

Codici di uscita

Kubernetes

I pod Kubernetes condividono il kernel dell'host, quindi la stessa primitiva del socket AF_ALG è raggiungibile da qualsiasi pod su un nodo vulnerabile. Il seccomp RuntimeDefault non è sufficiente — i cluster testati hanno mostrato che i pod ammessi sotto PSS Restricted potevano comunque aprire socket AF_ALG. È richiesto un profilo Localhost con una regola di deny esplicita.

La mitigazione richiede due cose: il JSON del profilo presente sul filesystem di ogni nodo, e ogni spec di pod che lo referenzi. Le sezioni seguenti coprono entrambe, incluso come iniettare il profilo globalmente senza modificare gli spec dei singoli pod.

Passo 1 — Distribuisci il profilo su ogni nodo

Il kubelet risolve i profili seccomp Localhost relativamente alla sua root seccomp, che per impostazione predefinita è /var/lib/kubelet/seccomp. Il profilo deve esistere a quel percorso su ogni nodo che può pianificare un carico di lavoro.

Applica il ConfigMap e il DaemonSet da questo repository:

Il DaemonSet esegue un container init che copia il profilo dal ConfigMap alla root seccomp del kubelet del nodo, poi parcheggia un container pause minimale così il pod rimane visibile per il monitoraggio della salute. Tollera tutti i taint così viene eseguito anche sui nodi control-plane.

Root seccomp kubelet non standard: RKE2 usa /var/lib/rancher/rke2/agent/kubelet/seccomp. Sovrascrivi il percorso impostando NODE_SECCOMP_ROOT nell'env del container init del DaemonSet prima di applicare.

Verifica che il file sia presente su un nodo:

Passo 2 — Inietta il profilo in ogni pod (nessuna modifica agli spec dei pod richiesta)

Invece di modificare i singoli spec dei pod o i chart Helm, usa un webhook di ammissione mutante per iniettare seccompProfile automaticamente al momento dell'ammissione. Sono fornite due opzioni: Kyverno e OPA Gatekeeper.

Entrambi gli approcci iniettano il profilo solo quando un pod non ne dichiara già uno, quindi i pod con profili espliciti vengono lasciati intatti.

Importante: I pod esistenti in esecuzione non vengono mutati retroattivamente. Dopo aver applicato la policy, fai un rollout dei tuoi deployment per applicare il profilo iniettato:

root@kitploit:~

kubectl rollout restart deployment -A

Opzione A — Kyverno

Questo template usa l'API MutatingPolicy (policies.kyverno.io/v1), che ha raggiunto la GA in Kyverno 1.17. L'API legacy ClusterPolicy (kyverno.io/v1) è stata deprecata in Kyverno 1.17 (gennaio 2026) ed è prevista per la rimozione in 1.20 (ottobre 2026); non usarla per nuove policy.

L'espressione CEL matchConditions verifica che seccompProfile sia assente prima di mutare, quindi i pod che dichiarano già un profilo vengono lasciati intatti.

Verifica che un nuovo pod riceva il profilo iniettato:

Vedi templates/kyverno-mutate-seccomp.yaml.

Opzione B — OPA Gatekeeper

Il CRD di mutazione Assign di Gatekeeper usa una condizione pathTests per iniettare il profilo solo quando spec.securityContext.seccompProfile non esiste già. La mutazione è stabile da Gatekeeper 3.10+; nessun flag di funzionalità è richiesto.

Verifica:

Vedi templates/gatekeeper-assign-seccomp.yaml.

Gatekeeper vs. Kyverno: L'approccio Assign opera a livello di campo e richiede che il webhook di mutazione di Gatekeeper sia abilitato. Il MutatingPolicy di Kyverno con un matchCondition CEL gestisce la condizione inline. Entrambi ottengono lo stesso risultato — preferisci quello già distribuito nel tuo cluster.

Cosa questo non copre

I pod con hostPID: true, hostNetwork: true o securityContext.privileged: true hanno accesso elevato che il solo seccomp non contiene completamente. Controlla quei carichi di lavoro separatamente e rimuovi i privilegi dove possibile.

Note di progettazione dei template

ConfigMap come fonte di verità. Il JSON del profilo vive in configmap-seccomp-profile.yaml invece di essere incorporato nel DaemonSet o duplicato tra i file. Il DaemonSet lo monta e lo copia sul nodo. Aggiornare il profilo significa modificare un ConfigMap e riavviare i pod del DaemonSet — nessun altro file cambia.

Il DaemonSet usa la priorità system-node-critical. Questo garantisce che il pod di distribuzione non venga sfrattato prima che i carichi di lavoro che protegge vengano pianificati, il che lascerebbe i nodi con un file di profilo mancante e i pod bloccati in CreateContainerError.

Gatekeeper esclude kube-system e gatekeeper-system. Iniettare un profilo Localhost nei pod di sistema che potrebbero precedere l'installazione del DaemonSet rischia un riferimento a un profilo rotto se il file non è ancora presente sul nodo. La policy Kyverno non ha bisogno di questa esclusione perché Kyverno gestisce l'ordinamento dei webhook in modo più elegante, ma le regole exclude possono essere aggiunte anche lì se necessario.

Iniezione condizionale, non sovrascrittura. Sia il matchCondition CEL del MutatingPolicy di Kyverno che il test di percorso MustNotExist di Gatekeeper significano che la policy di ammissione agisce solo quando un pod non ha un seccompProfile esistente. I carichi di lavoro che dichiarano già il proprio profilo — inclusi quelli che legittimamente necessitano di AF_ALG tramite una allow-list personalizzata — vengono lasciati intatti.

Riferimenti

• https://copy.fail — Advisory del ricercatore originale (Xint)
• https://cert.europa.eu/publications/security-advisories/2026-005/ — Advisory CERT-EU
• https://www.cve.org/CVERecord?id=CVE-2026-31431 — Record CVE
• https://security-tracker.debian.org/tracker/CVE-2026-31431 — Tracker di sicurezza Debian
• https://docs.docker.com/engine/security/seccomp/ — Documentazione seccomp di Docker
• https://github.com/moby/profiles — Profilo seccomp predefinito canonico di Docker
• https://kyverno.io/docs/kyverno-policies/ — Documentazione delle policy Kyverno
• https://open-policy-agent.github.io/gatekeeper/website/docs/mutation/ — Documentazione della mutazione Gatekeeper

Sì, Claude ha fatto la maggior parte del lavoro, ecco la chat

https://gist.github.com/devstuff/3ff3ca0139e2a2da7f1ee5875802f76f