POLITICHE DI CONTROLLO DEGLI ACCESSI NEL SISTEMA OPERATIVO SELINUX di Giorgio Zanin Tesi presentata per la discussione del diploma di laurea in Informatica Università degli Studi di Roma La Sapienza a.a. 2002/2003 Relatore: prof. Luigi Vincenzo Mancini Laureando: Giorgio Zanin
RINGRAZIAMENTI Desidero ringraziare soprattutto i miei genitori, che mi hanno permesso di studiare e hanno sempre avuto fiducia in me e nelle mie capacità. A loro dedico questa tesi. Ringrazio Carolina che ha avuto pazienza nei miei ultimi anni di università e soprattutto nel periodo durante il quale ho scritto questo lavoro. Voglio anche ringraziare tutti i miei amici dell Università e il Sandro, che hanno reso felici questi anni, oltre che di studio, anche di divertimento e di amicizia e mi hanno più volte sopportato. Grazie anche ad Alessandra e a Luigia che hanno sempre fatto funzionare bene i centri di calcolo, nei quali ho passato così tanto tempo durante il periodo universitario. E a Saverio, al quale ho chiesto tante di quelle volte aiuto con Linux, che non posso contarle. Per quanto riguarda più propriamente la tesi, i principali ringraziamenti vanno a Stephen Smalley dei NAI LABS, leader del progetto SELinux, che ha sempre chiarito i tanti dubbi ed interrogativi sorti durante lo studio delle tematiche e degli argomenti qui trattati, e tutti i ragazzi della mailing list di SELinux. Infine, un ringraziamento particolare a Trent Jaeger, dell IBM Watson Research Institute, il quale si è sempre dimostrato disponibile nelle spiegazioni e nei chiarimenti e suggerimenti, riguardanti alcuni concetti che sono alla base dell argomento affrontato in questa tesi, ed il cui contributo è stato di notevole valore.
a mamma e papà con amore
SOMMARIO Introduzione... i Concetti e terminologia della sicurezza dei computer... 1 1.1 La sicurezza dei computer... 1 1.2 Il reference monitor... 4 1.3 La politica di sicurezza... 6 1.4 Il Trusted Computing Base... 9 Modelli di controllo degli accessi... 11 2.1 La matrice degli accessi... 11 2.1.1 Access Control List e sistemi Capability-based... 13 2.2 Modelli discrezionali... 17 2.1 Unix... 20 2.3 Modelli mandatori... 23 2.3.1 Modelli LBAC e MLS... 26 2.3.2 Modello RBAC... 33 2.3.3 Modelli TE e DTE... 40 2.4 Il problema della safety... 46 Controllo degli accessi mandatorio in SELinux... 52 3.1 Architettura Flask e sistema SELinux... 52 3.2 Etichette di sicurezza... 59 3.3 Classi di oggetti e modalità di accesso... 60 3.4 Sottomodello TE in SELinux... 62 3.5 Sottomodello RBAC in SELinux... 63 3.6 Sottomodello User Identity in SElinux... 64 3.7 Transizioni e cambiamenti di security context... 66 3.8 Spazio dei security context... 69 Il linguaggio di configurazione di SELinux... 72 4.1 Semplificazioni del linguaggio di configurazione... 73 4.2 Configurazione del sottomodello TE... 80
4.3 Configurazione del sottomodello RBAC... 84 4.4 Configurazione del sottomodello UI... 87 4.5 Configurazione dei vincoli... 89 4.6 Classi di oggetti e modalità di accesso... 92 4.7 Configurazione delle transizioni di security context... 93 Il modello formale SELAC...100 5.1 SELinux Access Control...102 5.2 Insiemi e funzioni fondamentali...105 5.3 Insiemi derivati...116 5.4 Spazi di accessibilità...121 5.4.1 Universo...127 5.4.2 Specificati...127 5.4.3 Vincolati...128 5.4.4 Autorizzati...129 5.5.5 Proibiti 1...130 5.5.6 Proibiti 2...132 5.5.7 Proibiti 3...133 5.6 Utilità degli spazi di acccessibilità...134 Il tool di analisi...137 6.1 Organizzazione dei sorgenti...140 6.1.1 Modulo MISC...144 6.1.2 Modulo IBAC...150 6.1.3 Modulo RBAC...152 6.1.4 Modulo TE...153 6.1.5 Modulo ACCESS_SPACE...155 6.2 Inizializzazione del tool...157 6.3 Interrogazioni relative ad una configurazione...160 6.4 Esecuzione del tool...161 Conclusioni e lavoro futuro...166 Glossario dei termini...i Acronimi...XIX
Insiemi e funzioni di SELAC... XX Linguaggi di configurazione... XXVI Il linguaggio di configurazione di SELinux...XXVII Il linguaggio di configurazione SEL...XXXV Bibliografia... XXXIX
Introduzione Introduzione Le politiche di controllo degli accessi sono necessarie in ogni ambiente multiutente che permetta di condividere informazioni e risorse. Le politiche sono definite, analizzate ed implementate mediante i formalismi messi a disposizione da appositi modelli. È necessario che tali modelli siano sufficientemente flessibili da poter permettere la realizzazione di diverse politiche di controllo, in modo tale che sia possibile sceglierne una in un dato insieme predefinito, o crearne un altra ad hoc, specifica per l ambiente che si voglia proteggere. A partire dagli anni Settanta, sono stati proposti numerosi modelli per il controllo degli accessi alle informazioni contenute in un sistema, e la letteratura a riguardo è piuttosto ricca. In realtà, però, solamente una piccola parte di essi ha avuto un applicazione pratica nei sistemi reali. Alcuni sono definiti sulle ben note astrazioni di soggetti, oggetti e diritti di accesso. Altri si basano sui concetti più generali di ruoli, utenti e permessi. I più moderni introducono la possibilità di specificare dei vincoli. Gli aspetti importanti da considerare, in questo contesto, sono l implementazione, la capacità espressiva, la neutralità rispetto alla politica e la semplicità di amministrazione dei controlli degli accessi. In questa tesi prendiamo in esame il sistema Security Enhanced Linux, chiamato più brevemente SELinux, che è il risultato finale di una serie di progetti di ricerca nell ambito della sicurezza dei sistemi operativi, sviluppato dalla National Security Agency (NSA) americana. Esso sta ricevendo una considerevole attenzione nell ambito della comunità dei ricercatori, degli sviluppatori e degli utilizzatori di sistemi operativi sicuri. i
Introduzione SELinux consiste principalmente di una serie di potenziamenti relativi alla sicurezza del sistema Linux, implementati per mezzo di un architettura di controllo degli accessi mandatorio, incorporata nei maggiori sottosistemi del kernel. Il controllo degli accessi mandatorio, come verrà spiegato nel seguito della tesi, è il presupposto minimo per la reale protezione di un sistema nei confronti di azioni illegali, volte a comprometterne la confidenzialità e l integrità delle informazioni in esso contenute. In SELinux vengono forniti dei meccanismi capaci di realizzare la separazione delle informazioni, proprio in base ai requisiti di confidenzialità ed integrità dei dati, due degli aspetti fondamentali di quella che definiremo sicurezza dei computer. Il sistema Linux è stato scelto come base del progetto a causa del suo crescente successo e perché fornisce un ambiente di sviluppo aperto, capace di dimostrare la fattibilità dell integrazione di architetture di sicurezza in sistemi operativi esistenti ed ampiamente utilizzati. I meccanismi di sicurezza implementati in SELinux forniscono il supporto per un ampio spettro di politiche; ciò si traduce nella possibilità di configurare il sistema per soddisfare numerosi requisiti di sicurezza. La distribuzione del progetto include la configurazione di una sua politica generale, che ha il principale scopo di dimostrare come possano essere realizzati alcuni determinati obiettivi ([SF01]). La flessibilità del sistema, ottenuta in virtù della sua neutralità rispetto alle politiche in esso realizzabili, permette di modificare ed estendere tale configurazione, per personalizzarla in base alle specifiche esigenze. Il progetto è attualmente in fase di sviluppo, ma sicuramente costituisce un buon punto di inizio per l introduzione di meccanismi di sicurezza nel sistema Linux. Inoltre, le sue idee generali possono essere estese ad altri sistemi operativi. ii
Introduzione Allo stato attuale, tuttavia, esiste fondamentalmente un problema ad esso legato, ancora aperto e di difficile soluzione. Tale problema riguarda la difficoltà di configurazione e di analisi di una sua arbitraria politica di sicurezza. Infatti SELinux è molto complesso e la sua configurazione ed amministrazione è un attività estremamente complicata. Il modello di controllo degli accessi implementato è composito, basandosi su alcune varianti di altri modelli noti in letteratura. I concetti principali sono quelli di dominio di un soggetto, tipo di un oggetto, ruolo di un utente, diritto di accesso di una classe di oggetti. Fondamentalmente, ad ogni processo viene assegnata un etichetta di sicurezza che consta di tre campi: un identità, un ruolo ed un dominio. L identità indica l utente per il quale il processo è in esecuzione, il ruolo indica la funzione dell utente nel sistema ed il dominio specifica i privilegi di accesso che il processo ha sugli oggetti aventi determinati tipi. Ad ogni oggetto, corrispondente ad un determinato deposito di informazioni e appartenente ad una data classe, è assegnata un etichetta che indica il suo creatore, il suo ruolo e il suo tipo. I tre attributi di un etichetta di sicurezza, corrispondono ai tre sottomodelli sui quali si basa il controllo degli accessi. Ai vari sottomodelli, corrispondono altrettante componenti del sistema che devono essere configurate. La politica realizzata è il risultato complessivo della loro configurazione, che avviene per mezzo di un apposito linguaggio di alto livello. Tale linguaggio mette a disposizione una serie di costrutti, ognuno dei quali è relativo alla configurazione di uno dei sottomodelli e quindi ad una delle componenti del sistema. Non esiste un formalismo che permetta di definire, in maniera rigorosa, le conseguenze di una data configurazione. In altri termini, è in generale molto iii
Introduzione difficile comprendere l effetto complessivo sortito da un insieme di regole di configurazione scritte con l apposito linguaggio; ciò viene lasciato alla sola esperienza di amministratori di sicurezza molto esperti. Quindi, se da una parte la flessibilità di SELinux permette di realizzare diverse politiche di controllo degli accessi, dall altra una sua particolare configurazione è, in generale, molto complessa e richiede capacità, conoscenze ed eseperienze piuttosto vaste. Comprensibilmente, l amministrazione del sistema è molto importante e deve essere attentamente controllata per assicurare che la politica realmente realizzata non si distanzi dai suoi obiettivi pianificati; tuttavia, verificare se una configurazione realizzi o meno gli obiettivi di sicurezza della politica che si vuole imporre nel sistema, è un attività tutt altro che banale. Per sistemi di ragionevole utilità pratica, quindi, la gestione di grandi insiemi di tipi, ruoli, diritti di accesso ed utenti, e quella delle loro relazioni, è un compito molto gravoso. Questa tesi ha lo scopo principale di fornire un valido aiuto per la comprensione del sistema operativo SELinux e per la configurazione di una sua politica di sicurezza. Per fare ciò, è stato da noi formalizzato un modello, chiamato SELAC, che permetta di stabilire in maniera chiara le relazioni tra le varie regole di configurazione e quindi renda possibile la verifica dei loro effetti complessivi. Il modello è formato da una serie di concetti di alto livello e non fa riferimento ai dettagli interni di SELinux. La comprensione degli effetti di una data configurazione, come si è detto, non è cosa facile. Prima di tutto perché la documentazione fornita a corredo con il progetto sembra essere carente in tal senso, e poi perché il linguaggio di configurazione, pur se di semplice utilizzo, fondamentalmente nasconde le relazioni indotte da insiemi di regole. iv
Introduzione Siamo convinti che una qualsiasi metodologia di analisi e sviluppo di politiche, per essere possibile ed efficace, debba basarsi su un modello formale. Il nostro principale contributo in questa tesi è proprio la definizione di un formalismo che permetta, a partire da un fissato insieme di regole di configurazione di SELinux, di stabilire cosa esse consentano di fare nel sistema. Il vantaggio pratico di un modello formale è poi da ricercare nel fatto che, suo tramite, sia possibile sviluppare degli strumenti attraverso i quali automatizzare l analisi. A partire da SELAC, abbiamo sviluppato un tool, chiamato PACUM, col quale si possono effettuare elementari operazioni di analisi di una configurazione di SELinux. Tali analisi, allo stato attuale, sono molto a basso livello e non permettono di stabilire esplicitamente se una data configurazione soddisfi o meno generici requisiti di sicurezza, come ad esempio la confidenzialità e l integrità dei dati. Tuttavia si pongono come basi, a nostro avviso indispensabili, per qualsiasi futura analisi più generale. Inoltre, esse non sono affatto banali: ad esempio, permettono di determinare se un determinato soggetto possa accedere ad un determinato oggetto, e in che modo ciò, eventualmente, avvenga. Vista la complessità del controllo degli accessi di SELinux e vista l ampiezza di una sua generica configurazione, questa è sicuramente un informazione molto desiderabile. Siamo convinti che il lavoro presentato in questa tesi sia un buon punto di partenza per lo sviluppo di una metodologia di analisi generale delle politiche realizzabili in SELinux. Una tale metodologia prevede, infatti, almeno tre attività preliminari: la chiara comprensione del linguaggio di configurazione, la definizione di un modello formale per tale linguaggio e l implementazione del modello. Il contributo di questa tesi è proprio relativo a queste tre attività. v
Introduzione In particolare, riguardo alla comprensione del linguaggio di configurazione, c è da dire che il lavoro svolto risulta essere, a nostro avviso, abbastanza originale. Infatti, non solo la presentazione qui esposta permette di colmare alcune lacune della documentazione ufficiale, ma affronta la tematica da un diverso punto di vista. Laddove ogni costrutto del linguaggio di configurazione viene, in generale, considerato solamente rispetto al sottomodello al quale si riferisce, noi introduciamo il concetto di spazio dei security context, che permette di considerare gli effetti di ogni regola, non in relazione al solo sottomodello al quale essa si riferisca, ma a tutti e tre i sottomodelli di cui si compone il controllo degli accessi. Quindi, mentre nella documentazione ufficiale, un determinato costrutto del linguaggio viene visto relativamente ad un componente del sistema, noi vediamo tale costrutto relativamente a tutto il modello, determinando i controlli, imposti dalle regole corrispondenti, nella loro interezza. È su queste basi che, in SELAC, è possibile verificare gli effetti complessivi di una configurazione, mediante il concetto di spazio di accessibilità. Tramite questa tesi siamo convinti di permettere un avvicinamento al problema della definizione di politiche di sicurezza in SELinux, delineando quali cose siano da tener presenti e fornendo alcuni strumenti di analisi, elementari ma fondamentali e attualmente non disponibili altrove. Naturalmente, lo studio non si esaurisce qui. I risultati ottenuti da semplici sperimentazioni con il nostro tool hanno evidenziato una complessità della configurazione di esempio, fornita a corredo con SELinux, ancora più elevata di quanto si potesse immaginare. Bisogna trovare il modo di gestire questa complessità, che non dipende da SELAC ma dal modello di controllo degli accessi realizzato nel sistema. Ciò costituisce il primo obiettivo principale di qualsiasi eventuale lavoro futuro, che volesse prendere le mosse da quello qui presentato. vi
Introduzione La tesi si compone di sei capitoli e due appendici. Quello che si è cercato di creare è un cammino ideale che, di capitolo in capitolo, conducesse dalle nozioni generali, relative al termine sicurezza (legato spesso ad un idea piuttosto generica ed astratta), al problema di come verificare che il sistema SELinux possa o meno garantirla. A tale scopo, nel primo capitolo vengono introdotti la terminologia e i concetti fondamentali legati alla sicurezza dei computer. La terminologia è quella universalmente riconosciuta e presente in letteratura. Quanto scritto ha valore generale, ma la sua comprensione è indispensabile, perché i concetti esposti sono utilizzati a più riprese nel resto della tesi. Il secondo capitolo è dedicato ai modelli di controllo degli accessi presenti in letteratura e alle politiche di sicurezza in essi realizzabili. In particolare, sono presentati quei modelli che interessano direttamente SELinux. Di ognuno di essi sono descritte le caratteristiche salienti; la loro comprensione è fondamentale, perché il controllo degli accessi di SELinux si basa su alcune loro varianti o semplificazioni. Il terzo capitolo è dedicato più particolarmente a SELinux. Sono definite le caratteristiche dell architettura di sicurezza in esso implementata, chiamata Flask, ed è mostrato in cosa i sottomodelli che compongono il controllo degli accessi si differenzino dalle loro versioni originali, presenti in letteratura. Il quarto capitolo è interamente dedicato al linguaggio di configurazione del sistema. In particolare, ne viene descritta una variante, da noi chiamata SEL, costituita da un sottoinsieme dei costrutti del linguaggio originale; di alcuni vii
Introduzione di essi sono fornite delle versioni appositamente semplificate. I costrutti non presi in considerazione sono relativi a funzionalità che vanno oltre gli scopi di questa tesi, mentre le semplificazioni operate sono di natura minima, mirate solamente ad una più agevole spiegazione. Quanto detto nel capitolo, comunque, è valido per il linguaggio originale, perché SEL è ad esso equivalente. Il quinto capitolo è dedicato al modello SELAC. Essenzialmente, SELAC è costituito da una serie di insiemi i cui elementi mantengono informazioni relative ad una configurazione di SELinux. Nel capitolo sono definiti tutti gli insiemi fondamentali che lo compongono e una serie di funzioni di utilità generale. Per ogni insieme, viene fornito un algoritmo che permetta di costruirlo a partire da una data configurazione. Inoltre viene mostrato come sia possibile definire, in maniera semplice, altri insiemi, derivati da quelli fondamentali. La principale comodità nell utilizzo di SELAC è che esso permette di effettuare analisi di configurazioni di SELinux, semplicemente per mezzo di operatori insiemistici. Il sesto capitolo è dedicato alla presentazione del tool PACUM, da noi sviluppato. La spiegazione è generale e per i dettagli implementativi si rimanda ai codici sorgenti, liberamente scaricabili dal web. PACUM consiste principalmente di una serie di strutture dati e di funzioni, che implementano il modello SELAC. Il tool è stato sviluppato seguendo il paradigma orientato agli oggetti ed il linguaggio utilizzato è C++. Per ogni modulo di cui si compone logicamente il tool, viene fornito il diagramma delle classi, in notazione Unified Modelling Language (UML). Inoltre, per ogni insieme di SELAC, sono elencati i metodi delle classi che permettono di ottenerne gli elementi. viii
Introduzione L appendice A contiene un glossario dei termini, reputato da noi di particolare valore, vista l ampiezza della tesi e della terminologia utilizzata. Nel glossario sono riuniti, in un unico spazio, i nomi e le definizioni dei concetti generali, presenti in letteratura, di quelli relativi a SELinux, presenti nella documentazione ufficiale, e di quelli da noi introdotti e peculiari di questa tesi. Inoltre, è fornita una lista di acronimi di uso comune, anch essi presenti in letteratura e quindi, a nostro avviso, lecitamente utilizzati nei capitoli della tesi; infine, un apposita sezione è dedicata agli insiemi e alle funzioni che definiscono SELAC. L appendice B riporta le grammatiche del linguaggio di configurazione originale di SELinux e della sua versione semplificata, SEL. La tesi si conclude con una bibliografia, contenente tutti i riferimenti alla letteratura presenti in questo lavoro e l elenco dei siti web citati. ix
Capitolo I : Concetti e terminologia della sicurezza dei computer Capitolo 1 Concetti e terminologia della sicurezza dei computer In questo capitolo ci concentriamo sulla spiegazione dei concetti fondamentali per la comprensione della sicurezza dei computer. I concetti e i termini qui esposti verranno utilizzati in tutta la tesi. La terminologia di base è quella che è stata adottata ormai da diversi anni a questa parte, introdotta in [An72, TCSE85, ITSE91] e ripresa ed utilizzata ampiamente in [AJP95]. 1.1 La sicurezza dei computer Esistono numerose definizioni del termine SICUREZZA DEI COMPUTER, ognuna delle quali pone l attenzione su uno o più aspetti specifici di un campo di studio molto vasto. La caratterizzazione alla materia che qui forniamo è legata al termine sicurezza della tecnologia informatica, la cui definizione è presente nel documento della Comunità Europea [ITSE91]. Secondo tale documento la sicurezza della tecnologia informatica è formata da tre requisiti principali che devono essere soddisfatti, corrispondenti a tre proprietà dei sistemi informatici: la CONFIDENZIALITÀ, l INTEGRITÀ e la DISPONIBILITÀ dell informazione (nel caso della disponibilità, questa deve essere relativa anche alle risorse). Con il termine confidenzialità si intende la capacità di prevenire che l informazione possa essere ottenuta da individui non autorizzati. L integrità, invece, riguarda l impossibilità per gli individui non autorizzati 1
Capitolo I : Concetti e terminologia della sicurezza dei computer di poter modificare l informazione. Infine, la disponibilità riguarda la prevenzione di un trattenimento non autorizzato di informazioni o risorse. I tre termini sopraelencati differiscono tra loro. La prima differenza, immediatamente visibile, è che la disponibilità riguarda l informazione e le risorse, mentre gli altri due solamente l informazione. In realtà la differenza tra la disponibilità e gli altri due requisiti, o proprietà, è molto più forte ed emerge considerando che, come mostrato in [LA91], mentre i controlli degli accessi forniscono le basi per la confidenzialità e per l integrità, essi sono assai meno utili nei confronti della disponibilità. In altre parole, è possibile soddisfare i primi due requisiti prevenendo un accesso illecito all informazione che si vuole proteggere, tramite un sistema di controllo degli accessi, ma la disponibilità non può essere garantita allo stesso modo. Questo si traduce, ovviamente, in una distinzione netta tra le soluzioni che permettono di ridurre o eliminare le minacce relative alla confidenzialità e all integrità delle informazioni e quelle relative alla disponibilità di informazioni e risorse: nel seguito, una volta introdotti i concetti necessari, vedremo come sia possibile fornire un REFERENCE MONITOR per le prime due, ma non per la disponibilità. Il problema di fondo, alla base della divisione dei tre requisiti in due classi di proprietà distinte, è che esiste una grande differenza tra le proprietà di confidenzialità ed integrità ed altre proprietà, fra le quali la disponibilità: le prime due possono essere definite precisamente in un modo globale e persistente, in maniera tale che sia possibile stabilire, senza ombra di dubbio, se un dato sistema ne goda o meno. In altre parole, utilizzando la terminologia propria della Teoria della Calcolabilità, la verifica delle proprietà di confidenzialità ed integrità delle informazioni in un sistema costituisce un PROBLEMA CALCOLABILE. Dire che la verifica di determinate 2
Capitolo I : Concetti e terminologia della sicurezza dei computer proprietà costituisce un problema calcolabile significa, essenzialmente, che è possibile specificare un algoritmo che possa essere utilizzato per automatizzare il modo di determinare il risultato di un problema decisionale. Il problema di determinare se i sistemi godano di altre proprietà, come ad esempio la disponibilità, l affidabilità e la SAFETY (di cui ci occuperemo in seguito), è invece fondamentalmente un problema non calcolabile. In realtà, dato un arbitrario sistema di protezione, come dimostrato in [HRU76] e come vedremo nel prossimo capitolo, è in generale non calcolabile il problema di determinare se il sistema goda di alcune date proprietà. Fortunatamente, confidenzialità ed integrità costituiscono un caso particolare, per il quale è decidibile il problema di determinare se un dato sistema risulti sicuro rispetto ad esse. Per quanto detto finora, la confidenzialità e l integrità sono le due componenti della sicurezza della tecnologia dell informazione che possiamo considerare come costituenti la SICUREZZA DEI COMPUTER. Quindi la sicurezza dei computer è un sottoinsieme della sicurezza della tecnologia dell informazione, che riguarda la salvaguardia delle informazioni in un computer rispetto alle minacce relative alla confidenzialità e all integrità, ma non rispetto a quelle relative alla disponibilità. Perciò la sicurezza dei computer, o più semplicemente sicurezza, può essere fornita dai metodi utilizzati per il controllo degli accessi nel sistema. E proprio ai metodi e modelli di controllo degli accessi è dedicato il capitolo 2 di questa tesi. Capire la sicurezza dei computer presuppone la conoscenza di tre nozioni fondamentali: quella di POLITICA DI SICUREZZA che stabilisca delle leggi che regolino come un sistema gestisca, protegga e distribuisca le informazioni sensibili; quella di funzionalità dei MECCANISMI DI SICUREZZA interni al sistema che impongono la politica; quella di certezza che i meccanismi realizzino 3
Capitolo I : Concetti e terminologia della sicurezza dei computer realmente la politica. Gli ultimi due aspetti competono, rispettivamente, all implementazione dei sistemi e alla verifica formale dei modelli e pertanto vanno oltre gli scopi di questa tesi. Noi ci concentreremo invece, soprattutto nel prossimo capitolo, sulle politiche di sicurezza e sui più importanti modelli di controllo degli accessi che permettono la loro realizzazione. 1.2 Il reference monitor Come detto sopra, i pericoli relativi alla sicurezza dei computer possono essere contrastati per mezzo di un controllo degli accessi alle informazioni nel computer, per assicurare che solamente gli individui autorizzati possano accedere a quelle reputate sensibili. Ciò che si vuole, quando si parla di sicurezza dei computer, è la possibilità di costruire una parte relativamente piccola del sistema, capace di rendere sicuro tutto il sistema, anche se il resto di esso e le sue applicazioni siano sviluppate tramite software malizioso, potenzialmente utilizzabile da un attaccante esperto. La teoria della sicurezza dei computer si basa quindi sul controllo degli accessi e si realizza nella costruzione di questo componente, il cui concetto è chiamato REFERENCE MONITOR. Il reference monitor, così come definito in [An72], è un astrazione che permette ad entità attive, chiamati soggetti, di fare riferimento ad entità passive chiamate oggetti, in base ad un insieme di autorizzazioni di accesso. Il reference monitor fa riferimento ad un database delle autorizzazioni e comunica con un sistema di auditing che memorizza quali accessi agli oggetti siano stati permessi e/o negati ai soggetti, in funzione delle autorizzazioni correnti. Un reference monitor, come spiegato in [Sc74], supporta due classi di funzioni: le funzioni di riferimento e le funzioni di 4
Capitolo I : Concetti e terminologia della sicurezza dei computer autorizzazione: le prime servono a prendere delle decisioni riguardanti il permesso o il diniego di accesso alle informazioni, in base alle regole memorizzate nel database delle autorizzazioni; le seconde servono a controllare i cambiamenti alle singole regole di controllo degli accessi presenti nel database delle autorizzazioni. Tale database non fa logicamente parte del reference monitor, ma tutte le modifiche al suo contenuto avvengono per mezzo delle funzioni di autorizzazione. Riguardo alle modalità di accesso alle quali fanno riferimento le regole contenute nel database delle autorizzazioni, a livello astratto queste sono solamente due: in lettura e in scrittura; tuttavia, nelle reali implementazioni del concetto di reference monitor, tali modalità possono essere anche molto numerose, raggiungendo, come avviene nel sistema SELinux alti livelli di granularità. Un implementazione completa del concetto di reference monitor in un sistema reale prende il nome di security kernel. Essa deve soddisfare una serie di requisiti, identificati in [An72] ed utilizzati in [TCSE85], ai quali ci si riferisce con i termini di completezza, isolamento e verificabilità. La prima proprietà prevede che il reference monitor sia invocato, senza eccezioni, per ogni riferimento di un soggetto ad un oggetto; la seconda che il reference monitor e il database delle autorizzazioni siano protetti da alterazioni non autorizzate (in gergo si dice che devono essere tamper proof ); l ultima, che il reference monitor sia piccolo, ben strutturato e semplice, così che possa essere completamente analizzato e testato e sia possibile verificare in maniera formale il suo corretto funzionamento. La corrispondenza tra i componenti di un reference monitor, che è un concetto astratto, e i componenti di un sistema reale risulta chiara: i soggetti sono le entità attive del sistema che operano sulle informazioni a beneficio degli utenti; essi sono quindi i processi che vengono eseguiti su un 5
Capitolo I : Concetti e terminologia della sicurezza dei computer computer e fungono da surrogati degli utenti; gli oggetti mantengono le informazioni che i soggetti possono accedere, quindi file, record, segmenti di memoria e tutti gli altri depositi di informazioni di un sistema sono oggetti. Il database delle autorizzazioni specifica le circostanze sotto le quali un soggetto può ottenere l accesso agli oggetti. 1.3 La politica di sicurezza Si è detto che alla base della sicurezza dei computer vi è il concetto di POLITICA DI SICUREZZA. Una politica di sicurezza utile è abbastanza generale: tipicamente non specifica meramente i nomi di chi può o non può avere accesso a determinate informazioni; invece può stabilire che i responsabili di determinate cariche abbiano l autorità di ottenere l accesso a determinate risorse. Inoltre la politica di sicurezza può prevedere dei requisiti, come ad esempio il ricoprimento di un ruolo all interno di un organizzazione, che gli individui devono poter soddisfare per l accesso alle risorse. Un dato sistema può essere detto sicuro solamente rispetto ad una particolare politica di sicurezza. È fondamentale capire quale sia la differenza tra il concetto di politica di sicurezza e quello di MECCANISMI DI SICUREZZA che realizzano la politica in un sistema: una politica di sicurezza stabilisce delle regole di controllo degli accessi che devono essere rispettate, laddove i meccanismi forniscono delle funzionalità che permettono l implementazione del controllo degli accessi. Alcuni di questi meccanismi e i loro modelli, come ad esempio il TYPE ENFORCEMENT, verranno presi in considerazione nel prossimo capitolo. Le politiche sono quindi delle linee guida di alto livello che stabiliscono come sono controllati gli accessi e come sono determinate le decisioni di accesso. I meccanismi sono invece costituiti da software (alcune volte anche 6
Capitolo I : Concetti e terminologia della sicurezza dei computer da hardware) di basso livello, che può essere configurato per implementare una particolare politica. È stato mostrato in [HRU76] e in [ShSc81] che in generale per ogni dato meccanismo di sicurezza, esistono politiche di sicurezza che il meccanismo non è in grado di imporre. Perciò il meccanismo può essere modellato sulla politica di sicurezza che è progettato per supportare. Il CONTROLLO DEGLI ACCESSI BASATO SUI RETICOLI, ad esempio, è progettato per supportare una politica di sicurezza che preveda un flusso unidirezionale di informazioni all intero di un reticolo di etichette di sicurezza. D altra parte esistono politiche di sicurezza che possono essere realizzate per mezzo di differenti meccanismi, così come meccanismi che risultano neutrali rispetto alla politica, come ad esempio il CONTROLLO DEGLI ACCESSI BASATO SUI RUOLI ed il TYPE ENFORCEMENT. I meccanismi di controllo degli accessi largamente indipendenti dalla politica per la quale possono essere utilizzati sono i più utili perché possono essere riutilizzati in diversi contesti di sicurezza [BJSS97]: il sistema SELinux costituisce uno degli esempi di maggiore interesse di questa ultima tipologia. Il concetto di reference monitor è compatibile con un ampio spettro di politiche di sicurezza, che possono essere considerate divise in due classi: le POLITICHE DI SUPPORTO e le politiche di controllo degli accessi. Le politiche di supporto rappresentano dei requisiti correlati a quella che viene chiamata accountability degli individui nel sistema: principalmente includono la politica di identificazione/autenticazione degli utenti e la politica di auditing degli accessi. L AUTENTICAZIONE specifica i requisiti per identificare un individuo prima di permettere ai soggetti di agire nel sistema come suoi surrogati. Il più comune metodo di autenticazione di un utente all interno di un sistema è per mezzo di una password. Più in generale, l autenticazione può stabilire 7
Capitolo I : Concetti e terminologia della sicurezza dei computer l identità di un computer ad un altro ed in alcuni casi è richiesto che ciò avvenga in entrambe le direzioni. L AUDITING fornisce le basi per la memorizzazione di quegli eventi rilevanti dal punto di vista della sicurezza che possono essere univocamente associati ad un individuo. L auditing è quindi l esame della storia degli eventi nel sistema per determinare se e come si è tentato di, o si è riusciti a, violare la sicurezza del sistema. Qualora l analisi avvenga on-line in maniera più o meno real-time, essa prende il nome di INTRUSION DETECTION. L auditing è essenziale anche per verificare che gli utenti non abusino dei propri PRIVILEGI. Il termine POLITICA DI SUPPORTO deriva dal fatto che essa è a supporto della politica di controllo degli accessi, che costituisce la nostra principale area di interesse. Una politica di controllo degli accessi specifica le regole per il controllo degli accessi che sono necessarie perché sia realizzata la politica di sicurezza. È bene distinguere chiaramente tra autenticazione e controllo degli accessi: è responsabilità del sottosistema di autenticazione stabilire l identità di un individuo; il controllo degli accessi assume che l identità dell individuo sia stata verificata con successo, prima di imporre una propria politica attraverso un REFERENCE MONITOR. In generale non esistono politiche che siano migliori di altre, piuttosto esistono politiche che assicurino maggiore protezione di altre, ma non tutti i sistemi hanno gli stessi requisiti di sicurezza. La scelta delle politiche dipende dall ambiente che si deve proteggere. 8
Capitolo I : Concetti e terminologia della sicurezza dei computer Le politiche di controllo degli accessi ricadono in due categorie: politiche discrezionali e politiche mandatorie, intendendo con il termine mandatorio il complemento del termine discrezionale (come stabilito in [TCSE85]). Il punto fondamentale alla base di tutta la discussione sulle politiche di controllo degli accessi è che, sebbene il paradigma del reference monitor di soggetti, oggetti e funzioni di riferimento si possa applicare sia a CONTROLLI DEGLI ACCESSI MANDATORI sia a CONTROLLI DEGLI ACCESSI DISCREZIONALI, solo un implementazione del reference monitor che realizzi politiche mandatorie fornisce una reale protezione contro software malizioso (si veda a tal proposito [Be91]). Le politiche di controllo degli accessi non sono necessariamente esclusive: possono esserne combinate di differenti per fornire uno strumento di protezione più adeguato. Quando più politiche sono combinate, è garantita solo l intersezione dei loro permessi autorizzati. Il sistema SELinux, ad esempio, utilizza due livelli di controlli combinati: al livello più esterno vengono effettuati dei controlli di tipo mandatorio, superati i quali subentrano quelli standard di tipo discrezionale, propri del sistema Linux e degli Unix in generale. 1.4 Il Trusted Computing Base Si è detto che l implementazione di un reference monitor all interno di un sistema è chiamata SECURITY KERNEL. In realtà, quando si pensa ad un sottosistema che funga da reference monitor, spesso si è interessati ad operare nel sistema operativo, già esistente, delle modifiche e miglioramenti: si parla in questi casi di sistemi potenziati dal punto di vista della sicurezza, 9
Capitolo I : Concetti e terminologia della sicurezza dei computer o SISTEMI SECURITY ENHANCED. Il sistema SELinux (Security Enhanced Linux) rientra esattamente in questa tipologia. La maggior parte dei sistemi operativi può essere modificata per implementare una porzione più o meno grande del concetto di reference monitor e migliorare da un punto di vista della sicurezza, ad un costo relativamente basso: andare oltre e modificare il sistema per incorporare un reale SECURITY KERNEL è, in generale, tanto costoso quanto reimplementare il sistema da zero. Esistono quindi, sostanzialmente, due tipi di approcci, che possono essere adottati nel rendere sicuri i sistemi: il semplice potenziamento del sistema e l incorporamento di un security kernel. Indipendentemente dal tipo di approccio utilizzato, si chiama Trusted Computing Base (TCB) il generico sottoinsieme del sistema operativo che implementa tutti i meccanismi responsabili della realizzazione della politica di sicurezza ([TCSE85]). Il TCB è una parte relativamente piccola del sistema, che fornisce la totalità dei meccanismi di protezione; ogni software che non faccia parte del TCB può essere software malizioso, senza per questo rendere il sistema insicuro. L ampiezza del TCB è quindi variabile da sistema a sistema: spazia da un piccolo numero di potenziamenti del sistema operativo ad un vero e proprio SECURITY KERNEL, fino anche a coincidere con la totalità del sistema stesso. Ovviamente, al crescere della quantità di codice che costituisce il TCB diventa sempre più difficile essere sicuri che esso realizzi i requisiti del reference monitor in ogni circostanza. 10
Capitolo II: Modelli di controllo degli accessi Capitolo 2 Modelli di controllo degli accessi Dopo aver introdotto la terminologia di base necessaria nel capitolo precedente, descriviamo qui i modelli di controllo degli accessi più conosciuti in letteratura. In particolare vengono presentati quei modelli che poi verranno ripresi nel capitolo successivo, dedicato al sistema SELinux, che si basa, come vedremo, su alcune loro varianti. Infine introduciamo il PROBLEMA DELLA SAFETY, intrinseco ai modelli di controllo degli accessi. 2.1 La matrice degli accessi Nel precedente capitolo si è detto che, secondo il paradigma del REFERENCE MONITOR, in un sistema esistono entità attive, chiamati SOGGETTI ed entità passive, contenitrici di informazioni, chiamate OGGETTI, sulle quali i soggetti operano. I soggetti sono tipicamente gli utenti o i processi che agiscono a beneficio degli utenti. Un utente può entrare nel sistema tramite differenti soggetti, in differenti occasioni, in funzione dei PRIVILEGI che vuole esercitare in una data sessione di lavoro: per esempio, un utente che lavori a due progetti può entrare nel sistema allo scopo di lavorare ad uno o all altro; si hanno quindi due soggetti corrispondenti a quell utente, in funzione del progetto sul quale l utente lavori. In realtà i soggetti possono a loro volta svolgere la funzione di oggetti; essi infatti possono creare nuovi soggetti per realizzare i propri scopi: nei sistemi classici, come ad esempio Unix, i processi possono creare altri processi e comunicare con essi, ad esempio, mediante invio e ricezione di segnali. 11
Capitolo II: Modelli di controllo degli accessi La distinzione semantica tra soggetti ed oggetti è alla base di tutti i modelli di controllo degli accessi. L autorizzazione di un soggetto su un oggetto è espressa in termini di DIRITTI DI ACCESSO o di MODALITÀ DI ACCESSO, il cui significato dipende dall oggetto in questione. Per i file, ad esempio, i diritti di accesso classici sono quelli di lettura, scrittura ed esecuzione. A questi si aggiunge, in alcuni controlli degli accessi 1, il diritto di proprietà (ownership), che ha a che fare con l autorizzazione di cambiare i diritti sui file. La matrice degli accessi, formalizzata in [La74] ripresa in [HRU76] e citata praticamente in tutta la letteratura successiva, è un modello concettuale che specifica i diritti di accesso che ogni soggetto ha rispetto ad ogni oggetto. Nella matrice, ad ogni riga corrisponde un soggetto e ad ogni colonna un oggetto; ogni cella della matrice specifica i diritti di accesso che il soggetto associato alla riga ha sull oggetto associato alla colonna. L insieme di oggetti che un soggetto può accedere è chiamato dominio del soggetto. La matrice degli accessi è il modello di protezione più semplice e generale che possa essere immaginato; l obiettivo del controllo degli accessi è quello di permettere solamente le operazioni in essa autorizzate. La matrice degli accessi così semplicemente definita, non permette di realizzare il principio dei privilegi minimi: ad ogni soggetto dovrebbero essere garantiti i soli privilegi minimi necessari affinché possa portare a compimento il proprio compito. Infatti non esiste per il soggetto la possibilità di cambiare dominio in funzione del compito che deve svolgere. 1 quelli definiti in seguito DAC 12
Capitolo II: Modelli di controllo degli accessi Figura 1: esempio di matrice degli accessi; own indica il diritto di proprietà, r quello di lettura e w quello di scrittura Il principio dei privilegi minimi è alla base della sicurezza di un sistema, perché garantisce che sia limitato il danno che possa risultare da un incidente, errore o azione maliziosa, e perché limita il numero di soggetti privilegiati, che potrebbero essere attaccati. 2.1.1 Access Control List e sistemi Capability-based In un sistema reale una matrice degli accessi avrebbe dimensioni enormi e risulterebbe, in generale, molto sparsa, soprattutto in presenza di piccoli domini per i soggetti, cosa desiderabile per la realizzazione del PRINCIPIO DEI PRIVILEGI MINIMI. Per i precedenti motivi la matrice degli accessi raramente viene implementata come una matrice; si preferisce invece utilizzare uno dei due seguenti approcci, l uno speculare all altro: le ACCESS CONTROL LIST e le Liste di CAPABILITY. Qualora si memorizzi la matrice degli accessi per colonne, per ogni oggetto si indicano i diritti di accesso che i soggetti sono autorizzati ad avere 13
Capitolo II: Modelli di controllo degli accessi sull oggetto; ad ogni oggetto viene cioè associata una Access Control List (ACL). Al momento del tentativo di accesso, il soggetto viene autenticato e la lista scandita. Tramite le ACL è semplice determinare per un soggetto quali siano le modalità di accesso autorizzate. È semplice anche determinare quali siano i soggetti che possano accedere in un qualche modo all oggetto. È sempre sufficiente controllare solamente la ACL per l oggetto in questione. Figura 2: ACL per la matrice degli accessi in Figura 1 Per quanto riguarda la revoca di un autorizzazione, è sufficiente una ricerca ed una eliminazione nella ACL. Qualora si vogliano revocare tutti gli accessi ad un oggetto, è sufficiente sostituire la ACL dell oggetto con una ACL vuota. Il rovescio della medaglia è che risulta difficile reperire altre informazioni, ad esempio quali siano tutti gli accessi autorizzati di un dato soggetto: è necessario infatti analizzare le ACL di tutti gli oggetti nel sistema, alla ricerca del dato soggetto. Allo stesso modo, se devono essere 14
Capitolo II: Modelli di controllo degli accessi revocate tutte le autorizzazioni di un dato soggetto, è necessario visitare tutte le ACL, una per una. La lunghezza di una ACL costituisce un problema. Molti sistemi permettono di inserire nomi di gruppi di soggetti all interno di una ACL, piuttosto che nomi di singoli soggetti: molti sistemi operativi popolari, fra i quali Unix, implementano una forma abbreviata di ACL nella quale un piccolo numero di nomi di gruppi, spesso solo uno o due, possa essere presente nella ACL; i nomi di singoli soggetti non sono permessi. Nel caso in cui si memorizzi, invece, la matrice degli accessi per righe, ad ogni soggetto è associata una lista, chiamata Lista di Capability, che indica, per ogni oggetto, le modalità di accesso alle quali il soggetto è autorizzato. Una singola CAPABILITY può essere pensata come una coppia (x, r) dove x rappresenta il nome di un oggetto ed r è un insieme di PRIVILEGI o DIRITTI DI ACCESSO. Una Lista di Capability indica, quindi, in tutto e per tutto il DOMINIO di un soggetto. Figura 3: liste di capability per la Matrice degli Accessi in Figura 1 15
Capitolo II: Modelli di controllo degli accessi Utilizzando questo approccio, determinare quali siano tutti gli accessi autorizzati di un soggetto è molto semplice: è sufficiente analizzare la Lista di Capability del soggetto in questione. Per contro, determinare tutti i soggetti che possano accedere ad un dato oggetto necessita l analisi delle Liste di Capability di tutti i soggetti. L approccio basato sulle Capability elimina la necessità dell autenticazione perché ad un soggetto, per accedere ad un oggetto, basta fornire la Capability relativa. Tuttavia le Capability devono essere rese, ovviamente, irriproducibili. Il successo di un meccanismo basato sulle Capability dipende proprio dai meccanismi che garantiscano la loro irriproducibilità e fra le varie possibilità vi è ovviamente la crittografia. Come risulta chiaro, i due approcci sono l uno speculare all altro. I moderni sistemi operativi, tipicamente, utilizzano l approccio basato sulle ACL, ma è possibile anche combinare i due in implementazioni più complesse. Abbiamo visto sinora il più semplice modello di controllo degli accessi, la MATRICE DEGLI ACCESSI, ed abbiamo fornito due sue possibili implementazioni. Di seguito trattiamo una serie di modelli ben noti in letteratura. Abbiamo deciso, in accordo con [TCSE85] e [AJP95], di partizionare tutti i modelli in due soli classi, quella dei modelli discrezionali e quella dei modelli mandatori. In realtà, in letteratura, non si trova accordo unanime sulla suddivisione di cui sopra: in [Sa93], ad esempio, non si considera il CONTROLLO DEGLI ACCESSI BASATO SUI RUOLI come una forma di controllo degli accessi mandatorio, bensì come una forma che non sia né discrezionale né mandatoria; in alcuni documenti ([Sa93, Sa96, Sa98, SaSa97]) con il termine controllo degli accessi mandatorio si intende il solo CONTROLLO DEGLI ACCESSI BASATO SUI RETICOLI. 16
Capitolo II: Modelli di controllo degli accessi Noi preferiamo, seppur forse riduttiva sotto certi aspetti, una suddivisione in sole due classi, facendo ricadere nella classe dei modelli mandatori tutti quei modelli che non siano discrezionali. Questo sia per motivi di semplicità della trattazione, sia perché, comunque, tutti i modelli non discrezionali condividono alcune caratteristiche legate al concetto di ETICHETTA DI SICUREZZA e ad altri concetti simili, che vedremo nei prossimi paragrafi e che consideriamo come il denominatore comune di tutti i modelli non discrezionali. 2.2 Modelli discrezionali Il controllo degli accessi discrezionale (Discretionary Access Control, DAC) ha la sua genesi negli anni settanta. Le idee di base sono già presenti in [La74]. Le politiche discrezionali governano l accesso dell utente alle informazioni in funzione della sua identità. L idea che c è alla base è che gli utenti siano i proprietari degli oggetti, ed in quanto tali è a loro completa discrezione stabilire chi possa essere autorizzato ad accedervi e in che modalità; in altre parole i soggetti possono determinare chi abbia accesso ai propri oggetti. La proprietà di un oggetto viene in genere acquisita a seguito della sua creazione. L amministrazione dei diritti di accesso in DAC è quindi basata sul concetto di PROPRIETARIO. Esistono numerose varianti di DAC in letteratura ([SM98]); in particolare, esse differiscono riguardo a come il potere discrezionale del proprietario possa essere delegato ad altri utenti, e a come l accesso possa essere revocato. In generale, le più comuni politiche DAC condividono le seguenti caratteristiche: il creatore di un oggetto ne diventa automaticamente il proprietario 17
Capitolo II: Modelli di controllo degli accessi esiste un solo proprietario per un oggetto; la proprietà in alcuni casi rimane fissata nel creatore originario, in altri può essere trasferita ad un altro utente la distruzione di un oggetto può essere fatta solamente dal suo proprietario Alcune variazioni di DAC rispetto al modo in cui vengono garantiti gli accessi sono le seguenti: Strict-DAC: solo il proprietario, a sua discrezione, garantisce l accesso ad un oggetto e l autorità discrezionale di garantire l accesso, chiamata in gergo grant, non può essere trasferita Liberal-DAC: il proprietario può delegare il grant ad altri utenti; distinguiamo: o one level grant: il proprietario può delegare il grant ad altri utenti, ma questi non possono ulteriormente delegare questo potere o two level grant: oltre a quanto previsto dal precedente, il proprietario può permettere ad alcuni utenti di delegare ulteriormente il grant o multilevel grant: può essere delegata la stessa autorità di delegare il grant. DAC con cambio di proprietario: agli utenti è permesso trasferire la proprietà di un oggetto ad un altro utente; può essere combinato con Strict-DAC e Liberal-DAC in tutte le varianti di cui sopra. Per quanto riguarda poi la revoca, esistono in generale due approcci corrispondenti al fatto che la revoca sia dipendente o indipendente da colui che ha garantito l accesso. In generale, comunque, chiunque abbia l autorità di permettere l accesso ha anche l autorità di revocarlo. 18