MAC on My personal blog

AppArmor

Tue, 12 May 2026 09:00:00 +0200

Perché conta

SELinux è potentissimo ma usa etichette e type, che molti trovano ostici. AppArmor persegue lo stesso scopo — controllo d’accesso obbligatorio che confina i programmi — con un modello diverso: profili basati sui percorsi. Un profilo dice, in un file di testo leggibile, “questo programma può leggere qui, scrivere lì, usare queste capabilities, e nient’altro”. È il MAC di default su Ubuntu e SUSE, ed è spesso più immediato da capire e da scrivere.

Lo stato dei profili

aa-status            # quali profili sono caricati e in quale modalità
# apparmor module is loaded.
# 30 profiles are in enforce mode.
#    /usr/sbin/nginx ...
# 5 profiles are in complain mode.

Come SELinux, ha due modalità operative per profilo:

1
2

enforce   → applica il profilo: ciò che non è permesso viene bloccato (produzione)
complain  → non blocca, ma LOGGA le violazioni → per mettere a punto un profilo nuovo

1
2

aa-enforce /etc/apparmor.d/usr.sbin.nginx    # metti un profilo in enforce
aa-complain /etc/apparmor.d/usr.sbin.nginx   # mettilo in complain (diagnosi)

Leggere un profilo

I profili vivono in /etc/apparmor.d/. La sintassi è esplicita e leggibile:

