Erano le tre di notte quando ho sentito il mio telefono vibrare sul comodino. Un alert di Proxmox: CPU al 100% su un container che doveva stare fermo. Ho aperto il terminale dal letto, gli occhi ancora mezzi chiusi, e quello che ho trovato nei log mi ha svegliato di colpo. Qualcuno — o qualcosa — stava tentando di scrivere in /sys/kernel/security/apparmor/.load. Da un container non privilegiato.
Non era un attacco mirato al mio homelab, ovviamente. Era uno script automatizzato che girava su porte esposte. Ma il punto è un altro: quel tentativo avrebbe potuto funzionare. Perché la vulnerabilità CrackArmor in AppArmor su Linux — quella che Qualys TRU ha divulgato il 12 marzo 2026 — era lì da nove anni, silenziosa, in attesa.
CrackArmor: la vulnerabilità AppArmor Linux che dormiva dal 2017
Nove vulnerabilità. Presenti dal kernel v4.11, anno 2017. Dodici milioni e seicentomila istanze enterprise esposte — Ubuntu, Debian, SUSE. Il nome collettivo è CrackArmor, e se gestisci un homelab con Proxmox o Docker su Ubuntu, ti riguarda direttamente. Chi ha seguito la vicenda della supply chain di Trivy sa che i guardiani della sicurezza possono diventare il problema. Stavolta il guardiano è AppArmor stesso.
Due CVE pubblicati il 18 marzo: CVE-2026-23268 e CVE-2026-23269. Ma il numero non rende l’idea. Serve capire il meccanismo.
Credit: Noah Davis (CC BY-SA 4.0)
Il confused deputy: quando il kernel si fida della persona sbagliata
Il cuore di CrackArmor è un pattern classico nella sicurezza informatica: il confused deputy. Un componente privilegiato che viene ingannato per compiere azioni che non dovrebbe.
Funziona così. Nel filesystem virtuale del kernel, sotto /sys/kernel/security/apparmor/, esistono tre pseudo-file: .load, .replace, .remove. Servono per caricare, modificare e rimuovere profili di sicurezza. I permessi? Mode 0666 — leggibili e scrivibili da chiunque.
Iscriviti alla newsletter per ricevere i migliori articoli direttamente nella tua inbox.
Self-Hosting
Vaultwarden self-hosted in homelab: 7,4 MiB di RAM e zero compromessi
Vaultwarden self-hosted homelab: setup completo su Proxmox LXC con Caddy HTTPS, admin panel sigillato e backup testato. Sette decisioni motivate.
Il problema sta in un errore architetturale preciso.
Il controllo dei permessi avviene al momento della write(), non della open(). Un utente non privilegiato può aprire quei file senza problemi. Poi usa su -P come proxy privilegiato per scrivere dati arbitrari. Il kernel vede la scrittura arrivare da un processo con privilegi elevati e la accetta. Il confused deputy ha eseguito l’ordine.
«Qualsiasi controllo d’accesso su write() è un code smell nel modello UNIX tradizionale.» — Epa, sviluppatore kernel, commento su LWN.net
C’è di peggio. Una delle nove falle — un out-of-bounds read nella funzione aa_dfa_match() — permette di leggere fino a 64 KB di memoria kernel. Abbastanza per estrarre puntatori KASLR e rendere un exploit affidabile e ripetibile.
AppArmor privilege escalation root: dalla teoria al cronometro
Secondo la Cloud Security Alliance, l’exploit raggiunge una root shell su Ubuntu 24.04 LTS in meno di 4,5 secondi. Quattro secondi e mezzo per passare da utente normale ad accesso completo al sistema.
Serve accesso locale e un utente con password. Non è un attacco remoto. Questa distinzione conta, e ci torneremo. Ma in un contesto dove container non fidati girano su host condivisi — Proxmox, Kubernetes, qualsiasi piattaforma multi-tenant — «accesso locale» è la condizione di partenza, non un ostacolo.
Otto mesi di silenzio: la disclosure coordinata
Qualys TRU ha scoperto le falle e contattato i maintainer il 10 luglio 2025. La divulgazione pubblica è arrivata il 12 marzo 2026. Otto mesi di lavoro dietro le quinte.
John Johansen, maintainer di AppArmor, ha categorizzato i nove bug in cinque gruppi di gravità e prodotto undici patch, tutte integrate upstream il giorno della divulgazione. Le patch per Ubuntu coprono le versioni 25.10, 24.04 LTS, 22.04 LTS e 20.04 LTS. Per chi è ancora su 18.04, 16.04 o 14.04: le patch sono in stato «pending».
Tradotto in versione kernel per Ubuntu 24.04: il fix è nel pacchetto 6.8.0-106.106. Anche sudo ha ricevuto un aggiornamento specifico: versione 1.9.15p5-3ubuntu5.24.04.2.
Una curiosità.
sudo-rs — la riscrittura in Rust di sudo, default su Ubuntu 25.10+ — non è vulnerabile. Non implementa le email notifications che l’exploit sfrutta come vettore. A volte riscrivere da zero paga.
Il fantasma di Dirty COW e il pattern che si ripete
CrackArmor non è un caso isolato. È l’ultimo capitolo di un pattern ricorrente nella sicurezza Linux.
Dirty COW, CVE-2016-5195: privilege escalation locale nel kernel, presente dal 2007, scoperta nel 2016 dopo nove anni. Stessa dinamica — una falla dormiente che aspetta il ricercatore giusto. Dirty Pipe nel 2022: altra escalation locale, e tra le mitigazioni suggerite c’era proprio AppArmor. L’ironia è pesante.
Ma l’ironia più grossa riguarda Qualys stessa. Nel 2022 il loro team scoprì vulnerabilità critiche in Snap. La mitigazione raccomandata? Rafforzare i profili AppArmor. Quattro anni dopo, sono loro a dimostrare che AppArmor era il buco.
Credit: Larry Ewing, Simon Budig, Garrett LeSage (CC0)
CrackArmor CVE-2026: hype o pericolo reale?
Non tutti la pensano allo stesso modo, e le voci critiche meritano spazio.
Su LWN.net, la community kernel ha reagito con scetticismo misurato. L’exploit richiede accesso locale e un utente con password — non è un attacco remoto. Il nome «CrackArmor» e il numero «12,6 milioni» puzzano di marketing. La falla, tecnicamente, è un bug banale: check dei permessi nel punto sbagliato. Niente di sofisticato.
Hanno ragione? In parte sì.
Ma c’è un’altra lettura, più radicale. Edera.dev — startup che lavora su hypervisor leggeri — ha scritto qualcosa che va oltre il bug singolo: il problema non è la falla specifica, ma il fatto che meccanismi di enforcement di sicurezza residenti in un kernel condiviso possono essi stessi diventare superficie d’attacco. Non basta patchare. Serve ripensare l’architettura.
«CrackArmor dimostra che anche le protezioni più radicate possono essere aggirate senza credenziali di amministratore.» — Dilip Bachwani, CTO Qualys
Il terremoto silenzioso: chi sta già abbandonando AppArmor
Ecco il dettaglio che molti hanno trascurato. CrackArmor non arriva nel vuoto. Arriva in un momento in cui AppArmor stava già perdendo terreno.
Febbraio 2025: openSUSE annuncia lo switch a SELinux. Poco dopo, Microsoft rimuove il supporto AppArmor da Azure Linux 3.0 per AKS e raccomanda SELinux come MAC predefinito. Due colossi che cambiano direzione, prima che CrackArmor diventasse pubblico. Sapevano qualcosa? O semplicemente avevano già valutato i limiti strutturali di un sistema basato su path anziché su label, senza supporto MLS/MCS, incapace di separare container tra loro?
RHEL e Fedora, con SELinux di default, non sono colpiti. Amazon Linux nemmeno. Il 43,1% del mercato enterprise Linux era già al sicuro per scelta architetturale. Ubuntu, con il 33,9% e AppArmor abilitato sull’86% dei server, porta il peso maggiore.
Container escape e Proxmox: cosa rischia chi ha un homelab
Proxmox VE usa un kernel Debian-based. Se non hai aggiornato dopo il 12 marzo, ogni container LXC sul tuo host è potenzialmente esposto a CrackArmor. Docker su Ubuntu applica profili AppArmor di default — stessa esposizione. E chi ha provato a far girare Docker dentro container LXC unprivileged su Proxmox 9 sa già che AppArmor creava problemi ancor prima di CrackArmor.
Il rischio concreto: container escape. Un’immagine Docker malevola, scaricata magari da un registry non verificato, potrebbe sfruttare la catena di vulnerabilità per uscire dal container e ottenere root sull’host. Senza bisogno di cooperazione da parte di processi privilegiati.
Patch e mitigazioni: cosa fare adesso
Le azioni immediate, in ordine di priorità:
Aggiorna kernel e sudo — è il passo più urgente
Riavvia — il kernel si aggiorna solo al boot
Verifica la versione attiva e lo stato di AppArmor
Abilita il monitoraggio degli eventi di sicurezza
bash
# 1. Aggiorna tutto e riavvia
sudo apt update && sudo apt upgrade -y && sudo reboot
# 2. Dopo il riavvio, verifica kernel
uname -r
# Deve essere >= 6.8.0-106.106 su Ubuntu 24.04
# 3. Controlla stato AppArmor
sudo aa-status
# 4. Monitora eventi AVC con auditd
sudo apt install auditd -y
sudo auditctl -w /sys/kernel/security/apparmor/ -p wa -k apparmor_access
Per chi vuole andare oltre la patch: il sysctl kernel.unprivileged_userns_apparmor_policy mitiga gli attacchi via user namespace. Landlock, un LSM più recente, offre un modello di sandboxing che non soffre degli stessi limiti architetturali. C’è anche landrun, un tool CLI in Go con oltre 2100 stelle su GitHub, che semplifica l’uso di Landlock da riga di comando.
Il verdetto
CrackArmor, la vulnerabilità in AppArmor su Linux, non è la fine del mondo. È un bug locale, richiede un utente con password, e le patch esistono già. Ma è la conferma di qualcosa che il settore stava già metabolizzando: AppArmor ha limiti strutturali che vanno oltre il singolo CVE. openSUSE e Microsoft se ne sono andati prima della disclosure. Il kernel condiviso come piano di enforcement è un modello che scricchiola. Per il tuo homelab la risposta immediata è semplice — aggiorna, riavvia, verifica. Per il lungo termine, tieni d’occhio SELinux, Landlock e le alternative che separano davvero il piano di sicurezza dal kernel. La guardia ha dormito nove anni. Svegliala tu.
