Come disattivare SELinux su CentOS in modo sicuro

Disattivare SELinux su CentOS non è una scelta neutra: togli un livello di controllo che, in molti ambienti, evita errori di permessi, accessi impropri e comportamenti ambigui delle applicazioni. La cosa giusta non è “spegnere tutto e basta”, ma capire perché SELinux sta bloccando un servizio, se il blocco è davvero un falso positivo, e solo dopo decidere se passare a una modalità meno restrittiva o disabilitarlo in modo permanente.

Se devi intervenire su un server CentOS in produzione, la sequenza sensata è sempre la stessa: osservi il contesto, identifichi il layer che fallisce, provi una mitigazione reversibile e solo in ultimo modifichi la policy di sicurezza. In pratica: prima diagnostica, poi change. Non il contrario.

Quando ha senso disattivare SELinux

La domanda corretta non è se si possa disattivare SELinux, ma se sia davvero necessario. In molti casi il problema è un contesto sbagliato, un’etichetta SELinux non coerente, oppure un servizio che scrive in una directory fuori policy. Spegnere SELinux risolve il sintomo, ma spesso nasconde il difetto di configurazione.

Ha senso valutare una disattivazione solo in casi limitati: ambienti di laboratorio, macchine temporanee, troubleshooting urgente con rollback previsto, oppure applicazioni legacy che non possono essere adattate in tempi ragionevoli. In tutti gli altri casi, la scelta più robusta è mantenere SELinux in enforcing e correggere il motivo del blocco.

Se ti serve una regola pratica: se il server espone servizi pubblici, non disattivare SELinux senza un motivo documentato e una verifica successiva. Se invece stai lavorando su un nodo di test e vuoi solo capire se il problema dipende da SELinux, puoi passare a permissive per isolare la causa senza togliere completamente il controllo.

Prima verifica lo stato reale di SELinux

Su CentOS il punto di partenza è sempre lo stato attuale. Non fidarti della memoria, perché tra un reboot e un cambio di configurazione lo stato può essere diverso da quello che pensi.

getenforce

Output atteso:

Enforcing

Altri valori possibili sono Permissive e Disabled. Se vedi Permissive, SELinux non blocca, ma registra gli eventi. Se vedi Disabled, non c’è enforcement e la macchina è già fuori dal perimetro di protezione di SELinux.

Per capire anche lo stato persistente, controlla il file di configurazione:

grep -E '^SELINUX=' /etc/selinux/config

Qui trovi di solito uno dei seguenti valori: enforcing, permissive, disabled. Il primo è lo stato più sicuro; il secondo è utile per diagnosi; il terzo disabilita SELinux anche dopo il reboot.

Disattivazione temporanea: la via meno rischiosa

Se il problema è in corso e devi capire rapidamente se SELinux è la causa, la soluzione minima è passare a modalità permissiva. È reversibile e non richiede reboot. Questa è la scelta giusta quando vuoi confermare un’ipotesi senza cambiare in modo permanente la superficie di sicurezza.

Comando:

sudo setenforce 0

Verifica subito dopo:

getenforce

Atteso:

Permissive

Se l’applicazione torna a funzionare in questo stato, hai una forte indicazione che il blocco è legato a SELinux. A quel punto non fermarti alla conclusione “basta disattivarlo”: serve capire quale accesso è stato negato e se il problema si risolve con una correzione di contesto, di boolean o di policy.

Rollback immediato:

sudo setenforce 1

Con questo torni in enforcing senza toccare la configurazione persistente. Se il servizio smette di funzionare di nuovo, hai confermato che il cambiamento temporaneo era l’unica variabile rilevante.

Disattivazione permanente: solo se hai deciso di farlo davvero

La disattivazione permanente si fa modificando il file /etc/selinux/config. È un change che richiede più cautela perché sopravvive ai reboot e quindi ha un impatto più ampio del semplice setenforce.

Prima di toccarlo, fai un backup del file. È un passo banale, ma è anche il rollback più rapido se sbagli una riga o vuoi tornare indietro al comportamento precedente.

sudo cp -a /etc/selinux/config /etc/selinux/config.bak.$(date +%F-%H%M%S)

Ora modifica il file con l’editor che usi di solito:

sudo vi /etc/selinux/config

Imposta:

SELINUX=disabled

Se invece vuoi restare in uno stato intermedio per un periodo di osservazione, puoi usare SELINUX=permissive. È una scelta spesso più sensata di disabled perché mantiene visibili i log e ti lascia spazio per correggere la causa reale.

Dopo il salvataggio, il cambio non è ancora completo: serve un reboot perché lo stato persistente venga applicato all’avvio. Prima però controlla che il file sia stato scritto correttamente:

grep -E '^SELINUX=' /etc/selinux/config

Se il valore non è quello atteso, non riavviare. Correggi prima il file, così eviti di portare il sistema in uno stato diverso da quello pianificato.

Riavvio e conferma dello stato dopo il reboot

Il reboot è il punto in cui distingui una modifica temporanea da una permanente. Dopo il riavvio, verifica lo stato con il comando standard:

getenforce

Se hai impostato SELINUX=disabled, l’output atteso è Disabled. Se hai scelto permissive, l’output atteso è Permissive. Se vedi ancora Enforcing, significa che il file non è stato applicato correttamente, oppure che stai leggendo un contesto non aggiornato e devi ricontrollare la configurazione effettiva.

