AppArmor o SELinux: quale sistema MAC scegliere su Linux?

Quando irrobustisci una macchina Linux, prima o poi arrivi a un bivio: AppArmor o SELinux. Entrambi sono sistemi di Controllo di Accesso Obbligatorio (MAC) integrati nel kernel Linux tramite lo stesso framework LSM (Linux Security Modules). Entrambi confinano un processo compromesso in modo che un exploit non possa raggiungere liberamente il resto del sistema. Ma adottano approcci molto diversi, e la scelta giusta dipende meno da quale sia «più potente» che da cosa esegui, da quale distribuzione usi e da quanto lavoro sulle policy sei disposto ad accollarti.

Questa guida li confronta per progettazione, per costo di manutenzione quotidiano e per modello di minaccia, così da farti decidere invece di tirare a indovinare.

Cosa fa davvero il Controllo di Accesso Obbligatorio

I permessi classici di Linux sono discrezionali: il proprietario di un file decide chi può leggerlo o scriverlo, e un processo viene eseguito con tutti i permessi dell’utente che lo ha avviato. Se quel processo viene compromesso, l’attaccante eredita quei permessi: i tuoi file, la tua rete, la tua cartella personale.

Il Controllo di Accesso Obbligatorio aggiunge un secondo livello che l’utente non può scavalcare. Una policy centrale, applicata dal kernel, decide cosa ciascun processo può fare a prescindere dalla proprietà del file. A un server web confinato dal MAC si può imporre di leggere solo la propria document root e ascoltare sulla porta 443; e anche se un attaccante ne prende il controllo, il kernel continua a rifiutare qualunque cosa fuori da quel perimetro.

AppArmor e SELinux svolgono entrambi questa funzione. La differenza sta in come identificano ciò che un processo è autorizzato a toccare.

La differenza progettuale fondamentale: percorsi contro etichette

Questa singola distinzione spiega quasi tutti i compromessi pratici tra i due.