#include <tunables/global>
/usr/local/bin/myapp {
  #include <abstractions/base>
  capability net_bind_service,          # può aprire porte basse
  /etc/myapp/** r,                      # legge la sua config
  /var/lib/myapp/** rw,                 # legge e scrive i suoi dati
  /var/log/myapp/app.log w,             # scrive il suo log
  network inet stream,                  # socket TCP
  # tutto ciò che non è elencato è NEGATO
}

La filosofia è la stessa del privilegio minimo: elenchi ciò che è permesso, tutto il resto è vietato. Se myapp viene compromesso, non può leggere /etc/shadow né scrivere fuori dalle sue directory: non è nel profilo.

Mettere a punto un profilo nuovo

AppArmor ha strumenti che generano il profilo osservando l’applicazione in funzione:

1
2

aa-genprof /usr/local/bin/myapp     # avvia la generazione guidata: usa l'app, poi conferma gli accessi
aa-logprof                          # rivede i log e propone di aggiungere al profilo gli accessi visti

Il flusso tipico: metti il profilo in complain, usi l’applicazione normalmente, poi aa-logprof legge cosa ha fatto e ti chiede quali accessi autorizzare. Confermi solo quelli legittimi, passi a enforce.

SELinux o AppArmor?

1
2

AppArmor  → profili per-percorso, leggibili, rapidi da scrivere; default Ubuntu/SUSE
SELinux   → etichette/type, più granulare e rigoroso; default RHEL/Fedora/Android

Non si scelgono: di solito usi quello della tua distribuzione (sono alternativi, non si installano insieme). Il principio è identico — una politica obbligatoria che confina i programmi oltre il DAC — e vale la regola d’oro di entrambi: davanti a un problema, metti in complain/permissive e diagnostica, non disabilitare.

Conclusione

AppArmor confina i programmi con profili per-percorso leggibili, in enforce o complain, con strumenti che li generano osservando l’app: lo stesso MAC di SELinux con un’ergonomia diversa. Confinamento e controlli sono in posto; ma un sistema sicuro è anche un sistema osservato. Passiamo al monitoraggio: l’auditing con auditd, prossimo capitolo.

SELinux

Tue, 05 May 2026 09:00:00 +0200

Perché conta

Tutto ciò che abbiamo visto finora è controllo discrezionale: il proprietario di una risorsa decide, e root scavalca ogni controllo. Il limite è evidente — se un servizio che gira come root (o un processo che ottiene root) viene compromesso, il DAC non lo ferma. Il controllo d’accesso obbligatorio (MAC) aggiunge una politica di sistema che vale sopra il DAC e che nemmeno root può aggirare: anche se un processo è root, può fare solo ciò che la politica SELinux consente al suo tipo. È un confinamento potentissimo — e la risposta sbagliata, setenforce 0, è anche la più diffusa.

L’idea: etichette e tipi

In SELinux ogni processo e ogni risorsa hanno un’etichetta (context), e la politica definisce quali interazioni tra etichette sono permesse. Il campo che conta di più è il type (type enforcement).

ls -Z /var/www/html/index.html     # contesto del file
# unconfined_u:object_r:httpd_sys_content_t:s0
#                       ^^^^^^^^^^^^^^^^^^^^ il TYPE: "contenuto web per httpd"
ps -eZ | grep nginx                # contesto del processo
# system_u:system_r:httpd_t:s0 ...  ← il processo web gira nel type httpd_t

La politica dice, in sostanza: “un processo httpd_t può leggere file httpd_sys_content_t”. Se il web server (confinato in httpd_t) viene compromesso, non può leggere /etc/shadow (shadow_t) o scrivere ovunque: la politica glielo vieta, root o no.

I tre modi

1
2
3

getenforce                     # Enforcing | Permissive | Disabled
setenforce 1                   # Enforcing: applica la politica (OBIETTIVO)
setenforce 0                   # Permissive: NON applica, ma LOGGA le violazioni (per diagnosi)

1
2
3

Enforcing   → la politica è applicata (produzione)
Permissive  → non blocca ma registra cosa bloccherebbe → usalo per DIAGNOSTICARE, non come resa
Disabled    → SELinux spento (da evitare: perdi anche le etichette)

Il riflesso sbagliato è passare a Disabled al primo problema. Quello giusto è passare a Permissive temporaneamente per vedere cosa verrebbe bloccato, capirlo, correggere la politica, e tornare a Enforcing.

Il troubleshooting che non spaventa

Quando “qualcosa non funziona e sospetto SELinux”, il flusso è preciso:

# 1. le negazioni finiscono nell'audit log
ausearch -m avc -ts recent            # mostra gli Access Vector Cache denial recenti
# 2. sealert spiega in linguaggio umano e suggerisce la soluzione
sealert -a /var/log/audit/audit.log
# 3. spesso basta un booleano o un contesto giusto, non disabilitare tutto

Due aggiustamenti coprono la maggioranza dei casi:

# A) BOOLEANI: interruttori predefiniti per comportamenti comuni
getsebool -a | grep httpd                     # es: httpd_can_network_connect
setsebool -P httpd_can_network_connect on     # -P = persistente

# B) CONTESTI: dare l'etichetta giusta a file in percorsi non standard
semanage fcontext -a -t httpd_sys_content_t "/srv/web(/.*)?"
restorecon -Rv /srv/web                        # riapplica i contesti

Quando serve una regola nuova: audit2allow

Se un’applicazione legittima ha bisogno di un accesso che nessun booleano copre, si genera un modulo di policy dai denial — senza disabilitare nulla.

1
2

ausearch -m avc -ts recent | audit2allow -M myapp_local
semodule -i myapp_local.pp        # installa il modulo: concede SOLO ciò che serviva

Attenzione: audit2allow va usato con criterio — concedi solo ciò che è davvero legittimo, non tutto ciò che l’app prova a fare (potrebbe provare anche cose che è giusto bloccare).

Domanda: SELinux ha la fama di rompere le applicazioni e di essere complicatissimo. Visto che ho già DAC stretto, capabilities e sandboxing systemd, non è più pragmatico disabilitarlo e vivere sereni?

È il ragionamento più comune e anche quello che butta via la protezione più forte proprio quando servirebbe di più. Partiamo dalla fama: SELinux "rompe le app" quasi sempre perché i file sono nel posto sbagliato (contesto errato) o manca un booleano — due cose che si diagnosticano in minuti con ausearch e sealert e si risolvono con un comando, senza disabilitare niente. La complessità vera (scrivere policy da zero) non ti riguarda nel 95% dei casi: usi la policy mirata della distribuzione e la ritocchi con booleani e contesti. Ora il punto sostanziale: DAC stretto, capabilities e sandboxing systemd sono ottimi, ma hanno un limite comune — operano dentro il modello discrezionale e, soprattutto, dipendono dal fatto che tu li abbia configurati correttamente per ogni servizio. SELinux aggiunge qualcosa che gli altri non danno: un confinamento obbligatorio, definito a livello di sistema, che vale anche contro un processo che è diventato root e che resta in piedi anche dove ti sei dimenticato di sandboxare. Il caso che conta è questo: un servizio ha una vulnerabilità che permette l'esecuzione di codice e magari un'escalation a root. Il DAC a quel punto non ferma più nulla (root scavalca tutto), e se quel servizio non l'avevi sandboxato con systemd, l'attaccante è libero. Con SELinux in enforcing, invece, il processo resta confinato nel suo type: il web server compromesso, anche da root, non può leggere /etc/shadow né scrivere fuori dalle sue directory, perché la policy non lo prevede per httpd_t. È esattamente la difesa che interviene quando tutte le altre hanno ceduto. Disabilitarlo per "vivere sereni" significa rinunciare all'unico strato che un attaccante con root non può semplicemente aggirare — in cambio di non dover imparare due comandi. Il pragmatismo vero è tenerlo in enforcing e imparare il flusso di troubleshooting: è molto meno lavoro di quanto la sua fama suggerisca, e copre proprio lo scenario peggiore.

Conclusione

SELinux impone una politica di sistema che confina ogni processo al suo type e che nemmeno root scavalca; il segreto è non disabilitarlo ma usare Permissive per diagnosticare, booleani e contesti per correggere, audit2allow per i casi residui. Esiste un secondo approccio al MAC, più semplice da leggere e basato sui percorsi invece che sulle etichette: AppArmor, prossimo capitolo.