Come disattivare SELinux su Rocky Linux 8 -- TrgtKLS • Tech, Sicurezza e Strumenti & guide per Webmaster

1 1 visite 03/05/2026 Pubblicato il: 03/05/2026 22:00 Tempo di lettura: 8 min

SELinux su Rocky Linux 8: cosa stai davvero spegnendo

Su Rocky Linux 8 SELinux non è un dettaglio cosmetico: è un livello di controllo accessi che può bloccare processi, porte, file e contesti non coerenti con la policy attiva. Spegnerlo elimina una barriera utile, quindi va fatto solo quando hai una ragione precisa e una via di ritorno chiara. In pratica, prima capisci se stai cercando di risolvere un errore di permessi, un binding su porta non standard, un accesso a file con contesto sbagliato o un comportamento voluto ma non ancora allineato alla policy.

La distinzione importante è tra disabilitazione temporanea e permanente. La prima serve per test rapidi e si perde al riavvio. La seconda modifica il bootloader e cambia il comportamento del sistema in modo persistente. Se il problema è applicativo o di configurazione, quasi sempre conviene correggere la policy o i contesti invece di lasciare SELinux spento. Se invece stai facendo troubleshooting controllato, la disattivazione temporanea è il primo passo sensato per capire se il blocco arriva davvero da lì.

Verificare lo stato prima di toccare la configurazione

Prima di cambiare qualcosa, controlla lo stato attuale e conserva un riferimento. Su un host in produzione, questa verifica ti dice se il problema è coerente con un enforcement attivo oppure no.

Controlla lo stato corrente:
```
getenforce
```
Atteso: Enforcing, Permissive o Disabled. Se trovi Enforcing, SELinux sta applicando la policy.
Controlla anche il riassunto completo:
```
sestatus
```
Qui vedi sia lo stato runtime sia quello configurato al boot. Le righe utili sono Current mode e Mode from config file.
Se stai inseguendo un blocco, guarda i log AVC:
```
sudo ausearch -m AVC,USER_AVC -ts recent
```
Se non hai auditd attivo o non trovi eventi recenti, non inventare: il dato manca. Chiudi il gap con sudo systemctl status auditd e con il file /var/log/audit/audit.log.

Se il tuo obiettivo è solo capire se SELinux è il colpevole, la prova più pulita è temporaneamente passare a permissive e ripetere l’azione che fallisce. Se l’errore sparisce, hai una conferma forte. Se l’errore resta, il problema è altrove e non hai sprecato tempo a cambiare una policy senza motivo.

Disattivazione temporanea: utile per test, non per lasciare il sistema in giro

Il cambio temporaneo impatta il runtime corrente e basta. È la scelta giusta quando vuoi fare una prova rapida e reversibile. Il blast radius è limitato alla sessione corrente del sistema, ma l’effetto operativo può essere ampio perché stai togliendo un controllo di sicurezza a tutto l’host.

Porta SELinux in permissive:
```
sudo setenforce 0
```
Verifica subito:
```
getenforce
```
Atteso: Permissive.
Ripeti l’operazione che prima falliva. Se il servizio web, il demone o l’app torna a funzionare, hai un indicatore forte che il problema è legato a SELinux e non a un guasto generico del servizio.
Se vuoi rientrare in enforcement senza riavviare:
```
sudo setenforce 1
```
Verifica di nuovo con getenforce. Atteso: Enforcing.

Il limite di questo approccio è ovvio: non ti dice quale regola o contesto stia bloccando il flusso, solo che SELinux è coinvolto. Per questo, se la prova funziona, il passo successivo non deve essere “lasciarlo spento”, ma leggere gli AVC e correggere la causa.

Disattivazione permanente: modifica controllata del boot

La disattivazione permanente richiede un cambio nel file di configurazione di SELinux e un riavvio. È una modifica di configurazione persistente, quindi va fatta con backup e con un criterio di rollback esplicito.

Fai una copia del file prima di toccarlo:
```
sudo cp -a /etc/selinux/config /etc/selinux/config.$(date +%F_%H%M%S).bak
```
Questo ti garantisce un rollback semplice se sbagli valore o se devi rimettere tutto com’era.
Apri il file:
```
sudo vi /etc/selinux/config
```
Oppure usa l’editor che preferisci. La riga da cambiare è questa:
```
SELINUX=disabled
```
Le alternative possibili sono enforcing e permissive. Per spegnere SELinux al boot serve proprio disabled.
Salva il file e riavvia:
```
sudo reboot
```
Dopo il reboot, verifica lo stato:
```
sestatus
```
Atteso: Current mode: disabled e Mode from config file: disabled.

Nota pratica: con SELINUX=disabled SELinux non viene solo messo in permissive, ma viene escluso dal boot. Questo è un cambio più radicale e meno reversibile sul campo rispetto a setenforce 0. Se devi solo fare troubleshooting, spesso conviene fermarsi alla modalità permissive e non arrivare alla disattivazione permanente.

Quando disattivarlo davvero e quando no

