Controllate le label prima di dare la colpa a SELinux

Quando un'applicazione si rompe su un host con SELinux in enforcing, il riflesso in molti team è passare SELinux a permissive e andare avanti. Noi lo teniamo in enforcing su ogni host che gestiamo, e nella nostra esperienza la causa è di solito molto più piccola di quanto il riflesso suggerisca: un file che porta la label sbagliata. Questo articolo mostra come trovarla in fretta, come correggerla nel modo giusto e come evitare di chiudervi fuori mentre lo fate.

Cos'è una label, e come va storta

SELinux prende decisioni in base alle label. Ogni file e ogni processo porta un security context, e la policy dice quali tipi di processo possono fare cosa a quali tipi di file. La policy dice anche quale label dovrebbe avere ciascun percorso: il contenuto di /var/www dovrebbe essere httpd_sys_content_t, un eseguibile sotto /usr/bin dovrebbe essere bin_t, e così via. Quelle label attese sono le regole di file context.

Un file riceve la sua label quando viene creato, normalmente ereditata dalla directory padre o impostata da una regola della policy. Funziona bene finché i file non arrivano per una strada insolita:

• mv conserva la label originale, quindi un file creato in una home directory e spostato in una web root dice ancora di appartenere a una home directory.
• Gli archivi scompattati senza attributi SELinux, o ripristinati da un backup che non li ha conservati, ricevono quello che la directory di destinazione assegna.
• Il contenuto messo in una posizione personalizzata, come /srv/app, riceve una label generica perché la policy non ha ancora una regola per quel percorso.

In ognuno di questi casi la policy è a posto. Il file indossa semplicemente la label sbagliata, e il processo che ne ha bisogno viene rifiutato.

Leggete prima il denial

Prima di cambiare qualsiasi cosa, leggete cosa SELinux ha effettivamente rifiutato:

ausearch -m AVC -ts recent

Ogni denial indica il tipo del processo (scontext), il tipo del target (tcontext), la classe dell'oggetto e il permesso. Se il tipo del target sembra sbagliato per quel file (un web server a cui viene negata la lettura di qualcosa etichettato user_home_t, per esempio), state quasi certamente guardando un problema di label, non una lacuna della policy.

Confrontate ciò che c'è con ciò che dovrebbe esserci

Tre comandi rispondono direttamente alla domanda:

ls -Z /path/to/file            # the label it has
matchpathcon /path/to/file     # the label the policy expects
restorecon -nv /path/to/file   # dry run: what restorecon would change

restorecon -n non cambia nulla. Riporta soltanto la differenza tra la label attuale e quella attesa, il che lo rende lo strumento di audit perfetto. Eseguitelo su un intero albero dopo un'installazione, un ripristino o una migrazione:

restorecon -Rnv /etc /usr /var /srv 2>/dev/null

Un risultato vuoto significa che ogni file sotto quei percorsi porta la label che la policy si aspetta. Ogni riga nell'output è un file che non la porta, e quell'elenco è di solito corto e molto eloquente. Eseguiamo questo tipo di verifica sulle nuove installazioni come routine, e i nostri template di installazione rietichettano i percorsi critici nel passaggio post-install, così un nuovo host inizia la sua vita con le label corrette prima che qualcuno vi acceda.

Correggete nel modo giusto

Per un file che ha semplicemente la label sbagliata, rietichettatelo con ciò che la policy si aspetta:

restorecon -Rv /path

Per una posizione personalizzata che la policy non conosce, insegnate prima la regola alla policy, poi rietichettate, così la correzione sopravvive al prossimo relabel completo:

semanage fcontext -a -t httpd_sys_content_t "/srv/app(/.*)?"
restorecon -Rv /srv/app

Anche chcon cambia le label, ma solo fino al prossimo relabel, dopo il quale il problema ritorna. Usatelo per gli esperimenti, non per le correzioni.

Se le label sono giuste e il denial riguarda un comportamento, controllate i booleani prima di scrivere policy. Molte esigenze comuni, come un web server che apre connessioni di rete in uscita, sono un singolo interruttore:

getsebool -a | grep httpd
setsebool -P httpd_can_network_connect on

Diffidate di audit2allow

audit2allow legge i denial e scrive un modulo di policy che li permette. Produrrà sempre qualcosa che funziona, ed è esattamente questo il pericolo. Se la causa reale è un file con la label sbagliata, il modulo generato concede un permesso ampio per far sparire il sintomo, e ogni altro file e processo di quel tipo eredita la policy indebolita. Leggete cosa propone. Una regola che permette a un dominio di transitare in uno molto privilegiato, o di leggere tutto ciò che ha un tipo comune, è un forte indizio che la label è sbagliata e che il modulo è la correzione sbagliata. I moduli personalizzati a volte sono corretti, per software interno senza una policy propria, ma devono essere l'ultimo passo, non il primo.

Passate a enforcing in sicurezza su un host remoto

Passare una macchina remota da permissive a enforcing è una di quelle modifiche che possono tagliare la vostra stessa sessione se qualcosa ha ancora la label sbagliata. Armate prima una rete di sicurezza, così l'host si rimette a posto da solo se perdete l'accesso:

systemd-run --on-active=240 --unit=selinux-net /usr/sbin/setenforce 0
setenforce 1
# open a NEW ssh session and confirm it works
systemctl stop selinux-net.timer

systemd fa scattare il timer che la vostra sessione sopravviva o meno. Annullatelo solo dopo che un login completamente nuovo è riuscito. Lo stesso schema funziona per modifiche a firewall, SSH e routing su una macchina a cui non potete avvicinarvi fisicamente.

Una breve checklist

• Eseguite restorecon -Rnv sui percorsi di sistema dopo ogni installazione, ripristino o migrazione.
• Leggete il denial AVC e confrontate ls -Z con matchpathcon prima di cambiare la policy.
• Usate semanage fcontext più restorecon per i percorsi personalizzati, non chcon.
• Controllate i booleani prima di scrivere un modulo.
• Trattate l'output di audit2allow come una domanda, non come una risposta.
• Non passate mai un host remoto a enforcing senza una via di ritorno a tempo.

Se il fornitore di un'applicazione vi ha detto di disabilitare SELinux e preferireste di no, siamo lieti di aiutarvi a trovare la correzione precisa. Parla con un ingegnere

Related

Correlati: L'hardening baseline su ogni host · Risposta urgente alle vulnerabilità in giornata