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.