Disabilitare SELinux ha senso in pochi casi: ambienti lab, macchine temporanee, test di compatibilità, oppure sistemi legacy dove la remediation richiederebbe un lavoro di policy troppo costoso rispetto al valore dell’host. In produzione, invece, la scelta corretta di solito è correggere il contesto, la policy o il binding.

Gli errori più comuni che portano a spegnerlo troppo in fretta sono questi:

Un servizio web che legge file fuori dal path previsto e viene bloccato dai context label.
Un demone che prova ad aprire una porta non standard senza il relativo tipo SELinux.
Una directory dati copiata manualmente con contesto errato dopo restore o migrazione.
Un’app containerizzata o un reverse proxy configurato senza tenere conto delle label.

In tutti questi casi, spegnere SELinux maschera il problema ma non lo risolve. È una scorciatoia che funziona subito e poi si paga dopo, quando il sistema cambia, il servizio viene migrato o si riattiva la policy per un’altra ragione.

Alternative più sane alla disattivazione totale

Se il blocco è circoscritto, spesso puoi evitare di disabilitare SELinux del tutto. Prima di scegliere la soluzione drastica, verifica gli AVC e il contesto dei file coinvolti. Su Rocky Linux 8 i comandi più utili sono semplici e ti danno una diagnosi più precisa di una disattivazione cieca.

Controlla il contesto di un file o directory:
```
ls -Z /percorso/del/file
```
Se il contesto non è coerente con il servizio che deve usarlo, è probabile che il problema sia lì.
Ripristina i contesti standard su un path:
```
sudo restorecon -Rv /percorso
```
Questo è spesso il fix giusto dopo copie manuali, restore o spostamenti di contenuti web.
Per porte non standard, verifica i tipi assegnati:
```
sudo semanage port -l | grep -E 'http_port_t|ssh_port_t|postgresql_port_t'
```
Se il servizio ascolta su una porta fuori elenco, aggiungere il mapping corretto è più pulito che spegnere SELinux.
Per capire cosa viene negato, leggi i log audit:
```
sudo ausearch -m AVC -ts recent | tail -n 20
```
Se il messaggio è chiaro, spesso la correzione è immediata e localizzata.

Un esempio tipico: un sito statico o PHP migrato in una directory non standard funziona solo con SELinux disabilitato. Invece di lasciare il sistema in permissive, conviene correggere il contesto con restorecon o, se la directory è fuori schema, assegnare il label adatto in modo persistente.

Rollback rapido se hai fatto il cambio permanente

Se hai disabilitato SELinux nel file di configurazione e ti accorgi che non era necessario, il rollback è lineare. Il punto è farlo in modo verificabile, non “a memoria”.

Riapri il file di configurazione:
```
sudo vi /etc/selinux/config
```
Ripristina il valore precedente, di solito:
```
SELINUX=enforcing
```
Se stavi facendo solo un test controllato, puoi usare permissive come stato intermedio prima di tornare a enforcement completo.
Riavvia il sistema:
```
sudo reboot
```
Dopo il reboot, verifica con:
```
sestatus
```
Atteso: Current mode: enforcing o permissive, in base a quanto hai rimesso nel file.

Se il sistema non riparte come previsto, usa la copia di backup creata prima della modifica:

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

Qui il blast radius è limitato alla configurazione SELinux dell’host, ma il riavvio può impattare servizi esposti. Pianifica la finestra se stai intervenendo su un nodo con traffico reale.

Controlli finali dopo la modifica

Una volta cambiato lo stato, non fermarti a getenforce. Devi verificare che il sistema sia coerente con il nuovo assetto e che il problema originario sia effettivamente risolto o, almeno, riproducibile solo quando SELinux è attivo.

Verifica lo stato SELinux:
```
getenforce
```
e
```
sestatus
```
Confronta runtime e config file.
Rilancia il caso d’uso che prima falliva e osserva il comportamento del servizio.
Controlla i log applicativi e audit:
```
sudo journalctl -xe
```
e, se serve,
```
sudo ausearch -m AVC -ts recent
```
Se l’errore sparisce solo con SELinux disabilitato, hai una conferma diagnostica ma non ancora una correzione strutturale.
Se il problema era un contesto errato, correggilo e rimetti SELinux in enforcement. Questo è il punto in cui il sistema torna a uno stato più sicuro senza perdere funzionalità.

Assunzione: i comandi sono eseguiti su Rocky Linux 8 con privilegi amministrativi e con accesso console o SSH stabile per gestire il riavvio in sicurezza.

Decisione pratica: cosa fare in ordine

Se devi scegliere in fretta, la sequenza sensata è questa: prima controlla lo stato, poi prova setenforce 0 per una verifica temporanea, quindi analizza gli AVC, e solo alla fine valuta SELINUX=disabled. In un ambiente serio, la disattivazione permanente dovrebbe essere l’eccezione, non il default operativo.

In altre parole: se il problema è un contesto sbagliato, un mapping di porta o una policy incompleta, la soluzione giusta è correggere quel punto. Spegnere SELinux è rapido, ma spesso trasforma un incidente tecnico in un debito operativo che riemerge al prossimo cambiamento.