AppArmor si basa sui percorsi. Un profilo indica i percorsi reali a cui un programma può accedere. Una regola come /etc/nginx/** r significa «nginx può leggere qualsiasi cosa sotto /etc/nginx». Questo corrisponde direttamente al modo in cui gli amministratori già ragionano su un sistema, rendendo i profili leggibili e rapidi da scrivere.

SELinux si basa sulle etichette. Ogni file, processo, socket e porta porta un contesto di sicurezza (un’etichetta) come httpd_sys_content_t. Le regole descrivono quali etichette possono interagire tra loro, non quali percorsi. Il percorso /var/www/html/index.html è irrilevante per SELinux; ciò che conta è l’etichetta a esso associata.

La conseguenza: se sposti un file in AppArmor, la regola continua a valere finché il nuovo percorso è coperto. In SELinux, un file spostato può mantenere o perdere la propria etichetta a seconda del metodo usato (cp e mv si comportano diversamente), la fonte di confusione più comune del tipo «funzionava finché non ho copiato il file». In compenso, una policy basata sulle etichette è più difficile da ingannare: un attaccante non può aggirare una regola raggiungendo gli stessi dati tramite un link simbolico o un percorso alternativo, perché l’etichetta viaggia con l’oggetto.

Granularità e livello di garanzia

SELinux è il più granulare dei due. Poiché ogni oggetto è etichettato, la policy può esprimere controlli fuori dalla portata di AppArmor: sicurezza multilivello, applicazione dei tipi su centinaia di domini e vincoli che separano, per esempio, due applicazioni web che risiedono entrambe sotto /var/www ma che non dovrebbero mai leggere i dati l’una dell’altra. Per questo SELinux è l’impostazione predefinita negli ambienti con requisiti di sicurezza formali (RHEL, Fedora, distribuzioni di matrice governativa) ed è stato originariamente sviluppato con la National Security Agency statunitense.

AppArmor è deliberatamente più grossolano. Non può esprimere tutto ciò che esprime SELinux, ma per l’obiettivo comune – confinare alcuni servizi esposti alla rete e i browser perché un singolo exploit non possa rimbalzare oltre – quel tetto raramente conta. La maggior parte dei modelli di minaccia di desktop e piccoli server è pienamente coperta dall’espressività di AppArmor.

Un buon modo di inquadrarlo: SELinux offre un tetto più alto; AppArmor offre un pavimento di impegno più basso. Quale vinca dipende interamente dal fatto che tu abbia davvero bisogno di quel tetto.

Il costo di manutenzione nel mondo reale

È qui che la scelta di solito si decide.

Con AppArmor, i profili sono brevi file di testo che puoi leggere e modificare a mano. Le distribuzioni che lo adottano per impostazione predefinita (Ubuntu, Debian, openSUSE) includono profili già pronti, e puoi generarne di nuovi in modo interattivo:

# Vedere quali profili sono caricati e in quale modalità
sudo aa-status

# Generare un profilo per un'applicazione osservandola in esecuzione
sudo aa-genprof /usr/bin/myapp

# Mettere un profilo in modalità di applicazione
sudo aa-enforce /etc/apparmor.d/usr.bin.firefox

Una modalità «complain» registra le violazioni senza bloccarle, il che permette di sviluppare un profilo su un sistema in produzione e di stringerlo una volta noti i bisogni legittimi dell’applicazione.

Con SELinux, la policy è ampia e quasi mai la scrivi da zero: regoli valori booleani e rietichetti i file. Il punto critico è diagnosticare i dinieghi. Il riflesso sbagliato è eseguire setenforce 0 per disattivarlo; quello giusto è leggere il registro di audit:

# Verificare la modalità corrente
getenforce

# Esaminare i dinieghi recenti e ottenere una policy suggerita
sudo ausearch -m avc -ts recent | audit2allow -a

# Ripristinare le etichette corrette su un percorso
sudo restorecon -Rv /var/www/html

audit2allow propone un modulo di policy che consentirebbe l’azione negata; lo rivedi prima di applicarlo per capire perché il diniego è avvenuto, invece di concedere in blocco. Questo flusso è potente ma ha una curva di apprendimento reale, ed è il motivo principale per cui gli amministratori disattivano SELinux invece di impararlo, eliminando del tutto la protezione.

Segui l’impostazione predefinita della tua distribuzione

In pratica, la raccomandazione più solida è anche la più semplice: usa il sistema MAC che la tua distribuzione include e mantiene.

Andare contro l’impostazione predefinita significa eseguire una configurazione non supportata: i profili AppArmor per i pacchetti di Fedora non sono mantenuti, e la policy SELinux per la disposizione dei pacchetti di Ubuntu è incompleta. Erediti un carico di manutenzione che la distribuzione non ti aiuterà a sostenere. Su una macchina Fedora o RHEL, lascia SELinux in modalità Enforcing e impara audit2allow. Su Ubuntu o Debian, tieni AppArmor attivo e assicurati che browser e servizi di rete girino con profili in modalità di applicazione.

È lo stesso principio alla base della scelta di una distribuzione Linux sicura: la protezione realmente mantenuta vale più di quella teoricamente più forte ma non supportata sul tuo sistema.

Il posto del MAC in una difesa a più livelli

Né AppArmor né SELinux sono una strategia di sicurezza completa. Il MAC confina processi già in esecuzione; non fa nulla contro il codice non attendibile che scegli di eseguire, né per isolare interi carichi di lavoro l’uno dall’altro. Per isolare le singole applicazioni desktop, gli strumenti di sandboxing come Firejail e bubblewrap lavorano accanto al MAC invece di sostituirlo. Per un irrobustimento di sistema più ampio – parametri del kernel, sysctl, avvio verificato – il MAC è solo un livello nel quadro più generale dell’hardening di Linux, e si colloca nel confronto più ampio tra i modelli di sicurezza di Linux e Windows.

La conclusione è che la domanda AppArmor-o-SELinux è reale ma circoscritta. Scegli quello che la tua distribuzione mantiene, lascialo in modalità di applicazione e dedica il resto del tuo impegno ai livelli sopra e sotto di esso.

Domande frequenti

SELinux è più sicuro di AppArmor? SELinux può esprimere una policy più rigorosa e fine, quindi in termini assoluti il suo tetto è più alto. Ma la sicurezza nasce da una policy realmente applicata e mantenuta. Un sistema AppArmor lasciato in modalità di applicazione ti protegge più di un sistema SELinux che qualcuno ha disattivato perché i dinieghi erano confusi.

Posso usarli entrambi contemporaneamente? No. AppArmor e SELinux sono entrambi LSM «principali» e il kernel ne carica solo uno come sistema MAC primario. Ne scegli uno per macchina: in pratica, quello che la tua distribuzione imposta in modo predefinito.

Dovrei mai disattivarli? Quasi mai. Disattivare il MAC rimuove un livello che limita l’estensione dei danni di un servizio compromesso. Di fronte a un diniego, diagnosticalo (audit2allow per SELinux, modalità complain per AppArmor) invece di spegnere tutto.

Quale è più facile per un principiante? AppArmor. I suoi profili per percorsi si leggono come il filesystem che già conosci, e Ubuntu e Debian includono profili funzionanti di serie. SELinux ripaga il tempo investito a impararlo, ma quel tempo è reale.