Rocky Linux: configurare le modalità SELinux e diagnosticare i blocchi

Su Rocky Linux potete passare temporaneamente da enforcing a permissive con sudo setenforce 0, se SELinux è già attivo. Per diagnosticare un blocco conviene mantenere SELinux attivo e correggere la configurazione necessaria: disabilitarlo completamente richiede una procedura di avvio diversa e rende più delicata la successiva riattivazione.

Controllare lo stato attuale di SELinux

SELinux (Security-Enhanced Linux) aggiunge controlli di accesso basati su policy, cioè regole che limitano le operazioni dei processi sulle risorse. I normali permessi Unix restano necessari: rendere SELinux permissivo non elimina un errore di proprietario, permessi o configurazione del servizio.

getenforce
sestatus

getenforce restituisce lo stato effettivo corrente. sestatus distingue, tra le altre informazioni, modalità corrente, modalità nel file di configurazione e policy caricata: il valore salvato può differire da quello attivo.

La registrazione può essere limitata dalle regole di audit e dalla soppressione di alcuni messaggi: l'assenza di una riga nel log non prova da sola che SELinux non sia coinvolto. Prima di intervenire annotate stato, versione di Rocky, configurazione e parametri di avvio. Per modifiche permanenti o riavvii predisponete una console di recupero indipendente da SSH.

Usare temporaneamente la modalità permissive

Cambiare la modalità corrente

Se getenforce indica Enforcing, questo comando sospende l'applicazione dei controlli SELinux sull'intero sistema:

sudo setenforce 0
getenforce

Il risultato atteso del secondo comando è Permissive. Il cambiamento non modifica /etc/selinux/config e al riavvio valgono configurazione e parametri del kernel. Se lo stato è Disabled, setenforce non può riattivare SELinux: serve il percorso di riattivazione descritto più avanti.

Riproducete soltanto l'operazione necessaria alla diagnosi e confrontate sintomo e log. La modalità permissive riguarda tutti i processi: su un servizio in produzione valutate una prova isolata e limitate la durata dell'intervento.

Tornare alla modalità enforcing

sudo setenforce 1
getenforce

Verificate che il risultato sia Enforcing, poi riprovate il servizio e controllate i nuovi log. Se il problema scompare soltanto in permissive, cercate la causa della policy negata; questo confronto non giustifica automaticamente la disattivazione permanente.

Individuare la causa dei dinieghi

Leggere i messaggi AVC recenti

AVC significa Access Vector Cache, la cache delle decisioni di accesso di SELinux. I messaggi di diniego sono normalmente consultabili nel sistema di audit:

sudo ausearch -m AVC,USER_AVC -ts recent

-ts recent limita la ricerca agli ultimi dieci minuti. Riproducete il problema nell'intervallo considerato; per eventi precedenti scegliete un intervallo appropriato. Nel record confrontate processo, operazione richiesta, contesto del processo (scontext), contesto della risorsa (tcontext) e percorso, quando disponibile.

Se il comando manca, controllate il pacchetto audit; se non trovate eventi, controllate anche auditd, il periodo cercato e i log del servizio. La guida Red Hat alla diagnosi dei dinieghi SELinux descrive le ulteriori verifiche. Non generate come prima risposta una policy che autorizzi indistintamente tutti gli eventi registrati.

Correggere il contesto di sicurezza dei file

Un contesto è l'etichetta di sicurezza usata dalla policy; il tipo, per esempio httpd_sys_content_t, è una sua parte. Per contenuti web in una directory non standard, verificate prima con ls -Zd /srv/www l'etichetta corrente e con matchpathcon /srv/www quella prevista. Controllate inoltre le personalizzazioni con sudo semanage fcontext -l -C.

Solo se /srv/www è davvero l'albero dei contenuti che il servizio web deve leggere, potete registrare una corrispondenza persistente e poi applicarla. Eseguite la seconda riga soltanto se la prima è riuscita:

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

Le virgolette conservano l'espressione /srv/www(/.*)? come un solo argomento, includendo directory e discendenti. semanage fcontext modifica la regola; restorecon applica le etichette ai file. Controllate nuovamente con ls -Z e provate l'accesso in enforcing.

semanage è fornito su Rocky dal pacchetto policycoreutils-python-utils. Se la stessa regola esiste già, esaminatela prima di decidere se modificarla con -m. Non assegnate a tutto l'albero un tipo scrivibile per risolvere un singolo errore: scegliete il tipo adatto solo alle directory che richiedono scrittura.

