1 11/10/2026 9 min

SELinux: non si cambia “a sentimento”

Se devi cambiare le modalità SELinux in un sistema Linux, la domanda giusta non è “come lo spengo”, ma “quale stato mi serve davvero e per quanto tempo”. In produzione, la scelta tra Enforcing, Permissive e Disabled ha effetti molto diversi su sicurezza, diagnosi e tempi di ripristino. Il punto operativo è semplice: modifica minima, verifica immediata, poi persistenza solo se il motivo regge.

SELinux non è un interruttore decorativo. Se lo disattivi per far partire un servizio, stai probabilmente mascherando un problema di label, policy o permessi. Se lo metti in permissive in modo permanente, stai riducendo la superficie di controllo del sistema. La sequenza corretta è: leggere lo stato attuale, capire il motivo del blocco, raccogliere gli AVC denial, correggere il contesto o la policy, e solo in ultima istanza cambiare modalità.

Le tre modalità e quando usarle

Enforcing è lo stato normale: le regole sono applicate e i denial bloccano davvero l’azione. È la modalità da mantenere quasi sempre in produzione.

Permissive registra i denial ma non li applica. È utile per troubleshooting controllato, perché ti mostra cosa verrebbe bloccato senza interrompere il servizio. È la scelta corretta quando devi raccogliere evidenza prima di fare una correzione strutturale.

Disabled spegne SELinux. Va considerato solo come eccezione temporanea in contesti molto specifici, e di norma non è la soluzione giusta: perdi enforcement, audit e una parte importante del modello di hardening. Se il tuo obiettivo è far ripartire un servizio, quasi sempre Permissive è meno rischioso di Disabled.

Verificare lo stato prima di toccare la configurazione

Prima di cambiare qualcosa, identifica lo stato attuale e il contesto. Su sistemi moderni, questi comandi sono il punto di partenza:

getenforce
sestatus
cat /etc/selinux/config

Atteso: getenforce restituisce Enforcing o Permissive; sestatus mostra lo stato runtime e quello configurato al boot; /etc/selinux/config contiene la modalità persistente. Se runtime e configurazione non coincidono, stai già guardando un indizio utile: qualcuno ha cambiato lo stato al volo senza fissarlo nel boot, oppure viceversa.

Un esempio tipico: il servizio web funziona dopo setenforce 0, ma torna a fallire al reboot. Questo significa che il problema non è risolto, è soltanto nascosto. La verifica successiva deve essere sui log di audit e sui contesti SELinux del contenuto o del processo coinvolto.

Cambiare modalità in modo reversibile

Se devi intervenire in emergenza, la modifica più reversibile è passare da Enforcing a Permissive. È una misura temporanea, utile per confermare il legame tra SELinux e il sintomo, non per risolvere il problema in modo definitivo.

Comando runtime:

sudo setenforce 0

Verifica immediata:

getenforce

Atteso: Permissive. Se il servizio torna operativo, hai conferma che SELinux stava bloccando qualcosa, ma non hai ancora identificato cosa. A quel punto devi raccogliere evidenza, non fermarti alla mitigazione.

Per rendere la modifica persistente al reboot, modifica il file di configurazione:

sudo cp -a /etc/selinux/config /etc/selinux/config.bak.$(date +%F_%H%M%S)
sudo sed -i 's/^SELINUX=.*/SELINUX=permissive/' /etc/selinux/config

Se invece devi tornare a enforcement:

sudo sed -i 's/^SELINUX=.*/SELINUX=enforcing/' /etc/selinux/config
sudo setenforce 1

Blast radius: il runtime cambia solo sulla macchina locale; il file di configurazione impatta il prossimo boot. Rollback: ripristina il backup del file o rimetti il valore precedente e riavvia solo se hai cambiato lo stato persistente.

Quando “Disabled” ha senso e quando no

Disabilitare SELinux richiede il reboot e va trattato come un cambio più invasivo. È da considerare solo se hai una necessità tecnica chiara, una finestra di manutenzione e una strategia di rollback. In troubleshooting ordinario è quasi sempre una scorciatoia sbagliata, perché ti toglie visibilità sui denial e ti allontana dalla causa reale.

Per impostare il boot su disabled, la voce nel file di configurazione è questa:

SELINUX=disabled

Dopo il reboot, verifica con:

getenforce
sestatus

Atteso: lo stato risulta Disabled. Se non lo è, controlla che il sistema abbia letto il file corretto e che non ci siano vincoli del bootloader o di un profilo immagine/container che sovrascrive la configurazione. Su macchine gestite in modo centralizzato, il file locale può non essere la sola fonte di verità.

Nota operativa: passare a Disabled non è un fix, è un bypass. Se il problema era un contesto errato su file web, un boolean mancante o una porta non etichettata, stai solo rinunciando al controllo. In audit serio questa scelta va motivata e tracciata.

Capire il motivo del blocco: audit e AVC denial

Se il servizio fallisce in Enforcing, la prima evidenza utile è quasi sempre nel log di audit. Su molte distribuzioni trovi i denial in uno di questi percorsi:

/var/log/audit/audit.log
/var/log/messages
/journalctl -t setroubleshoot

Estrai gli eventi recenti così:

sudo ausearch -m avc -ts recent
sudo journalctl -xe | grep -i 'avc\|selinux\|denied'

Atteso: trovi righe che indicano processo, oggetto, classe e permesso negato. Questi dettagli servono per distinguere un problema di label da un problema di policy. Per esempio, un web server che non legge contenuti in una directory non standard spesso ha un contesto file sbagliato, non una policy mancante.

Se hai installato gli strumenti giusti, puoi usare anche:

