Questo articolo descriverà nel dettaglio come proteggere una cartella o una struttura di cartelle e i files presenti all'interno sul filesystem linux dagli accessi non autorizzati. Questo è molto utile quando si desidera avere una traccia degli accessi per esempio a una struttura documentale e si desidera gestire le utenze indipendentemente dai permessi del silesystem (root,ecc..).

Nell'esempio è stata utilizzata come distribuzione la RedHat Enterprise versione 5.2.

I requisiti per l'implementazione delle ACL sono:

• Installazione del Sistema Operativo con tutte le librerie DEV del pacchetto SELinux, fondamentale il pacchetto “selinux-policy-devel” che installa come dipendenze tutti i moduli DEV fondamentali.
• Attivazione di SELinux con le policy Targeted. Nel file /etc/sysconfig/selinux assicurarsi di avere le seguenti righe: SELINUX=enforcing e SELINUXTYPE=targeted

Creazione di una Categoria

Per proteggere il filesystem dobbiamo creare una categoria che servirà etichettare le cartelle e i files da proteggere.

In questo contesto abbiamo scelto di la denominazione “TopSecret”, quindi la definizione andrà nel file /etc/selinux/targeted/setrans.conf aggiungendo semplicemente la seguente riga:

s0:c3=TopSecret

Per essere protetti, tutti i files e le cartelle dovranno avere questa etichetta. Per fare ciò, occorre lanciare il seguente comando:

chcat +TopSecret NOMEFILE o CARTELLA

Il comando andrà eseguito per ogni file che si desidera proteggere, sistema un po' svantaggioso quando i files sono provenienti da un sistema che li genera automaticamente. Quindi, per risolvere questo problema abbiamo scelto di implementare i “File Contexts” in maniera tale da permetterci l'uso del comando “restorecon” in una maniera ricorsiva.

Prima di cominciare a creare il modulo di sicurezza, è obbligatorio disabilitare temporaneamente l'enforcing del sistema con il comando: “setenforce 0”

Fatto questo, quando il modulo sarà compilato basterà riabilitare SELinux con il comando “setenforce 1”

Se avete dubbi sullo stato potete lanciare in comando “sestatus” che mostra lo stato attuale di SELinux.

Un esempio pratico

In questo esempio abbiamo scelto una cartella /docsecret/ e abbiamo creato 2 files all'interno:

• docsecret.te ---> contiene le policy e la definizione dei nuovi tipi
• docsecret.fc ---> contiene i contesti da applicare ai files.

Andremo di seguito ad elencare il contenuto dei files sopra elencati:

 

 

Osserviamo che il file docsecret.te contiene la definizione “docsecret_t” che servirà per identificare univocamente i files e proteggerli contro i demoni non protetti del sistema. Inoltre, contiene anche i permessi per attribuire l'etichetta di “docsecret_t” da parte del sistema.

Compilazione del modulo

Adesso passiamo alla compilazione vera e propria del modulo:

make -f /usr/share/selinux/devel/Makefile

e lo carichiamo nelle policy con

semodule -i docsecret.pp

Il modulo adesso sarà permanente attraverso i reboot del sistema perchè “semodule”, oltre a caricarlo in memoria provvede anche a copiare il file nella directory “/etc/selinux/targeted/modules/active/modules/”

Lanciando il comando “semodule -l” vedremo il nostro modulo appena compilato:

Attribuzione dei permessi alla cartella e ai files

Abbiamo a questo punto due passaggi da seguire per attribuire i corretti permessi alla cartella /documenti/ e ai files all'interno:

touch /.autorelabel

Questo comando forza al prossimo riavvio il relabel delle cartelle e dei files seguendo le policy appena descritte.

Eseguiamo a questo punto un REBOOT del sistema per rendere operative le modifiche. Al riavvio del sistema, gli script di startup provvederanno a rimettere a posto le etichette di SELinux.

Possiamo, comunque, impostare le etichette e i permessi manualmente anche lanciando il comando:

“restorecon -ivvr /documenti/”

Dove le opzioni:

• -r sta per applicare le modifiche ricorsivamente;
• -v sta per verbosità dell'output
• -i sta per ignorare i files non esistenti

Definizione dell'utenza applicativa per l'accesso ai file protetti

Di default tutte le utenze non hanno accesso a nessun file che abbia una categoria associata, con l'eccezione dell'utente root. Per abilitare un utente ad accederci dobbiamo eseguire il seguente comando:

“chcat -l +TopSecret nomeutente_applicativo”

Per verificare che all'utente sia stato assegnato il livello corretto si può eseguire il comando “semanage” per esempio:

Login Name SELinux User MLS/MCS Range

__default__ user_u s0

lucian user_u s0

root root SystemLow-SystemHigh

Personalizzazione del comando SUDO

Abbiamo abilitato l'utente “lucian” per accedere ai files sotto la cartella /documenti/

Ora dobbiamo abilitare anche gli utenti amministrativi, come in questo esempio l'utente “admin” ad eseguire programmi come shell scripts, reboot o altro.

Apriamo il seguente file “/etc/sudoers” e aggiungiamo le seguenti righe:

admin ALL= NOPASSWD:/usr/bin/id

admin ALL= NOPASSWD:/bin/cat

Se proviamo a loggarci sul sistema come utente admin e lanciamo il comando “sudo id” otterremo questo:

[admin@localhost ~]$ sudo id

uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) context=root:system_r:unconfined_t:SystemLow-SystemHigh

Provando ad accedere a un file protetto otterremo:

sudo cat /documenti/test.txt

cat: Permission denied

Notiamo quindi che, nonostante l'essere diventati root, l'utente admin non ha l'accesso alla cartella protetta da SELinux. Ogni tentativo sarà loggato usando il sistema di AUDIT di SELinux, quindi la traccia si troverà nel file “/var/log/audit/audit.log”

Ulteriori Restrizioni di accesso per “ROOT”

Come requisito strategico, abbiamo scelto di lasciare la possibilità di eseguire il comando “su” ad un gruppo di persone. Andrà quindi configurato il modulo “PAM” per il comando “su” come segue:

In questo modo, solo gli utenti appartenenti al gruppo wheel possono eseguire il comando “su” anche se altri utenti conoscono la password di root.

Auditing

Di default, SELinux tiene traccia di tutti i tentativi di accesso alle risorse protette. Per necessità abbiamo personalizzato il sistema di log agendo sul file “/etc/audit/audit.rules” inserendo la seguente riga:

-a exit,always -S open -S truncate -F dir=/documenti -F uid!=300

Per configurare il plugin di log a SysLog (audispd) dobbiamo agire sul file “/etc/audisp/plugins.d/syslog.conf” e specificando nella stringa “active = yes”

In sostanza, questo comando tiene traccia degli eventuali accessi attraverso le chiamate (syscall) “open” e “truncate” alla cartella “/documenti/” se la userID non è equivalente alla UID 300, ovvero la UID che abbiamo dato all'utente applicativo “admin”. In questo modo possiamo tenere traccia di qualsiasi tentativo di accesso dagli utenti alla cartella “/documenti/” contenente i files protetti.

Sicurezza

Per una maggiore sicurezza e per garantire una certa protezione dei dati nel caso in cui SELinux per qualche motivo sia stato disabilitato, ho lanciato i seguenti comandi sulla cartella da proteggere:

chmod 0750 lucian:lucian /documenti/

setfacl -m lucian:rwx /documenti/

getfacl -m root:rwx /documenti/

getfacl - -access /documenti/ | setfacl -d -M- /documenti/