Può essere utile leggere anche il log di boot per confermare che SELinux sia stato disabilitato correttamente e che non ci siano errori correlati:

journalctl -b | grep -i selinux

Se il sistema usa un kernel con supporto SELinux ma il file di configurazione è coerente, il messaggio di boot dovrebbe riflettere lo stato scelto. Se emergono errori, il problema non è la sola opzione nel file: c’è un tema più ampio da leggere nei log.

Come capire se SELinux era davvero il colpevole

La prova più pulita non è “il sito è tornato su”, ma “il sito torna su solo quando SELinux non blocca”. Per questo conviene guardare gli audit log prima e dopo il cambio. Su CentOS, gli eventi SELinux finiscono spesso in /var/log/audit/audit.log se il demone audit è attivo.

sudo ausearch -m avc -ts recent

Se il comando restituisce denials coerenti con il servizio in difficoltà, hai la conferma che SELinux stava intervenendo. I campi da osservare sono il tipo di accesso negato, il processo coinvolto e il contesto del file o della porta. Non è raro che un’applicazione abbia permessi Unix corretti ma contesto SELinux sbagliato.

In alternativa puoi cercare i messaggi AVC in modo più grezzo:

sudo grep -i avc /var/log/audit/audit.log

Se non trovi nulla, non concludere in fretta che SELinux non c’entra. Potrebbe significare che audit non è attivo, che il problema è altrove, o che gli eventi sono vecchi rispetto alla finestra temporale che stai analizzando. In quel caso la chiusura del gap è semplice: ricostruisci la finestra temporale con il timestamp del problema e rileggi i log in quel range.

Alternative migliori della disattivazione totale

Spesso il modo corretto di “risolvere SELinux” non è spegnerlo, ma correggere il componente che non rispetta le policy. Per esempio, un web server che deve scrivere in una directory non standard può richiedere un contesto appropriato; un servizio che ascolta su una porta diversa può richiedere un boolean o una regola specifica.

Per gli errori di contesto sui file, il primo strumento da guardare è restorecon. Non modifica la policy globale, ma ripristina il contesto previsto per il percorso. Se il problema nasce da file copiati a mano o da directory create fuori standard, spesso è proprio qui che si chiude il caso.

sudo restorecon -Rv /percorso/della/directory

Se il servizio usa una porta non standard, valuta il mapping SELinux invece di disabilitare tutto. È il tipo di correzione che mantiene il controllo attivo e riduce il rischio di regressioni future. La differenza pratica è semplice: la disattivazione elimina il controllo, la correzione lo rende compatibile con il tuo servizio.

Per servizi web, database, mail e storage, l’analisi migliore parte quasi sempre dai log del servizio e dai denial SELinux nello stesso intervallo temporale. Se i due non coincidono, stai guardando il layer sbagliato.

Rollback pulito se hai già disabilitato SELinux

Se hai cambiato il file di configurazione e vuoi tornare indietro, il rollback migliore è ripristinare il backup fatto prima del change. È un’operazione lineare e ti evita di ricostruire a mano la configurazione precedente.

sudo cp -a /etc/selinux/config.bak.YYYY-MM-DD-HHMMSS /etc/selinux/config

Poi riavvii il sistema e verifichi con getenforce. Se invece non hai un backup, devi almeno ricostruire il valore precedente leggendo la cronologia operativa, il sistema di versioning della configurazione o l’orchestrazione usata per il provisioning. Se questo dato manca, il gap va chiuso prima del reboot successivo, altrimenti rischi di non sapere più quale stato stai mantenendo davvero.

Se vuoi mantenere SELinux attivo ma evitare il blocco immediato del servizio, la strada giusta è tornare a enforcing solo dopo aver corretto il denial specifico. In altre parole: il rollback della disattivazione non deve essere un salto nel buio, ma la conseguenza di una verifica già completata.

Checklist operativa per farlo senza errori

Questa è la sequenza che userei su un server reale, perché riduce il rischio di fare cambi inutili.

Questa sequenza evita il classico errore operativo: cambiare subito il file di configurazione e scoprire dopo che il problema era un path sbagliato, una porta non autorizzata o un contesto non allineato.

Cosa controllare quando SELinux resta in enforcing ma il servizio continua a fallire

Se hai lasciato SELinux attivo e il servizio non parte ancora, non insistere con la disattivazione come prima risposta. Guarda se il problema è davvero SELinux oppure un guasto diverso: permessi Unix, disco pieno, servizio non in ascolto, dipendenza mancante, database offline, certificato scaduto, firewall o WAF.

Un controllo rapido lato servizio può essere utile, per esempio:

systemctl status nome-servizio --no-pager

Se lo stato mostra crash, restart loop o errori di configurazione, SELinux potrebbe essere solo un elemento secondario. In quel caso la priorità va al log applicativo o al journal del servizio, non alla disattivazione del controllo di sicurezza.

In sintesi: disattivare SELinux su CentOS è semplice tecnicamente, ma farlo bene richiede disciplina operativa. Il percorso più pulito è test temporaneo, lettura dei denial, correzione mirata e rollback pronto. Quando il motivo del blocco è chiaro, spesso non serve spegnere nulla: basta allineare il servizio alle policy invece di abbassare il livello di protezione dell’intero host.