Sappiamo bene quanto i moderni sistemi operativi siano complessi da configurare e amministrare, soprattutto se speriamo di garantire sicurezza in termini di confidenzialità e integrità dei dati presenti nelle nostre macchine. GNU/Linux è da sempre considerato un sistema operativo sicuro per una lunga serie di motivi, tuttavia anch’esso ha dei limiti strutturali in termini di sicurezza, che risiedono nell’implementazione del controllo d’accesso alle risorse.
La maggior parte dei problemi di sicurezza all’interno di un sistema operativo avviene perché alcuni software contengono dei difetti, oppure vengono manomessi in seguito ad un’intrusione, e riescono così ad ottenere i privilegi di un determinato utente, anziché rimanere confinati nella propria specifica area di pertinenza: questo accade perché i processi ereditano i privilegi degli utenti, e seguono quindi le limitazioni d’accesso degli stessi. Questo tipo di controllo d’accesso, utilizzato nei più comuni sistemi operativi odierni, è detto discrezionario, ma non è l’unica alternativa.
DAC, MAC, RBAC
In un approccio DAC (Discretionary Access Control), ogni utente è proprietario (owner) di un insieme di risorse, e può gestire i permessi a quelle risorse. Le politiche per il controllo d’accesso sono basate sull’identità dell’utente, e su autorizzazioni esplicite che definiscono chi può o meno eseguire una data azione su una determinata risorsa. Questo è il tipo di controllo d’accesso utilizzato normalmente nei sistemi Unix, in cui ogni file ha un proprietario, un gruppo e un insieme di permessi, e queste informazioni sono le uniche utilizzate per gestire gli accessi alle risorse del sistema.
Non viene fatta alcuna distinzione tra utente e processo: in questo modo un processo eseguito con i privilegi di un dato utente, che contenga codice maligno (il tipico trojan horse), può sfruttare i privilegi dell’utente per eseguire azioni dannose, come ad esempio rendere leggibili informazioni confidenziali ad utenti non autorizzati.
In un approccio MAC (Mandatory Access Control), al contrario, i sistemi sono costruiti per garantire le politiche di sicurezza indipendentemente dalle azioni degli utenti: un’autorità centralizzata impone delle regole per l’accesso alle risorse cui tutti sono soggetti. In pratica, i processi sono sempre considerati untrusted, e non ereditano i privilegi degli utenti, considerati invece trusted.
Nella pratica, la forma più comune di politica MAC è la cosiddetta sicurezza multilivello, basata sull’assegnazione di classi di sicurezza ad oggetti (entità passive) e soggetti (entità attive che richiedono accesso agli oggetti); le classi di sicurezza assegnabili sono un insieme finito e parzialmente ordinato, ad esempio un semplice sistema a due classi potrebbe essere "admin > user". Ogni entità non può leggere risorse di classe superiore, e non può scrivere risorse di classe inferiore.
Non ci dilunghiamo in dettagli tecnici, ma un esempio può rendere evidente ciò di cui stiamo parlando: questo approccio risolve il problema dei trojan horse così critico nei sistemi DAC comunemente usati ogni giorno sui nostri sistemi operativi; un processo in esecuzione con classe user non può leggere oggetti di classe admin, e un processo in esecuzione con classe admin non può scrivere su oggetti di classe user: in questo modo la fuga di informazioni confidenziali viene correttamente bloccata, e di conseguenza un trojan horse risulterebbe inoffensivo.
È importante sottolineare che politiche DAC e politiche MAC possono convivere sullo stesso sistema: le autorizzazioni del DAC operano all’interno dei confini definiti dal MAC, limitando ulteriormente le possibilità di accesso alle risorse definite dal MAC.
Una terza rilevante alternativa per le imprese è l’approccio basato sui ruoli, detto RBAC (Role-Bades Access Control). In questo caso le politiche di sicurezza sono definite in modo flessibile in base alla struttura interna dell’azienda. All’interno di un’organizzazione, infatti, l’identità di un singolo utente è poco rilevante in termini di controllo d’accesso, e si preferirebbe definire dei gruppi di persone classificati in base alle loro responsabilità aziendali; non bisogna però fare confusione con un approccio DAC basato su gruppi, ad esempio con il concetto di gruppo in Unix: un gruppo, o meglio, un ruolo, in RBAC può rappresentare uno o più utenti, ma definisce anche i permessi di cui quegli utenti dispongono. L’approccio RBAC cerca di mantenere in parte la flessibilità del DAC, aggiungendo una maggiore sicurezza con regole imposte secondo una filosofia vicina al MAC.
SE-Linux
Arriviamo quindi a presentare SE-Linux (Security Enhanced Linux), un prodotto il cui scopo è migliorare la robustezza del sistema operativo aggiungendo la possibilità di definire politiche MAC ed RBAC all’interno di esso. SE-Linux è un’implementazione dell’architettura Flask (Flux Advanced Security Kernel), un’architettura di security pensata appunto per offrire controllo d’accesso "mandatorio" (obbligatorio) all’interno di un sistema operativo, fornendo al contempo alternative flessibili basate ad esempio su sicurezza multilivello e RBAC. Il sistema operativo di riferimento è ovviamente GNU/Linux, ma esistono dei porting per Solaris e FreeBSD.
SE-Linux fornisce un’implementazione interna al kernel Linux 2.6 e una serie di utility applicative per l’implementazione di questo tipo di politiche di sicurezza. Quello che offre agli amministratori di sistema è quindi la possibilità concreta di confinare ogni processo in esecuzione all’interno del sottoinsieme minimo di risorse necessarie per svolgere il proprio lavoro, risolvendo alla base gravi problemi di sicurezza, come il flusso incontrollato di informazioni sensibili, che nascono quando i programmi vengono compromessi (sia a causa di configurazioni errate, sia a causa dell’azione deliberata di un malintenzionato).
I meccanismi di sicurezza di SE-Linux sono indipendenti dai complessi meccanismi interni implementati nei sistemi Linux, e basati su politiche DAC: questo significa che sarà possibile limitare l’accesso a determinate risorse anche all’utente root, nel caso ad esempio vi siano file con informazioni cui i responsabili del sistema informatico non debbano poter accedere. Questo significa anche una maggior semplicità di gestione della security del sistema operativo, perchè le politiche MAC coprono eventuali errori o malfunzionamenti, volontari o meno, presenti nel kernel, nelle applicazioni e nelle loro configurazioni, che possano causare accessi indesiderati a risorse sensibili.
SE-Linux è progettato per garantire la confidenzialità (protezione da letture indesiderate) e l’integrità (protezione da scritture indesiderate) delle proprie risorse, impedendo ai processi in esecuzione di accedere ad aree del sistema che non siano di loro competenza, e confinando opportunamente il danno potenziale derivabile dall’esecuzione di codice maligno o difettoso sulla propria macchina.
Conclusioni
La gestione della sicurezza in un sistema GNU/Linux può essere resa al contempo più solida e robusta grazie a SE-Linux e alle politiche di controllo d’accesso di tipo mandatorio che implementa. Gli amministratori di sistemi le cui risorse siano ad alto livello di sensibilità dovrebbero per tanto prendere in seria considerazione l’opportunità di utilizzare SE-Linux per implementare soluzioni di sicurezza valide, che non sarebbero possibili con i normali sistemi basati sul limitato approccio DAC per il controllo di accesso alle risorse.
