CrackArmor
Negli ultimi anni GNU/Linux ha fatto enormi passi avanti sul fronte della sicurezza. Tra kernel hardening, container, sandbox e Linux Security Modules, la superficie di difesa si è evoluta parecchio rispetto ai sistemi di vent’anni fa.
Uno degli strumenti più diffusi per il confinamento delle applicazioni è AppArmor. Se usate Debian o Ubuntu probabilmente è già attivo senza che vi siate mai preoccupati troppo di lui.
Ed è proprio questo il punto: AppArmor è così integrato nel sistema che spesso ci dimentichiamo della sua esistenza.
Recentemente però alcuni ricercatori hanno analizzato una tecnica di attacco soprannominata CrackArmor, che dimostra come in determinate condizioni sia possibile sfruttare il modello di sicurezza di AppArmor per arrivare ad una privilege escalation fino a root.
Non è una vulnerabilità “semplice” e non è nemmeno un exploit remoto. Ma è comunque interessante perché ci ricorda una cosa importante: anche i meccanismi di sicurezza possono diventare parte della catena di attacco.
Vediamo perché.
Un piccolo ripasso: cos’è AppArmor
AppArmor è uno dei Linux Security Modules (LSM), cioè quei componenti del kernel che implementano controlli di sicurezza avanzati.
L’idea è abbastanza semplice.
Nel modello classico UNIX i permessi funzionano con il DAC (Discretionary Access Control):
- utente
- gruppo
- permessi sui file
AppArmor invece introduce il MAC (Mandatory Access Control).
In pratica:
non importa chi sei, importa cosa il sistema ti permette di fare.
Ogni applicazione può essere associata a un profilo di sicurezza che definisce:
- quali file può leggere
- quali directory può scrivere
- quali capability può usare
- quali operazioni di sistema sono consentite
Se un processo prova a fare qualcosa fuori dal profilo, il kernel può:
- bloccare l’operazione
- loggare l’evento
- terminare il processo
I profili sono generalmente salvati in:
/etc/apparmor.d/
e caricati automaticamente dal sistema.
Se volete vedere cosa sta girando sul vostro sistema:
sudo aa-status
Il risultato mostra:
- profili caricati
- profili in modalità enforce
- processi confinati
Su una installazione moderna di Ubuntu troverete facilmente profili per:
- snap
- system services
- container runtime
- browser
Perché AppArmor è così diffuso
AppArmor ha un grande vantaggio rispetto ad altri sistemi MAC come SELinux: è relativamente semplice da configurare.
I profili sono basati su percorsi filesystem e risultano abbastanza leggibili.
Un esempio semplificato potrebbe essere:
/usr/bin/myapp {
/etc/myapp/config r,
/var/log/myapp/* rw,
}
In questo modo l’applicazione può leggere il file di configurazione e scrivere i log, ma non fare altro.
Questo approccio è particolarmente utile per confinare servizi esposti in rete:
- web server
- database
- container
- servizi di sistema
L’obiettivo è semplice: se un servizio viene compromesso, l’attaccante resta confinato.
Almeno in teoria.
Dove entra in gioco CrackArmor?
La tecnica chiamata CrackArmor riguarda l’interazione tra:
- AppArmor
- namespace del kernel
- processi non privilegiati
Negli ultimi anni Linux ha introdotto un meccanismo molto potente chiamato user namespaces.
I namespace permettono di creare ambienti isolati in cui un utente può apparire come root all’interno del namespace, pur restando un utente normale nel sistema host.
È una tecnologia fondamentale per:
- container
- sandbox applicative
- ambienti di build
- CI/CD
Il problema è che i namespace espongono al processo diverse funzionalità del kernel normalmente accessibili solo a root.
Ed è qui che nascono molte delle escalation locali moderne.
Una combinazione pericolosa
Il punto chiave non è un bug diretto in AppArmor.
Il problema nasce dalla combinazione di vari fattori:
- profili AppArmor permissivi
- uso dei namespace
- vulnerabilità del kernel
- codice eseguito da utenti non privilegiati
In alcune condizioni un attaccante può:
- eseguire codice controllato
- sfruttare i namespace per ottenere nuove capacità
- aggirare il confinamento del profilo AppArmor
- sfruttare un bug kernel
- ottenere privilegi root
È un classico esempio di catena di exploit.
Nessun componente da solo è necessariamente vulnerabile. Ma insieme creano una superficie di attacco più ampia.
Impatto reale sui sistemi
Per un normale desktop domestico questo scenario è relativamente limitato.
Ma diventa più interessante in ambienti come:
- server multi-utente
- infrastrutture cloud
- ambienti CI/CD
- piattaforme di hosting
- container shared
Molti container runtime utilizzano AppArmor come livello di isolamento.
Docker, ad esempio, applica automaticamente un profilo di sicurezza predefinito ai container.
Se questo livello viene aggirato, l’attaccante può potenzialmente uscire dal confinamento.
Qualche verifica utile
La prima cosa da fare è capire se AppArmor è attivo:
sudo aa-status
Controllate anche quali profili sono in modalità complain invece che enforce.
La modalità complain serve per debug ma non blocca le violazioni.
Monitorare i log
AppArmor registra molti eventi nei log di sistema.
Su Debian e Ubuntu si trovano spesso in:
/var/log/syslog
oppure nel sistema di audit:
/var/log/audit/audit.log
Se state sviluppando o testando profili, strumenti utili sono:
aa-logprof
aa-notify
Mitigazioni pratiche
Al di là della teoria, le contromisure sono abbastanza classiche.
Aggiornare il kernel
La maggior parte delle escalation locali viene risolta con patch kernel.
Sembra banale ma resta la difesa più efficace.
Limitare i namespace se non servono
In alcuni ambienti può avere senso limitare l’uso dei user namespaces per utenti non privilegiati.
Molte distribuzioni stanno introducendo restrizioni proprio per ridurre la superficie di attacco.
Hardening dei servizi
AppArmor dovrebbe essere solo uno dei livelli di difesa.
Altri strumenti utili includono:
- seccomp
- capability dropping
- container isolation
- systemd sandboxing
La sicurezza moderna su Linux è sempre più un modello a strati.
Conclusioni
AppArmor resta uno strumento estremamente utile. È semplice, efficace e già integrato in molte distribuzioni.
Ma casi come CrackArmor dimostrano una cosa che chi lavora con Linux da anni sa bene:
la sicurezza non è mai un singolo componente.
Kernel, namespace, sandbox e container interagiscono tra loro in modi sempre più complessi. Questo aumenta la flessibilità del sistema, ma introduce anche nuove possibilità per chi cerca di aggirare le difese.
Per noi sysadmin la lezione è sempre la stessa:
- patch veloci
- configurazioni restrittive
- monitoraggio dei log
Perché spesso la differenza tra un sistema confinato e una root shell inattesa è nascosta nei dettagli.
Le opinioni in quanto tali sono opinabili e nulla ti vieta di approfondire l’argomento.
Risorse: