SELinux

Ammettiamolo: la maggior parte di noi disabilita SELinux come prima azione quando installa un server ex novo.

Selinux viene visto come una rottura di scatole, che non fa funzionare le cose che installiamo. A parziale discolpa dei SysAdmin va detto che SELinux non è esattamente intuitivo (sto parlando di livello di intuitività di un SysAdmin) e spesso lo si percepisce come quello che sta tra un problema e la soluzione dello stesso.

Con l’aumentare degli attacchi è bene iniziare a considerare l’opzione di (ri)abilitare SELinux, magari partendo dai server meno critici.

Da punto di vista della sicurezza, il vantaggio di SELinux è che le sue policy non sono facilmente modificabili dall’utente o da un applicativo e permettono un controllo molto più granulare dei normali attributi di lettura/scrittura/esecuzione di *NIX. Inoltre SELinux applica delle policy obbligate: in un normale sistema *NIX un utente può fare chmod 777 della propria home directory, mentre se sono attive delle opportune policy di SELinux lo stesso utente potrebbe non riuscire a farlo anche se è proprietario della directory ed ha i permessi di scrittura.

SELinux è un argomento complesso e articolato, di seguito viene solamente grattata la superficie con un esempio di implementazione su CentOS 6.4, tenendo ben presente che nella sicurezza non esiste un singolo silver bullet, ma una buona sicurezza è sempre frutto di varie azioni coordinate.

L’attivazione di SElinux dovrebbe avvenire in due fasi: nella prima si abilita la sicurezza a livello permissive e si analizzano i comportamenti delle applicazioni; in questa modalità SELinux non blocca nulla, ma si limita a segnalare ciò che avrebbe bloccato. Nella seconda fase si abilita la modalità enforcing per rendere attive tutte le policy di blocco.

Da qui in avanti le indicazioni si riferiscono ad una CentOS 6.4, per cui è disponibile anche un howto; su altri sistemi ci potrebbero essere delle differenze. Per rendere il debug degli errori molto più semplice è necessario installare i pacchetti setroubleshoot e setroubleshoot-server. Il demone auditd deve essere attivo.

La prima volta che viene (ri)attivato SELinux bisogna riavviare il sistema per permettere il relabeling del file system. Questa operazione potrebbe richiedere svariati minuti o anche decine di minuti in relazione alla velocità dei dischi e al numero di file da etichettare. Portate pazienza. Al termine del relabeling il sistema si riavvia automaticamente.

Si può controllare in ogni momento il livello di sicurezza di SELinux con il comando getenforce.

Gli eventi di blocco di SELinux vengono registrati in /var/log/messages

In SELinux i processi, i file, i socket e le porte TCP hanno un contesto di sicurezza; per vedere quello di un file si può utilizzare ls -Z, per vedere quello di un processo ps -Z (in generale -Z è il parametro che permette di vedere il contesto di sicurezza). Il contesto di sicurezza è nel formato utente:ruolo:tipo:livello. Per convenzione i nomi degli utenti finiscono con _u, i nomi dei ruoli con _r e i nomi dei tipi con _t.

In questo articolo viene trattato il tipo targeted di SELinux, che utilizza solamente il campo tipo; i campi utente, ruolo e livello sono utilizzati solamente da SELinux in modalità Multi Level Security. Il tipo è il modo in cui vengono definiti gli accesi, nel caso di un processo il tipo prende anche il nome di dominio.

Una volta definiti i tipi per i vari componenti del sistema (file, socket, processi, porte TCP…) si possono definire delle politiche di accesso: ad esempio il processo di Apache può accedere alle directory con i siti, alle directory con la configurazione del server, alla directory con i moduli da caricare, alle porte 80 e 443 e al socket del database server, ma non c’è nessun motivo per cui Apache debba leggere la configurazione del MTA, anche se questa è leggibile da tutti gli utenti (magari per una distrazione del SysAdmin). Ecco la differenza tra SELinux e i permessi del file system: se non è autorizzato a farlo, un processo non può leggere un file anche se questo ha 777 come permessi del file system.

Se sono installati setroubleshoot e setroubleshoot-server, dopo aver abilitato SELinux inizieranno a comparire in /var/log/messages messaggi con la descrizione di un blocco seguito da qualcosa tipo

For complete SELinux messages. run sealert -l 8a4d7e77-0a0c-4f02-afff-48a736a39057

Se non sono installati i pacchetti di troubleshoot la diagnostica è un po’ meno chiara:

kernel: type=1400 audit(1381490372.869:3): avc:  denied  { getattr } for  pid=9609 comm="smbd" path="/yadda/yadda" dev=sda1 ino=6297198 scontext=system_u:system_r:smbd_t:s0 tcontext=system_u:object_r:default_t:s0 tclass=file

Quando si esegue sealert il sistema mostra in un linguaggio abbastanza chiaro quel è il problema e quali sono i comandi che possono essere copiati e incollati per risolverlo. Generalmente vengono proposti più comandi: la scelta di quello giusto è responsabilità del SysAdmin.

Dopo qualche giorno che il sistema non segnala errori e dopo aver accuratamente letto la documentazione di SELinux è possibile passare in modalità enforcing.

Questo video di Thomas Cameron (RedHat) mostra molto bene quanto non sia così complesso implementare SELinux.