sudo sealert -a /var/log/audit/audit.log

Il vantaggio pratico è che ti restituisce una lettura più umana del denial. Il limite è che non sostituisce la verifica tecnica: devi comunque controllare contesti, path e policy effettiva.

Correggere il contesto invece di abbassare la guardia

Molti problemi SELinux nascono da file o directory con etichette sbagliate. È il caso più comune nei document root personalizzati, nei volumi montati a mano, nelle directory dati di servizi e nei percorsi copiati da backup senza preservare i contesti.

Controlla il contesto con:

ls -Z /var/www/html
ls -Z /percorso/del/servizio

Atteso: le etichette corrispondono al tipo atteso per quel contenuto. Se il web server deve leggere una directory di contenuti, ma il contesto è generico o sbagliato, SELinux blocca anche se i permessi Unix sembrano corretti.

Per ripristinare il contesto predefinito su una directory web, spesso la strada giusta è:

sudo restorecon -Rv /var/www/html

Se il contenuto vive in un path non standard e vuoi renderlo persistente, usa un mapping di contesto con semanage fcontext e poi applica il restore. Esempio:

sudo semanage fcontext -a -t httpd_sys_content_t '/srv/web(/.*)?'
sudo restorecon -Rv /srv/web

Qui il vantaggio è chiaro: il fix sopravvive ai reboot e agli aggiornamenti del filesystem, senza abbassare la protezione globale. Rollback: rimuovi la regola con semanage fcontext -d e riapplica restorecon se hai assegnato il tipo sbagliato.

Boolean SELinux: il punto giusto tra blocco e permissività totale

Quando il problema non è il contesto ma il comportamento consentito al servizio, i boolean SELinux sono spesso la correzione più pulita. Per esempio, un web server che deve fare rete in uscita, leggere contenuti in una directory condivisa o connettersi a un backend può richiedere un boolean specifico.

Elenca i boolean rilevanti con:

getsebool -a | grep httpd

Attiva solo quello necessario, per esempio:

sudo setsebool -P httpd_can_network_connect on

L’opzione -P rende la modifica persistente. Se vuoi testare senza fissarla, ometti la persistenza e osserva il comportamento. Questo è spesso il modo migliore per distinguere una necessità reale da un workaround eccessivo.

Atteso: il servizio torna a funzionare e i denial spariscono o cambiano natura. Se continui a vedere blocchi, il boolean non era il problema principale oppure il servizio richiede anche correzioni di contesto o policy.

Policy custom: quando il contesto e i boolean non bastano

Se hai un servizio custom o un’applicazione con comportamento fuori standard, potresti dover creare una policy dedicata. In quel caso, la logica resta la stessa: prima raccogli i denial reali, poi costruisci il minimo indispensabile per autorizzare quel comportamento specifico.

Per generare un modulo di base a partire dagli AVC recenti, puoi usare strumenti come audit2allow, ma con cautela. Il rischio è produrre una policy troppo ampia. Il flusso corretto è: analisi dei denial, revisione manuale, test in staging o in finestra controllata, quindi deploy del modulo firmato e tracciato.

sudo ausearch -m avc -ts recent | audit2allow -M local-custom
sudo semodule -i local-custom.pp

Questa è una strada da usare quando hai un caso ripetibile e ben compreso. Se la usi per coprire un errore di configurazione banale, stai trasformando un problema operativo in debito di sicurezza.

Scenario pratico: sito web che funziona solo con SELinux permissive

Il caso classico è un sito che risponde correttamente con setenforce 0 ma restituisce errore o pagina vuota in Enforcing. La diagnosi corretta segue questo ordine:

  1. Controlla lo stato: getenforce e sestatus.
  2. Guarda i denial: ausearch -m avc -ts recent.
  3. Verifica il contesto della directory: ls -Z.
  4. Ripristina etichette: restorecon o semanage fcontext.
  5. Solo se serve, abilita un boolean o crea una policy minima.

In questo schema, cambiare modalità serve soltanto a confermare il nesso causale. Il fix vero è quasi sempre uno di questi tre: contesto corretto, boolean corretto, policy corretta. Se il servizio usa una directory in /srv o un mount esterno, controlla anche il tipo di filesystem e la persistenza del label dopo il reboot.

Controlli finali prima di chiudere l’intervento

Dopo il cambio, la verifica non è solo “il servizio parte”. Devi controllare che SELinux stia facendo il suo lavoro nel modo previsto. I controlli minimi sono questi:

getenforce
sestatus
sudo ausearch -m avc -ts recent

OK: lo stato è quello voluto, il servizio risponde, e non compaiono nuovi denial collegati al problema che stavi risolvendo. KO: il servizio funziona solo perché hai lasciato il sistema in permissive o disabled, oppure i denial continuano ma hai cambiato strada senza aver chiuso la causa.

Se hai modificato /etc/selinux/config, annota il motivo e il rollback. Se hai applicato una regola di contesto, conserva il comando semanage fcontext usato. Se hai attivato un boolean, registra quale e perché. Questa disciplina evita che, tra qualche mese, qualcuno si ritrovi a inseguire un problema che era stato “risolto” abbassando il livello di protezione del nodo.

Regola pratica da portare a casa

Se SELinux ti blocca, non partire dalla disattivazione. Parti dall’evidenza: denial, contesto, boolean, poi policy. Enforcing resta la destinazione; permissive è un ponte diagnostico, non una soluzione permanente.

Assunzione operativa: il sistema è Linux recente con SELinux attivo e systemd presente; i comandi mostrati coprono il flusso più comune su ambienti server RHEL-like e compatibili, ma la logica resta la stessa anche quando il packaging o i percorsi dei log cambiano.