Annotate le regole preesistenti. Per annullare una regola aggiunta solo per questa prova, rimuovete quella precisa specifica con sudo semanage fcontext -d '/srv/www(/.*)?', quindi applicate con restorecon la mappatura precedente. Non cancellate una regola che esisteva già: ripristinatene il valore originale. Il manuale upstream di semanage fcontext, distribuito da Debian distingue regole persistenti ed etichette effettive.

Regolare booleani e porte non standard

Abilitare una funzione prevista dalla policy

I booleani SELinux sono interruttori per funzionalità già previste dalle regole installate. La prima riga elenca i valori relativi a httpd; la seconda è un esempio di modifica da eseguire soltanto dopo averne verificato la necessità:

getsebool -a | grep httpd
sudo setsebool -P httpd_can_network_connect on

httpd_can_network_connect permette al dominio httpd connessioni TCP in uscita con un ambito ampio. Non è un interruttore per aprire la porta HTTP in ingresso. Se serve soltanto l'accesso a una specifica risorsa, cercate prima l'opzione più limitata nella policy installata. Il sorgente della policy SELinux di Fedora per Apache documenta questo booleano; disponibilità e regole effettive vanno verificate sulla versione locale.

-P rende persistente la scelta. Annotate il valore iniziale e controllate il risultato con getsebool httpd_can_network_connect; per annullare la prova ripristinate quel valore con setsebool -P, senza presumere che fosse sempre off. Verificate poi il comportamento reale del servizio.

Associare una porta al tipo corretto

Una porta non standard può richiedere una mappatura SELinux oltre alla configurazione del servizio e del firewall. L'esempio seguente riguarda un servizio web sulla porta TCP 8088:

sudo semanage port -l | grep http_port_t
sudo semanage port -a -t http_port_t -p tcp 8088

La prima riga mostra le porte del tipo http_port_t. Prima di aggiungere 8088 esaminate anche l'elenco completo con sudo semanage port -l, inclusi gli intervalli, e le personalizzazioni con sudo semanage port -l -C: il filtro sul solo tipo web non rivela una porta assegnata a un altro tipo.

Se esiste già una mappatura non usate automaticamente -m: cambiare il tipo potrebbe interferire con un altro servizio. Annotate lo stato precedente e scegliete una porta coerente con la policy. La mappatura non avvia il servizio e non apre il firewall; verificate l'ascolto, una richiesta dal client previsto e i log AVC in enforcing. Per zone e regole di rete consultate la guida a firewalld su Rocky Linux.

Se avete creato una nuova mappatura locale solo per la prova, potete rimuoverla con sudo semanage port -d -p tcp 8088; se avete modificato una voce preesistente, ripristinate invece il suo valore originale. Il manuale upstream di semanage port spiega aggiunta, modifica e rimozione delle mappature.

Mantenere permissive dopo un riavvio

Per proseguire una diagnosi dopo il riavvio, su un sistema con SELinux già attivo controllate prima che /etc/selinux/config contenga una sola impostazione attiva SELINUX=. Questo esempio conserva una copia e modifica il valore soltanto se il backup riesce:

sudo cp -a --backup=numbered /etc/selinux/config /etc/selinux/config.backup &&
sudo sed -i 's/^SELINUX=.*/SELINUX=permissive/' /etc/selinux/config &&
grep '^SELINUX=' /etc/selinux/config

Il risultato atteso è SELINUX=permissive. Se la riga manca, è duplicata o il comando fallisce, correggete il file con un editor e verificate prima di riavviare. --backup=numbered conserva anche un precedente config.backup con un suffisso numerato; la copia appena creata in config.backup corrisponde allo stato prima dell'ultima modifica.

Questo cambia il prossimo avvio, non la modalità corrente. I parametri del kernel, come selinux=0 o enforcing=0, possono determinare un risultato diverso: controllate cat /proc/cmdline e la configurazione di avvio. Dopo il riavvio confrontate getenforce e sestatus. Per terminare la diagnosi ripristinate SELINUX=enforcing, verificate gli argomenti di avvio e tornate a enforcing anche nella sessione corrente, se SELinux è attivo.

Disabilitare e riattivare SELinux in base alla versione

Verificare versione e configurazione di avvio

La disattivazione completa elimina controlli e messaggi di diniego SELinux; non è necessaria per una normale diagnosi. Se un requisito documentato la rende indispensabile, identificate versione principale di Rocky e bootloader e conservate configurazione, argomenti originali e backup:

cat /etc/rocky-release
rpm -q grubby
cat /proc/cmdline
sudo grubby --info=ALL

La documentazione RHEL 9 su stati, modalità e riattivazione usa selinux=0 per la disattivazione completa. In RHEL 9 il solo SELINUX=disabled nel file non è una procedura equivalente per rimuovere l'infrastruttura dal kernel; non applicate indistintamente istruzioni di versioni diverse.

Confermate che grubby gestisca realmente il sistema in uso. --update-kernel ALL interessa tutte le voci selezionate da grubby: controllate i valori prima e dopo, e non sovrascrivete criteri gestiti dal provider o dall'amministratore. Solo nell'intervento pianificato potete aggiungere:

sudo grubby --update-kernel ALL --args selinux=0

Controllate le voci con sudo grubby --info=ALL, poi riavviate nella finestra prevista. getenforce deve indicare Disabled e cat /proc/cmdline deve confermare gli argomenti realmente usati. Non eseguite i passaggi di disattivazione e riattivazione come un unico script.

Riattivare prima in permissive e verificare le etichette

Un sistema rimasto disabilitato può contenere file senza etichette corrette. Predisponete una console di recupero e tempo sufficiente per la rietichettatura. Verificate i pacchetti selinux-policy-targeted, libselinux-utils e policycoreutils, preparate SELINUX=permissive in /etc/selinux/config e controllate gli argomenti correnti.

Il seguente esempio rimuove il parametro selinux e aggiunge enforcing=0 per il primo avvio. Vale quando dovete annullare il selinux=0 aggiunto sopra e non esistono impostazioni diverse da preservare; se i valori originali erano differenti, ripristinate il piano previsto per quella macchina:

sudo grubby --update-kernel ALL --remove-args selinux &&
sudo grubby --update-kernel ALL --args enforcing=0

Rileggete tutte le voci di avvio e riavviate con la console disponibile. Il sistema deve avviarsi con SELinux attivo in Permissive; attendete l'eventuale rietichettatura automatica e verificate con getenforce e sestatus. Se compare ancora Disabled, risolvete la configurazione di avvio prima di proseguire.

Una volta effettivamente in permissive, sudo fixfiles -F onboot può predisporre una rietichettatura al riavvio successivo. Il comando crea /.autorelabel con l'opzione -F; non esegue immediatamente la rietichettatura completa. Controllate che il comando riesca, lasciate enforcing=0 per quel riavvio pianificato e attendete il completamento senza interrompere l'operazione. Il manuale upstream di fixfiles distingue pianificazione e applicazione delle etichette.

Dopo aver verificato servizi ed eventi AVC in permissive, impostate SELINUX=enforcing. Se enforcing=0 era stato aggiunto esclusivamente per questo recupero, rimuovetelo con sudo grubby --update-kernel ALL --remove-args enforcing e rileggete le voci. Usate quindi sudo setenforce 1 per il sistema corrente, riprovate i servizi e confermate lo stato anche al successivo riavvio pianificato. Se emergono blocchi, tornate temporaneamente a permissive e correggetene la causa prima di mantenere enforcing.

Seguire un ordine di diagnosi ripetibile

1. Rilevate stato corrente, configurazione salvata e parametri di avvio.
2. Controllate log applicativi, proprietario e permessi dei file, configurazione di rete e firewall.
3. Se serve, confrontate brevemente il sintomo in permissive, con una prova controllata.
4. Cercate gli eventi AVC relativi all'operazione e al periodo corretti.
5. Correggete soltanto etichette, booleani o tipi di porta necessari, annotando i valori per il ripristino.
6. Tornate a enforcing e verificate sia la funzione desiderata sia i nuovi log; controllate anche la persistenza dopo il riavvio quando avete modificato l'avvio.

Consultare i riferimenti della policy

La guida Rocky Linux alla sicurezza SELinux offre un riferimento su contesti, booleani e modalità. Per le operazioni di avvio usate la documentazione della versione principale installata e i manuali locali dei pacchetti: una regola valida per un servizio non autorizza automaticamente le altre funzioni del sistema.