politiche di controllo degli selinux di …spazioinwind.libero.it/paculandia/tesi.pdfil controllo...

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 Proibiti1 .............................................................................................. 130

5.5.6 Proibiti2 .............................................................................................. 132

5.5.7 Proibiti3 .............................................................................................. 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

i

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.

Introduzione

ii

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.

Introduzione

iii

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

Introduzione

iv

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.

Introduzione

v

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à.

Introduzione

vi

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.

Introduzione

vii

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

Introduzione

viii

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.

Introduzione

ix

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.

Capitolo I : Concetti e terminologia della sicurezza dei computer

1

C a p i t o l o 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


2

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


3

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


4

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


5

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


6

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


7

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


8

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.


9

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,


10

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.

Capitolo II: Modelli di controllo degli accessi

11

C a p i t o l o 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.


12

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 accessi1, 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


13

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


14

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


15

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


16

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.


17

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


18

• 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.


19

Le politiche di controllo degli accessi discrezionali che si basano sulla

esplicita specificazione delle autorizzazioni sono dette politiche chiuse,

perché il comportamento predefinito del REFERENCE MONITOR del sistema è

quello di negare l’accesso. In maniera opposta, le politiche aperte sono

quelle che specificano divieti, anziché autorizzazioni; per ogni utente ed

oggetto del sistema vengono specificate le modalità di accesso proibite che

l’utente ha sull’oggetto: ogni richiesta di accesso dell’utente viene controllata

rispetto ad una lista di permessi negativi e viene autorizzata solamente se

non esiste alcun vincolo che lo vieti. L’utilizzo di autorizzazioni positive e

negative può essere combinato, permettendo di esprimere sia gli accessi che

devono essere garantiti sia quelli che devono essere negati. L’approccio,

tuttavia, può diventare estremamente complicato, come mostrato in

[BJS93].

I modelli di controllo degli accessi discrezionali risultano essere molto

flessibili ed infatti sono stati adottati in molti ambienti. Tuttavia soffrono

del grave problema di non garantire nulla relativamente al flusso di

informazioni nel sistema: ad esempio, un utente che sia autorizzato alla

lettura di un dato, può passarne una copia ad un altro che non sia

autorizzato a farlo, senza che il proprietario del dato ne venga a conoscenza.

In questo caso, tramite la cooperazione degli utenti, si può violare la politica di

sicurezza del sistema. Il problema di fondo è che le politiche di controllo

degli accessi discrezionali non impongono restrizioni sull’utilizzo delle

informazioni una volta che queste siano state acquisite dagli utenti. Inoltre,

alcune copie degli oggetti possono essere propagate da software chiamati

Cavalli di Troia, anche senza un’esplicita cooperazione degli utenti ai quali è

concesso di accedere all’originale. Un esempio classico di quanto detto è la

seguente situazione, che può presentarsi in un sistema che utilizzi il DAC: si


20

supponga di avere un soggetto S che abbia accesso ad un qualche oggetto O

il cui contenuto è altamente segreto. Inoltre si supponga di avere un altro

soggetto, S’, che non abbia accesso in lettura ad O ma al quale ciò farebbe

comodo. Perché S’ possa leggere le informazioni in O è sufficiente che una

qualsiasi applicazione che S possa essere interessato ad utilizzare (ad

esempio un videogame o un editor di testo) esegua, in maniera non visibile

ad S, il seguente algoritmo: 1. crea un nuovo oggetto O’ in una directory in cui non

è probabile che S vada a guardare

2. permetti ad S di scrivere su O’ 3. permetti a S’ di leggere da O’ 4. copia O su O’

In questo modo, se S utilizza l’applicazione, S’ può ottenere accesso al

contenuto di O, presente in O’. Un Cavallo di Troia è un programma che

fa esattamente questo genere di cose.

2.1 Unix

Descriviamo di seguito gli elementi salienti del controllo degli accessi del

sistema operativo Unix, che, in un certo senso, può essere considerato il

controllo degli accessi discrezionale per antonomasia.

Unix implementa la matrice degli accessi per mezzo delle ACL.

I diritti di accesso agli oggetti sono specificati per utenti e gruppi. Ogni

utente è associato ad un’unica identità ed almeno ad un gruppo. Il gruppo

predefinito è elencato nella definizione dell’utente, presente nel file delle

password /etc/passwd. L’utente può prendere parte ad altri gruppi

inserendo il suo nome nella definizione dei gruppi, presente nel file


21

/etc/groups. Ogni processo ha associate una identità utente reale ed una

identità utente effettiva: quella reale corrisponde all’identità dell’utente che ha

creato il processo, quella effettiva può essere differente da quella reale. Lo

stesso discorso è valido per il gruppo: esistono un gruppo reale ed un gruppo

effettivo. Quando viene creato un processo, gli viene associata la lista di tutti i

gruppi nei quali si trova.

Unix utilizza l’astrazione del filesystem per tutti gli oggetti presenti nel

sistema, quindi è sufficiente qui descrivere i controlli di accesso facendo

riferimento all’accesso ad un file.

Il filesystem di Unix è organizzato come un albero, i cui nodi sono chiamati

directory. Una directory contiene almeno due elementi, uno per se stessa ed

uno per la directory dalla quale discende (quella che la contiene). Inoltre può

contenere elementi per i figli che possono essere un qualsiasi tipo di file

(directory, file regolari o dispositivi). Così come per i processi, anche ai file

vengono associate un’identità utente ed un gruppo. L’identità fa riferimento

al proprietario del file. I permessi di accesso sono specificati tramite 12 bit.

Nove bit sono divisi in tre insiemi da tre: un insieme rappresenta i permessi

per il proprietario, uno quelli per gli appartenenti al gruppo e l’ultimo

insieme rappresenta i permessi globali per tutti gli altri utenti (chiamati

collettivamente “world”). Ognuno dei tre bit in ciascun insieme denota una

specifica modalità di accesso: lettura (r), scrittura (w) o esecuzione (x). Per

esempio, User: rwx, Group: r-x, World: r--, indicano che il proprietario ha

diritti di lettura, scrittura ed esecuzione del file; gli utenti nel gruppo hanno

diritti di lettura ed esecuzione; tutti gli altri utenti, infine, possono solo

leggere il file.

Esistono diverse regole per impostare questi bit. Per il loro cambiamento

esiste un comando apposito chiamato chmod ed un altro comando chiamato

chown permette di cambiare il proprietario e/o il gruppo di un file.


22

Poiché anche le directory sono file (da qui la distinzione fra generici file e

file regolari), il significato dei diritti di accesso è sovraccaricato: il diritto di

lettura per un file regolare permette di vedere il suo contenuto, quello per

una directory permette di elencare i nomi dei file nella directory. In maniera

simile, il permesso di scrittura per un file regolare permette di modificare il

contenuto del file, quello per una directory permette di rinominare, creare o

eliminare file nella directory. Il diritto di esecuzione di un file regolare,

permette ovviamente di eseguire un programma contenuto nel file, mentre

per una directory permette di attraversare la directory, cioè di vedere il

contenuto dei file che la directory contiene, in funzione dei diritti specificati

per i singoli file. Quindi è possibile che sia permesso di leggere un file ma

non il suo nome e viceversa.

I tre bit rimanenti sono chiamati sticky, setuid e setgid.

Lo sticky bit ha due significati: innanzitutto, un programma che abbia lo

sticky bit impostato rimane nell’area di swap dopo la sua terminazione;

inoltre, un file in una directory che abbia lo sticky bit impostato, può essere

cancellato o rinominato solamente dal padrone del file o da quello della

directory contenitrice, in funzione dei diritti di accesso.

setuid e setgid [LPI89] permettono ad un utente, che non sia il

proprietario di un file, di eseguire i comandi nel file con i permessi del

proprietario o, rispettivamente, del gruppo, forzando il cambiamento

dell’identità utente effettiva e del gruppo effettivo a quella del proprietario e

del gruppo del file: un programma che abbia impostato il bit setuid dà

origine ad un processo setuid il quale non viene eseguito con l’identità

effettiva dell’utente che lo ha invocato, ma piuttosto con quella del

proprietario del file da cui è generato il processo, e quindi viene eseguito

con i privilegi di quest’ultimo. Questo meccanismo permette di ottenere un

cambiamento di dominio per un processo, ovvero permette ad un processo


23

di cambiare soggetto durante la propria esecuzione. Il bit setgid lavora

sullo stesso principio, ma è relativo ai gruppi.

Unix ha anche un utente speciale, chiamato root, che può modificare

qualsiasi file quando il sistema è in esecuzione. L’utente root è anche

chiamato superuser. Questa smisurata potenza, assieme al meccanismo

setuid costituisce un’enorme minaccia alla sicurezza del sistema: infatti un

file eseguibile setuid appartenente all’utente root, quando eseguito da un

qualsiasi utente, gira con privilegi totali, come se fosse stato invocato

dall’utente root; questo significa che la compromissione del processo

risultante può rendere completamente vulnerabile l’intero sistema.

La quasi totalità degli attacchi alla sicurezza di sistemi Unix avviene proprio

su applicazioni setuid altamente privilegiate.

2.3 Modelli mandatori

Con il termine controllo degli accessi mandatorio (MAC) intendiamo un

qualsiasi controllo degli accessi che non sia discrezionale. In [CW87]

vengono analizzate le differenze tra le due tipologie, ma non viene utilizzato

il termine mandatorio, quanto piuttosto quello di non discrezionale. In

[LSMTTF98] vengono invece mostrate le motivazioni per le quali al giorno

d’oggi i sistemi operativi devono necessariamente implementare un MAC.

L’idea che c’è alla base è quella di poter associare agli oggetti un’ETICHETTA DI

SICUREZZA che rifletta la sensibilità dell’informazione che essi contengono.

In maniera analoga si può associare ai soggetti un’etichetta che rifletta la

sensibilità delle informazioni che essi possano accedere.

In questo caso il reference monitor confronta le etichette di soggetto ed

oggetto ed autorizza il primo ad accedere al secondo in un determinato


24

modo solo se il risultato del confronto indica che l’accesso sia autorizzato.

L’utilizzo delle etichette di sicurezza permette di definire delle classi di

equivalenza per la sensibilità delle informazioni che gli oggetti contengono e

che i soggetti possono accedere.

Le politiche MAC, al contrario di quelle DAC, possono fornire protezione

sia contro modifiche non autorizzate di informazioni (INTEGRITÀ) sia contro

la loro acquisizione non autorizzata (CONFIDENZIALITÀ).

Si consideri ancora il precedente esempio di Cavallo di Troia e si consideri

una politica MAC volta a garantire la confidenzialità. Poiché viene associata

un’etichetta ad ogni copia dell’oggetto che viene creata e poiché al Cavallo

di Troia non è consentito cambiare le etichette degli oggetti2, il Cavallo di

Troia non può fornire accesso ad alcuna informazione in maniera non

prevista dalla politica di controllo degli accessi.

Di fondamentale importanza è capire che una politica MAC non impedisce

ad un processo, che possa accedere ad un file, di farne una copia, ma gli

impedisce di cambiare l’etichetta del file e ne regola l’accesso su delle basi

globali e persistenti.

Proprio la globalità e la persistenza sono le caratteristiche distintive delle

politiche MAC: globale significa che una particolare informazione ha la

stessa sensibilità (e quindi la stessa etichetta) dovunque essa sia; persistente

significa che tale sensibilità è sempre la stessa. In altre parole le etichette di

soggetti ed oggetti non cambiano.

Perché una politica di controllo degli accessi sia globale e persistente,

l’insieme delle CLASSI DI ACCESSO (o etichette) deve formare quello che in

matematica viene chiamato un INSIEME PARZIALMENTE ORDINATO. Ciò significa

2 Questo è vero per la proprietà di ISOLAMENTO di un reference monitor: assumiamo cioè che

il meccanismo di assegnazione delle etichette agli oggetti sia inviolabile


25

che sull’insieme è definita una relazione chiamata DOMINANZA, rappresentata

tramite ≥: per ogni coppia di membri distinti x e y di un insieme

parzialmente ordinato, x domina y, oppure y domina x, oppure x e y sono

incomparabili.

La relazione di dominanza rispetta tre proprietà:

• riflessività: x ≥ x

• antisimmetria: x ≥ y e y ≥ x implica x = y

• transitività : x ≥ y e y ≥ z implica x ≥ z

con x, y e z appartenenti all’insieme.

Se una qualsiasi delle tre precedenti proprietà non è soddisfatta, la politica di

controllo egli accessi perde la qualità di persistenza o quella di globalità.

Ad esempio, se viene violata la riflessività, può venir meno la proprietà di

persistenza: supponendo di avere due livelli di sensibilità, Public e Sensitive, la

politica “i soggetti Public possono accedere gli oggetti Public tutti i giorni,

tranne il primo di ogni mese” viola la riflessività e non è persistente. La

persistenza può venire meno anche se viene violata l’antisimmetria: la

politica “i soggetti Public possono accedere agli oggetti Sensitive una volta al

mese”3 ne è un esempio. Infine, supponendo di avere un’altra etichetta,

Proprietary, e supponendo che la politica permetta ai soggetti Proprietary di

accedere agli oggetti Sensitive, qualora esistano alcuni oggetti Public non

accessibili a Proprietary, verrebbe violata la proprietà di transitività e la

politica di controllo degli accessi non sarebbe globale.

Una politica di controllo degli accessi che non utilizzi etichette conformi alle

tre proprietà di un insieme parzialmente ordinato per tutti i suoi soggetti ed

3 Si assume, ovviamente, Sensitive ≥ Public, nell’ordinamento delle etichette


26

oggetti, non è una politica di controllo degli accessi mandatoria, di

conseguenza è discrezionale.

Nel prossimo paragrafo, introduciamo un modello ed una politica di

controllo degli accessi mandatoria, basati su un particolare tipo di insieme

parzialmente ordinato, chiamato reticolo.

2.3.1 Modelli LBAC e MLS

Come si è detto, in generale, le politiche MAC governano l’accesso alle

informazioni, sulla base di una classificazione indotta da ETICHETTE DI

SICUREZZA di soggetti ed oggetti. Ad esempio, in ambienti militari, ma anche

civili, si possono avere le seguenti etichette: Top Secret, Secret, Confidential,

Unclassified, con il seguente ordinamento:

Top Secret ≥ Secret ≥Confidential ≥Unclassified

Il controllo degli accessi basato sui reticoli (Lattice Based Access

Control, LBAC), proposto da Bell e LaPadula in [BL73], nato proprio in

ambito militare, impone una direzione al flusso di informazioni all’interno di

un reticolo di etichette di sicurezza. Con il termine reticolo si intende un

insieme parzialmente ordinato L tale che x,y ha estremi superiore ed

inferiore per ogni x e y appartenenti ad L.

LBAC può essere applicato per soddisfare diversi requisiti: confidenzialità,

integrità, confidenzialità ed integrità contemporaneamente, o può essere

utilizzato in politiche di aggregazione, come quella del Muro Cinese ([BN89]).

Un’etichetta attaccata ad un oggetto è chiamata classificazione di

sicurezza, mentre un’etichetta attaccata ad un soggetto è chiamata


27

autorizzazione di sicurezza (security clearance). In generale, un’etichetta

di sicurezza viene chiamata anche livello di sicurezza, o più semplicemente

LIVELLO, indistintamente per i soggetti e per gli oggetti. Un utente al quale è

assegnata una certa etichetta, può eseguire lo stesso programma o al livello

di quell’etichetta, o a qualsiasi livello inferiore nella gerarchia: con

riferimento al precedente ordinamento, un utente a livello Secret può

eseguire lo stesso programma, ad esempio un editor di testi, sia come

soggetto Secret sia come soggetto Confidential o Unclassified. Anche se i tre

soggetti eseguono tutti lo stesso programma a beneficio dello stesso utente,

essi ottengono differenti privilegi, in funzione della loro diversa etichetta di

sicurezza.

Un tipico reticolo per la confidenzialità è mostrato in figura:

Figura 4: esempio di reticolo di confidenzialità; A e B denotano rispettivamente un livello di confidenzialità Alto ed uno Basso. M1 ed M2 sono due livelli medi non comparabili fra loro rispetto alla relazione di dominanza

In questo reticolo, il flusso dell’informazione può fluire solamente dal basso

verso l’alto, perché le regole di accesso mandatorie per il reticolo in

questione sono le seguenti:


28

• Simple Security: il soggetto S può leggere l’oggetto O se e solo se

)()( OS εε ≥

• Liberal *-Property: il soggetto S può scrivere l’oggetto O se e solo

se )()( SO εε ≥

dove con )(Xε si intende l’etichetta di sicurezza di X.

Con riferimento al reticolo di confidenzialità in figura, le regole impongono

le seguenti limitazioni:

• un soggetto a livello A può leggere oggetti ai livelli A, M1, M2 e B,

ma può scrivere solo al livello A

• un soggetto a livello M1 (rispettivamente M2) può leggere oggetti ai

livelli M1 (M2) e B e scrivere ai livelli M1 (M2) ed A

• un soggetto a livello B può scrivere oggetti ai livelli B, M1, M2 e A,

ma può leggere solamente al livello B

Così come per l’esecuzione dei programmi, un utente può entrare nel

sistema al livello di autorizzazione assegnatogli o a un qualsiasi livello di

autorizzazione da esso dominato, quindi un soggetto con autorizzazione A,

può entrare nel sistema sia al livello A che ai livelli M1, M2 o B; un soggetto

con autorizzazione M1 (rispettivamente M2) può entrare al livello M1 (M2)

o B; infine un soggetto con autorizzazione B può entrare nel sistema

solamente al livello B.

Le due regole corrispondono, rispettivamente, ad una imposizione di letture

verso il basso del reticolo (perché l’autorizzazione di un soggetto deve

dominare la classificazione di sicurezza dell’oggetto da leggere) e di scritture

verso l’alto (perché l’autorizzazione di un soggetto deve essere dominata

dalla classificazione di sicurezza dell’oggetto da scrivere).

Il soddisfacimento delle due precedenti regole impedisce che l’informazione

fluisca da oggetti a livelli alti (e quindi contenenti informazioni più sensibili)


29

ad oggetti a livelli più bassi (e quindi più facilmente accessibili) o ad oggetti

a livelli incomparabili. In questo modo la pericolosità di un ipotetico Cavallo

di Troia, come quello precedentemente descritto, viene eliminata.

Dimostrare che questa proprietà viene soddisfatta è semplice: il caso in cui i

livelli di soggetto ed oggetto siano incomparabili è banale, perché i soggetti,

secondo le regole mandatorie, possono solo leggere e scrivere oggetti che

siano a livelli di sicurezza comparabili. Per dimostrare, invece, che il flusso

di informazioni nel reticolo è unidirezionale (verso l’alto) si noti

innanzitutto che l’informazione fluisce solamente se qualcosa viene prima

letto e qualcos’altro viene poi scritto. Si supponga che l’oggetto O sia letto e

che l’oggetto O’ sia scritto. Questa cosa contraddice ciò che dobbiamo

dimostrare solo nel caso in cui )'()( OO εε ≥ . Se un soggetto S può leggere

O, se ne può concludere dalle precedenti regole che )()( OS εε ≥ .

Similarmente, se S scrive O’ se ne può dedurre che )()'( SO εε ≥ . La

relazione di dominanza, come abbiamo visto, è transitiva, quindi se ne

deduce che )()'( OO εε ≥ , come volevasi dimostrare.

Si noti che in un simile reticolo si ha un duplice carattere: i soggetti con

etichette di livello alto nel reticolo hanno più potere rispetto alle operazioni

di lettura ma hanno meno potere rispetto alle operazioni di scrittura. Un

discorso speculare si ha per i soggetti con etichette di livello basso.

La regola di scrittura verso l’alto, corrispondente alla *-Property, può

sembrare a prima vista contraria alle aspettative: un utente che si trovi a

livello Secret non può scrivere ai livelli Confidential e Unclassified, quindi, ad

esempio, non può inviare email ad utenti a questi livelli. Ciò è contrario a

quanto accade nel mondo reale, dove è consueto permettere agli utenti di

livello alto di scrivere, ad esempio, delle note per gli utenti ai livelli più bassi.

In realtà questa apparente contraddizione è facilmente eliminata


30

permettendo ad un utente appartenente ad un certo livello di poter attivare

sessioni ad un qualsiasi livello dominato dal livello di appartenenza: perché

un utente al livello Secret possa inviare un’email ad un utente al livello

Confidential, può entrare nel sistema al livello Confidential, cosa che gli è

permessa perché Secret ≥ Confidential nella gerarchia delle etichette.

La *-Property sopra definita è funzionale nei casi in cui si voglia garantire la

confidenzialità, tuttavia permette a soggetti a livelli di sicurezza bassi di

alterare oggetti a livelli di sicurezza più alti. Per motivi di integrità spesso si

può ricorrere ad una regola *-Property più rigida, per evitare che

informazioni a livelli di sicurezza alti possano essere distrutte

maliziosamente o danneggiate da soggetti appartenenti a livelli di sicurezza

bassi, che paradossalmente non possono leggere quelle informazioni, in

virtù della regola Simple Security. Per quanto detto si può utilizzare, quindi,

la regola:

Strict *-Property: il soggetto S può scrivere l’oggetto O se e solo se

)()( OS εε = .

LBAC fu inizialmente formulato per scopi di CONFIDENZIALITÀ e quindi

storicamente il flusso dell’informazione va verso l’alto. In realtà può essere

facilmente impiegato per scopi di INTEGRITÀ ([Bi77]), semplicemente

invertendo la direzione del flusso delle informazioni. Quanto detto viene

fatto nel reticolo di integrità semplicemente considerando le versioni

complementari delle due regole precedenti:

• Simple Security: il soggetto S può leggere l’oggetto O se e solo se

)()( SO εε ≥

• Liberal *-Property: il soggetto S può scrivere l’oggetto O se e solo

se )()( OS εε ≥


31

Sono quindi consentite solamente le letture verso l’alto (il livello di integrità

del soggetto deve essere dominato dal livello di integrità dell’oggetto da

leggere) e scritture verso il basso (il livello di integrità del soggetto deve

dominare il livello di integrità dell’oggetto da scrivere).

In alternativa si possono anche prendere in considerazione altri approcci,

come quello in [Sa93], che consiste nell’invertire i livelli nel reticolo, in

maniera tale da preservare le regole di accesso mandatorio ed il flusso

dell’informazione verso l’alto.

Come è evidente, l’essenza di questo tipo di controlli mandatori è che si ha

un flusso di informazioni unidirezionale all’interno di un reticolo di etichette

di sicurezza.

I reticoli hanno una proprietà matematica particolarmente utile: due reticoli

possono essere combinati in un reticolo composito. Questo permette, ad

esempio, di ottenere un unico reticolo combinato per garantire allo stesso

tempo sia la confidenzialità sia l’integrità.

Un possibile problema nella combinazione dei reticoli di confidenzialità ed

integrità, o di più reticoli in generale, è che essi possono utilizzare differenti

versioni della *-Property: in particolare, quelli relativi alla confidenzialità

tendono ad usare la sua versione più rigida.

I sistemi MLS (Multi-Livel Security) aggiungono, oltre ai livelli di sicurezza

gerarchici, il concetto di categoria. Una categoria per un utente indica una

specifica area nella quale egli operi. Una categoria per un oggetto indica

l’area alla quale fa riferimento l’informazione contenuta in esso. Ai soggetti

e agli oggetti possono essere associate più categorie.


32

Figura 5: due reticoli indipendenti (a sinistra) combinati in un unico reticolo composito (a destra); AC indica un livello di Alta Confidenzialità; allo stesso modo, BC Bassa Confidenzialità, AI Alta Integrità e BI Bassa Integrità. Si assume che in entrambi i reticoli a sinistra l’informazione fluisca verso l’alto; la stessa cosa avviene per il reticolo composito a destra

Il concetto stesso di categoria non è molto diverso da quello di semplice

etichetta di sicurezza, e serve semplicemente ad aumentare la granularità dei

controlli.

Con linguaggio militare, nel cui ambito i sistemi MLS hanno avuto molto

successo, le categorie realizzano una restrizione sull’accesso alle

informazioni, in base del principio del “need to know”: ad un soggetto

dovrebbero essere garantiti solamente quegli accessi che sono richiesti per

portare a termine i propri compiti. Ad esempio, ad un dato soggetto

potrebbe essere assegnata un’etichetta di sicurezza di livello Top Secret per

quanto riguarda informazioni cifrate, ma si potrebbe volere che egli abbia

un’etichetta di livello solamente Sensitive per quanto riguarda le informazioni

riguardanti le armi nucleari. Il principio precedente, al di fuori degli ambienti

militari, è quello che abbiamo precedente chiamato PRINCIPIO DEI PRIVILEGI

MINIMI.


33

Figura 6: esempio di reticolo in un sistema MLS; ad ogni oggetto è associato un insieme di categorie (ad esempio, cripto e nuclear) e il controllo degli accessi viene fatto in base alla classificazione di sicurezza degli oggetti e alle loro categorie

2.3.2 Modello RBAC

La letteratura riguardo il controllo degli accessi basato sui ruoli (Role

Based Access Control, RBAC) è molto ricca: [FK92, Sa98] descrivono il

modello, [K97, NO99, SM98, SZ97] mostrano come mediante RBAC sia

possibile realizzare alcuni principi alla base della sicurezza dei sistemi,

[SCFY96] formalizza un serie di modelli che realizzano RBAC e [Sa98,

CL03] mostrano come sia possibile amministrare RBAC.

Noi qui introduciamo i concetti fondamentali di RBAC, in particolare quelli

che poi saranno utili nel seguito della tesi.

La nozione centrale di RBAC è quella di ruolo. Un ruolo è un costrutto

semantico, attorno al quale viene formulata una politica di controllo degli

accessi. Ad un ruolo vengono associati da una parte dei PERMESSI, dall’altra

degli UTENTI: gli utenti assegnati ad un ruolo R, che attivano quel ruolo,

hanno i permessi associati ad R.


34

I ruoli possono essere creati per le varie funzioni lavorative all’interno di

un’organizzazione: per ogni funzione lavorativa, infatti, può essere definito

un insieme di permessi necessari affinché la funzione possa essere svolta;

inoltre gli utenti sono assegnati ai ruoli in base alle proprie responsabilità,

qualifiche ed attività svolte all’interno dell’organizzazione.

In RBAC esistono tre insiemi di entità, chiamate UTENTI (U), RUOLI (R) e

PERMESSI (P). Un utente è un astrazione che rappresenta un essere umano.

Il concetto può essere generalizzato per includere agenti software intelligenti

automatici, reti di computer ecc… Un ruolo è una funzione lavorativa, o un

titolo all’interno di un’organizzazione, con un qualche significato associato,

che rappresenti la responsabilità e l’autorità conferita ai membri del ruolo.

Un permesso indica la capacità di accedere ad uno o più oggetti del sistema

in un determinato modo. In letteratura, alcune volte si trovano come

sinonimi di permesso i termini DIRITTO DI ACCESSO o PRIVILEGIO; altre volte si

distingue: i diritti di accesso e i privilegi costituiscono le MODALITÀ DI ACCESSO

(ad esempio lettura e scrittura) e i permessi sono intesi come la combinazione

di un oggetto ed un diritto di accesso. I permessi sono sempre positivi e

conferiscono la possibilità a chi li possiede di agire in un determinato modo

all’interno del sistema.

Esistono poi due relazioni molti a molti, chiamate assegnamento di utenti

(User Assignment, UA) e assegnamento di permessi (Permission

Assignment, PA). La prima specifica che un utente può essere membro di

più ruoli e ad un ruolo possono essere assegnati più utenti. La seconda, in

maniera simile, specifica che un permesso può competere a più ruoli e che

un ruolo può garantire più permessi.


35

Figura 7: Il modello di controllo degli accessi basato sui ruoli nella sua forma più generale; le frecce continue singole indicano una relazione 1 a molti, quelle doppie una relazione molti a molti; i ruoli possono essere organizzati all’interno di differenti gerarchie, più utenti possono essere assegnati a più ruoli, più permessi possono essere assegnati a più ruoli, gli utenti possono attivare più sessioni contemporaneamente, ma ogni sessione appartiene ad un solo utente; infine è possibile imporre dei vincoli su tutti gli elementi del modello

Il cuore di RBAC si trova in PA ed in UA: un ruolo non è altro che un

intermediario che permette agli utenti di esercitare i propri permessi.

Un’associazione di un utente a uno o più ruoli è chiamata sessione: un

utente inizia una sessione durante la quale può attivare un qualche

sottoinsieme dei ruoli di cui è membro. Possono essere attivati più ruoli

simultaneamente, e i permessi disponibili per l’utente sono quelli nell’unione

dei permessi associati a tutti i ruoli attivati durante la sessione. Una sessione

è associata ad un singolo utente, che non può cambiare durante la sessione,

ma un singolo utente può attivare più sessioni contemporaneamente, a

meno che la configurazione dei vincoli non lo vieti4.

Questa possibilità permette di realizzare il PRINCIPIO DEI PRIVILEGI MINIMI: un

utente che è membro di differenti ruoli può attivare uno qualsiasi dei 4 In realtà quanto detto sulle sessioni è solo una delle molte alternative. In letteratura si

trovano differenti versioni e vincoli all’attivazione di ruoli e sessioni, e diversi sistemi reali

utilizzano diversi approcci


36

sottoinsiemi di questi, che gli permetta di realizzare il compito da svolgere.

In particolare può attivare la combinazione di ruoli meno potente fra tutte

quelle che gli permettano di svolgere il proprio compito.

In generale, in RBAC è a completa discrezione dell’utente decidere quali

ruoli attivare all’interno di una sessione. Come si può notare, il concetto di

sessione equivale a quello tradizionale di SOGGETTO. Il principio dei privilegi

minimi, tuttavia, si realizza solamente se l’utente esercita una certa disciplina

rispetto ai ruoli che possa attivare: l’attivazione della combinazione di ruoli

meno potente fra tutte quelle che permettano di realizzare il compito non è

automatica, ma deve essere operata espressamente dall’utente.

I ruoli possono essere organizzati all’interno di gerarchie. Le gerarchie di

ruoli sono un modo molto naturale e comune di strutturare i ruoli per

riflettere le linee di responsabilità ed autorità all’interno di una

organizzazione. Due ruoli all’interno di una gerarchia sono tali che, o sono

incomparabili, o uno eredita le caratteristiche dell’altro (permessi ed utenti)

e ne aggiunge di nuove: il ruolo che eredita è detto ruolo senior, quello

ereditato ruolo junior. Matematicamente le gerarchie sono degli

ordinamenti parziali e quindi sono relazioni riflessive, antisimmetriche e

transitive. Qualora esista una gerarchia di ruoli, un utente può iniziare una

sessione con una qualsiasi combinazione di ruoli junior di quelli dei quali

l’utente è membro: i permessi sono quelli associati ai ruoli attivati nella

sessione e a tutti i loro ruoli junior.


37

Figura 8: esempio di gerarchia di ruoli relativo ad un progetto; C1, C2, C3 e C4 sono quattro ruoli relativi ad altrettanti compiti; ognuno eredita i permessi da un generico ruolo P, contenente i permessi minimi per appartenere al progetto; il ruolo S è relativo al supervisore del progetto; C3 e C4 sono compiti che vanno svolti all’interno di un sottoprogetto, che ha S3 come supervisore e P3 come ruolo generico nel sottoprogetto

In RBAC esiste anche il concetto di vincoli. I vincoli si applicano ai diversi

aspetti di RBAC e sono una delle sue maggiori potenzialità: ad esempio,

mediante la configurazione dei vincoli, è possibile imporre che due ruoli

siano mutuamente disgiunti, cosa che riflette la reale struttura di molte

organizzazioni, all’interno delle quali ad uno stesso individuo non è

permesso di svolgere due particolari funzioni, onde evitare la possibilità di

commettere una frode5. I ruoli mutuamente disgiunti permettono di

5 Un esempio classico che si trova in letteratura è quello relativo alla creazione ed

approvazione di ordini di acquisto: se i due compiti vengono svolti da una stessa persona è

facile che questa venga tentata di commettere una frode; al contrario se sono assegnati a

due persone differenti, l’eventuale frode richiede l’intervento e la cospirazione di almeno

due individui e quindi è più improbabile.


38

realizzare quello che nell’ambito della sicurezza è chiamato principio della

separazione delle mansioni (separation of duty).

I vincoli sono dei predicati che, applicati alle relazioni PA e UA e alle

sessioni, ritornano il valore accettabile o non accettabile. Essi possono anche

essere visti come costrutti di qualche appropriato linguaggio formale, come

ad esempio quelli in [TJ00b, JT01]. Vincoli che ragionevolmente possono

essere di particolare importanza sono, ad esempio, i seguenti:

• ruoli mutuamente esclusivi: lo stesso utente può essere assegnato al più

ad uno dei ruoli all’interno di un insieme di ruoli mutuamente

esclusivi

• permessi mutuamente esclusivi: lo stesso permesso può essere assegnato

al massimo ad uno dei ruoli all’interno di un insieme di ruoli

mutuamente esclusivi

• vincoli di cardinalitá: ad esempio si può imporre che un ruolo abbia un

massimo numero di membri o che sia limitato il numero di ruoli ai

quali un utente possa essere assegnato, o, ancora, che un permesso

possa essere assegnato solamente ad un numero massimo di ruoli

• ruoli prerequisiti: ad esempio si può imporre che un utente possa

essere assegnato ad un ruolo A solo se è già assegnato ad un ruolo

B; un vincolo simile può essere imposto anche sui permessi

• vincoli sulle sessioni: un utente può essere membro di due ruoli ma si

può imporre che non sia possibile per esso attivarli

contemporaneamente.

[K97, NO99, SZ97] forniscono delle tassonomie dei vincoli relativi a due

principi molto presenti nella letteratura relativa a RBAC, la separazione dei

ruoli e il conflitto di interessi; [JT01] armonizza le differenti tassonomie.


39

Volendo, è possibile considerare una gerarchia di ruoli come un vincolo che

imponga che un permesso assegnato ad un ruolo junior J debba essere

assegnato anche a tutti i ruoli senior di J e che un utente assegnato ad un

ruolo senior S debba anche essere assegnato a tutti i ruoli junior di S.

I permessi di modificare U, P, R, PA e UA sono chiamati permessi

amministrativi e la loro gestione compete alle politiche di amministrazione

del sistema. Le politiche di amministrazione stabiliscono chi sia autorizzato

a modificare la politica di controllo degli accessi. In sistemi MLS, si è visto,

gli accessi consentiti sono determinati interamente sulla basi della

classificazione di sicurezza di soggetti ed oggetti. I LIVELLI DI SICUREZZA degli

utenti sono assegnati dall’amministratore di sicurezza e quelli degli oggetti

sono determinati dal sistema sulla base dei livelli degli utenti creatori.

L’amministratore di sicurezza è in generale uno solo e la politica di sicurezza

è pertanto molto semplice.

RBAC permette la specifica di molte politiche amministrative. Una delle sue

maggiori potenzialità è che questo può avvenire per mezzo dello stesso

concetto di RUOLO che è alla base del controllo degli accessi. In altre parole,

una volta modellato RBAC è possibile estendere in maniera minima il

modello per includere coerentemente la gestione ed il controllo dei

meccanismi amministrativi. Tuttavia questa operazione può essere molto

complessa ed i modelli proposti in letteratura non sembrano ancora

sufficientemente maturi ([Sa98]).

Infine una piccola nota sulla generalità del modello. Si è detto che RBAC è

neutrale rispetto alla politica di controllo degli accessi. RBAC, infatti,

fornisce una serie di caratteristiche per articolare una politica piuttosto che

inglobarne una particolare. La politica realizzata all’interno del sistema è il


40

risultato della precisa configurazione ed interazione dei vari componenti.

LBAC, al contrario, è stato costruito specificatamente per incorporare una

particolare politica per ottenere un flusso di informazioni unidirezionale

all’interno di un reticolo di etichette di sicurezza. Una delle caratteristiche

veramente vantaggiose di RBAC, legata alla sua neutralità rispetto alla

politica, è che esso possa essere configurato per simulare LBAC o, in altri

termini, LBAC non è altro che una particolare istanza di RBAC. Quindi uno

stesso sistema può essere configurato per imporre RBAC in generale ed

LBAC in particolare. Del resto le nozioni di RUOLO, alla base di RBAC e di

LIVELLO DI SICUREZZA, alla base di LBAC, sono molto simili.

In maniera simile RBAC può essere configurato per simulare i più comuni

modelli DAC. Per l’esatta configurazione di RBAC per ottenere LBAC o

DAC si vedano [Sa98, SM98].

RBAC, come visto, è molto potente ma è anche estremamente complesso.

Molti prodotti supportano qualche forma di RBAC direttamente, altri

supportano concetti correlati, come quello di gruppo di utenti, che possono

essere utilizzati per implementare i ruoli. L’utilizzo amministrativo dei ruoli

si trova anche in sistemi operativi di rete moderni, come NetWare® di

Novell e Windows NT® di Microsoft. Nel capitolo seguente, quando

tratteremo nel dettaglio il sistema SELinux, vedremo come esso utilizzi un

concetto molto semplificato di RBAC.

2.3.3 Modelli TE e DTE

Il Type Enforcement (TE) è l’ultimo modello MAC che prendiamo in

considerazione, ed è quello che sarà di maggiore importanza nel seguito

della tesi.


41

Il TE è una forma di controllo degli accessi orientato alle tabelle che risale

agli anni ’80, introdotto in [BK85] e rifinito in [OR91], che solo oggi sta

acquistando importanza nell’ambito dei sistemi operativi sicuri. In [TH90]

viene fornito un interessante confronto fra il TYPE ENFORCEMENT ed il

meccanismo setuid di Unix.

Il Type Enforcement è stato implementato inizialmente nel progetto Secure

Ada (LOCK) ed in seguito in Trusted Xenix [Age]. Secure Computing lo

utilizza tuttora nel suo prodotto, un firewall chiamato Sidewinder [Com].

Il concetto alla base del TE è quello classico dei modelli MAC: gli spazi

degli oggetti e dei soggetti vengono partizionati in classi di equivalenza; le

classi di equivalenza dello spazio degli oggetti sono chiamate tipi, quelle

dello spazio dei soggetti domini6. Tutti gli oggetti con un dato tipo hanno

una semantica comune nel sistema, mentre tutti i soggetti che appartengono

ad un dato dominio hanno gli stessi privilegi.

La Tabella di Definizione dei Domini (Domain Definition Table, DDT)

rappresenta quali operazioni i soggetti in uno specificato dominio possono

fare su oggetti di un particolare tipo; rappresenta quindi le interazioni

possibili tra domini e tipi e quindi fra soggetti ed oggetti. Ogni riga della

tabella è associata ad un dominio, ogni colonna ad un tipo ed ogni elemento

indica quali diritti di accesso un soggetto ha su un oggetto. Le decisioni di

controllo degli accessi di soggetti ad oggetti si basano su semplici ricerche

nella tabella: quando un soggetto vuole accedere ad un oggetto in un

determinato modo, si seleziona la riga corrispondente al dominio del

6 Si noti che il termine è coerente con il concetto di DOMINIO DEI SOGGETTI delle matrici di

accesso.


42

soggetto, la colonna corrispondente al tipo dell’oggetto e si verifica che

l’elemento della DDT identificato contenga la modalità di accesso richiesta.

Sysbin Usrbin Readable Writeable Syslog Passwd Browser

Daemon RXT RT RWT RT RT

System RT RWT RWT

Syslog RT RWT RWT

Login RT RT RT RWT RT R

User RXT RXT RWXT RWT RT R RT

Passwd RXT RXT RT RWT RW

Admin RXT RWXT RWXT RWT RWT R RWT

Security RWXT RWT RWT RWT RWT RW

Browser RXT RXT RT RWT R RWT

Figura 9: Esempio di DDT; sulle righe compaiono i nomi dei domini nei quali rimangono confinati i soggetti, sulle colonne quelli dei tipi associati agli oggetti; i diritti di accesso sono quelli di lettura (R), scrittura (W), esecuzione (X) e attraversamento di directory (T)

Come si può vedere la DDT ed una generica matrice degli accessi sono

molto simili; la DDT risulta essere semplicemente di dimensioni in generale

più piccole, dovute al raggruppamento in classi di equivalenza di soggetti ed

oggetti.

La vera novità del TE è la Tabella di Interazione dei Domini (Domain

Interaction Table, DIT), che stabilisce le interazioni fra domini specificando

quali azioni un soggetto in un dominio possa fare su un soggetto in un altro

dominio (ad esempio l’invio di segnali fra processi); risulta qui

estremamente chiaro perché l’insieme dei soggetti venga in genere

considerato un sottoinsieme degli oggetti. I soggetti che si trovano in un

dominio corrispondente ad una data riga della DIT possono trasferire il

controllo ai soggetti in domini per i quali il corrispondente elemento della


43

DIT autorizzi il trasferimento. Le interazioni possibili fra i domini sono

l’invio di segnali fra i soggetti (ad esempio i segnali standard tra i processi di

sistemi operativi come UNIX) e la specificazione della possibilità di

MIGRAZIONE (o TRANSIZIONE) DEI DOMINI: qualora sia specificato nell’apposito

elemento della DIT, un soggetto che viene eseguito in un determinato

dominio può migrare in un altro dominio durante la sua esecuzione, e al

cambiamento di dominio, in generale, corrisponde un cambiamento di

privilegi che il processo possiede. Questa caratteristica rende possibile la

realizzazione del PRINCIPIO DEI PRIVILEGI MINIMI: migrando di dominio ad un

processo possono essere garantiti sempre e solo i diritti di accesso che gli

sono necessari per svolgere il proprio compito, in ogni momento della sua

durata.

Daemon System Syslog Login User Passwd Admin Security Browser

Daemon CS C C C

System CS

Syslog S

Login S C C C

User C CS C

Passwd CS

Admin S C C CS

Security CS

Browser CS

Figura 10: Esempio di DIT; sia sulle righe sia sulle colonne compaiono i nomi dei domini nei quali restano confinati i soggetti; i diritti specificati sono quelli di invio segnali (S) e di creazione di soggetti (C), corrispondente alla possibilità di migrare di dominio

Se la DDT e la DIT sono definite staticamente, ovvero non possono essere

manipolate durante la vita del sistema, il TE fornisce più protezione dei

metodi che lasciano alla discrezione dell’utente la decisione sugli accessi

garantiti. Inoltre DDT e DIT possono essere configurate staticamente da un

amministratore per soddisfare specifici requisiti di sicurezza: se le tabelle


44

sono statiche i requisiti di sicurezza specificati sono sempre soddisfatti (nel

prossimo paragrafo, in virtù di ciò diremo che il TYPE ENFORCEMENT è SAFE).

Quindi il TE può essere usato per realizzare politiche MAC diverse da

quelle basate sui reticoli: in realtà il TE e le sue varianti, al pari di modelli

come RBAC, risulta essere neutro rispetto alla politica.

Anche se il TE risulta essere molto flessibile, le tabelle per il controllo degli

accessi tendono ad essere troppo complesse per cui il modello risulta

difficile da usare nella pratica. Per questo motivo sono nate numerose

varianti del TE; l’ultima e la più interessante è il sistema SELinux che è

l’argomento principale di questa tesi.

Un altro sistema di particolare interesse è il Domain and Type

Enforcement (DTE), una tecnologia di controllo degli accessi derivata dal

TE e sviluppata per i sistemi Unix, BSD e Linux ([WEB-DTE]). Nel DTE il

controllo degli accessi è fatto nella maniera usuale del TE: un DOMINIO viene

associato a ciascun processo ed un TIPO a ciascun oggetto. Durante la vita

del sistema, un sottosistema del DTE a livello di kernel confronta il

dominio del processo con il tipo dell’oggetto (o con il dominio del soggetto)

che si vuole accedere. Il sottosistema DTE rifiuta l’accesso all’oggetto

qualora il dominio del processo richiedente non includa un diritto di accesso

a quel tipo nella richiesta modalità.

Il DTE restringe l’accesso dei processi, anche a quelli di proprietà

dell’utente root o di tipo setuid, ed opera in aggiunta ai bit di protezione

standard di Unix. La grande differenza con il TE standard si ha nel fatto che

nel DTE le politiche di controllo degli accessi vengono specificate per

mezzo di un linguaggio di alto livello chiamato DTEL, creato

appositamente per riutilizzare ed adattare configurazioni di controllo degli

accessi precedentemente ingegnerizzate. DTEL fornisce i costrutti per

definire i tipi degli oggetti (le classi di equivalenza dei dati) e i domini dei


45

soggetti (le classi di equivalenza dei processi). È possibile specificare nel

costrutto relativo ad un dominio il suo punto di ingresso7 (ENTRYPOINT),

ovvero il programma che deve essere eseguito affinché un processo venga

confinato nel dominio; inoltre, tramite lo stesso costrutto, vengono

specificati i diritti di accesso che si hanno sui tipi precedentemente dichiarati

e le eventuali modalità di transizione di dominio. La semantica della

transizione di domini è in qualche modo differente da quella del TE

classico: le transizioni possono essere sia automatiche che volontarie: nel caso di

transizioni automatiche, all’invocazione del programma entrypoint per un

dominio, un processo viene forzatamente spostato in tale dominio, mentre

se la transizione è volontaria, questo avviene solamente se il processo lo

richiede (mediante l’invocazione di apposite funzioni di librerie che sono

state aggiunte al kernel del sistema).

Si è già detto per il TE che il supporto al PRINCIPIO DEI PRIVILEGI MINIMI risiede

nella possibilità per i processi di effettuare le transizioni di dominio. In

DTE una transizione di dominio avviene all’esecuzione dei programmi.

Quindi in DTE è perfettamente definito il modo in cui avvengono le

transizioni di dominio per mezzo di un costrutto sintattico del suo

linguaggio di configurazione (quello relativo alla definizione dei domini).

Inoltre, lo stesso costrutto collassa in un’unica rappresentazione le matrici

DDT e DIT proprie del TE.

Per una dettagliata descrizione di tutti i costrutti del linguaggio DTEL e di

come DTE possa rendere più sicuro il sistema Unix, sono di particolare

interesse [BSSWH95a, BSSWH95b, WSBPSO96].

7 un dominio può avere anche più di un punto di ingresso


46

IL DTE, così come il TE, viene configurato staticamente. È possibile

tuttavia trovare modelli e metodi per una sua configurazione dinamica

([TP97]).

2.4 Il problema della safety

Chiudiamo questo capitolo con una breve discussione relativa ad una

proprietà dei modelli di controllo degli accessi molto importante, chiamata

SAFETY.

Il filone di studi e ricerche relativi alla proprietà di safety dei sistemi di

protezione inizia negli anni settanta, con [HRU76], ed è tuttora in corso.

In [HRU76] viene preso in considerazione un sistema di protezione molto

semplice, noto in letteratura come modello HRU, in cui una configurazione è

rappresentata da una terna (S,O,P), dove S è l’insieme dei soggetti, O quello

degli oggetti e P è una matrice degli accessi. HRU è dotato di una serie di

regole che permettono di passare da una configurazione ad un’altra,

descrivendo quindi i suoi comportamenti dinamici; chiamiamo l’insieme di

tali regole SCHEMA DI AUTORIZZAZIONE. Uno schema di autorizzazione è

formato da una serie di comandi che hanno una parte condizionale ed un

corpo: la parte condizionale specifica i diritti che si richiede siano garantiti

prima che il corpo sia eseguito con i parametri specificati. Il corpo consiste

di una sequenza di operazioni primitive che permettono di inserire o

eliminare un diritto da una cella della matrice degli accessi e di creare e

distruggere una nuova riga o una nuova colonna. Ad esempio, considerato

un tradizionale sistema DAC, in cui ogni soggetto sia un processo, ogni

oggetto diverso da un soggetto sia un file e i diritti di accesso ai file siano

own (per esprimere la proprietà), read, write ed execute, i comandi dello schema


47

di autorizzazione che possono essere eseguiti dai processi potrebbero essere

i seguenti:

CREAZIONE DI UN FILE DA PARTE DI UN PROCESSO; IL PROCESSO CREATORE DIVENTA PROPRIETARIO DEL FILE: command CREATE(process, file)

create object file

enter own into (process,file)

end

CONFERIMENTO DI DIRITTI DI ACCESSO AL FILE; SOLO IL PROPRIETARIO PUÒ EFFETTUARE

QUESTA OPERAZIONE; IL DIRITTO PUÒ ESSERE read, write o execute: command CONFER(owner,r,friend,file)

if own in (owner,file)

then enter r into (friend,file)

end REVOCA DI UN DIRITTO DI ACCESSO AD UN FILE; SOLO IL PROPRIETARIO DI UN FILE PUÒ

EFFETTUARE QUESTA OPERAZIONE; IL DIRITTO PUÒ ESSERE read, write o execute: command REMOVE(owner,r,exfriend,file)

if own in (owner,file) and r in (exfriend,file)

then delete r from (exfriend,file)

end

Nella sua forma più semplice il PROBLEMA DELLA SAFETY chiede se, a partire

da una data configurazione, ne esista una raggiungibile nella quale un

particolare soggetto possieda un dato privilegio su un dato oggetto.

In un’altra formulazione, ci si chiede se, data una matrice degli accessi

iniziale, esiste una qualche sequenza di comandi appartenenti allo schema di

autorizzazione che permetta di inserire un particolare diritto in una cella

della matrice nella quale esso non esista.


48

Svincolando la definizione dai modelli DAC, più in generale, si può dire che

una configurazione di una politica di controllo degli accessi è detta safe se

essa ed ogni configurazione che può essere derivata da essa, per mezzo delle

azioni dei soggetti, non permettono la cessione di un permesso ad un

soggetto non autorizzato.

In [HRU76] è dimostrato che in generale non è possibile decidere il

problema della safety. In realtà è dimostrato che non esiste un singolo

algoritmo che possa decidere la safety per tutti i sistemi di protezione, né c’è

la possibilità che per ogni sistema di protezione sia possibile trovare un

particolare algoritmo che posa farlo. Tuttavia possono esistere casi speciali

di sistemi di protezione nei quali la safety sia decidibile; ma, pur se è

possibile fornire differenti algoritmi per differenti classi di sistemi, non si

può sperare di coprire tutti i sistemi con un numero finito, o anche infinito,

di essi. Il problema è che i sistemi per i quali sia possibile decidere la safety,

possono avere funzionalità troppo ridotte e quindi essere nella pratica

inutili, oppure la dimostrazione della decidibilità può essere esageratamente

difficile.

Con il modello HRU si aprì un filone di ricerca e di studi finalizzati

all’identificazione di classi sempre più grandi di sistemi di protezione per i

quali la safety fosse decidibile e trattabile.

In realtà esistono due differenti approcci al trattamento del problema. Il

primo prevede la restrizione della potenza espressiva dei modelli;

ovviamente se si riduce troppo tale capacità, il modello risultante non è

particolarmente utile: per esempio, come mostrato proprio in [HRU76], si

può effettuare una decisione sulla safety nel caso si abbia uno schema di

autorizzazione che preveda solamente comandi monooperazionali (nei quali

la parte condizionale può essere arbitrariamente complessa, ma il corpo


49

consiste nell’invocazione di una sola primitiva), ma un simile sistema è del

tutto inutile nella pratica. Altri esempi si hanno quando il numero di soggetti

sia finito ([LS78]) o quando siano coinvolte solamente trasformazioni

monotone, cioè tali che non sia possibile la revoca di diritti di accesso

([SG92]). Anche il modello Take-Grant, presentato in [LS77] permette

un’analisi della safety efficiente, ma ha un potere espressivo veramente

limitato.

Una classe di sistemi sicuramente più potente di quelli citati, ma la cui

dimostrazione della decidibilità della safety si basa sempre sulla riduzione

del modello, è quella presente in [KMP02]. Citiamo, infine, i lavori presenti

in [Sa88, Sa92], relativi a modelli monotoni con una forte proprietà di

safety.

In realtà l’approccio di definire modelli di controllo degli accessi limitati non

è più ultimamente molto seguito, a causa del fatto che per ottenere una

sufficiente potenza espressiva per un utilizzo pratico, la dimostrazione della

proprietà diventa esageratamente complessa sia a livello concettuale che

algoritmico. Per questo motivo la ricerca attualmente è più orientata verso il

trattamento del problema mediante la definizione di linguaggi di VINCOLI, che

permettano, anziché dimostrare la safety in sé, di definire una tecnica per

mantenere dinamicamente un’invariante che la garantisca. Ciò è importante

perché i controlli dell’invariante a tempo di esecuzione sono in genere

trattabili, laddove equivalenti prove statiche potrebbero essere intrattabili.

Esempi di questo secondo tipo di approccio al problema si hanno in [TP98,

AS00], che riguardano, rispettivamente modifiche ai modelli TE e RBAC.

Tuttavia, anche questo approccio soffre di notevoli problemi, soprattutto a

causa del fatto che i linguaggi proposti finora sembrano essere carenti o di

semplicità o di potere espressivo. Una delle più promettenti tecniche di

espressione di vincoli è quella presentata in [TJ00a, TJ00b, JT01], che

specifica un modello di controllo degli accessi grafico nel quale i vincoli


50

sono definiti utilizzando un piccolo numero di insiemi e tipi di relazioni. Il

modello permette di esprimere un’ampia varietà di vincoli presenti in

letteratura e, data la loro rappresentazione, è possibile valutare

empiricamente se e come il modello di controllo degli accessi grafico

semplifichi la realizzazione della safety.

Sistemi MAC tradizionali, come LBAC o TE sono safe per definizione,

semplicemente perché non hanno uno SCHEMA DI AUTORIZZAZIONE: essi

permettono infatti solamente la specifica di politiche statiche, quelle che

vengono fissate una volta sola per tutta la vita del sistema, da un ristretto

numero di individui completamente fidati (gli amministratori di sicurezza).

Loro modifiche, anche minime, tuttavia, introducono diversi problemi

relativi alla safety: ad esempio, il modello presentato in [LDSHS90]

generalizza LBAC permettendo ad alcuni individui di poter effettuare

cambiamenti all’assegnamento dietichette di soggetti ed oggetti.

Chiaramente, tali cambiamenti corrispondono ad uno schema di

autorizzazione non vuoto. In questo caso o tali individui sono considerati

completamente fidati oppure è necessario verificare la safety delle

configurazioni alle quali possono dare origine. Anche altri modelli MAC, nei

quali è possibile specificare politiche dinamiche, soffrono dello stesso

problema: in RBAC, ad esempio, gli amministratori di sicurezza possono

operare, durante la vita del sistema, cambiamenti nelle relazioni UA e PA

che si traducono in un cambiamento dei permessi attribuiti ai soggetti. Il

fatto tuttavia che il modello permetta di organizzare gli amministratori

all’interno di gerarchie, tende a far escludere la possibilità che essi possano

essere considerati come individui completamente fidati e quindi non si può

assumere che la safety sia decidibile in generale (sebbene esistano casi

particolari in cui lo sia, [KMP02]).


51

Nei prossimi tre capitoli verrà preso in esame il sistema SELinux.

Anticipiamo qui solamente che SELinux permette la specifica di politiche

MAC statiche, nelle quali l’amministratore di sicurezza assegna le etichette ai

soggetti e agli oggetti e configura la politica di sicurezza una volta sola,

fissandola per tutta la vita del sistema. Il problema della safety di una

configurazione, quindi, non si pone, perché la politica è automaticamente

safe. Tuttavia si pone un importante problema pratico: quello di scrivere

configurazioni che garantiscano veramente un aumento della sicurezza del

sistema rispetto a proprietà quali ad esempio la CONFIDENZIALITÀ e l’INTEGRITÀ.

In altre parole, dire che una politica è safe, di per sé, non garantisce che il

sistema che realizzi quella politica sia sicuro rispetto a potenziali attacchi ad

esso sferrati. Un sistema con una politica safe, qualora malconfigurato, può

essere benissimo vulnerabile. Per questo motivo è buona regola non

considerare l’amministratore di sicurezza completamente fidato. Il fatto di

non considerare completamente fidato l’amministratore di sicurezza non

significa che esso agisca necessariamente in maniera maliziosa.

Semplicemente, come vedremo, la configurazione di SELinux è

un’operazione estremamente complessa, quindi si rende necessario che sia

assistita da modelli formali e tool di analisi, che verifichino esattamente cosa

una data configurazione permetta di fare nel sistema. Il problema con il

quale ci scontreremo è quindi un problema di accessibilità di soggetti ad

oggetti.

Capitolo III: Controllo degli accessi mandatorio in SELinux

52

C a p i t o l o 3

Controllo degli accessi mandatorio in SELinux

Dopo aver introdotto i concetti fondamentali relativi alle politiche di

controllo degli accessi ed aver visto i caratteri distintivi dei più importanti

modelli presenti in letteratura, descriviamo in questa sezione un’architettura

di sicurezza chiamata Flask, che permette di realizzare diverse politiche,

essendo neutra rispetto ad esse, e la sua implementazione nel sistema

operativo Linux. Il prodotto risultante ha il nome di Security Enhanced Linux,

conosciuto più brevemente come SELinux.

3.1 Architettura Flask e sistema SELinux

Nel 1992 e 1993, i ricercatori della National Security Agency americana

(NSA) e quelli della Secure Computing Corporation (SCC) lavorarono al

progetto e all’implementazione di Distributed Trusted Mach (DTMach,

[FM93]), un sistema che si basa sui progetti TMach ([BTMD89]) e LOCK

([SBL89]). DTMach integra una variante del TYPE ENFORCEMENT. Il progetto

DTMach continuò nel progetto Distributed Trusted Operation System (DTOS,

[Mi95, OFSS96, SSC97]). Al completamento di DTOS, NSA, SCC ed il

gruppo di ricerca Flux dell’Università dell’Utah si unirono per trasferire

l’architettura di sicurezza di DTOS nel sistema operativo Fluke [FHLMT99].

Durante la sua integrazione in Fluke, l’architettura venne potenziata e prese

il nome di Flask. Negli ultimi anni la NSA ha implementato Flask nel


53

sistema operativo Linux8 ed il prodotto finale ha preso il nome di Security

Enhanced Linux, o più brevemente SELinux. Altri contributi al progetto

sono derivati da NAI Labs, SCC e MITRE. SELinux è scaricabile

all’indirizzo web [WEB-SELinux] assieme a tutta la documentazione

ufficiale disponibile, al compilatore della politica di sicurezza e ad una sua

configurazione di esempio.

La specifica dell’architettura di sicurezza Flask ([SSC99a, SSC99b],

SSLHAL99]) descrive le interazioni tra due tipi di sottosistemi: quelli che

applicano la politica di controllo degli accessi, chiamati OBJECT MANAGER, e

quelli che prendono le decisioni di sicurezza in base ad una data

rappresentazione della politica, chiamati SECURITY SERVER: gli object manager

sono i responsabili dell’imposizione delle decisioni di un security server sugli

oggetti del sistema; il security server, a sua volta, incapsula la logica della

politica di controllo degli accessi.

Figura 11: Architettura Flask; gli object manager sono i componenti responsabili dell’imposizione (enforcement) della politica di sicurezza; il security server è il componente responsabile delle decisioni di sicurezza

8 Altri progetti sono volti all’integrazione dell’architettura Flask all’interno di sistemi

operativi open source; si veda, ad esempio, TrustedBSD (http://www.trustedbsd.org)


54

Flask è un’architettura flessibile che viene utilizzata per fornire un supporto

alla specifica di politiche MAC. Essa fornisce due tipi di decisioni: le più

importanti sono le decisioni di sicurezza, del tipo si/no, che specificano

se un particolare accesso ad un’entità etichettata (un oggetto) possa essere

garantito o meno ad un’altra entità etichettata (un soggetto). La decisione

viene presa interamente in base alle etichette. Per ogni decisione di sicurezza

viene analizzata la politica incapsulata nella logica del security server: questo

garantisce il controllo sulla propagazione dei diritti di accesso. Utilizzando la

terminologia relativa al concetto di reference monitor, le decisioni di

sicurezza corrispondono alle FUNZIONI DI RIFERIMENTO ed il security server

ingloba al suo interno il DATABASE DELLE AUTORIZZAZIONI.

Il secondo tipo di decisioni di cui è responsabile l’architettura è quello delle

decisioni di etichettatura, che specificano quale etichetta debba essere

assegnata ad un oggetto (tipicamente alla sua creazione), in base alle

etichette di soggetti ed oggetti correlati.

Figura 12: etichettatura di oggetti in Flask; un client richiede la creazione di un nuovo oggetto ad un objerct manager, fornendo la propria etichetta (SID); l’object manager invia una richiesta per una nuova etichetta al security server inviando il SID del client, quello dell’oggetto correlato ed il tipo di oggetto da creare; il security server consulta le proprie regole di etichettatura, determina il SID per il nuovo oggetto e lo restituisce; infine l’object manager associa il SID ricevuto all’oggetto


55

L’architettura specifica dei requisiti riguardo agli OBJECT MANAGER e al

SECURITY SERVER, assumendo che il sistema sottostante fornisca la

separazione fra questi componenti e fornisca anche dei meccanismi

attraverso i quali essi possano comunicare.

Flask fornisce, per ogni object manager, delle interfacce per ottenere le

decisioni di sicurezza e di etichettatura dal security server. Gli object

manager, inoltre, possono memorizzare le decisioni di sicurezza in un

apposito modulo chiamato Access Vector Cache (AVC) per limitare il

degrado di prestazioni del sistema dovuto ai costi associati alla

comunicazione con il security server. Si può avere un’unica AVC

centralizzata o un’AVC per ogni object manager, in funzione

dall’implementazione.

Figura 13: Richiesta e memorizzazione di decisioni di sicurezza in Flask; il client richiede la modifica di un oggetto esistente; l’object manager interroga la AVC riguardo ad una regola relativa; se non esistono elementi appositi nella AVC la richiesta viene inoltrata al security server, che consulta le proprie regole di accesso, determina se l’accesso sia consentito o meno e ritorna le proprie decisioni alla AVC

Le decisioni di sicurezza sono prese dal security server in base all’insieme di

ATTRIBUTI DI SICUREZZA che compongono le etichette di soggetti ed oggetti. Di

fondamentale importanza è ovviamente mantenere l’associazione tra oggetti

ed etichette. La soluzione più semplice sarebbe quella di definire un singolo


56

tipo di dato, indipendente dalla politica, che sia parte degli attributi associati

a ciascun oggetto. Tuttavia nessun tipo di dato singolo è adeguato a tutti i

differenti modi in cui le etichette sono usate nel sistema. Inoltre, da un

punto di vista dell’amministrazione del sistema, la migliore rappresentazione

di un’etichetta è sicuramente una stringa altamente descrittiva, mentre da un

punto di vista implementativo, per motivi di prestazioni nella ricerca delle

decisioni di sicurezza, è sicuramente conveniente utilizzare etichette che

possano essere tradotte velocemente in chiavi di ricerca all’interno di

strutture dati efficienti (ad esempio delle tabelle hash). Flask, per ovviare a

queste esigenze contrastanti, utilizza per le operazioni di etichettatura due

tipi di dato, indipendenti dalla politica: un security context è una stringa di

lunghezza variabile che può essere interpretata da un’applicazione (o da un

utente) che abbia una conoscenza della logica del security server; un security

context può consistere di differenti ATTRIBUTI DI SICUREZZA (un identità

utente, un livello MLS, un ruolo, un dominio TE, o una qualsiasi

combinazione di concetti che possa essere utilizzata per realizzare una

etichetta) ma ciò non è specificato dall’architettura e compete piuttosto al

particolare modello di sicurezza adottato dall’implementazione. Un security

identifier (SID), invece, è un valore di dimensioni fisse (in genere un

semplice intero positivo) che può essere interpretato solamente dal security

server. Il security server associa in maniera biunivoca i security context ai

security identifier, per cui un SID può essere visto semplicemente come un

dettaglio implementativo di Flask. L’utilizzo dei SID permette alla maggior

parte delle operazioni degli object manager di essere indipendenti dal

contenuto e dal formato del security context corrispondente.

Quando viene creato un oggetto è necessario assegnargli un’etichetta.

Questo avviene in Flask in uno dei seguenti tre modi:


57

• l’etichetta del nuovo oggetto può essere copiata dal soggetto che

richiede la creazione o da qualche altro oggetto correlato (ad

esempio la directory contenitrice nel caso in cui l’oggetto creato sia

un file)

• l’etichetta del nuovo oggetto può essere specificata dal soggetto

come parte della richiesta di creazione

• è possibile consultare il security server per ottenere la decisione di

etichettatura

In ogni caso la politica di sicurezza viene sempre esaminata per assicurarsi

che al soggetto sia permesso di creare un oggetto con l’etichetta scelta.

Nell’implementazione più semplice, un OBJECT MANAGER può effettuare una

richiesta al SECURITY SERVER ogni volta che sia necessaria una decisione di

sicurezza. Tuttavia, come anticipato sopra, Flask mette a disposizione un

dispositivo per la memorizzazione di decisioni di sicurezza precedentemente

prese, allo scopo di ridurre il potenziale degrado delle prestazioni del

sistema, dovuto alla comunicazione con il security server. Quando un object

manager richiede una decisione di sicurezza, interroga l’AVC, fornendo le

etichette dei soggetti e degli oggetti coinvolti e le modalità di accesso

richieste9; se le decisioni ricercate non sono trovate nell’AVC, la richiesta

viene inoltrata al security server. Per aumentare le prestazioni, il security

server può rispondere con decisioni per più modalità di accesso di quante

siano state realmente richieste. In particolare esso risponde con lo stato di

un insieme di diritti, chiamato VETTORE DI ACCESSO. Un vettore di accesso è

un insieme di MODALITÀ DI ACCESSO correlate ad una particolare CLASSE DI

OGGETTI; ogni classe di oggetti (ad esempio file, processi, socket, ...) ha un

9 in realtà fornisce anche la classe alla quale l’oggetto appartiene; il concetto di CLASSE DI

OGGETTI viene spiegato in seguito


58

vettore di accesso associato, che specifica quali siano le modalità di accesso

possibili agli oggetti appartenenti a quella classe. È responsabilità

dell’implementazione dell’architettura definire quali siano le classi degli

oggetti del sistema e quali i rispettivi vettori di accesso.

Quando un soggetto richiede l’accesso ad un oggetto, in una qualche

modalità, il security server risponde con un vettore di accesso per

quell’oggetto; il vettore contiene la specificazione di quali modalità di

accesso siano garantite al soggetto e quali gli siano negate. Tale risposta

viene poi memorizzata all’interno dell’AVC per evitare future richieste

relative a decisioni che siano già state fornite.

Il security server si occupa quindi di fornire le decisioni di sicurezza, di

mantenere l’associazione tra security context e SID, di fornire SID per gli

oggetti creati (decisioni di etichettatura) e di gestire le AVC degli object

manager.

Una caratteristica importante dell’architettura Flask è che il security server

può essere modificato, addirittura sostituito e, a patto che l’interfaccia resti

la stessa, non sono necessarie corrispondenti modifiche a nessuno degli altri

componenti dell’architettura.

Nel seguito della trattazione non parleremo più dell’architettura Flask in

generale, ma tratteremo la sua implementazione reale nel sistema operativo

Linux, chiamata SELinux.


59

3.2 Etichette di sicurezza

SELinux incorpora nel sistema operativo Linux un TCB che corrisponde

all’implementazione dell’architettura di sicurezza Flask.

Esso utilizza due tipi di controlli degli accessi, uno MAC ed uno DAC. I

controlli MAC possono essere configurati dall’amministratore di sicurezza,

quelli DAC sono i controlli tipici dei sistemi Unix e subentrano solamente

qualora vengano superati con successo quelli MAC.

È fondamentale definire i concetti relativi alle ETICHETTE DI SICUREZZA

utilizzate. Si è già detto che in Flask un’etichetta di sicurezza è chiamata

SECURITY CONTEXT; nel seguito utilizzeremo indistintamente i termini etichetta,

etichetta di sicurezza e security context.

Come in tutti i modelli di controllo degli accessi mandatori, in SELinux

viene assegnata un’etichetta ad ogni entità del sistema, sia essa un soggetto o

un oggetto.

Il security server di SELinux adotta un modello di controllo degli accessi

che si basa, contemporaneamente, su aspetti appartenenti a tre differenti

sottomodelli: TYPE ENFORCEMENT (TE), ROLE BASED ACCESS CONTROL

(RBAC) e USER IDENTITY (UI)10. Di conseguenza il formato delle etichette

specifica tre ATTRIBUTI DI SICUREZZA: un TIPO, che rappresenta, utilizzando la

terminologia propria del TE, il dominio per un soggetto o il tipo per un

oggetto; un RUOLO, che indica una funzione che un soggetto può svolgere

nel sistema11; un’IDENTITÀ SELINUX (differente da quella di Linux), che indica

per i soggetti l’identità dell’utente di cui sono surrogati e per gli oggetti

10 a questi si aggiunge un ulteriore sottomodello, il MULTI-LEVEL SECURITY (MLS), che però

sembra essere meramente supportato e del quale non ci occupiamo. 11 Questo attributo di sicurezza ha significato solamente per le etichette relative ai soggetti


60

quella del loro creatore. Gli insiemi di identità SELinux, ruoli e tipi verranno

rappresentati, rispettivamente, con U, R e T.

In base a questi tre attributi di sicurezza, il meccanismo di autorizzazione è

quello tipico di un REFERENCE MONITOR che realizzi una politica mandatoria:

ogni qualvolta un soggetto voglia accedere ad un oggetto in una determinata

modalità, si verifica che ciò sia autorizzato dalla politica in base ai valori dei

security context delle entità coinvolte.

Nel capitolo precedente sono stati introdotti diversi modelli di controllo

degli accessi. Descriviamo qui quali delle loro caratteristiche e quali loro

varianti vengano utilizzate nell’implementazione del security server presente

in SELinux.

Il linguaggio che permette di configurare i vari aspetti dei modelli e quindi

permette di impostare le regole di controllo degli accessi, viene descritto nel

capitolo seguente.

3.3 Classi di oggetti e modalità di accesso

Prima di descrivere il sottomodello TE, è necessario precisare il concetto di

CLASSE DI OGGETTI sul quale si basa l’attribuzione dei diritti di accesso in

SELinux.

Il significato intuitivo di DIRITTO o MODALITÀ DI ACCESSO è che esso sia una

sorta di titolo che garantisca la possibilità di eseguire una qualche operazione

ad un certo livello di astrazione.

La maggior parte dei sistemi si basa su una serie di astrazioni, come quelle di

processo o di filesystem, ognuna delle quali ha un proprio insieme distinto di

operazioni, corrispondenti ai servizi forniti dai meccanismi che realizzano


61

l’astrazione. È quindi logico definire per ogni astrazione un insieme distinto

di modalità di accesso: le modalità di accesso definite dalle operazioni sul

filesystem, quali quelle di lettura, scrittura ed esecuzione, sono in generale

considerate universali e quindi applicate a differenti astrazioni. Unix, come

visto, è un esempio di quanto detto. In realtà non lo sono, perché le

modalità di accesso agli oggetti dovrebbero essere definite solamente

quando lo sono le corrispondenti operazioni e le operazioni disponibili

dipendono strettamente dai servizi offerti, e quindi variano da astrazione ad

astrazione: a meno di sovraccaricarne il significato, non ha senso

considerare le modalità di accesso in lettura e in scrittura per un processo.

Infatti le due astrazioni di processo e file sono molto differenti.

Si rende quindi necessario partizionare gli oggetti del sistema in classi, per le

quali siano definiti insiemi, in generale distinti, di modalità di accesso.

L’appartenenza di un oggetto ad una data classe definisce quali siano le

operazioni effettuabili sull’oggetto e quindi quali siano i diritti di accesso che

possano essere garantiti o negati sull’oggetto in questione.

Le modalità di accesso in SELinux sono definite rispetto a classi di

oggetti. Esistono classi, gestite da differenti sottosistemi, relative ai processi,

ai file, al networking... Modalità di accesso di differenti classi di oggetti

possono avere lo stesso nome; si pensi ai diritti definibili sulle classi file e

dir: molti di questi, fra i quali quello di lettura e scrittura saranno gli stessi per

entrambe le classi e quindi saranno definiti in entrambe con lo stesso nome.

Il diritto di attraversare una directory sarà però definito solo sulla classe dir,

così come quello di esecuzione solo su quella file. Ad ogni modo, non si

verificano mai conflitti di nomi, visto che le modalità di accesso vengono

sempre specificate rispetto ad una classe.


62

Quindi per ogni classe è definito un insieme di modalità di accesso peculiari

per la classe, che prende il nome di vettore di accesso.

Un simile approccio ha notevoli vantaggi, perché è sempre ben definita la

semantica dei singoli diritti di accesso. Inoltre la classificazione degli oggetti

si rende particolarmente utile nella configurazione del sottomodello TE, nel

quale entrano in gioco security context che possono essere applicati ad

oggetti di classi differenti: il controllo degli accessi, come verrà spiegato nel

prossimo paragrafo, viene effettuato infatti in base alle etichette di soggetto

e oggetto ma anche in base alla classe dell’oggetto, permettendo quindi di

distinguere differenti comportamenti in funzione della tipologia di oggetto

al quale si vuole accedere.

3.4 Sottomodello TE in SELinux

Si è visto in precedenza che il modello tradizionale TE associa un attributo

di sicurezza DOMINIO ad ogni soggetto ed un attributo di sicurezza TIPO ad

ogni oggetto. Vengono così definite delle classi di equivalenza di soggetti e

di oggetti. Le interazioni fra i soggetti e quelle fra i soggetti e gli oggetti

vengono definite per mezzo delle due matrici DIT e DDT, i cui elementi

contengono i diritti di accesso che i domini hanno, rispettivamente, su altri

domini e sui tipi.

In SELinux, pur rimanendo semanticamente distinti i concetti di dominio e

di tipo, il sottomodello TE non fa distinzioni interne fra i due, e l’attributo

di sicurezza sia per i soggetti sia per gli oggetti è chiamato indistintamente

tipo. Questo permette di definire una sola matrice degli accessi TE. Nel

seguito della trattazione con il termine dominio intenderemo, quindi,

semplicemente il tipo associato ad un soggetto.


63

Una seconda differenza tra il TE standard e quello implementato in

SELinux è che le interazioni tra tipi avvengono in base ad una coppia di tipi

e ad una classe di oggetti. Inoltre uno stesso tipo può essere assegnato ad

oggetti di classi differenti; è possibile quindi specificare, per uno stesso

soggetto, differenti autorizzazioni su oggetti che hanno lo stesso tipo ma

appartengono a differenti classi. Ragionando quindi in termini di matrici

degli accessi TE, quella definita in SELinux, piuttosto che bidimensionale, è

una matrice tridimensionale.

3.5 Sottomodello RBAC in SELinux

Come si è visto, il modello tradizionale RBAC si basa sulle associazioni di

utenti a ruoli e di permessi a ruoli. Un utente acquisisce un diritto di accesso

su un oggetto solamente agendo in un dato ruolo che sia autorizzato su

quell’oggetto alla modalità di accesso indicata dal diritto.

In SELinux viene mantenuto il concetto di assegnamento di identità di

utenti a ruoli, ma anziché associare anche i permessi ai ruoli, vengono

associati ad essi degli insiemi di domini TE. Le identità assegnate ai ruoli

sono quelle definite nel sottomodello UI.

È possibile organizzare i ruoli all’interno di una gerarchia, così come

avviene nel modello RBAC standard: qualora un ruolo r domini un ruolo

r’, r è automaticamente autorizzato a tutti i tipi ai quali è autorizzato r’.

Inoltre ogni identità SELinux esplicitamente autorizzata al ruolo r, lo è

anche implicitamente al ruolo r’.


64

Ricordiamo, infine, che l’attributo di sicurezza ruolo ha significato

solamente per le etichette relative ai soggetti; in quelle relative agli oggetti è

impostato ad un generico valore object_r e non viene utilizzato.

Il supporto a RBAC in SELinux si limita a quanto detto. Non vi è la

possibilità per un soggetto di attivare più ruoli contemporaneamente, né

esiste un supporto per la specifica di vincoli presenti in letteratura. RBAC in

SELinux è semplicemente un concetto centrato sull’utente che serve ad

introdurre un ulteriore livello di astrazione rispetto al TE; è poco più che

una comodità per raggruppare insiemi di domini ed assegnarli agli utenti. La

parte realmente importante del controllo degli accessi è operata a livello di

TE.

3.6 Sottomodello User Identity in SElinux

Nei sistemi Unix in generale, e in Linux in particolare, il cambiamento

dell’identità utente di un processo implica un cambiamento dei diritti di

accesso sugli oggetti, in accordo con un modello DAC. Quindi il

cambiamento dell’attributo di sicurezza identità di un soggetto non

corrisponde ad un cambiamento reale dell’utente per il quale il soggetto

agisce. Piuttosto corrisponde ad un’acquisizione e/o perdita di diritti di

accesso.

Inoltre le identità Linux possono essere cambiate in qualsiasi momento

tramite chiamate set*uid, e questo meccanismo, come si è

precedentemente fatto notare, è alla base della principale vulnerabilità dei

sistemi di sicurezza tradizionali.

Ovviamente, in un qualsiasi modello MAC, il precedente meccanismo

discrezionale di acquisizione e perdita dei diritti di accesso in base ad


65

un’identità fluttuante dei soggetti e degli oggetti, non è soddisfacente.

SELinux, piuttosto che imporre limitazioni sui possibili cambiamenti di

identità dei processi, mantiene nelle etichette dei soggetti e degli oggetti un

attributo di sicurezza che indichi l’identità dell’utente e che non possa essere

alterato, a meno che la configurazione della politica non lo permetta

esplicitamente12. L’attributo identità SELinux è separato dall’identità

utente Linux, in modo da essere ad essa ortogonale: viene così garantita la

compatibilità con i meccanismi di controllo degli accessi standard del

sistema operativo e quindi con le applicazioni esistenti. Vista l’indipendenza

dei due attributi di identità, è possibile associare più identità Linux ad una

singola identità SELinux, approccio particolarmente utile quando non sia

necessario separare alcuni utenti tramite la politica mandatoria.

L’associazione tra IDENTITÀ SELINUX e DOMINIO di un soggetto viene fatta

attraverso un RUOLO.

Riassumendo, quindi, un soggetto ha un’etichetta di sicurezza composta

dall’IDENTITÀ SELINUX in funzione della quale opera il soggetto, dal RUOLO

assunto dal soggetto nel sistema e dal dominio (TIPO) nel quale è confinato il

soggetto; un oggetto ha un’etichetta di sicurezza formata dall’identità

SELinux del soggetto che lo ha creato, da un ruolo impostato ad un valore

object_r e dal tipo associato all’oggetto.

12 I soggetti che possono cambiare l’attributo IDENTITÀ SELINUX sono in genere associati a

programmi particolari come login, crond e sshd che sono stati modificati per chiamare

nuove funzioni di libreria che impostino l’attributo in maniera opportuna. I privilegi di

questi programmi sono comunque controllati tramite la configurazione dei domini TE per i

relativi processi


66

3.7 Transizioni e cambiamenti di security context

Per quanto detto finora è chiaro che in un qualsiasi modello di controllo

degli accessi mandatorio, al cambiamento dell’etichetta di sicurezza di un

soggetto corrisponde in generale un cambiamento dei privilegi che questi

possiede, così come al cambiamento dell’etichetta di un oggetto cambiano

in generale le modalità con cui i soggetti possono accedere a quell’oggetto.

È chiaro anche che, allo scopo di realizzare il PRINCIPIO DEI PRIVILEGI MINIMI, il

cambiamento delle etichette dei soggetti costituisce una potenzialità

indispensabile. Nel TE un soggetto può cambiare dominio durante la sua

esecuzione; alla TRANSIZIONE DI DOMINIO corrisponde un cambiamento della

propria etichetta di sicurezza. Nel RBAC si può ottenere qualcosa di

analogo: un utente che agisca in un dato ruolo, ad un certo punto può

attivarne un altro, acquistando e/o perdendo diritti sui vari oggetti. In Unix,

al cambiamento dell’identità utente (che può essere vista, in un certo senso,

come un’etichetta di sicurezza per i processi con quell’identità) corrisponde

un cambiamento dei privilegi di cui un processo dispone.

In SELinux è possibile cambiare le etichette dei soggetti e degli oggetti

mediante l’invocazione di alcune apposite chiamate a sistema ed interfacce

del kernel, ma tale cambiamento deve essere autorizzato e viene controllato

dalla politica. Il modo in cui questo cambiamento avviene compete ai

meccanismi interni del kernel, nei quali non entriamo nel dettaglio, tuttavia

è necessario qui precisarne alcuni (per la spiegazione completa dei

meccanismi interni di SELinux si veda [LS01a]: il documento è ovviamente

estremamente tecnico, ed anche se è datato e non rispecchia più alla

perfezione il funzionamento odierno del sistema, è l’unico disponibile a

riguardo). Il modo in cui tali meccanismi vengono configurati è spiegato in

un apposito paragrafo del capitolo seguente.


67

Esistono due casi particolari in cui si verifica una modifica delle etichette di

sicurezza in SELinux: quando si crea un oggetto o si trasforma un soggetto

e quando si vuole cambiare volutamente l’etichetta di un oggetto. Il primo

caso ha a che fare con nuove entità nel sistema (soggetti e oggetti) e con le

DECISIONI DI ETICHETTATURA proprie del security server: le modifiche sono

chiamate transizioni di security context; nel secondo caso invece le

modifiche riguardano operazioni di rietichettatura di oggetti già esistenti nel

sistema e sono chiamate cambiamenti di security context. Vediamo i casi

separatamente.

Una decisione di transizione per un processo è richiesta ogni qualvolta venga

eseguito un programma da parte di un soggetto (e quindi venga trasformato

un processo) e si basa sull’etichetta del soggetto e su quella del programma

eseguibile. In Unix il meccanismo di trasformazione di un processo

coinvolge l’utilizzo delle chiamate a sistema della famiglia exec(), che

permettono di cambiarne l’immagine in memoria13. Alla chiamata di

execve(), quindi, il security server, tramite l’utilizzo di una sua interfaccia

chiamata security_transition_sid, produce l’etichetta da assegnare al

processo trasformato: tale etichetta, per default, è quella del processo che

esegue il programma, ma può essere differente qualora il sistema sia

opportunamente configurato dall’amministratore di sicurezza.

L’assegnamento dell’etichetta al processo è operata dall’object manager

relativo alla gestione dei processi. Ovviamente, perché possa avvenire, la

transizione necessita di essere autorizzata dalla politica di sicurezza. In

particolare è necessario che il dominio del processo che invoca la execve()

13 La chiamata a sistema execve() prende come parametro il nome del programma

eseguibile che costituisce la nuova immagine per il processo. Per questo motivo, un

processo per il quale sia invocata una execve() è chiamato PROCESSO TRASFORMATO.


68

sia autorizzato ad eseguire il programma ENTRYPOINT del nuovo dominio ed

abbia, ovviamente, l’autorizzazione ad effettuare la transizione (queste due

autorizzazioni corrispondono a due differenti privilegi definiti,

rispettivamente, nella classe relativa ai file e in quella relativa ai processi).

Una decisione di transizione per un oggetto è richiesta ogni qualvolta venga creato

un nuovo oggetto e si basa sull’etichetta del processo creatore e su quella di

qualche oggetto correlato (ad esempio, se si crea un file, l’oggetto correlato

è la directory che contiene il file). In questo caso, il comportamento

predefinito del sistema è quello di assegnare l’etichetta dell’oggetto

correlato, ma mediante un’opportuna configurazione, è possibile assegnare

all’oggetto creato un’etichetta differente. Anche in questo caso l’etichetta è

prodotta dal security server, mediante una chiamata alla sua interfaccia

security_transition_sid, e viene associata all’oggetto da un

opportuno object manager (ad esempio quello del filesystem). Ovviamente,

perché la transizione possa avvenire, è necessario che essa sia autorizzata

dalla politica di sicurezza. In particolare è necessario che il dominio del

processo che crea l’oggetto abbia l’autorizzazione di operare la creazione.

Sono inoltre richieste altre autorizzazioni dipendenti dalla natura

dell’oggetto creato (ad esempio, nel caso di un file, quelle per aggiungere il

nome del file alla lista degli elementi della directory contenitrice e per

associare il file al filesystem).

I due casi visti fino ad ora sono tutti gestiti automaticamente dal kernel di

SELinux. In realtà le etichette di sicurezza possono anche essere cambiate

da applicazioni che utilizzino le nuove chiamate a sistema sicure, aventi

come parametro la nuova etichetta da assegnare. Tale etichetta può essere

ricavata da una decisione del security server, tramite una sua interfaccia

chiamata security_change_sid, o in altri modi (ad esempio tramite la


69

configurazione esplicita dei security context per i file). Nel primo caso, il

meccanismo di rietichettatura è analogo a quello di transizione e la nuova

etichetta da assegnare dipende da quella del soggetto e da quella che

l’oggetto possiede correntemente.

Un’applicazione può passare ad una di queste nuove chiamate a sistema una

qualsiasi etichetta, ma la rietichettatura deve essere autorizzata dalla politica.

In particolare sono necessarie due autorizzazioni, quella per rietichettare un

oggetto avente una data (vecchia) etichetta e quella per rietichettare

l’oggetto con un’altra (nuova) etichetta. Nel seguito non ci occuperemo

molto dei cambiamenti di security context, perché questi presuppongono

una parziale riscrittura delle applicazioni, al fine di invocare le nuove

chiamate a sistema; concentreremo invece la nostra attenzione sulle

TRANSIZIONI DI SECURITY CONTEXT per i processi, che permettono di far

funzionare applicazioni esistenti senza alcuna loro modifica.

3.8 Spazio dei security context

Forniamo in questo paragrafo una serie di definizioni informali relative ai

SECURITY CONTEXT, che saranno utili nel prossimo capitolo. Le definizioni

formali dei concetti qui esposti saranno fornite nel capitolo 5 dedicato

interamente alla creazione di un modello formale in grado di descrivere le

regole di accesso nel sistema SELinux.

Si è detto che le etichette dei soggetti e degli oggetti in SELinux sono

formate da tre attributi di sicurezza, un’IDENTITÀ SELINUX, un RUOLO ed un

TIPO. Ogni attributo di sicurezza appartiene ad un dato insieme, U, R o T. È

naturale quindi definire un generico security context come una terna

appartenente al prodotto cartesiano TRU ×× .


70

Definiamo spazio dei security context14 l’insieme delle terne appartenenti

al prodotto cartesiano TRU ×× .

Definiamo anche sottospazio dei security context, o più brevemente

sottospazio, un qualsiasi sottoinsieme non vuoto dello spazio dei security

context, ''' TRU ×× , con TTRRUU ⊆⊆⊆ ',',' .

Come vedremo nel capitolo successivo, la configurazione di una politica di

sicurezza in SELinux avviene per mezzo di un linguaggio di alto livello che

mette a disposizione un insieme di costrutti. L’utilizzo di tali costrutti, in

generale, permette di definire dei vincoli sull’insieme dei security context

che possano essere utilizzati nel sistema. In altre parole le etichette utilizzate

nel sistema non sono arbitrarie etichette appartenenti allo spazio TRU ×× ,

ma seguono determinate regole imposte dalla configurazione ed

appartengono quindi ad un suo sottospazio.

Chiameremo quindi security context validi quelle etichette che rispettano i

vincoli imposti dalle regole di configurazione ed il loro insieme spazio dei

security context validi.

Chiamiamo, infine, gli ATTRIBUTI DI SICUREZZA delle etichette componenti

dello spazio dei security context (e dei suoi sottospazi): ogni etichetta ha

quindi tre componenti.

Qualora un sottospazio di etichette sia tale che uno o più attributi dei suoi

elementi assuma valore costante, indicheremo l’attributo costante con una

lettera minuscola; esempi di sottospazi di etichette con attributi costanti

sono quindi: TRu ×× , TrU ×× , trU ×× , con Uu∈ , Rr∈ e Tt ∈ ; un

altro esempio di sottospazio con un attributo costante è quello delle

14 Per quanto detto precedentemente lo spazio dei security context può essere anche

chiamato SPAZIO DELLE ETICHETTE, o SPAZIO DELLE ETICHETTE DI SICUREZZA


71

etichette degli oggetti: in esse la componente ruolo è infatti sempre

impostata al valore object_r.

Capitolo IV: Il linguaggio di configurazione di SELinux

72

C a p i t o l o 4

Il linguaggio di configurazione di SELinux

La specifica di una politica di sicurezza in SELinux avviene per mezzo di un

apposito linguaggio di alto livello, attraverso cui è possibile scrivere dei file

di configurazione testuali che poi vengono concatenati in un unico file

chiamato policy.conf. La versione della politica di sicurezza contenuta in

policy.conf viene in seguito compilata in un’immagine binaria,

comprensibile dal security server.

Figura 14: schema del processo di compilazione della politica di sicurezza in SELinux; mediante il linguaggio di configurazione vengono scritti diversi file, alcuni contenenti delle macro; le macro vengono espanse e tutti i file di configurazione vengono concatenati in un unico file, policy.conf, contenente tutta la configurazione della politica in una forma leggibile dall’uomo; il file policy.conf viene poi compilato per mezzo di un compilatore chiamato checkpolicy che produce una forma binaria della politica, comprensibile dal security server. A questo punto, mediante un’apposita chiamata a sistema è possibile caricare la politica di sicurezza.

Il linguaggio di alto livello viene descritto sommariamente in [LS01a, LS01b]

e abbastanza approfonditamente in [Sm02]. Si aggiungono poi le


73

documentazioni non ufficiali [TT02a, TT02b]. Con l’eccezione di [Sm02] i

documenti risultano datati e abbastanza lacunosi. [Sm02] è invece

sufficientemente chiaro anche se non sempre sincronizzato con la versione

corrente di SELinux: in più occasioni abbiamo riscontrato inesattezze,

dovute principalmente a modifiche successive alla stesura del documento e

non seguite dal suo aggiornamento.

Per comprendere i vari aspetti del linguaggio di configurazione è quindi

fondamentale, innanzitutto, lo studio della sua grammatica, derivabile a

partire dalle specifiche LEX e YACC fornite assieme ai sorgenti del sistema.

Inoltre, è di particolarmente aiuto l’iscrizione alla mailing list presente sul

sito web ufficiale di SELinux.: i responsabili del progetto rispondono

sempre alle domande poste in maniera sufficientemente chiara ed in tempi

ragionevoli.

In questo capitolo descriviamo un linguaggio di configurazione di SELinux

che è una semplificazione del linguaggio ufficiale. Tale linguaggio, pur

consentendo di semplificare l’argomento, è equivalente al linguaggio

originale, permettendo di rendere la nostra trattazione del tutto generale.

4.1 Semplificazioni del linguaggio di configurazione

Il linguaggio di configurazione di SELinux consta di 25 costrutti. Per

l’esatto formato di una configurazione, si rimanda all’appendice B nella

quale vengono presentate tutte le produzioni della grammatica del

linguaggio.


74

Costrutti del linguaggio di configurazione di SELinux

class_def

initial_sid_def

common_perms_def

av_perms_def

mls

attribute_def

type_def

type_transition

type_change

allow_def

auditallow_def

auditdeny_def

dontaudit_def

neverallow_def

role_type_def

role_dominance

role_trans_def

role_allow_def

constraint_def

user_def

initial_sid_context_def

fs_context_def

net_contexts

fs_use_def

genfs_context_def

Figura 15: elenco dei costrutti mediante i quali è possibile configurare una politica

di sicurezza in SELinux

Della totalità dei costrutti messi a disposizione, per i nostri scopi sono stati

selezionati gli 11 che non riguardano l’inizializzazione del sistema, la

configurazione del sottositema di auditing, e i supporti a funzionalità ancora

solamente sperimentali e che sembrano destinate a subire delle modifiche

nel futuro. Con riferimento all’appendice B, non rientrano nella nostra

trattazione i seguenti:

• initial_sid_def e initial_sid_context_def, relativi

all’inizializzazione del sistema

• auditallow_def, auditdeny_def e dontaudit_def, relativi alla

configurazione delle regole di auditing

• fs_use_def, genfs_context_def e fs_context_def, relativi

all’etichettatura dei filesystem e quindi, a buon titolo,

all’inizializzazione del sistema

• net_context, relativo al supporto (sperimentale) all’etichettatura

degli oggetti del networking


75

Inoltre non sono stati presi in considerazione i costrutti reputati ormai

obsoleti e che presto non saranno più disponibili (role_trans_def), né i

costrutti che nulla aggiungono a livello di controllo degli accessi

(neverallow15). Non è stato preso in considerazione neanche il costrutto

type_change, perché la sua utilità si ha solo nei casi in cui le applicazioni

vengano riscritte per supportare le nuove chiamate a sistema sicure fornite

da SELinux, cosa di cui non ci occupiamo.

Infine, non è stato preso in considerazione il supporto per i controlli MLS

(mls) per due motivi principali: prima di tutto tale supporto è definito

sperimentale dagli autori del progetto ed il suo utilizzo viene tutt’altro che

incoraggiato: risulta essere opzionale e deve essere attivato esplicitamente in

fase di compilazione del kernel del sistema operativo; nelle documentazioni

ufficiali che ne accennano l’esistenza, si consiglia sempre di configurare

opportunamente il TE ed evitare il ricorso ai controlli MLS; in secondo

luogo, per ovvi motivi dopo quanto detto, la configurazione di esempio,

fornita a corredo con il sistema, non utilizza questa funzionalità né tanto

meno esiste una reale documentazione relativa, anche minima.

Di seguito illustriamo un linguaggio di alto livello, chiamato da noi SEL, che

è equivalente al linguaggio formato dagli undici costrutti di configurazione

di SELinux da noi presi in considerazione. I due linguaggi sono equivalenti

nel senso che per ogni configurazione che possa essere scritta in uno dei

due, esiste una configurazione equivalente che possa essere scritta nell’altro

15 questo costrutto permette solo di verificare a tempo di compilazione alcune semplici

proprietà di una data configurazione


76

e viceversa, intendendo due configurazioni “equivalenti” se garantiscono o

negano ai soggetti l’accesso agli oggetti nello stesso modo.

Costrutti considerati Costrutti non considerati

class_def

av_perms_def

attribute_def

type_def

type_transition

allow_def

role_type_def

role_dominance

role_allow_def

user_def

constraint_def

initial_sid_def

common_perms_def16

mls

auditallow_def

auditdeny_def

dontaudit_def

neverallow_def

role_trans_def

initial_sid_context_def

fs_context_def

net_context

fs_use_def

genfs_context_def type_change

Figura 16: distinzione tra i costrutti di configurazione presi in considerazione e

quelli ignorati

Nel proseguimento della trattazione, laddove faremo riferimento alla

configurazione di SELinux, intenderemo una configurazione tramite

l’utilizzo di SEL: più precisamente, considereremo SELinux configurato

tramite regole, corrispondenti ad istanze dei costrutti di SEL.

16 questo costrutto non è stato preso in considerazione a causa delle semplificazioni operate

e di seguito descritte


77

SEL è formato dagli undici costrutti di cui sopra con le seguenti

semplificazioni:

• in av_perms_def non è possibile ereditare insiemi di modalità di

accesso precedentemente dichiarati17

• in type_def non è possibile specificare alcun alias per un tipo (un

alias per un tipo non è altro che un nome alternativo per quel tipo)

• in user_def non è possibile esprimere degli intervalli MLS per

l’identità utente

• i costrutti allow_def, role_type_def, role_allow_def,

constraint_def, e user_def, sono stati normalizzati.

Con normalizzazione di un costrutto intendiamo la seguente trasformazione:

ogni qualvolta in un determinato campo del costrutto sia possibile

specificare più di un nome, o dei caratteri jolly, intendendo che il costrutto

si applica a tutti i nomi specificati, o all’insieme dei nomi derivante

dall’esplosione dei caratteri jolly18, forziamo la specifica di più costrutti dello

stesso tipo, ognuno relativo ad un singolo nome.

17 questo avviene nel linguaggio originale per mezzo del costrutto common_perms_def,

escluso da SEL perché non fondamentale 18 i caratteri jolly sono due, * e ~: il primo serve ad indicare un universo di nomi (ovvero

tutti i nomi di ruoli, tipi, utenti, classi di oggetti o diritti di accesso, a seconda del tipo di

campo e di costrutto nel quale il carattere jolly viene utilizzato); il secondo invece viene

utilizzato per complementare l’insieme di nomi (eventualmente unitario, ma non vuoto)

espresso subito dopo fra parentesi graffe ( e ).


78

Quindi, ad esempio, il costrutto:

allow_def ALLOW names names : names names ;

names identifier

| identifier_list

| *

| ~ identifier

| ~ identifier_list

identifier_list identifier

| identifier_list identifier

identifier IDENTIFIER

diventa:

allow_def ALLOW identifier identifier : identifier identifier ;


e quindi la regola:

allow t1 t2 t3 : process transition fork

va espressa mediante le regole normali:

allow t1 t3 : process transition

allow t1 t3 : process fork

allow t2 t3 : process transition

allow t2 t3 : process fork

In generale, quindi, l’effetto di una singola regola espressa nel linguaggio di

configurazione originale, corrisponde all’unione degli effetti di più regole

(normali) espresse in SEL.


79

La normalizzazione nulla toglie alla potenza del linguaggio, non dà origine

ad effetti collaterali ed incide solamente sull’economia della specifica della

configurazione, ovvero sulla sua dimensione in termini di caratteri di testo.

L’insieme completo delle produzioni del linguaggio SEL, così come quello

del linguaggio di configurazione originale di SELinux, è fornito

nell’appendice B.

La configurazione di una politica di sicurezza in SELinux si divide nella

specifica delle classi di oggetti e dei relativi vettori di accesso, nella

configurazione dei tre sottomodelli TE, RBAC, UI e in quella dei vincoli. Le

regole di configurazione dei tre sottomodelli saranno classificate come

regole TE, regole RBAC e regole UI.

Il punto fondamentale da tener presente nella creazione di un modello

formale per il sistema di controllo degli accessi di SELinux, chiamato nel

seguito SELAC (SELinux Access Control), è che si devono considerare gli

effetti che ogni regola o vincolo ha su un insieme di security context. Infatti

un SECURITY CONTEXT consta di tre componenti, ma una regola di

configurazione è in genere relativa solamente ad una delle tre: questo

implica che l’effetto di una singola regola si applichi non ad un singolo

security context, ma ad un SOTTOSPAZIO DEI SECURITY CONTEXT, in cui uno

degli attributi sia vincolato dalla regola e gli altri due siano in generale liberi.

Così, ad esempio, una regola di configurazione TE relativa ad un tipo t

stabilisce il comportamento di tutti i security context validi appartenenti al

sottospazio tRU ×× , ed una relativa ad un ruolo r, il comportamento di

tutti i security context validi appartenenti al sottospazio TrU ×× .


80

Nel seguito descriviamo i costrutti di SEL. Un apposito paragrafo è

dedicato ai costrutti relativi alle TRANSIZIONI DI SECURITY CONTEXT.

4.2 Configurazione del sottomodello TE

La configurazione del sottomodello TE è il cuore della specifica di una

politica di sicurezza in SELinux. La quasi totalità di una politica viene infatti

specificata tramite le regole TE.

Come già accennato, la configurazione del TE relativa alle TRANSIZIONI DI

SECURITY CONTEXT (transition_def) viene effettuata nel seguito, in un

apposito paragrafo. Vengono invece qui descritti gli altri tre costrutti:

• type_def, che permette di dichiarare i domini dei soggetti e i tipi

degli oggetti

• attribute_def, che permette di dichiarare gli attributi per i tipi

• allow_def, che permette di garantire ai domini dei soggetti i diritti

di accesso sugli oggetti con i tipi dichiarati

Le produzioni relative al primo costrutto che consideriamo sono le seguenti:

attribute_def ATTRIBUTE attribute_name ;

attribute_name IDENTIFIER

attribute_def non fa altro che dichiarare un ATTRIBUTO PER UN TIPO. Un

attributo è un nome che può essere associato a più tipi. Può essere visto

come una sorta di macro che, espansa, restituisce tutti i tipi ai quali

l’attributo è associato.


81

Il termine non va confuso con quello di ATTRIBUTO DI SICUREZZA, da noi

utilizzato per intendere una qualsiasi delle tre componenti dei security

context.

L’utilità di un attributo deriva dal fatto che esso possa essere utilizzato in

ogni regola che abbia un campo per la specifica di un nome di tipo: l’effetto

ottenuto è che la regola si applica a tutti i tipi che hanno il dato attributo.

Le regole:

attribute domain

attribute file_type

dichiarano due attributi che nella configurazione di esempio vengono

associati, rispettivamente, ai tipi relativi ai domini e agli oggetti che sono file.

Le due precedenti regole evidenziano chiaramente come sia possibile

classificare i tipi in base ad alcune loro caratteristiche semantiche, per mezzo

degli attributi. Si badi però che, di per sé, gli attributi non definiscono la

semantica dei tipi, ma sono solamente dei nomi arbitrari ad essi associati.

Le produzioni relative al secondo costrutto sono le seguenti:

type_def TYPE type_name opt_attr_list

type_name identifier

opt_attr_list , id_comma_list

| λ

id_comma_list identifier

| id_comma_list , identifier



82

type_def dichiara i nomi che possono essere utilizzati come componenti

TIPO nei security context, ovvero i nomi dei domini dei soggetti e i nomi dei

tipi degli oggetti. Inoltre permette, opzionalmente, di associare ad un tipo

una lista di attributi precedentemente dichiarati.

Ad esempio le regole:

type syslogd_t domain

type syslogd_exec_t file_type exec_type

definiscono due tipi, syslogd_t e syslogd_exec_t. Al primo tipo viene

associato l’attributo domain, mentre al secondo vengono associati i due

attributi, file_type e exec_type.

Le produzioni del terzo ed ultimo costrutto TE considerato sono le

seguenti:

allow_def ALLOW source_type target_type : class permission;

source_type IDENTIFIER

target_type IDENTIFIER

class IDENTIFIER

permission IDENTIFIER

allow_def definisce le interazioni possibili tra soggetti ed oggetti: vengono

infatti specificati i diritti di accesso che i soggetti con un dato tipo hanno

sugli oggetti aventi un altro dato tipo. Un oggetto viene identificato tramite

una coppia indicante il tipo e la classe dell’oggetto. Il costrutto allow_def

definisce la matrice degli accessi TE. Tutte le interazioni tra entità


83

etichettate non esplicitamente permesse tramite regole allow_def

vengono automaticamente vietate dal meccanismo di autorizzazione.

Ad esempio, le regole:

allow user_t user_home_t: file read ;

allow user_t user_home_t: file write ;

qualora non siano specificate altre regole allow_def per user_t,

user_home_t, e file, permettono a soggetti con tipo user_t di

accedere in lettura e scrittura ai file con tipo user_home_t. In altre parole,

un soggetto con security context in tuserRU _×× può solamente leggere

e scrivere un file con security context in home_tuserRU _×× .

La regola seguente:

allow domain init_t : process sigchld;

mostra un esempio di utilizzo degli attributi. Essa stabilisce che tutti i tipi

con attributo domain abbiano il permesso sigchld della classe process

sugli oggetti con tipo init_t. Nella configurazione di esempio questo si

traduce nella possibilità per i processi di inviare il segnale SIGCHLD al

processo init. Si noti come, qualora la classe degli oggetti specificata sia

process, il tipo dell’oggetto rispetto a cui vengono espressi i diritti di

accesso sia in realtà il tipo di un soggetto (nell’esempio precedente init_t).

Una regola allow_def si applica ad una quaterna (dominio soggetto, tipo

oggetto, classe oggetto, modalità di accesso della classe); è possibile assegnare uno

stesso tipo ad oggetti di classi differenti e specificare diritti differenti per

una stessa coppia di tipi ma differente classe di oggetti. L’utilità di ciò è

evidente nel caso in cui si vogliano differenziare, ad esempio, i diritti che un


84

soggetto ha su alcuni file regolari e quelli che ha sulle directory che

contengono tali file; infatti, a meno della presenza di specifiche regole, in

generale, i file regolari ereditano alla loro creazione lo stesso security context

della directory che li contiene.

Se alle precedenti regole si aggiungono:

allow user_t user_home_t: dir read ;

allow user_t user_home_t: dir execute ;

si può notare come il tipo user_home_t possa essere assegnato sia a file

che a directory e come si possano diversificare i diritti che i soggetti con

tipo user_t hanno su file e directory con quello stesso tipo (read e write

nel caso l’oggetto sia un file regolare, read ed execute nel caso in cui sia

una directory).

Mediante la specifica di più regole allow_def relative ad una stessa coppia

di tipi t e t’ e ad una classe c, è possibile definire l’insieme di tutte le

modalità di accesso che un soggetto avente etichetta con componente TIPO

t ha su oggetti della classe c aventi etichetta con componente TIPO t’.

Ovviamente tali modalità di accesso devono essere definite sulla classe c.

4.3 Configurazione del sottomodello RBAC

Configurando il modello RBAC è possibile:

• dichiarare i ruoli ai quali i soggetti possono essere autorizzati e

definire i domini ai quali tali ruoli sono autorizzati

• definire possibili transizioni di ruolo per i soggetti

• definire, opzionalmente, una gerarchia dei ruoli.


85

Ciò viene fatto per mezzo di tre costrutti, rispettivamente,

role_type_def, role_transition e role_dominance. Anche in

questo caso, la trattazione del secondo di tali costrutti, essendo relativo alla

TRANSIZIONE DEI SECURITY CONTEXT, è fornita successivamente in un apposito

paragrafo.

Le produzioni dei due altri costrutti sono le seguenti:

role_type_def ROLE role_name TYPES domain_name ;

role_name identifier

domain_name identifier

e

role_dominance DOMINANCE roles

roles ROLE senior ROLE junior;

senior identifier

junior identifier


I tipi (domini19) ai quali i ruoli sono autorizzati devono essere dichiarati nella

configurazione del sottomodello TE.

I ruoli dominati e dominanti (rispettivamente junior e senior) devono essere

precedentemente dichiarati tramite regole role_type_def. 19 Si ricordi che in SELinux con il termine tipo si intendono sia i tipi degli oggetti che i

domini dei soggetti. Nell’ambito delle regole RBAC, ovviamente, i tipi a cui si fa

riferimento sono i domini dei soggetti.


86

Il costrutto role_type_def restringe lo spazio dei security context validi

per i soggetti a quei security context con valori compatibili per gli attributi

RUOLO e TIPO.

Ad esempio, la regola:

role r1_r types t1_t;

qualora non siano specificate altre regole role_type_def per il ruolo

r1_r, autorizza r1_r solamente al dominio t1_t, quindi appartengono

allo spazio dei security context validi tutte le etichette in tt1r1_rU _×× ,

con Rrr1 ∈_ e Ttt1 ∈_ .

Mediante la specifica di più regole role_type_def relative allo stesso ruolo

r, è possibile definire l’insieme di tutti i domini ai quali r è autorizzato: tale

insieme è pari all’unione dei tipi specificati nelle regole role_type_def per

r.

Il costrutto role_dominance permette di organizzare i ruoli all’interno di

una gerarchia. In maniera analoga a quanto avviene nel modello RBAC

classico, in SELinux una gerarchia di ruoli che preveda un ruolo senior S ed

un ruolo junior J fa sì che un utente autorizzato a S sia, implicitamente,

autorizzato anche a J e che S sia autorizzato (implicitamente) a tutti i domini

ai quali è autorizzato J. Quanto detto si traduce, ovviamente, in un

ampliamento dello spazio dei security context validi.

Ad esempio, le regole:



dominance role r1_r role r2_r;


87

qualora non siano specificate altre regole role_decl e role_dominance

per i ruoli e i tipi r1_r, r2_r, t1_t e t2_t, autorizzano il ruolo r1_r al

dominio t1_t (esplicitamente) e al dominio t2_t (implicitamente) mentre

il ruolo r2_r è autorizzato solo al dominio t2_t. Questo significa che

appartengono allo spazio dei security context validi tutte le etichette in

tt1rr1U __ ×× , in tt2rr1U __ ×× e in tt2rr2U __ ×× , ma non

quelle in tt1rr2U __ ×× con Rr1_r ∈ e Tt1_t,t2_t ∈ .

In realtà l’implementazione del supporto alla creazione di gerarchie di ruoli

tramite il costrutto role_dominance è molto limitata e sembra necessitare

di un ridisegno radicale.

Nella configurazione di esempio non esiste alcuna regola role_dominance

e del resto il significato della sintassi del costrutto non è spiegato in nessun

documento, quindi la sua comprensione è lasciata all’esperimento personale

e ai pochi commenti sulla mailing list ufficiale di SELinux.

Inoltre, così come è implementata, la relazione di dominanza non risulta

essere transitiva e l’ordine in cui vengono specificate le regole

role_dominance sembra avere conseguenze sul risultato finale.

4.4 Configurazione del sottomodello UI

La configurazione del sottomodello UI prevede la sola specifica delle

IDENTITÀ SELINUX degli utenti, alle quali vengono assegnati i ruoli a cui sono

autorizzate. Questo viene fatto mediante il costrutto user_def per il quale

si hanno le seguenti produzioni:


88

user_def USER user_name ROLES authorized_role ;

user_name identifier

authorized_role identifier


I ruoli ai quali sono autorizzate le IDENTITÀ SELINUX devono essere dichiarati

nella configurazione del sottomodello RBAC.

Il precedente costrutto restringe lo spazio dei security context validi per i

soggetti a quelle etichette con valori compatibili per gli attributi IDENTITÀ

SELINUX e RUOLO. Ad esempio, la regola:

user u1_u roles r1_r;

qualora non siano specificate altre regole user_def per l’utente u1_u,

afferma che l’identità u1_u può essere associata al solo ruolo r1_r, ovvero

definisce il sottospazio Trr1uu1 ×× __ , con Uuu1 ∈_ e Rrr1 ∈_ .

Mediante la specifica di più regole user_def relative alla stessa identità u, è

possibile definire l’insieme di tutti i ruoli ai quali u è autorizzato: tale

insieme è pari all’unione dei ruoli specificati nelle regole user_def per u.

Inoltre, le IDENTITÀ SELINUX possono anche essere autorizzate implicitamente

a dei ruoli, qualora siano presenti nella configurazione delle regole

role_dominance.


89

4.5 Configurazione dei vincoli

La maggior parte della configurazione di una politica di sicurezza di

SELinux avviene per mezzo dei costrutti relativi ai tre sottomodelli sui quali

si basano le etichette dei soggetti e degli oggetti. In altre parole, il

comportamento del meccanismo di autorizzazione viene definito in maniera

“proiettiva” sui tre attributi IDENTITÀ SELINUX, RUOLO e TIPO.

Inoltre i diritti che vengono garantiti ai soggetti sono specificati solamente

in base all’attributo TIPO dei soggetti e degli oggetti, tramite regole

allow_def. Questo comporta, come già notato, che una singola regola

allow_def del TE per un tipo t si riferisca a tutti i security context validi

appartenenti al sottospazio tRU ×× , con Tt ∈ .

È possibile specificare dei vincoli che permettano di ridurre lo spazio dei

security context validi autorizzati ad una data modalità di accesso su oggetti

aventi un altro security context.

Questo permette di poter garantire i diritti di accesso ad un soggetto in base

a tutti gli attributi di sicurezza del suo security context, e non solamente in

base alla loro componente TIPO.

Il costrutto che permette di realizzare quanto detto è constraint_def, cui

sono associate le seguenti produzioni:


90

constraint_def CONSTRAIN class_name permission_name expr ;

class_name identifier

permission_name identifier

expr ( expr ) | ! expr | expr && expr | expr || expr | cexpr_prim

cexpr_prim U1 op U2 | R1 roleop R2 | T1 op T2 | U1 op user_id

| U2 op user_id

| R1 op identifier | R2 op identifier | T1 op identifier

| T2 op identifier

op == | !=

roleop op | DOM | DOMBY | INCOMP

ientifier IDENTIFIER

Il costrutto constraint_def impone che un dato diritto di accesso sia

garantito solamente se la condizione booleana rappresentata da expr sia

valutata vera. La detta condizione booleana permette di confrontare rispetto

all’uguaglianza le componenti dell’etichetta del soggetto (u1, r1, t1) con

quelle dell’etichetta dell’oggetto (u2, r2, t2); nel caso della componente

RUOLO, il confronto può avvenire anche rispetto alla relazione di dominanza,

qualora esista una gerarchia di ruoli specificata tramite regole

role_dom.inance. Ad esempio, si supponga di avere le regole:

type t1_t;

type t2_t;

allow_def t1_t t2_t : file create ;


91

Questo significa che i soggetti con etichetta in tt1RU _×× possono creare

file con una qualsiasi etichetta in tt2RU _×× . Tuttavia, qualora si

imponga il vincolo:

constrain file create ( u1 == u2 );

l’effetto totale è quello di garantire il diritto solamente a patto che le

componenti IDENTITÀ SELINUX di soggetto ed oggetto siano uguali, e quindi si

restringono rispetto alla prima componente i due sottospazi coinvolti dalla

regola allow_def. In questo caso, scriviamo che i security context coinvolti

sono quelli nei due sottospazi tt1Ru _×× e tt2Ru _×× , Uu∈∀ .

In realtà i vincoli hanno effetti ben più grandi, perché si applicano a tutte le

coppie di security context che soddisfino la condizione booleana. Con

riferimento all’esempio precedente, supponendo anche Ttt3 ∈_ ,

sarebbero vincolate anche le coppie in tt1Ru _×× , tt3Ru _×× e in

tt2Ru _×× , tt3Ru _×× , ma nella configurazione, potrebbero non

essere presenti le regole:



In altre parole mediante constraint_def si possono vincolare anche diritti

di accesso che non sono comunque garantiti dal meccanismo di

autorizzazione.


92

4.6 Classi di oggetti e modalità di accesso

Si è spiegato che nella configurazione del sottomodello TE vengono

specificate le modalità di accesso che possono essere garantite ai soggetti

sugli oggetti. Si è anche detto che i diritti sono definiti in VETTORI DI ACCESSO

associati alle classi degli oggetti.

La configurazione di una politica di sicurezza prevede che le classi degli

oggetti e i relativi diritti di accesso siano definiti in due appositi file di

configurazione, forniti con SELinux, e che non devono essere modificati.

Tali file vengono compilati, al pari di ogni altro file di configurazione,

nell’immagine binaria che il sistema ha della politica. Il linguaggio di

configurazione mette quindi a disposizione i costrutti relativi, anche se

questi non vengono utilizzati direttamente da chi configuri il sistema.

Riportiamo qui tali costrutti per completezza e perché verranno comunque

utilizzati nella definizione degli insiemi del modello formale presentato nel

prossimo capitolo.

Il costrutto class_def permette di dichiarare il nome di una classe di

oggetti. Le produzioni della grammatica relative sono molto semplici:

class_def CLASS identifier;


Il costrutto che permette invece di definire le modalità di accesso di una

classe di oggetti, ovvero il suo VETTORE DI ACCESSO, è access_vectors che

ha le seguenti produzioni:


93

access_vectors CLASS class_name permission_list ;

class_name identifier

permission_list identifier

| permission_list identifier


Il nome della classe specificato in access_vectors deve essere

precedentemente dichiarato, tramite class_def.

4.7 Configurazione delle transizioni di security context

La configurazione delle TRANSIZIONI DEI SECURITY CONTEXT è sicuramente la

parte più complessa di tutta la specifica di una politica di sicurezza in

SELinux. In realtà essa è il punto più delicato da trattare e la

documentazione disponibile sembra carente nella spiegazione delle relazioni

tra i vari costrutti coinvolti.

Principalmente sono utilizzati un costrutto relativo alla configurazione del

TE, uno relativo a quella del RBAC e gran parte della configurazione dei

vincoli.

Nel precedente capitolo si è detto che esiste un’interfaccia del kernel,

chiamata security_transition_sid, utilizzabile per ottenere decisioni

di etichettatura (di transizione). L’interfaccia è utile per ottenere l’etichetta

da assegnare ad un processo trasformato da una chiamata ad execve() o

quella per un nuovo oggetto creato. Il kernel di SELinux invoca questa

interfaccia ogni volta che un processo viene trasformato o un oggetto viene

creato.


94

Il risultato della computazione di security_transition_sid è calcolato

in base alle regole specificate nella politica di sicurezza per mezzo del

seguente costrutto TE:

type_transition TYPE_TRANSITION source_type related_type : class

transformed_type ;

source_type identifier

related_type identifier

class identifier

transformed_type identifier


type_transition, di per sé, non etichetta nulla, né autorizza nulla;

istruisce solamente il security server a restituire un determinato valore

quando vengono invocate delle chiamate di sistema standard di Linux (ad

esempio execve, o mkdir). La transizione deve essere autorizzata per

mezzo di apposite regole allow_def che garantiscano determinati diritti ai

soggetti responsabili della trasformazione dei processi o della creazione

degli oggetti.

Nel caso di transizioni di security context per processi trasformati, ovvero di

TRANSIZIONI DI DOMINI, l’insieme minimo di autorizzazioni che devono essere

specificate per mezzo del costrutto allow_def è il seguente:

allow A B : process transition ;

allow B C : file entrypoint ;

allow A C : file execute ;


95

La prima regola autorizza il processo a migrare dal dominio A a quello B; la

seconda definisce che C sia il tipo del programma ENTRYPOINT di B; l’ultima

regola permette ad un processo in A l’esecuzione del programma

ENTRYPOINT per B. Le tre regole precedenti, assieme alla regola

type_transition A C : process B ;

permettono ad un processo qualsiasi che giri nel dominio A di migrare

automaticamente nel dominio B all’esecuzione di un programma che abbia

tipo C.

Quindi una regola costruita con il costrutto type_transition che non sia

accompagnata da almeno tre regole di autorizzazione del tipo visto sopra,

non ha alcun effetto reale all’interno del sistema. In realtà, perché la

transizione di dominio, oltre ad essere consentita, abbia anche un’utilità, è

necessario in generale che siano specificate altre autorizzazioni per i domini

coinvolti. In particolare, con riferimento ai tipi sopra utilizzati, un generico

insieme di regole che potrebbe essere utile specificare in questo contesto è il

seguente20:

allow A C : file getattr ;

allow B A : process sigchld ;

allow B A : fd use ;

allow A B : fd use ;

allow B A : fifo_file ioctl read getattr lock write

append

allow B C : file read getattr lock execute ioctl

20 utilizziamo in questo paragrafo, per motivi di compattezza degli esempi, la versione non

normalizzata delle regole.


96

per permettere una comunicazione fra il vecchio ed il nuovo dominio e per

ereditare ed utilizzare le descrizioni dei file dai processi creatori e viceversa.

Nel caso di transizioni di security context per nuovi oggetti, ovvero di etichettatura

di oggetti appena creati, ad esempio files, un insieme ragionevole di

autorizzazioni che devono essere specificate per mezzo del costrutto

allow_def è il seguente:

allow A B : file create ioctl read getattr lock write

setattr append link unlink rename

allow A C : dir read getattr lock search add_name

remove_name write

La prima regola permette ad un processo che giri in un dominio A di creare

ed operare su un file con tipo B; la seconda regola permette al processo di

operare su una directory etichettata con tipo C. Se alle precedenti regole

viene aggiunta la regola:

type_transition A C : file B;

un qualsiasi file creato in una directory etichettata con il tipo C da un

processo che giri nel dominio A , viene automaticamente etichettato con il

tipo B.

Alla trasformazione di un processo, oltre a permettere transizioni di tipo per

la sua etichetta, è possibile anche effettuare delle transizioni di ruolo. Pe

specificare quali transizioni di ruolo siano ammesse, esiste un apposito

costrutto RBAC:


97

role_allow_def ALLOW from_role to_role ;

from_role identifier

to_role identifier


Una regola role_allow_def permette di specificare una transizione

consentita tra ruoli all’invocazione di una execve(), ovvero il nuovo ruolo

da dare ad un processo trasformato. Ad esempio, la regola:

allow user_r sysadm_r

permette di specificare che il ruolo user_r possa effettuare una transizione

a sysadm_r alla trasformazione del processo.

A differenza delle transizioni di dominio, RBAC non controlla la transizione

di ruolo in base al tipo del programma ENTRYPOINT specificato come

parametro nell’invocazione di execve(). Tuttavia, è possibile limitare molto

le transizioni e i cambiamenti di security context e ridurne la capacità

tramite un’opportuna configurazione dei vincoli; ad esempio, il vincolo:

constrain process : transition ( r1==r2 or t1==privrole);

dove privrole sia un attributo associato ad alcuni domini, non permette

ad un processo trasformato di avere l’attributo RUOLO differente da quello

del processo responsabile della trasformazione, a meno che il dominio in cui

esso venga eseguito non abbia attributo privrole.


98

Tramite i vincoli è possibile anche controllare i cambiamenti all’attributo

IDENTITÀ SELINUX di un security context:

constrain process : transition ( u1 == u2 ) ;

vieta la possibilità che un processo trasformato possa avere etichetta con

componente IDENTITÀ SELINUX differente da quella corrispondente

nell’etichetta del processo responsabile della trasformazione.

Il seguente esempio fa uso di tutte le regole che entrano in gioco alla

trasformazione di un processo:

Siano UvuRsrTcba ∈∈∈ ,,,,,, , privrole e privuser degli attributi di

tipi. Sia poi p un processo con etichetta (u,r,a) ed f un file eseguibile con

etichetta (v,object_r,c). Consideriamo il seguente insieme di regole di

configurazione:

1) allow a b : process transition ;

2) allow b c : file entrypoint ;

3) allow a c : file execute ;

4) type_transition a c : process b ;

5) allow r s

6) constrain process : transition (r1==r2 or t1==privrole)

7) constrain process : transition (u1==u2 or t1==privuser)

Quali sono le etichette valide per il processo p, quando questi viene

trasformato all’esecuzione di f?

Innanzitutto, il processo p ha la facoltà di eseguire f grazie alla regola 3. La

regola 2 specifica che f sia un programma ENTRYPOINT per il dominio b, nel

quale il processo p può entrare in virtù della regola 1. La regola 4 stabilisce


99

che sicuramente p, all’esecuzione di f viene confinato nel dominio b.

Quindi, tutte le etichette valide per p, all’esecuzione di f, hanno

componente TIPO pari a b.

Per quanto riguarda la componente RUOLO, r è sicuramente un valore valido

per la regola 6; s è valido solo nel caso in cui il tipo a abbia attributo

privrole (regole 5 e 6), mentre tutti gli altri eventuali valori non sono

validi. Infine, riguardo la componente IDENTITÀ SELINUX, è sicuramente

valido il valore u per la regola 7; sempre per la stessa regola però, risultano

validi anche tutti gli altri eventuali elementi di U qualora il tipo a abbia

attributo privuser.

Da quanto visto, determinare quali siano le transizioni di security context

consentite, e cosa esse comportino, è un’attività in generale molto difficile

da svolgere. I costrutti utilizzati sono diversi e sono relativi a differenti

componenti delle etichette di sicurezza, ma hanno degli effetti combinati

molto complessi.

Il linguaggio di configurazione di SELinux, seppure composto da non molti

costrutti, è quindi molto complicato, soprattutto per le implicazioni che

hanno combinazioni di regole differenti, appartenenti a sottomodelli

differenti. Per questo motivo nel prossimo capitolo mostriamo un modello

formale del controllo degli accessi di SELinux da noi costruito, chiamato

SELAC. Mostreremo come sia possibile, a partire dalle regole specificate nel

linguaggio, ricavare informazioni su una data configurazione. Descriveremo

infine, nel capitolo 6 un tool da noi realizzato che, utilizzando SELAC,

permetta di analizzare arbitrarie configurazioni di sicurezza di SELinux.

Capitolo V: Il modello formale SELAC

100

C a p i t o l o 5

Il modello formale SELAC

Nei capitoli precedenti si è visto come il sistema SELinux realizzi un

controllo degli accessi mandatorio particolarmente complesso, che trova le

proprie basi teoriche in modelli noti in letteratura. È stato descritto un

linguaggio di configurazione, da noi chiamato SEL, utilizzabile per la

specifica di politiche di sicurezza e si è detto che una delle caratteristiche più

importanti del sistema è che esso sia neutrale rispetto alle politiche che

possono essere imposte. Il fatto che, a differenza di altri modelli, come ad

esempio LBAC, SELinux sia neutrale rispetto alle politiche pone il

problema di determinare se, effettivamente, una sua data configurazione

raggiunga gli obiettivi che un amministratore di sicurezza voglia prefiggersi.

A causa del fatto che il linguaggio di configurazione è tale che il livello di

dettaglio arrivi sino alla specifica dei singoli permessi che devono essere

garantiti ai soggetti, e a causa del fatto che vengono utilizzati differenti

costrutti appartenenti ai differenti livelli di astrazione dei sottomodelli

utilizzati, la relazione che una data configurazione ha con gli obiettivi per la

quale essa è stata scritta, in generale non è ovvia.

Una configurazione di sicurezza in SELinux tende ad essere molto lunga,

dettagliata e complessa e coinvolge un grandissimo numero di entità

(soggetti, oggetti, classi di oggetti, diritti di accesso, …): ciò rende

impossibile determinare con una semplice ispezione se una data

configurazione raggiunga o meno determinati obiettivi di alto livello (ad

esempio se garantisca la CONFIDENZIALITÀ o l’INTEGRITÀ dei dati). Per rendere

possibile una effettiva analisi, sembra quindi chiaramente necessario il


101

supporto di tool che possano essere forniti ai membri della comunità di

utilizzatori del sistema, per verificare la correttezza delle proprie

configurazioni. Tali tool, necessariamente, devono essere costruiti a partire

da modelli formali che descrivano cosa analizzare e come farlo.

Rispetto alla correttezza di una data configurazione della politica di

sicurezza, tre sono in generale gli aspetti che vanno determinati: se la

politica sia compilata correttamente, se, cioè, la sua forma interna (nel caso di

SELinux, quella comprensibile dal security server) sia equivalente alla sua

definizione; se la politica sia effettivamente realizzata nel sistema, ovvero, se

le decisioni del security server siano poi imposte dai meccanismi interni (gli

object manager); infine, se una data configurazione, in base alla semantica

dei costrutti del linguaggio utilizzato, raggiunge determinati obiettivi di sicurezza,

ovvero se le decisioni prese dal security server sono quelle “corrette”

rispetto ai fini di colui che ha configurato il sistema (l’amministratore di

sicurezza).

Le tre verifiche sopra elencate richiedono che vengano svolte differenti

attività; in particolare, le prime due riguardano un aspetto implementativo,

perché richiedono la verifica del codice, rispettivamente, del compilatore

della politica (attualmente, il programma fornito a corredo con SELinux,

chiamato checkpolicy) e del TCB del sistema (soprattutto security server

ed object manager). Lo scopo principale di questa tesi riguarda invece la

terza caratterizzazione della correttezza, che è indipendente dal codice e dai

dettagli implementativi del sistema.

Il fine ultimo del nostro lavoro è quello di produrre una serie di strumenti

utili alla formulazione di una metodologia che permetta agli sviluppatori e

agli amministratori di sicurezza di analizzare le proprie configurazioni. Il

primo passo verso ciò è stato compiuto nel capitolo precedente, nel quale è


102

stata definita precisamente la semantica del linguaggio di configurazione di

SELinux. Tale operazione è chiaramente alla base della possibilità di provare

le eventuali proprietà di una politica specificata tramite il linguaggio.

Quello che viene fatto in questo capitolo è la definizione di un modello

formale del linguaggio di configurazione SEL. Lo scopo del modello è

quello di passare dalla descrizione informale del linguaggio presente in

[Sm02, TT02a, TT02b, LS01a], fornita soprattutto per esempi, ad una sua

descrizione formale. Questo per permettere di catturare le interrelazioni che

si creano tra le varie regole che compongono la specifica di una politica di

sicurezza.

In altre parole, lo scopo ultimo del modello da noi sviluppato, chiamato

SELAC (SELinux Access Control), è quello di fornire una solida base per

modellare formalmente il controllo degli accessi di SELinux, a partire dal

suo linguaggio di configurazione. In particolare, come esempio di sua

possibile applicazione, mostreremo come SELAC permetta di determinare

se un dato soggetto possa accedere ad un determinato oggetto. Determinare

ciò non è semplice vista la complessità di una generica configurazione.

L’importanza principale del modello SELAC, e di altri modelli creati con

scopi analoghi (ad esempio quello in [ALP02]) va ricercata quindi nell’utilità

che tali modelli hanno nella creazione di tool di supporto che possano

essere utilizzati per la comprensione di un sistema di configurazione

complesso quale è quello di SELinux.

5.1 SELinux Access Control

SELAC definisce una serie di insiemi che contengono le informazioni

relative alla configurazione di una politica di sicurezza, specificata mediante


103

il linguaggio SEL. Per ogni insieme viene fornita la definizione e viene

descritto il modo per derivarlo a partire dalle regole di configurazione. La

derivazione viene fatta per mezzo di algoritmi che permettono la

costruzione dei vari insiemi. Gli algoritmi qui forniti non sono i migliori che

possano essere pensati, ma sono sicuramente i più semplici ed hanno il solo

scopo di mostrare come sia possibile derivare gli insiemi di interesse.

Riguardo un’implementazione efficiente del modello è possibile far

riferimento a testi di algoritmi e strutture dati (come ad esempio [CLR]) che

trattino il tipo di dato insieme.

Abbiamo scelto di definire il modello in termini di insiemi, perché la

maggior parte delle verifiche che possono essere fatte su una data

configurazione sono esprimibili mediante semplici operazioni insiemistiche.

Inoltre, siamo convinti che un simile modello possa essere facilmente

visualizzato per mezzo di una rappresentazione grafica, simile a quella

presentata in [JT01], che faccia uso di grafi, i cui nodi corrispondono agli

insiemi del modello e gli archi alle relazioni binarie che intercorrono tra gli

insiemi.

Come si è visto nel precedente capitolo, una generica regola di

configurazione di SELinux è formata dal nome della regola seguito da una

serie di valori per dei campi che identificano alcuni elementi base del

controllo degli accessi.

Con il termine elemento base del modello, intendiamo uno fra i seguenti

concetti: IDENTITÀ SELINUX, RUOLO, TIPO, ATTRIBUTO, CLASSE DI OGGETTI, DIRITTO

DI ACCESSO.

Classificando gli elementi base in insiemi, è comodo rappresentare una

regola di configurazione tramite una notazione funzionale, in cui il nome


104

della regola sia il nome della funzione, ed i campi della regola compongano

la segnatura della funzione, ovvero corrispondano ai suoi parametri.

Ad esempio, la regola:

type_transition T1 T2 : C T3

può essere rappresentata tramite una funzione

type_transition(T1, T2, C, T3)

con T1, T2 e T3 appartenenti all’insieme dei tipi e C a quello delle classi di

oggetti del sistema.

Quindi agli undici costrutti di SEL corrispondono undici funzioni ed alle

regole di configurazione corrispondono altrettante applicazioni di funzioni.

Nel prossimo paragrafo definiamo gli insiemi fondamentali di SELAC,

mentre in quello successivo mostriamo come questi insiemi possano essere

utilizzati per risolvere problemi relativi alla determinazione dell’accessibilità

dei soggetti agli oggetti.

Molti degli insiemi definiti sono relativi ad elementi base del modello (o a

loro aggregati): ad esempio un VETTORE DI ACCESSO contiene tutti i diritti di

accesso rispetto ad una specifica classe. Per questo motivo utilizziamo per

questi insiemi la seguente notazione funzionale:

X(y1, ..., yn)

dove y1, ... , yn sono gli elementi base del modello (o dei loro aggregati) ai

quali si riferisce l’insieme. La precedente notazione può anche essere


105

interpretata nel seguente modo: un insieme è rappresentato tramite una

funzione che restituisca gli elementi ad esso appartenenti.

Questa notazione risulta particolarmente utile perché permette di riunire

tutti gli insiemi che condividono una stessa semantica sotto uno stesso

nome (X) e permette allo stesso tempo di stabilire l’associazione tra un

insieme e gli elementi del modello ai quali esso si riferisca (y1, …, yn).

Ritornando all’esempio dei diritti di accesso, mediante la notazione adottata,

è possibile esprimere i vettori di accesso delle due classi file e process

tramite P(file) e P(process): entrambi gli insiemi condividono la stessa

semantica, rappresentata da P (quella di essere insiemi di diritti di accesso),

ma si riferiscono a due elementi base differenti (le due classi file e

process).

5.2 Insiemi e funzioni fondamentali

L’insieme A è l’insieme degli attributi che possono essere associati ai domini

dei soggetti e ai tipi degli oggetti. Un generico tipo può avere una lista

arbitraria di attributi, appartenenti a questo insieme. Mediante l’analisi delle

regole attribute_def è possibile costruire A:

1. ∅←A

2. Per ogni regola del tipo attribute_def(a) :

aAA ∪←


106

L’insieme T è l’insieme dei domini per i soggetti e dei tipi per gli oggetti21.

Tutte le etichette di sicurezza devono avere come componente TIPO un

elemento di questo insieme. Mediante l’analisi delle regole type_def

utilizzate per la configurazione del sottomodello TE è possibile costruire

l’insieme:

1. ∅←T

2. Per ogni regola del tipo type_def(t, a1, a2, … ,an) :

tTT ∪←

con Aaaa n ∈,...,, 21

È comodo anche definire una famiglia di insiemi associati ai tipi, ognuno dei

quali contenga gli attributi di uno dei tipi. Ogni elemento A(t) di questa

famiglia è derivabile dalle regole type_def:

Dato Tt ∈ :

1. ∅←)(tA

2. Per ogni regola del tipo type_def(t, a1, a2, … ,an) :

,...,,)()( 21 naaatAtA ∪←

con Aaaa n ∈,...,, 21

A partire dagli insiemi precedenti, possiamo definire una funzione 2: TA →α , che restituisca l’insieme di tutti i tipi che hanno un

determinato attributo:

21 Si ricordi che SELinux utilizza un’unica astrazione, quella di tipo, sia per i domini dei

soggetti sia per i tipi degli oggetti


107

Dato Aa∈ :

)(|)( tAaTta ∈∈=α

La funzione α è utile perché in SEL, come si è visto, ogni regola che abbia

un campo per un nome di tipo, può specificare un nome di attributo al

posto di quello del tipo.

L’insieme R contiene i ruoli che possono essere attivati dai soggetti. Tutte le

etichette di sicurezza che si riferiscono a soggetti devono avere come

attributo RUOLO un elemento di questo insieme. Inoltre, assumiamo che

l’insieme contenga l’elemento object_r, in maniera tale che anche tutte le

etichette di sicurezza per gli oggetti abbiano come attributo RUOLO un

elemento di R.

L’insieme può essere facilmente costruito, in base alle regole

role_type_def specificate nella configurazione del sottomodello RBAC:

1. _ robjectR ←

2. Per ogni regola del tipo role_type_def(r,t) :

rRR ∪←

con Tt ∈

L’insieme U è l’insieme delle IDENTITÀ SELINUX. Tutte le etichette di sicurezza

devono avere come attributo IDENTITÀ SELINUX un elemento di questo

insieme. L’insieme U può essere definito in maniera costruttiva a partire

dalle regole user_def specificate nella configurazione del sottomodello UI:


108

1. ∅←U

2. Per ogni regola del tipo user_def(u,r) :

uUU ∪←

con Rr ∈

Chiamiiamo spazio dei security context l’insieme O definito come:

,,|),,( TtRrUutruO ∈∈∈=

L’insieme O definisce il prodotto cartesiano TRU ×× , ed è l’insieme al

quale appartengono tutte le etichette di sicurezza del sistema, sia per i

soggetti sia per gli oggetti. In generale, non è detto che un qualsiasi

elemento di O sia un’etichetta di sicurezza valida, perché le regole di

configurazione impongono dei vincoli sulle combinazioni legali degli

attributi di sicurezza che compongono un security context. Ciò verrà

chiarito nel seguito, quando definiremo i sottospazi dei security context

validi.

È utile definire sullo spazio dei security context tre funzioni proiettive,

TOOT →:# , ROO

R →:# e UOOU →:# , che restituiscano le tre

componenti di un’etichetta. La loro definizione è la seguente:

Dato Ostrus ∈= ),,,( :

tsOT =)(#

rsOR =)(#

uoOU =)(#


109

Il modello di controllo degli accessi di SELinux, come si è visto, permette di

specificare una gerarchia tra gli attributi di sicurezza relativi ai ruoli: questo

avviene per mezzo delle regole role_dominance. Dato un generico ruolo

s, l’insieme ↓D(s) contiene tutti e soli i ruoli junior di s. È facile derivare

l’insieme nel seguente modo:

Dato Rs∈ :

1. ∅←↓ )(sD

2. Per ogni regola del tipo role_dominance(s,j) :

)()( jsDsD ∪←↓↓

con Rj∈

Una volta definiti gli insiemi U, R, T e la famiglia degli insiemi ↓D(s) per

tutti i ruoli s, è possibile definire gli insiemi R(u) dei ruoli ai quali è

autorizzata una data identità SELinux u, e quello dei domini T(r) nei quali

può entrare un dato ruolo r, a partire, rispettivamente, dalle regole

user_def e role_type_def.

Formalmente:

Dato Uu∈ :

1. ∅←)(uR

2. Per ogni regola del tipo user_def(u,r) :

)()( ruRuR ∪←

con _ robjectRr −∈

3. Per ogni ruolo )(' uRr ∈

)'()()( rDuRuR ↓∪←


110

e

Dato Rr∈ :

1. ∅←)(rT

2. Per ogni regola del tipo role_type_def(r,t) :

)()( trTrT ∪←

con Tt ∈

3. Per ogni regola del tipo role_type_def(r,a) :

)()()( arTrT α∪←

con Aa∈

4. Per ogni ruolo )(' rDr ∈↓

)'()()( rTrTrT ∪←

Si noti come, in entrambi i casi, sia formalizzato l’effetto di una eventuale

relazione di dominanza tra i ruoli: in R(u) rientrano anche tutti i ruoli junior

di un arbitrario ruolo al quale sia autorizzato u e in T(r) rientrano anche tutti

i domini ai quali è autorizzato un qualsiasi ruolo junior di r.

Come accennato precedentemente, non è detto che un generico security

context, appartenente allo spazio O, sia valido nel sistema. Infatti, le

combinazioni valide dei valori per le componenti delle etichette sono

stabilite tramite apposite regole di configurazione e quindi sono vincolate.

Per formalizzare questo genere di restrizioni, definiamo l’insieme S, OS ⊂ ,

che chiamiamo spazio dei security context validi per i soggetti:

)(),(,|),,( rTtuRrUuOtruS ∈∈∈∈=


111

Lo spazio S definisce tutte e sole le etichette che possono essere assegnate

ai soggetti, valide in una data configurazione del sistema. Tutti i soggetti,

quindi, sono etichettati con elementi in questo spazio. Nell’insieme O-S

restano invece definite le etichette valide per gli oggetti e tutte le etichette

che non appartengono ad entità del sistema e che quindi non hanno alcuna

validità.

L’insieme C è l’insieme delle classi degli oggetti. Tutti i diritti di accesso

garantiti ai soggetti sugli oggetti devono essere definiti su un elemento di

questo insieme. L’insieme P(c) è l’insieme delle modalità di accesso

supportate dalla classe c, ovvero il VETTORE DI ACCESSO di c. Siccome in

SELinux si possono avere nomi uguali per diritti di accesso appartenenti a

classi di oggetti differenti (ad esempio i diritti read e write per le classi

file e dir) e quindi due generici diritti di accesso possono essere, pur

semanticamente differenti, sintatticamente uguali, utilizziamo

l’accorgimento di specificare un diritto di accesso come una coppia, in cui la

prima componente indichi la modalità di accesso e la seconda componente

indichi la classe a cui tale modalità di accesso fa riferimento. In questo

modo non esistono problemi di sovrapposizione di nomi.

I due insiemi possono essere definiti in maniera costruttiva a partire dalle

regole class_def e access_vector:

1. ∅←C

2. Per ogni regola del tipo class_def(c):

cCC ∪←

e


112

Dato Cc∈ :

1. ∅←)(cP

2. Per ogni regola del tipo access_vector(c, p1, p2, … , pn) :

),(),...,,(),,()()( 21 cpcpcpcPcP n∪←

L’insieme dei diritti di accesso P è semplicemente l’unione degli insiemi P(c)

per tutte le classi di oggetti definite:

UCc

cPP∈

= )(

Una volta definiti l’insieme delle classi degli oggetti e gli insiemi

corrispondenti ai vettori di accesso delle classi, è possibile definire l’insieme

dei PERMESSI RISPETTO AL TIPO di un dato dominio. Con il termine permesso

rispetto al tipo, intendiamo una coppia, appartenente al prodotto

cartesiano PT × . In altre parole un permesso rispetto al tipo altro non è

che una coppia in cui la prima componente è il tipo di un oggetto e la

seconda componente è un diritto di accesso. Un dominio che abbia il

permesso rispetto al tipo (t,(p,c)), a meno di vincoli specificati in altre

regole di configurazione, può utilizzare il diritto di accesso p su tutti gli

oggetti della classe c aventi tipo t. Ovviamente p deve essere nel vettore di

acceso per c.

L’insieme dei permessi rispetto al tipo di un dato dominio, M(s), è

equivalente all’unione delle due matrici DDT e DIT del TE classico e può

essere costruito a partire dalle regole allow_def:


113

Dato Ts∈ :

1. ∅←)(sM

2. Per ogni regola del tipo allow_def(s,t,c,p) :

),()()( ptsMsM ∪←

con )(,, cPpCcTt ∈∈∈

3. Per ogni regola del tipo allow_def(s,a,c,p) :

3.1 Per ogni )(ati α∈

),()()( ptsMsM i∪←

con AacPpCc ∈∈∈ ),(,

4. Per ogni regola del tipo allow_def(a,t,c,p) :

4.1 Se )(as α∈

),()()( ptsMsM ∪←

con AacPpCcTt ∈∈∈∈ ),(,,

5. Per ogni regola del tipo allow_def(a1,a2,c,p) :

5.1 Se )( 1as α∈

5.1.1 Per ogni )( 2ati α∈

),()()( ptsMsM i∪←

con AaacPpCc ∈∈∈ 21,),(,

Definiamo inoltre due funzioni proiettive di utilità generale,

TPTPTT →×× :# e PPTPT

P →×× :# , che restituiscano le due componenti

di un dato permesso rispetto al tipo:


114

Dato PTqptq ×∈= ),,( :

tqPTT =× )(#

pqPTP =× )(#

Definiamo una funzione booleana, ,: falsoveroPOS →××γ , che

verifichi se esiste un vincolo che vieti ai soggetti con un dato security

context di accedere in un determinato modo ad oggetti con un altro dato

security context. La funzione può essere definita in maniera estensiva a

partire dalle regole di configurazione constraint_def. Con la notazione

osexpr

,intendiamo il risultato di verità della valutazione dell’espressione

expr in base ai valori degli attributi di sicurezza di s e di o:

1. Per ogni PpOoSs ∈∈∈ ,,

falsopos =),,(γ

2. Per ogni regola del tipo constraint_def(c,p’,expr) :

2.1 Per ogni OoSs ∈∈ , tali che veroexpros=

,

veropos =)',,(γ

con )(', cPpCc ∈∈

Definiamo l’insieme Do(s), relativo alle decisioni prese dal security server

riguardo all’etichettatura di nuovi oggetti creati. Do(s) contiene terne del tipo

TCTnct ××∈),,( , che indichino, rispettivamente, il tipo dell’oggetto

correlato, la classe dell’oggetto da etichettare ed il tipo da assegnare

all’oggetto creato.


115

L’insieme è derivato a partire dalle regole type_transition22:

Dato Ts∈ :

1. ∅←)(sDo

2. Per ogni regola del tipo type_transition(s,t,c,n) :

),,()()( nctsDsD oo ∪←

con ,, processCcTnt −∈∈

In maniera simile è possibile derivare l’insieme Dp(s), delle decisioni del

security server riguardanti l’etichettatura di un processo trasformato;

l’insieme contiene delle coppie indicanti il tipo da assegnare al processo

trasformato ed il tipo del programma ENTRYPOINT mediante il quale si

effettua la trasformazione:

Dato Ts∈ :

1. ∅←)(sDp

2. Per ogni regola del tipo type_transition(s,e,process,t) :

),()()( etsDsD pp ∪←

con Tet ∈,

Ricordiamo che perché le transizioni di tipo avvengano in base alle

informazioni codificate dagli elementi dei due insiemi Dp(s) e Do(s), è

necessario che s abbia determinati permessi rispetto al tipo, contenuti

nell’insieme M(s).

22 Per brevità, da qui in poi, non prendiamo in considerazione la possibilità di utilizzare dei

nomi di attributo al posto di quelli di tipo.


116

Infine, definiamo l’insieme )(sR→

dei ruoli ai quali un dato ruolo s può

effettuare una transizione alla trasformazione di un processo. Assumiamo

)(sRs→

∈ . L’insieme può essere costruito a partire dalle regole

role_allow_def, nel seguente modo:

Dato Rs∈ :

1. ssR ←→

)(

2. Per ogni regola del tipo role_allow_def(s,r) :

)()( rsRsR ∪←→→

con Rr ∈

5.3 Insiemi derivati

Gli insiemi precedentemente definiti sono gli insiemi fondamentali del

modello: tramite essi, è possibile formalizzare una data configurazione di

SELinux. Molti altri insiemi utili, per fini di analisi, possono essere definiti a

partire dalle regole di configurazione o, equivalentemente, essere derivati a

partire dagli insiemi fondamentali. Riportiamo qui solamente alcuni esempi

di insiemi derivati di particolare interesse.

L’insieme di tutti i ruoli senior di una dato ruolo è il seguente :

Dato Rj∈ :

)(|)( sDjRsjD ∈↓∈=↑


117

L’insieme di tutte le identità SELinux che possono assumere un determinato

ruolo è il seguente :

Dato Rr ∈ :

)(|)( uRrUurU ∈∈=

L’insieme di tutti i ruoli che possono entrare in un determinato dominio è23 :

Dato Tt ∈ :

)(|)( rTtRrtR ∈∈=

L’insieme di tutti i tipi dei soggetti che hanno un dato diritto di accesso su

oggetti con un dato tipo è il seguente24 :

Dati PpTt ∈∈ , :

)(),(|),( sMptTsptM ∈∈=

L’insieme di tutti i tipi dei programmi entrypoint per un dato dominio è il

seguente:

Dato Tt∈ :

eptMpTetE PTT =∈∃∈= × )(|#)(|)( e ),()(# fileentrypointpPT

P =×

23 Gli insiemi R(u) ed R(t), nonostante abbiano un nome simile, sono completamente

differenti e non vanno confusi 24 Sebbene abbiano nomi simili, gli insiemi M(s) e M(t,p) non vanno confusi


118

Rispetto alla componente TIPO dei security context, le transizioni consentite,

a partire da un tipo dato, possono essere rappresentate da coppie, nelle quali

la prima componente indica il tipo verso il quale effettuare la transizione e la

seconda il tipo del programma ENTRYPOINT da eseguire :

Dato Ts∈ :

),()(#,)(|#)(,|),()( processtransitionptpsMqpTTetsT PTP

PTT ==∈∃×∈= ××

→

e ),()(#),(,)(# fileexecuteqtEeeq PTP

PTT =∈= ××

Di particolare interesse è l’insieme dei tipi a cui un dato dominio può

effettuare una transizione automatica:

Dato Ts∈ :

)()(),(|)(|)( sTsDettEeTtsT p

→⇒

∩∈∈∃∈=

Si noti che, mentre )(sT⇒

è un insieme di tipi, )(sT→

è un insieme di coppie di

tipi. In realtà si può dimostrare che la specificazione del tipo del programma

ENTRYPOINT negli elementi di )(sT→

non è una semplice comodità, ma è

necessaria. Si consideri, infatti, la seguente definizione per l’insieme )(sT→

:

),()(#,)(|#)(,|)( processtransitionptpsMqpTtsT PTP

PTT ==∈∃∈= ××

→

e

),()(#),()(# fileexecuteqtEq PTP

PTT =∈ ××


119

In questo caso, la seguente definizione per )(sT⇒

non sarebbe corretta:

)(),(|)(|)( sDettEeTtsT p∈∈∃∈=⇒

e )(sTt→

∈ 25 perchè:

• )(tEe∈ implica che esista nella configurazione una regola del tipo:

allow(t,e,file,entrypoint)

• )(),( sDet p∈ implica che esista nella configurazione una regola del

tipo: type_transition(s,e,process,t)

• )(sTt→

∈ implica che esistano nella configurazione delle terne di

regole del tipo: allow(s,t,process,transition)

allow(s,e’,execute,file)

allow(t,e’,file,entrypoint)

In generale, visto che un dominio può avere più di un punto di ingresso, e

non coincide necessariamente con e’. Ad esempio, il seguente insieme di

regole :

1) allow(t,e1,file,entrypoint)

2) allow(s,t,process,transition)

3) allow(s,e2,execute,file)

4) allow(t,e2,file,entrypoint)

5) type_transition(s,e1,process,t)

con le due ultime definizioni di )(sT→

e )(sT⇒

, garantirebbe che s possa

effettuare una transizione automatica a t. Infatti 2), 3) e 4) implicano che s 25 Le due ultime definizioni corrispondono alle precedenti, ma fanno riferimento ad un

insieme )(sT→

costituito da tipi e non da coppie di tipi


120

possa effettuare una transizione a t, ovvero )(sTt→

∈ , e 5) che t sia

compatibile con una decisione di etichettatura per la trasformazione di s,

cioè )(),(|)( sDettEe p∈∈∃ . In realtà la transizione automatica non è

possibile, perché la decisione di etichettatura è relativa ad un determinato

entrypoint (e2) e la possibilità di transizione ad un altro (e1).

Il problema non si pone mantenendo in ogni elemento di )(sT→

l’informazione relativa al tipo del programma entrypoint attraverso il quale

effettuare la transizione.

Infine, possono essere utili gli insiemi corrispondenti alle chiusure transitive

di )(sT⇒

e )(sT→

, indicanti tutti i tipi raggiungibili tramite transizione

(automatica o meno) a partire da un determinato tipo iniziale. I due insiemi,

rappresentati tramite )(*

sT→

e )(*

sT⇒

, possono essere costruiti nel seguente

modo:

Dato Ts∈ :

1. )()(*

sTsT→→

←

2. )(*

sTt→

∈∀ , )()()(**

tTsTsT→→→

∪←

e

Dato Ts∈ :

1. )()(*

sTsT⇒⇒

←

2. )(*

sTt⇒

∈∀ , )()()(**

tTsTsT⇒⇒⇒

∪←


121

I due precedenti insiemi sono particolarmente utili per determinare se un

soggetto con un determinato tipo possa accedere, tramite una serie finita di

sue trasformazioni, ad un oggetto con un particolare tipo. Questo permette

di determinare se la compromissione di un soggetto possa, potenzialmente,

permettere ad un’attaccante di ottenere un accesso ad un dato oggetto,

alterando il normale flusso di controllo per quel soggetto.

5.4 Spazi di accessibilità

Fino ad ora sono stati definiti una serie di insiemi a partire dalle regole di

configurazione scritte con il linguaggio SEL e si è visto come ogni regola

contribuisca alla costruzione di almeno uno di questi insiemi. Come si è

detto in precedenza SEL permette di specificare una determinata politica di

controllo degli accessi mediante dei costrutti che si applicano in maniera

proiettiva alle componenti dei security context. Ad esempio, una regola

allow_def si applica solamente alle componenti TIPO delle etichette del

soggetto e dell’oggetto coinvolti. Questo implica che una data regola abbia

effetti non su singole coppie di security context, ma piuttosto su coppie di

loro sottospazi; precisamente su tutte quelle coppie di security context che

soddisfino una serie di requisiti propri del tipo di regola in questione:

allow tipo1 tipo2 : c p ;

in assenza di altre regole che impongano dei vincoli, si applica a tutti i

security context di soggetti ed oggetti appartenenti, rispettivamente, a

tipo1RU ×× e a tipo2RU ×× . La regola non dice nulla riguardo alle

componenti IDENTITÀ SELINUX e RUOLO dei security context coinvolti, quindi,


122

da sola, va interpretata come applicabile in maniera libera rispetto ad esse.

L’aggiunta di altre regole appartenenti ai modelli RBAC e alla

configurazione dei vincoli, tuttavia, può cambiare radicalemente gli effetti

complessivi, riducendo o ampliando i sottospazi dei security context

coinvolti.

Se da una parte questo schema di configurazione è comodo perché

permette di impostare una politica di controllo degli accessi rispetto a più

livelli di astrazione (corrispondenti ai sottomodelli TE, RBAC, UI e alla

configurazione dei vincoli), dall’altra introduce notevoli difficoltà nel capire

esattamente l’effetto complessivo di un insieme di regole che facciano

riferimento a quei diversi livelli di astrazione.

Il problema che si pone ora è il seguente: la politica di controllo degli accessi

in SELinux è costituita da regole di configurazione relative a differenti

componenti di un security context. Tuttavia il controllo degli accessi

avviene sui security context considerati nella loro interezza. Per rispondere

quindi a domande simili alla seguente: “può un dato soggetto accedere ad un dato

oggetto?”, è necessario, a partire dagli insiemi sopra definiti, relativi agli

elementi base del modello, definire degli insiemi sui security context che

tengano in considerazione contemporaneamente tutte le componenti di

un’etichetta di sicurezza. Tali insiemi prendono il nome di SPAZI DI

ACCESSIBILITÀ. Alcune delle idee presenti in [JEZ02] sono simili a quelle qui

esposte.

Già si è definito l’insieme S dei security context validi per i soggetti. Per

prima cosa, definiamo qui l’insieme dei security context validi per gli oggetti.

È utile derivare, per ogni classe di oggetti c, un sottoinsieme O(c) dello

spazio dei security context O, che contenga tutti e soli i security context

applicabili ad oggetti di c. Chiamiamo O(c) spazio dei security context

validi per gli oggetti della classe c.


123

Imponendo SprocessO =)( , segue UCc

cOS∈

⊂ )( , ovvero l’insieme dei

soggetti (rappresentato dalle etichette che essi possono avere) può essere

visto, rispetto al controllo degli accessi, come un sottoinsieme di quello

degli oggetti (anch’esso rappresentato dalle etichette che essi possono

avere), in accordo con quanto si ritrova in genere in letteratura

In SEL non esistono costrutti che permettano di derivare direttamente quali

etichette di sicurezza siano valide per oggetti appartenenti ad una data

classe. Si pone quindi il problema di derivare gli insiemi O(c). La

componente RUOLO di tali etichette, già sappiamo essere pari ad object_r.

Quindi, sicuramente, TrobjectUcO ××⊆ _)( .

In realtà, per motivi pratici, sarebbe utile restringere questo spazio a tutti i

security context per oggetti che siano accessibili da qualcuno in un qualche

modo. Infatti, se è vero che, in generale, le componenti IDENTITÀ SELINUX e

TIPO di un’etichetta per un oggetto, possono essere arbitrari elementi,

rispettivamente, in U e T, nella realtà un’etichetta per un oggetto che non sia

accessibile in nessun modo da alcun soggetto non ha alcuna utilità di

esistere e probabilmente la sua presenza è causata solamente da una errata

configurazione del sistema.

La precedente osservazione ci autorizza a pensare di poter restringere il

sottospazio TrobjectU ×× _ , ad un insieme di terne con valori

“ragionevoli” per i campi IDENTITÀ SELINUX e TIPO. Un possibile approccio

alla restrizione del sottospazio rispetto alla componente TIPO potrebbe

essere quello di imporre una metodologia di configurazione che preveda,

per ogni tipo definito, l’associazione di un attributo che stabilisca a quale


124

classe di oggetti si applica quel tipo26. Nella configurazione di esempio

fornita a corredo con SELinux, tutti i tipi relativi a file convenzionali hanno

un attributo chiamato file_type. In questo modo potremmo definire

)_(,_)(|#)( typefiletrobjectoOofileO OR α∈=∈= .

In realtà questo approccio non è soddisfacente perché file_type non è

definito nel linguaggio di configurazione, quindi non ha semantica rispetto

ad esso; è solamente un nome di attributo arbitrario, inserito nella

configurazione dall’amministratore di sicurezza per motivi pratici. Così

facendo, si lascerebbe nelle mani di costui la responsabilità di associare gli

attributi ai tipi ed un suo errore porterebbe a dei risultati di analisi

incompleti.

SELAC non deve assolutamente dipendere da scelte operate in una

particolare configurazione, ma deve essere definito solamente rispetto al

linguaggio con il quale viene configurato il sistema.

La scelta che a noi è sembrata più ragionevole è stata quella di ricavare i

possibili tipi da assegnare alle etichette degli oggetti, a partire dalle regole

TE allow_def. Del resto le regole allow_def definiscono esattamente

cosa possa avvenire nel sistema, per cui, guardando a qualcosa di simile a:

allow_def(s,o,c,p)

è ragionevole dedurre che esistano oggetti della classe c con tipo o e che

questi siano accessibili da qualcuno (che abbia tipo s). Questo approccio si

basa unicamente sulla struttura del linguaggio di configurazione e non su

26 questo approccio è stato proposto, nella mailing list ufficiale, da uno degli sviluppatori di

politiche di SELinux


125

linee guida (che potrebbero essere seguite o ignorate) su come scrivere una

data configurazione. Quindi, nel caso in cui la classe non sia process, è

ragionevole restringere O(c) allo spazio:

robjectoOocO OR _)(|#)( =∈= e )()),((#|∃ tMpoTtP(c)p O

T ∈∈∃,∈

Per chiarezza, scriviamo anche un possibile algoritmo per derivare gli

insiemi O(c) a partire da una data configurazione scritta in SEL:

1. SprocessO ←)(

Dato processCc −∈ :

2. Per ogni regola del tipo allow_def(t1,t2,c,p) :

_)(#,)(|#)()( 2 robjectotoOocOcO OR

OT ==∈∪←

con )(,, 21 cPpTtt ∈∈

Una restrizione dello spazio O(c) rispetto alla componente IDENTITÀ SELINUX

sembra essere cosa assai più ardua, a causa del fatto che, qualora fosse

possibile, richiederebbe la verifica non di singole regole ma di loro insiemi.

A tale scopo, sono stati analizzati diversi approcci, ma nessuno si è rivelato

soddisfacente: o gli insiemi dedotti erano troppo piccoli e quindi non

comprendevano casi sicuramente possibili, oppure la loro determinazione

era troppo complessa e quindi impraticabile. Un’analisi riguardo la

possibilità di restringere gli spazi O(c) rispetto alla componente IDENTITÀ

SELINUX necessita di ulteriore studio.

Facciamo notare, tuttavia, come, a nostro avviso, sia comunque ragionevole

e soddisfacente, in questo contesto, considerare tutto l’insieme U.

Innanzitutto, abbiamo detto che il security context di un oggetto può, in

generale, avere componenti TIPO ed IDENTITÀ SELINUX arbitrariamente scelti


126

negli insiemi T ed U. L’imposizione di una restrizione su T ai soli tipi ai

quali qualcuno possa accedere è stata effettuata più che per motivazioni

teoriche, per motivazioni pratiche: infatti ci aspettiamo che in una

configurazione “classica” di SELinux, il numero dei tipi definiti sia molto

elevato e quindi il numero di elementi di O(c) per una data classe, sia

altrettanto grande. Restringendo in un qualsiasi modo gli O(c), quindi, è

possibile diminuire la cardinalità di altri insiemi, successivamente descritti,

che si basano sui loro elementi.

L’approccio perde la sua motivazione nel caso delle IDENTITÀ SELINUX,

perché in generale il loro numero è piuttosto piccolo e coincide con il

numero di classi di utenti per le quali l’amministratore di sicurezza vuole

distinguere le regole di accesso. In generale, è inferiore al numero di utenti

autorizzati ad utilizzare il sistema (pari al numero di nomi specificati nel file

delle password di Linux). Quindi, visto il loro ridotto numero, non ci

sembra un problema eccessivamente importante il fatto che alcune etichette

da noi considerate (comunque valide nel sistema), potrebbero in realtà non

essere assegnate ad alcun oggetto.

Con il termine permesso rispetto al security context, o più

semplicemente permesso, indichiamo una coppia POpo ×∈),( .

Ovviamente, siamo interessati, per ogni classe c, a permessi appartenenti a

)()( cPcO × . Un insieme di permessi relativi ad una stessa classe forma

quello che chiamiamo uno spazio di accessibilità.

Di seguito mostriamo come, definendo una serie di spazi di accessibilità, sia

possibile tramite SELAC dedurre diverse informazioni riguardanti la

configurazione di una politica di sicurezza in SELinux. Ciò permette di

evidenziare l’utilità di SELAC.


127

5.4.1 Universo

Lo spazio Universo della classe c, )(cΩ , contiene tutti i possibili permessi

relativi alla classe c, ovvero tutte le coppie in cui il primo elemento è un

security context valido per un oggetto della classe sulla quale è definito il

secondo elemento.

Formalmente:

Dato Cc∈ :

)()()( cPcOc ×=Ω

Figura 17: L’universo di una classe è pari all’unione di tutti i possibili spazi di accessibilità relativi a quella classe

)(cΩ è quindi pari all’unione di tutti i possibili spazi di accessibilità relativi

alla classe di oggetti c.

5.4.2 Specificati

Lo spazio dei Permessi spacificati per il security context s rispetto alla

classe c, ),( csΣ , contiene tutti i permessi che possono essere garantiti a

soggetti con etichetta s, in base alla configurazione del sottomodello TE

tramite regole allow_def.


128

Formalmente:

Dati CcSs ∈∈ , :

))((#)),((#|)(),(=),( sMpocpocs OT

OT ∈∈ ΩΣ

Figura 18: l’insieme dei permessi specificati per s rispetto a c, è costruito a partire dalle regole allow_def. Esso contiene tutti i permessi che, in assenza di vincoli, verrebbero garantiti ai soggetti con etichetta s rispetto ad oggetti della classe c.

Si noti che, in realtà, non tutti i permessi specificati sono autorizzati: molti

di essi, infatti, vengono vietati mediante la configurazione dei vincoli e

quindi non sono garantiti ai soggetti dal meccanismo di autorizzazione.

5.4.3 Vincolati

Lo spazio dei Permessi vincolati per il security context s rispetto alla

classe c, ),( csΧ , contiene tutti i permessi relativi ad oggetti di c, che

vengono negati ai soggetti con etichetta s, a causa della presenza di espliciti

vincoli. In generale questo spazio è molto grande perché i permessi vincolati

non sono banalmente un sottoinsieme di quelli specificati, ma includono

anche permessi in )(cΩ non presenti in ),( csΣ .


129

Formalmente:


),,(|)(),(),( trueposcpocs =Ω∈=Χ γ

Figura 19: l’insieme dei permessi vincolati per s rispetto a c contiene tutti i permessi che vengono vietati dal meccanismo di autorizzazione a causa della presenza di qualche vincolo. Essi comprendono alcuni permessi specificati per s rispetto a c ed altri permessi che non sono specificati. In tutti i casi tali permessi non vengono autorizzati.

In base ai tre spazi di accessibilità sopra definiti è possibile derivare quattro

altri spazi di notevole interesse, la cui analisi permette di determinare diverse

proprietà di una configurazione, ad esempio, cosa un soggetto possa fare nel

sistema, ovvero cosa possa accedere ed in che modalità.

.

5.4.4 Autorizzati

Lo spazio dei Permessi autorizzati per il security context s rispetto alla

classe c, ),( cs∆ è l’insieme dei permessi specificati e non vincolati, che

vengono quindi garantiti ai soggetti con etichetta s e sono relativi ad

oggetti di c.


130

Formalmente:


),(),(),( cscscs Χ−Σ=∆

altrimenti espresso come:

))((#)),((#|)(),(=),( sMpocpocs OT

OT ∈∈ Ω∆ e ),,( falsopos =γ

Figura 20: l’insieme dei permessi autorizzati per s rispetto a c contiene tutti e soli i permessi che sono garantiti ai soggetti con etichetta s rispetto ad oggetti della classe c. Tutti i permessi che non rientrano in questo spazio sono negati dal meccanismo di autorizzazione

Relativamente agli oggetti della classe c, vengono autorizzati ai soggetti con

etichetta s solamente i permessi che rientrano in questo spazio. Tutti i

permessi relativi agli oggetti di c che non rientrano (per diversi motivi) in

),( cs∆ , vengono proibit dal meccanismo di autorizzazione.

5.5.5 Proibiti1

Lo spazio dei Permessi proibiti di prima specie per il security context s

rispetto alla classe c, ),(1 csΠ , è l’insieme dei permessi relativi ad oggetti


131

di c che non sono né specificati né esplicitamente vincolati per s. Sono i

permessi che vengono vietati dal meccanismo di autorizzazione di SELinux

perché mancano regole esplicite nella configurazione della politica di

sicurezza.

Il complemento di tale insieme contiene tutti i permessi per i quali esistono

relative regole di configurazione.

Formalmente:


)),(),(()(),(1 cscsccs Σ∪Χ−Ω=Π


))((#∈)),((#|)(),(=),( sMpocpocs OT

OTΩ∆ ∈ e ),,( falsopos =γ

Figura 21: l’insieme dei permessi proibiti di prima specie per s rispetto a c contiene tutti i permessi relativi ad oggetti della classe c tali che non esistano regole specifiche che proibiscano o autorizzino ad essi i soggetti con etichetta s.

Si noti che, perché un dato permesso possa essere spostato da questo spazio

in un qualsiasi sottoinsieme di ),( csΣ o ),( csΧ , è necessario aggiungere

alla specifica della politica di controllo degli accessi, una apposita regole di

configurazione (allow_def o constraint_def)


132

5.5.6 Proibiti2

Lo spazio dei Permessi proibiti di seconda specie per il security context

s rispetto alla classe c, ),(2 csΠ , è l’insieme dei permessi che sono sia

specificati sia esplicitamente vincolati per s rispetto a c. Questi permessi

corrispondono a quelli che, in genere, vengono in prima istanza garantiti

tramite la configurazione del TE e poi tagliati via tramite la configurazione

dei vincoli.

Formalmente:


),(),(),(2 cscscs Σ∩Χ=Π


))((#)),((#|)(),(=),(2 sMpocpocs OT

OT ∈∈ ΩΠ e ),,( veropos =γ

Figura 22: l’insieme dei permessi proibiti di seconda specie per s rispetto a c, contiene tutti i permessi per i quali esistono regole e vincoli che, allo stesso tempo, garantiscano e proibiscano ad s l’accesso. Tali permessi non vengono garantiti dal meccanismo di autorizzazione

Perché un permesso possa essere spostato da questo spazio in un qualsiasi

altro sottoinsieme di ),( csΣ non contenuto in ),(2 csΠ , è necessario


133

modificare la configurazione della politica di sicurezza, eliminando una o

più regole di configurazione di vincoli.

5.5.7 Proibiti3

Lo spazio dei Permessi proibiti di terza specie per il security context s

rispetto alla classe c, ),(3 csΠ , è l’insieme dei permessi che non sono

specificati e sono esplicitamente vincolati per s rispetto a c. Questo spazio

può essere visto come un “effetto collaterale” dovuto al fatto che la

specificazione dei vincoli in SELinux permette di vincolare permessi che

non siano specificati e che quindi già non verrebbero autorizzati.

Formalmente:


),(),(),(3 cscscs Σ−Χ=Π


))((#∈)((#|)(),(=),(3 sMocpocs OT

OT p),∈ ΩΠ e ),,( veropos =γ

Perché un permesso appartenente a questo spazio possa essere spostato in

un qualsiasi sottoinsieme di ),( csΣ è necessario modificare la

configurazione della politica di sicurezza, eliminando una o più regole di

configurazione di vincoli ed aggiungendo una regola allow_def.


134

Figura 23: l’insieme dei permessi proibiti di terza specie per s rispetto a c contiene tutti i permessi esplicitamente vincolati, ma che non sarebbero comunque autorizzati, perché non esplicitamente specificati

I precedenti spazi di accessibilità permettono di ricavare senza dubbio

informazioni utili riguardanti una data configurazione. Infatti l’appartenenza

di un permesso ad uno di essi indica se un dato soggetto sia autorizzato ad

accedere ad un dato oggetto in qualche modo e, in caso negativo, quale sia

la causa del divieto.

5.6 Utilità degli spazi di acccessibilità

Terminiamo fornendo un esempio di applicazione del modello SELAC, in

grado di mostrare la sua utilità. Quello seguente è lo pseudocodice di una

procedura che sia in grado di rispondere alla domanda “può un dato soggetto x

accedere ad un dato oggetto y nella modalità w?”. Per semplicità, assumiamo che x

sia un processo corrispondente ad un qualsiasi programma Linux,al quale

non siano state fatte modifiche e che quindi non invochi le nuove chiamate

a sistema sicure.

Tramite SELAC, rispondere a tale domanda e a domande simili riguardanti

l’accessibilità, è possibile in maniera piuttosto semplice:


135

Siano:

V: l’insieme dei security context già verificati

AUTORIZZATO: una variabile che contenga la risposta calcolata

s: il security context del soggetto

o: il security context dell’oggetto

p: la modalità di accesso all’oggetto

1. ∅←V 2. AUTORIZZATO ← NO 3. VERIFICA(x,y,w)

con

VERIFICA( )(),(, cPpcOoSs ∈∈∈ ) BEGIN

IF Vs∉ AND AUTORIZZATO = NO THEN BEGIN

sVV ∪←

IF ),(),( cspo ∆∈ THEN BEGIN

AUTORIZZATO ← SI RETURN

END ELSE

PER OGNI St ∈ tale che ))((#)(#)),((#)(# sRtsTt OR

OR

OT

OT

→⇒∈∈

VERIFICA(t,o,p) END ELSE

RETURN END

L’algoritmo non fa altro che verificare se il soggetto abbia l’autorizzazione

di accedere all’oggetto nel dato modo direttamente, ovvero se il permesso

corrispondente risieda nello spazio dei permessi autorizzati per il soggetto.

Qualora questo non sia possibile viene verificato se sia possibile accedere


136

all’oggetto mediante una transizione automatica di security context e si

considerano tutte le transizioni legali.

Il fatto di poter determinare cosa il soggetto possa fare mediante una serie

di transizioni di security context automatiche è particolarmente utile, perché

permette di verificare la pericolosità di un’eventuale compromissione del

soggetto da parte di un attaccante.

Sviluppare algoritmi di verifica tramite SELAC risulta essere utile secondo

almeno due orizzonti. Da una parte è possibile verificare la dannosità di

scenari in cui, scagliato un attacco al sistema, un attaccante riesca a

compromettere un determinato soggetto. Dall’altra parte è possibile

utilizzare SELAC per configurare una politica di controllo degli accessi in

maniera incrementale. A tale scopo è possibile, ad esempio, modificare il

precedente algoritmo perché, in caso di risposta negativa, ne restituisca la

motivazione, ovvero riporti informazioni sull’appartenenza del permesso ad

uno degli spazi dei permessi proibiti.

Capitolo VI: Il tool di analisi

137

C a p i t o l o 6

Il tool di analisi

Il capitolo precedente si è concluso con la dimostrazione dell’utilità del

modello SELAC nella verifica di configurazioni di sicurezza per il sistema

SELinux. Simili verifiche sono difficili da compiere a mano, perché in un

sistema reale, in genere, sono molte le entità che entrano in gioco e ci si

aspetta che una configurazione tipica sia estremamente lunga; ad esempio, il

file di configurazione fornito con SELinux, da noi preso in considerazione,

è lungo 155396 righe27. Di conseguenza è necessario poter automatizzare le

operazioni di analisi per mezzo di appositi tool.

Il problema principale è costituito dalla scarsa disponibilità di tali tool.

Infatti, allo stato attuale, l’unico conosciuto dalla comunità di utilizzatori di

SELinux è quello, ancora in fase di sviluppo, scaricabile all’indirizzo web

[WEB-TT].

In questo capitolo ne descriviamo un altro, chiamato PACUM, da noi

sviluppato. Allo stato attuale PACUM consiste principalmente di una

libreria nella quale è definita una serie di strutture dati, che memorizzano le

informazioni di una configurazione, contenuta in un file di testo. Si assume

che tale configurazione sia corretta, nel senso che sia possibile compilarla

correttamente per mezzo del programma checkpolicy.

27 Esso è relativo alla versione LSM-2.4-selinux-2002082308 di SELinux. Esistono

attualmente versioni più recenti, ma per i nostri scopi, è sufficiente quella da noi scelta, che

era quella corrente al momento in cui abbiamo iniziato questo lavoro


138

Dalle strutture dati implementate, è possibile ricavare tutti gli insiemi di

SELAC e quindi, a partire da esse, costruire vari algoritmi di analisi; per i

nostri scopi, allo stato attuale, è stato implementato solamente quello del

capitolo precedente, attraverso il quale è possibile verificare l’accessibilità di

un soggetto ad un oggetto; tuttavia, vista la facilità di utilizzo di SELAC,

non è difficile implementarne di altri.

Figura 24: come appare il tool al suo avvio

PACUM è un tool da riga di comando sviluppato, sotto Linux, in C++; le

sue strutture dati interne sono implementate facendo uso della libreria

standard dei modelli (Standard Template Library, STL), sviluppata dalla

Silicon Graphics Inc., ormai disponibile con tutti i compilatori c/c++ e

comunque scaricabile gratuitamente all’indirizzo web [WEB-STL1].

Informazioni relative all’utilizzo dei modelli possono essere reperite, oltre

che al suddetto indirizzo, anche a [WEB-STL2, WEB-STL3]. Visto che la

libreria fa parte dello standard del linguaggio, il codice prodotto è portabile

e può essere compilato su più piattaforme.

La scelta del C++ è stata dettata dal fatto che il linguaggio mette a

disposizione delle strutture dati molto efficienti e l’uso dei modelli e del

paradigma di programmazione ad oggetti permette il riutilizzo di molto

codice. Inoltre le librerie, utilizzando ampiamente i riferimenti piuttosto che

i puntatori, permette di programmare senza preoccuparsi di dettagli


139

implementativi complessi, come ad esempio l’allocazione dinamica della

memoria.

Un’altra possibile scelta sarebbe potuta essere quella di utilizzare JAVA,

mediante il quale sarebbe stato immediato anche lo sviluppo di un’eventuale

interfaccia grafica per il tool. Tuttavia, abbiamo preferito C++, per diversi

motivi. Innanzitutto, relativamente all’interfaccia grafica, questa non sembra

essere una delle priorità nello sviluppo di un tool come PACUM: ci si

aspetta, infatti, che gli amministratori del sistema, appartenenti al mondo

Unix, siano pratici con le applicazioni da riga di comando e che molti di essi

utilizzino solamente applicazioni di configurazione testuali. Inoltre, se

SELinux viene utilizzato, come sembra probabile, soprattutto nella

protezione di un sistema dal lato server, è possibile anche che non sia

disponibile il supporto alla grafica Del resto, una configurazione di SELinux

per il sistema X Windows è ancora in fase di studio, quindi, molto

probabilmente, i sistemi sui quali venga eseguito SELinux non sono affatto

dotati di ambienti grafici. Ciò non toglie, tuttavia, che sia possibile scrivere,

all’occorrenza, un frontend grafico per PACUM.

Riguardo poi il confronto delle caratteristiche di C++ e JAVA, c’è da dire

che il primo è sicuramente più efficiente del secondo, che un suo ottimo

compilatore (gcc) è disponibile, senza dover scaricare altro software, in ogni

distribuzione Linux, ma, soprattutto, che la vera potenzialità di JAVA di

poter scrivere codice indipendentemente dalla piattaforma sulla quale venga

eseguito, nel nostro caso è del tutto inutile. Infatti, ci si aspetta che PACUM

venga utilizzato, soprattutto, su sistemi Linux nei quali il supporto a

SELinux sia abilitato e correntemente funzionante. Se poi, per qualsiasi

motivo, si volesse analizzare una configurazione di SELinux mediante una

macchina sulla quale sia presente un altro sistema operativo, abbiamo

comunque sviluppato il tool utilizzando solamente le funzionalità e le


140

librerie standard del C++, quindi è possibile compilare i sorgenti in altri

ambienti.

6.1 Organizzazione dei sorgenti

I file sorgenti del progetto sono divisi logicamente in diversi moduli. Per

comodità, chiamiamo questi moduli MISC, IBAC, RBAC, TE,

ACCESS_SPACE, CONFRULES, QUERIES. Ai precedenti moduli si

aggiungono PARSER, contente i file di specifica pacum.policy_scan.l e

pacum.policy_parse.y e MAIN, contente il file main.cpp.

Figura 25: schema dei moduli in cui si divide logicamente l’implementazione del

tool. Le linee tratteggiate indicano le dipendenze. STL indica la libreria standard

dei modelli.


141

Il modulo MAIN contiene la funzione main() del tool; tale funzione

prende due parametri opzionali (corrispondenti ai parametri da riga di

comando, accettati dal tool), che specificano il percorso del file di

configurazione da leggere (quello predefinito si chiama

pacum.policy.conf ed è ricercato nella directory che contiene l’eseguibile

di PACUM) e l’abilitazione del supporto per i numeri di linea. Tale

supporto permette di visualizzare, nell’output delle analisi effettuate, la

posizione, nel file di configurazione, delle regole coinvolte. Ad esempio,

qualora si richieda di visualizzare gli elementi dell’insieme dei ruoli

dichiarati, se il supporto per i numeri di linea è abilitato, l’output prodotto

sarà la lista dei nomi dei ruoli e per ogni ruolo sarà fornito l’elenco delle

posizioni alle quali si trovano le regole role_type_def per quel ruolo.

Figura 26: esempio di output con il supporto per i numeri di linea abilitato; per ogni

ruolo sono elencate le posizioni delle relative regole di definizione, nel file di

configurazione

La funzione main() non fa altro che leggere due volte il file di

configurazione e richiamare l’interfaccia (testuale) del tool, implementata da


142

una funzione definita nello stesso file. L’interfaccia, allo stato attuale, è un

semplice menu le cui voci sono attivabili tramite appositi tasti della tastiera.

Figura 27: iterfaccia del tool; ogni analisi è attivabile mediante una voce del menu.

La selezione avviene per mezzo dei corrispondenti tasti della tastiera

Il modulo PARSER è costituito dai file pacum.policy_scan.l e

pacum.policy_parse.y, contenenti le specifiche LEX e YACC28 per il

parsing di un file di configurazione. Abbiamo avuto l’accortezza di utilizzare

la stessa grammatica usata dal compilatore checkpolicy, in maniera tale da

poter effettuare facilmente, in futuro, una fusione del tool con il

28 Assumiamo che il lettore conosca i tool lex e yacc, che costituiscono una sorta di

standard per la costruzione di analizzatori lessicali e sintattici, in ambiente Unix. In

alternativa, informazioni relative sono disponibili al sito web http://ds9a.nl/lex-yacc


143

compilatore, come del resto è esplicitamente richiesto dagli sviluppatori,

nella mailing list ufficiale di SELinux.29

Una delle linee guida da noi seguite, infatti, è stata quella di produrre un

software che, oltre a poter verificare configurazioni già confezionate,

potesse in futuro aiutarne la scrittura di altre. In tal senso, quindi, la

possibilità di integrare il tool (o porzioni di esso) con il compilatore delle

politica di sicurezza, ci è sembrato un approccio altamente vantaggioso.

Il modulo MISC, formato dall’header Misc.h e dal corpo Misc.cpp,

contiene tutte le definizioni dei tipi di dato di utilità generale. Tali tipi sono

utilizzati dalla libreria sviluppata per il tool. Vengono inoltre qui definiti i

codici di errore e le funzioni per i relativi messaggi.

Il modulo IBAC contiene la definizione dei tipi di dato relativi al

sottomodello UI di SELinux; tale definizione avviene nell’header IBAC.h

Allo stesso modo, la definizione dei tipi di dato relativi al sottomodello

RBAC è presente nel modulo RBAC, costituito dall’header RBAC.h

Il modulo TE, costituito dall’header TE.h e dal corpo TE.cpp, contiene la

definizione dei tipi di dato relativi al sottomodello TE e alle classi di oggetti

del sistema SELinux.

Il modulo CONFRULES dichiara, nell’header ConfuRules.h, ed

implementa, nel corpo ConfuRules.cpp, una serie di funzioni globali,

utilizzabili nelle azioni YACC, presenti nel file pacum.policy_parse.y.

29 Le produzioni complete di tale grammatica sono quelle presentate nell’appendice B


144

Tali funzioni permettono di inserire nelle strutture interne di PACUM le

informazioni prodotte dal parsing delle regole nel file di configurazione.

Il modulo ACCESS_SPACE dichiara, nell’header As.h, ed implementa, nel

corpo As.cpp, le strutture dati relative ai SECURITY CONTEXT e agli SPAZI DI

ACCESSIBILITÀ.

Infine, il modulo QUERIES contiene tutte le funzioni che implementano

le possibili operazioni di verifica di una data configurazione del sistema.

Allo stato attuale dello sviluppo di PACUM, le funzioni presenti

permettono, principalmente, di visualizzare gli insiemi di SELAC e di

implementare l’algoritmo VERIFICA del precedente capitolo.

Per i dettagli implementativi si rimanda al codice dei file del progetto,

scaricabili all’indirizzo web [WEB-PACUM]; qui, descriviamo brevemente le

caratteristiche principali dei tipi di dato e delle funzioni globali

implementate nei vari moduli. Per ogni modulo viene mostrato il

diagramma UML delle classi. Facciamo inoltre vedere come sia possibile da

essi ricavare gli insiemi di SELAC.

6.1.1 Modulo MISC

Il modulo contiene alcune funzioni globali legate ai messaggi di errore

supportati da PACUM e, soprattutto, la definizione di diversi tipi di dato

che vengono utilizzati nella libreria. Il diagramma delle classi relativo è

diviso, per motivi di leggibilità, in quattro figure:


145

Figura 28: diagramma delle classi per il modulo MISC; parte relativa agli elementi

base di SELAC

Tutti gli ELEMENTI BASE di SELAC hanno un nome e sono definiti in un

certo punto del file di configurazione. Queste caratteristiche, rappresentate

dai tipi Name e lnum, sono inglobate nella classe PolicyItem. Il numero di

linea è impostato automaticamente dal costruttore della classe. La

definizione di alcuni elementi base, tuttavia, non avviene in un unico punto

del file di configurazione, ma fa riferimento a più regole. Per tenere traccia

di tutte le regole che definiscono tali elementi, alcuni tipi di dato hanno un

campo di tipo DeclNumber.

Type, Role, User, Class, Right e Attribute si riferiscono ai

rispettivi elementi base di SELAC, quindi ereditano da PolicyItem.

Siccome un RUOLO ed un’IDENTITÀ SELINUX sono definiti per mezzo di più

regole, Role e User hanno un campo di tipo DeclNumber e forniscono i

metodi ad esso relativi. Class aggiunge la possibilità di alterare il proprio

numero di linea. Ciò è dovuto al fatto che esso è inizialmente impostato, in


146

maniera automatica, al valore in cui la classe di oggetti è dichiarata; tuttavia è

più logico che rappresenti il punto in cui essa sia definita, dove cioè viene

specificato il suo VETTORE DI ACCESSO.

Le seguenti, sono tipi di dato relativi ad utili aggregazioni di elementi base di

SELAC:

ClassRightPair permette di associare un DIRITTO DI ACCESSO ad una

CLASSE DI OGGETTI. Un diritto di accesso ha senso, infatti, solamente rispetto

ad una classe. È semplicemente una coppia, in cui la prima componente

indica una classe di oggetti e la seconda una modalità di accesso. Il numero

di linea, associato ad ogni elemento e restituito da un apposito metodo, è

quello della regola di definizione del diritto, specificato nel vettore di

accesso della classe.

ClassTypePair è una coppia in cui il primo elemento indica una classe di

oggetti ed il secondo un TIPO. Gli elementi di questo tipo di dato sono

utilizzati per la codifica delle TRANSIZIONI DI TIPO.

Il tipo di dato Permission definisce quello che in SELAC è chiamato

PERMESSO RISPETTO AL TIPO. È quindi relativo ad un TIPO e ad un DIRITTO DI

ACCESSO appartenente ad una CLASSE DI OGGETTI. In realtà, utilizza un

puntatore ad un diritto di accesso, perché, dal momento che ci si aspetta che

uno stesso diritto sia specificato in più regole di configurazione, tutti gli

oggetti di tipo ClassRightPair sono memorizzati in un’apposita struttura,

i cui elementi sono puntati per motivi di risparmio di memoria. Siccome

uno stesso permesso rispetto al tipo può essere specificato in più punti di

una configurazione, Permission ha un campo di tipo DeclNumber. Inoltre,

siccome Permission altro non è che un’istanza del modello pair di STL,

segue che le funzioni PTT×# e PT

P×# di SELAC possono essere simulate con il

semplice accesso diretto ai campi first e second del modello.


147

Figura 29: diagramma della classi per il modulo MISC; parte relativa alla

definizione dei permessi rispetto al tipo e degli aggregati degli elementi base di

SELAC

TypeTransDec è tipo di dato per le DECISIONI DI TRANSIZIONI DI TIPO. Associa

un TIPO ad una coppia, formata da una CLASSE DI OGGETTI e da un altro TIPO.

Per motivi analoghi a quanto detto per Permission, gli elementi della

classe ClassTypePair sono organizzati all’interno di un’apposita struttura

e vengono puntati da quelli della classe TypeTransDec. Anche una stessa

decisione di transizione di tipo può apparire in più regole di configurazione;

di qui la presenza di un campo di tipo DeclNumber e dei metodi relativi.


148

Figura 30: Diagramma delle classi per il modulo MISC; parte relativa agli insiemi di

elementi e di puntatori ad elementi

I tipi di dato TypeSet, RoleSet, UserSet, AttributeSet,

ClassSet, ClassRightPairSet, ClassTypePairSet, RightSet,

PermissionSet e TypeTransDecSet sono insiemi di elementi base di

SELAC, o di loro aggregati. Corrispondono ad istanze del modello set,

presente nella libreria STL. La scelta di questo tipo di dato è causata dal

fatto che esso sia particolarmente adeguato per le operazioni insiemistiche,

implementate dagli algoritmi della libreria STL (set_union, includes,

set_intersection,set_symmetric_difference, set_difference);

infatti set impone che i propri elementi siano sempre ordinati, secondo un

dato ordinamento; d’altra parte, gli algoritmi, tutti di complessità lineare,

presuppongono che i propri argomenti siano ordinati e generano un

risultato anch’esso ordinato. Ciò garantisce che l’operazione di inserimento

di elementi in un set richieda, anch’essa, una complessità lineare.

In maniera analoga, TypePtrSet, RolePtrSet, UserPtrSet,

ClassPtrSet,RightPtrSet,ClassRightPairPtrSet,AttributePtrSe

t, PermissionPtrSet e TypeTransDecPtrSet definiscono degli insiemi

di puntatori ad elementi base di SELAC, o a loro aggregati.

PTable e TypeTransDecisionTable sono due insiemi, l’uno relativo a

PERMESSI RISPETTO AL TIPO, l’altro a DECISIONI DI TRANSIZIONE DI TIPO. Entrambe


149

le classi offrono la possibilità di ottenere i numeri di linea ai quali

corrispondono le regole che coinvolgono i loro elementi.

Figura 31: Diagramma delle classi per il modulo MISC; parte relativa alle strutture

dati generiche

Table è un modello, per le strutture dati di alto livello di PACUM.

Permette di associare dei generici elementi base ad altrettanti insiemi di

informazioni, chiamati nel seguito descrittori, utili ai fini dell’analisi.

L’associazione è implementata per mezzo del modello map della libreria

STL. map è particolarmente utile per realizzare strutture dati associative; i

suoi elementi sono coppie, la cui prima componente è chiamata chiave, e

sono ordinati. Il modello impone che non ci siano elementi con la stessa

chiave e l’ordinamento garantisce che le operazioni di inserimento ed

eliminazione siano efficienti.

Le strutture dati di alto livello presenti nei moduli RBAC, IBAC e TE sono

istanze di questo modello.


150

Item, Item2 e Item3 sono dei modelli per i descrittori degli elementi base.

Essenzialmente, mantengono al loro interno un numero variabile, da uno a

tre, di insiemi di puntatori ad altri elementi base. Le loro istanze sono

definite, rispettivamente, nei moduli IBAC, RBAC e TE.

Infine, il modulo MISC contiene la definizione del tipo di dati Queue.

Queue è un altro nome per il tipo di dato deque<PolicyItem>. Il modello

deque è predefinito nella libreria STL: esso essenzialmente è un vettore,

ovvero una sequenza di elementi, che supporta un accesso diretto. Le

operazioni di inserimento e rimozione di elementi all’inizio e alla fine della

sequenza impiega tempo costante. Il nome Queue è giustificato dal fatto che

l’utilizzo che ne facciamo è quasi sempre quello proprio del tipo di dato

coda (gestione First In First Out). Tuttavia, per alcune particolari operazioni,

legate ai dettagli implementativi del tool, l’utilizzo dell’apposito modello

STL queue non sarebbe stato adeguato; di qui la scelta, per comodità, di

utilizzare il più flessibile deque.

6.1.2 Modulo IBAC

Il modulo contiene la definizione dei tipi di dato relativi al sottomodello UI.

Il diagramma delle classi è mostrato in figura.

ItemUser è il tipo di dati per i descrittori delle IDENTITÀ SELINUX. Più

precisamente, contiene i riferimenti ai RUOLI, ai quali le identitá SELinux

sono autorizzate.

UTable è una struttura dati che associa un’identità SELinux ad un

descrittore per quell’identità; quindi una sua chiave è costituita da un

oggetto di tipo User ed è associata ad un elemento di tipo ItemUser.


151

Figura 32: diagramma delle classi relativo al modulo IBAC

UTable fornice dei metodi che permettono, oltre ad inserire elementi, di

ottenere l’insieme delle chiavi della struttura (getUsers()), corrispondente

all’insieme delle identità SELinux definite, e per aggiungere riferimenti ai

rispettivi descrittori (addAuthorized()). Inoltre è possibile sapere, per

ogni identità SELinux, i relativi numeri di riga nel file di configurazione

(where()) e i corrispondenti ruoli autorizzati (getAuthorized()).

Quindi UTable fornisce i metodi per ricavare i seguenti insiemi di SELAC:

• U, tramite il metodo getUsers()

• R(u), tramite il metodo getAuthorized()


152

6.1.3 Modulo RBAC

Il modulo è analogo al precedente, ma è relativo al sottomodello RBAC.

Permette di definire, quindi, i descrittori per i RUOLI e la struttura per

associare i ruoli ai propri descrittori. Il diagramma delle classi è il seguente:

Figura 33: diagramma delle classi relativo al modulo RBAC

Le informazioni contenute in un descrittore di ruolo (classe ItemRole)

sono un insieme di puntatori ai DOMINI ai quali il ruolo è autorizzato, ed un

insieme di puntatori ai ruoli ai quali il ruolo associato può effettuare una

transizione.

RTable è una struttura dati che permette di associare un ruolo al suo

descrittore. Tramite i metodi da essa forniti, si possono costruire i seguenti

insiemi di SELAC:

• R, tramite il metodo getRoles()


153

• T(r), tramite il metodo getAuthorized()

• )(sR→

, tramite il metodo getTransitions()

Inoltre, per ogni ruolo memorizzato nella struttura, è possibile aggiungere

transizioni e domini autorizzati, e sapere in che punto del file di

configurazione si trovano le regole relative.

6.1.4 Modulo TE

Il modulo TE contiene le definizioni dei tipi di dato relativi al sottomodello

TE. Riguarda quindi i TIPI, gli ATTRIBUTI DEI TIPI e le CLASSI DI OGGETTI del

sistema. Il diagramma delle classi relativo è mostrato in figura

I tipi di dato ItemType e TTable sono analoghi ai corrispondenti nei due

precedenti moduli. Le informazioni utili contenute in un descrittore per un

tipo sono liste di puntatori agli ATTRIBUTI, ai PERMESSI RISPETTO AL TIPO e alle

DECISIONI DI TRANSIZIONE per quel tipo. TTable, al solito, associa i tipi ai

propri descrittori e permette di aggiungere ed ottenere informazioni ad essi

relative.

Gli insiemi di SELAC che possono essere creati attraverso i metodi di

TTable sono i seguenti:

• T, tramite il metodo getTypes()

• M(s), tramite il metodo getPermissions()

• Do(s) e Dp(s), entrambi tramite il metodo getTransitions()

• A(t), tramite il metodo getAttributes()

• )(sT→

, tramite il metodo getTypeTransitions()

• )(sT⇒

, tramite il metodo getAutoTypeTransitions()


154

Figura 34: diagramma delle classi relativo al modulo TE

AtTable è una struttura dati che permette di associare un ATTRIBUTO DI TIPO

ad un insieme di puntatori a tipi. I TIPI sono le chiavi della struttura TTable.

Rispetto al modello SELAC, il metodo getAttributes() permette di

ottenere l’insieme A, mentre getTypes() corrisponde alla funzione α .

Infine, la struttura dati CTable permette di associare una CLASSE DI OGGETTI

al suo VETTORE DI ACCESSO. I diritti di accesso sono memorizzati per mezzo

di coppie che indicano il nome della classe e la modalità di accesso (oggetti

di tipo ClassRightPair).

CTable mette a disposizione metodi per la costruzione dei vettori di

accesso delle classi in essa contenute, e per ottenere i seguenti insiemi di

SELAC:

• C, tramite il metodo getClasses()

• P(c), tramite il metodo getRights()


155

Inoltre, l’insieme P può essere facilmente calcolato iterando il metodo

getRights() su tutti i valori restituiti da getClasses().

I tipi di dato definiti nei moduli IBAC, RBAC e TE mettono quindi a

disposizione dei metodi che restituiscono gran parte degli insiemi

fondamentali di SELAC, ed alcuni suoi importanti insiemi derivati. Gli

insiemi fondamentali mancanti, S e O, sono calcolabili per mezzo degli

strumenti messi a disposizione dal modulo ACCESS_SPACE.

6.1.5 Modulo ACCESS_SPACE

Il modulo contiene la definizione dei tipi di dato e delle funzioni globali

relative alla gestione dei SECURITY CONTEXT e degli SPAZI DI ACCESSIBILITÀ. Il

diagramma delle classi relativo è mostrato in figura.

SecurityContext è una struttura dati che rappresenta un’etichetta di

sicurezza per un SOGGETTO o per un OGGETTO. In realtà essa contiene dei

puntatori ai tipi di dato relativi, memorizzati nelle strutture definite negli

altri moduli (UTable, Rtable e TTable). Per ogni etichetta è possibile

ottenere le sue componenti, tramite gli appositi metodi; essi corrispondono

alle funzioni OU# , O

R# e OT# di SELAC.

SecurityContextTable non è classe che possa essere istanziata, ma mette

a disposizione una serie di funzioni che permettono di costruire diversi

insiemi di SELAC. Tali insiemi vengono calcolati a partire dalle

informazioni contenute nelle strutture dati UTable, Rtable e TTable. Essi

sono:

• O, tramite la funzione getSecurityContext()

• S, tramite la funzione getSecurityContextsForS()


156

• O(c), tramite la funzione getSecurityContextsForC()

Figura 35: diagramma delle classi relativo al modulo ACCESS_SPACE. Le due

Class Utility raggruppano le funzioni globali e non corrispondono a classi che

possano essere istanziate

SpaceItem è un tipo di dato che memorizza quello che in SELAC è

chiamato PERMESSO RISPETTO AL SECURITY CONTEXT. Mette a disposizione due

metodi che restituiscono le sue due componenti. Un insieme di tali elementi

è rappresentato da un’istanza del tipo di dato Space.

Infine, AccessSpace non è un tipo di dato ma mette a disposizione delle

funzioni che permettono di calcolare gli spazi di accessibilità di SELAC e di

implementare, tramite la funzione canAccess(), l’algoritmo VERIFICA,

presentato nel capitolo precedente.

Tali funzioni fanno uso di quelle definite in SecurityContextTable. In

realtà, sono fornite solamente le funzioni per calcolare direttamente gli

insiemi UNIVERSO delle classi (getUniverse()), gli SPAZI DEI PERMESSI

SPECIFICATI (getSpecified()) e per la verifica se un dato permesso sia


157

vincolato (checkConstraint()). Ciò permette di generare comunque tutti

gli spazi, ma quelli a nostro avviso più importanti, dei PERMESSI AUTORIZZATI

e dei PERMESSI PROIBITI DI SECONDA SPECIE, possono essere calcolati in maniera

efficiente, senza dover generare necessariamente quello dei PERMESSI

VINCOLATI.

6.2 Inizializzazione del tool

Le funzioni globali, responsabili della popolazione delle strutture dati sopra

descritte, sono dichiarate in ConfRules.h ed implementate in

ConfRules.cpp. Tali funzioni sono utilizzate nelle azioni YACC all’interno

del file pacum.policy_parse.y. In tabella è riportata la corrispondenza

tra le funzioni della libreria e i costrutti del linguaggio di configurazione di

SELinux.

Il supporto al costrutto role_dominance, attualmente, non è

implementato. Siamo convinti, infatti, che il linguaggio di configurazione,

relativamente a tale costrutto, debba essere rivisto dagli sviluppatori. Ad

ogni modo, per i nostri scopi di analisi, role_dominance non è necessario,

perché la configurazione di esempio fornita con SELinux, da noi analizzata,

non ne fa uso.

Nel capitolo precedente si è detto che, per motivi di semplicità, SELAC

presuppone che alcuni costrutti del linguaggio di configurazione siano

normalizzati, ed opera alcune semplificazioni rispetto al linguaggio ufficiale.

PACUM, al contrario, dovendo essere in grado di interpretare un’arbitraria

configurazione di SELinux, scritta non in SEL, ma nel linguaggio ufficiale,

non presuppone alcuna semplificazione. Per questo motivo, la libreria


158

ConfRules mette a disposizione alcune funzioni che non trovano un

corrispondente in SELAC, per l’ereditarietá di diritti di accesso tra classi di

oggetti (_common_decl() e _class_inheritance()) e per la gestione

dei caratteri jolly che possono apparire nelle regole di configurazione

(__explode_jollies(), __explode_tilde()). Le prime due funzioni

sono dichiarate in ConfRules.h; le altre due, invece, sono funzioni di

servizio, richiamate dalle altre, e quindi non sono presenti nell’interfaccia

della libreria.

funzioni in ConfRules.h, cpp costrutti del linguaggio

_class_decl() class_def

_class_def() av_perms_def

_attrib_decl() attribute_def

_type_decl() type_def

_type_transition_rule() type_transition

_type_allow_rule() allow_def

_role_decl() role_type_def

_role_allow_rule() role_allow_def

_user_decl() user_def

_constraint_def() constraint_def

_common_decl() -

_class_inheritance -

Figura 36: corrispondenza fra le funzioni della libreria ConfRules ed i costrutti del

linguaggio di configurazione di SELinux

Le istanze dei tipi di dati appartenenti ai moduli sopra visti sono definite

globalmente nel file ConfRules.cpp. Più precisamente, sono definite le

seguenti strutture globali:

• TypeTable, per la memorizzazione delle informazioni relative ai tipi


159

• RoleTable, per la memorizzazione delle informazioni relative ai ruoli

• UserTable, per la memorizzazione delle informazioni relative alle identità SELinux

• AttributeTable, per la memorizzazione delle informazioni relative agli attributi per i tipi

• ClassTable, per la memorizzazione delle informazioni relative alle classi di oggetti e ai loro vettori di accesso

• PermissionTable,RightTable,TransTable, AutoTransTable sono utilizzate per memorizzare, senza duplicazioni, aggregati di elementi base ai quali fanno riferimento le altre strutture.

Tutte le operazioni e le interrogazioni possibili su una data configurazione

di SELinux, lavorano sulle precedenti strutture dati globali.

L’inizializzazione di PACUM avviene mediante una doppia scansione del

file di configurazione. Il motivo va ricercato nel fatto che il linguaggio di

configurazione non impone che gli ELEMENTI BASE siano dichiarati tutti

all’inizio del file, ma permette la loro diretta definizione, nel punto in cui

essi sono utilizzati; quindi, l’eventuale presenza di caratteri jolly implica la

necessità di una prima scansione per costruire gli insiemi U, R, T, C, P.

Le azioni di YACC fanno riferimento ad una struttura dati, chiamata Names,

di tipo Queue, che contiene i nomi degli elementi base che sono letti nel file

di configurazione. Names contiene solamente elementi di tipo PolicyItem

e separatori, che sono inseriti per distinguere i gruppi di nomi coinvolti nel

riconoscimento di una regola di configurazione. Tali separatori sono

implementati, semplicemente, tramite elementi di tipo PolicyItem il cui

nome corrisponde ad una stringa vuota. Ad esempio, al riconoscimento di

una regola del tipo:

type_transition t1 t2 t3 t4 t5 : c1 t6


160

lo stato della coda di nomi è il seguente:

Figura 37: stato della struttura Names dopo il riconoscimento della regola

type_transition

Le singole funzioni della libreria ConfRules provvedono automaticamente

all’espansione degli eventuali caratteri jolly; inoltre si occupano della

conversione dei generici elementi della coda Names, in altrettanti specifici

elementi base e al loro inserimento all’interno delle apposite strutture dati.

Il compilatore checkpolicy fa uso di un approccio simile, tramite una

coda, in cui sono inseriti i nomi degli elementi base (riconosciuti come

semplici stringhe), divisi da appositi separatori. Tuttavia, il codice sorgente

della libreria, o anche solamente la definizione della sua interfaccia, non è

disponibile. Da qui la necessità, per noi, di implementare la struttura Queue.

Disponendo almeno dell’interfaccia della coda usata da checkpolicy, è

possibile integrare il nostro tool all’interno del compilatore della politica di

sicurezza, senza alcuna modifica al suo codice.

6.3 Interrogazioni relative ad una configurazione

Il modulo QUERIES contiene una serie di funzioni sovraccaricate,

chiamate show(), per mezzo delle quali è possibile interrogare PACUM ed

analizzare una configurazione di SELinux. Tutte le funzioni richiamate

dall’interfaccia del tool sono definite in questo modulo.


161

Allo stato attuale, le funzionalità messe a disposizione permettono di

ottenere tutti gli insiemi fondamentali di SELAC30 e gli insiemi derivati

)(sT→

e )(sT⇒

. Inoltre, è possibile ottenere i numeri di linea associati agli

elementi di tali insiemi.

Infine è implementato l’algoritmo VERIFICA, presentato alla fine del

capitolo precedente, che permette di analizzare l’accessibilità di un soggetto

ad un oggetto.

6.4 Esecuzione del tool

Abbiamo testato la correttezza e le funzionalità del tool, su un semplice file

di configurazione da noi scritto ed abbiamo ottenuto i risultati voluti.

Successivamente abbiamo applicato il tool sul file di configurazione

originale, policy.conf, distribuito assieme a SELinux.

Il risultato di alcune semplici analisi è mostrato nelle figure seguenti.

Figura 38: insieme degli attributi per i tipi

30 ad eccezione di ↓D(s)


162

Figura 39: insieme degli attributi per il tipo local_login_t

Figura 40: insieme dei ruoli

Figura 41: insieme dei domini ai quali è autorizzato il ruolo user_r

Figura 42: insieme delle transizioni autorizzate per il ruolo system_r


163

Figura 43: insieme di permessi rispetto al tipo per checkpolicy_t

Figura 44: migrazioni di dominio permesse e migrazioni automatiche di dominio

per il tipo init_t


164

Figura 45: esempi di localizzazione delle regole di definizione di alcuni elementi

base. Si noti che, sebbene il supporto automatico ai numeri di linea è disabilitato, è

sempre possibile ottenere tali informazioni tramite le apposite voci di menu

Gli esempi sopra presentati non sono di grande interesse a livello teorico,

ma servono principalemente a mostrare output tipici di alcune comuni

interrogazioni che possono essere fatte relativamente ad una

configurazione. Ciò che è emerso di interessante riguarda pricipalmente le

dimensioni degli insiemi di SELAC. Infatti, la configurazione di SELinux da

noi analizzata consta di ben 892 tipi, 5 ruoli, 5 identità SELinux, 32 classi di

oggetti, con numero di diritti di accesso variabile da un minimo di 1 ad un

massimo di 29. Come è facile immaginare, gli insiemi di maggiore interesse

arrivano ad avere cardinalità molto elevate: si pensi, ad esempio, che il

numero di permessi rispetto al tipo per il programma login e per il demone

ssh sono, rispettivamente, 2807 e 2897. L’insieme di tutti i permessi


165

rispetto al tipo definiti ha 70729 elementi, mentre lo spazio dei security

context ne ha 22300.

Chiaramente è impossibile qui mostrare risultati così vasti e, del resto, non

c’è alcuna utilità di farlo.

Allo stato attuale, PACUM è poco più che una libreria che permette di

memorizzare in apposite strutture dati tutte le informazioni relative ad una

configurazione di SELinux. È possibile scrivere velocemente diverse

funzioni di interrogazione. Quelle attualmente implementate costituiscono

solamente un piccolissimo esempio di ciò che sia possibile fare; di reale

interesse pratico, è stato codificato solamente l’algoritmo che verifica

l’accessiblità di un soggetto ad un oggetto. Altre interrogazioni importanti

sono da realizzare, ma si riducono semplicemente a verifiche di inclusione

insiemistica e quindi sono implementabili con poche righe di codice.

Conclusioni e lavoro futuro

166


In questa tesi abbiamo preso in esame le principali tematiche legate alla

sicurezza dei computer. In particolare ci siamo occupati di modelli e

politiche di controllo degli accessi.

Dopo aver considerato i caratteri salienti di quanto presente in letteratura,

abbiamo concentrato l’attenzione su un sistema operativo sicuro reale, di

crescente successo, chiamato SELinux, avente un modello di controllo degli

accessi piuttosto complesso.

I contributi principali di questa tesi sono stati l’attenta analisi del linguaggio

di configurazione di SELinux, la costruzione di un modello formale con il

quale possa essere studiata una fissata configurazione del sistema e

l’implementazione di un tool che possa essere utilizzato a tale scopo.

A livello teorico è rimasto aperto il problema di come poter restringere lo

spazio dei security context validi per gli oggetti, rispetto alla componente

identità SELinux.

Inoltre, è apparso necessario poter individuare dei gruppi significativi di

diritti di accesso, in maniera tale da poter semplificare i risultati delle analisi:

infatti, in generale, perché una qualsiasi azione sia possibile nel sistema,

sono necessari non singoli diritti di accesso, ma insiemi di essi. Ad esempio,

perché un processo possa effettuare una migrazione di dominio, si è visto,

sono necessari tre diritti di accesso. Sarebbe estremamente utile individuare

analoghi gruppi di diritti di accesso per altre comuni operazioni e condurre

le analisi in base ad essi. Siamo convinti che ogni analisi di livello più alto

che si volesse fare su una data configurazione, debba necessariamente

appoggiarsi su un approccio simile.


167

Per quanto riguarda il tool di analisi, esso è ancora in fase di sviluppo e

molte funzionalità devono essere ancora integrate. Ciò che si è reso evidente

con il suo utilizzo, tuttavia, è che la sua interfaccia a menu è insufficiente

nell’effettuare analisi di interesse pratico. Stiamo valutando l’opportunità di

costruire un interprete di comandi che permetta la definizione on-line di

funzioni di analisi arbitrarie e la loro interpretazione. Una simile interfaccia

permetterebbe anche di definire delle arbitrarie funzioni di filtro con le quali

restringere gli output ottentuti dal tool e poter gestire in maniera migliore la

complessità di una configurazione, per rendere più agevoli le analisi.

Una volta migliorato PACUM da questo punto di vista, lo scopo ultimo è

quello di provarlo nuovamente sulla configurazione di esempio di SELinux

e verificare gli obiettivi di sicurezza presentati in [SF01].

Appendice A: Glossario dei termini

I

A p p e n d i c e A

Glossario dei termini

A ACCESS CONTROL LIST:

lista relativa ad un oggetto, i cui elementi specificano, per ogni soggetto,

le modalità di accesso autorizzate; corrisponde ad una colonna della

matrice degli accessi ACCESS VECTOR CACHE:

in Flask, modulo associato agli object manager, responsabile della

memorizzazione delle decisioni di sicurezza prese dal security server; è

utilizzato per mitigare la perdita di prestazioni del sistema, dovuta alla

comunicazione con il security server ASSEGNAMENTO DI PERMESSI:

nel controllo degli accessi basato sui ruoli, relazione molti a molti che

associa i pemessi ai ruoli ASSEGNAMENTO DI UTENTI:

nel controllo degli accessi basato sui ruoli, relazione molti a molti che

associa gli utenti ai ruoli ATTRIBUTO DI SICUREZZA:

nei controlli degli acessi mandatori, qualsiasi componente di un’etichetta

di sicurezza, in base alla quale vengono prese le decisioni di accesso ATTRIBUTO DI UN TIPO:

in SELinux, nome che può essere associato ad uno o più tipi; può essere

utilizzato in ogni regola di configurazione che preveda la specifica di un


II

nome per un tipo e l’effetto ottenuto è quello di applicare la regola a

tutti i tipi a cui è associato l’attributo AUDITING:

memorizzazione degli eventi in un sistema, rilevanti dal punto di vista

della sicurezza, che possono essere univocamente associati ad un

individuo AUTENTICAZIONE:

specifica i requisiti per identificare un individuo prima di permettere ai

soggetti nel sistema di agire come suoi surrogati AUTORIZZAZIONE:

sinonimo di diritto di accesso AUTORIZZAZIONE DI SICUREZZA:

nel modello di controllo degli accessi basato sui reticoli, etichetta di

sicurezza che è possibile assegnare ai soggetti

C CAMBIAMENTO DI SECURITY CONTEXT:

in Flask, operazione mediante la quale è possibile alterare il contenuto

dell’etichetta di sicurezza di un oggetto; avviene per mezzo di apposite

chiamate a sistema sicure e deve essere autorizzato dalla politica di

sicurezza; prevede che l’applicazione che richieda la rietichettatura

dell’oggetto sia riscritta per invocare le apposite chiamate a sistema CAPABILITY:

coppia la cui prima componente rappresenta un oggetto e la seconda

una sua modalità di accesso; viene posseduta dai soggetti nei modelli

basati sulle capability; l’insieme di tutte le capability possedute da un

soggetto corrisponde ad una riga della matrice degli accessi


III

CATEGORIA:

nei sistemi Multilevel-Security, specifica area nella quale può operare un

soggetto, o alla quale appartiene l’informazione contenuta in un oggetto;

serve a poter controllare gli accessi, non solo in base alle etichette di

sicurezza, ma anche al principio need to know CLASSE DI OGGETTI:

astrazione mediante la quale è possibile partizionare l’insieme degli

oggetti di un sistema in classi di equivalenza; tutti gli oggetti che

appartengono ad una stessa classe condividono una stessa interfaccia,

ovvero hanno uno stesso insieme di modalità di accesso e permettono

uno stesso insieme di operazioni; i diritti di accesso ad un oggetto sono

sempre relativi alla sua classe; in SELinux, la sua specificazione permette

di differenziare le regole di accesso ad oggetti di classi differenti, ma

aventi stesso tipo CLASSE DI ACCESSO:

nei controlli degli accessi mandatori, sinonimo di etichetta di sicurezza CLASSIFICAZIONE DI SICUREZZA:

nel controllo degli accessi basato sui reticoli, etichetta di sicurezza che è

possibile assegnare agli oggetti COMPLETEZZA:

proprietà che deve essere verificata dalle implementazioni del concetto

di reference monitor; prevede che le funzioni di riferimento vengano

invocate ad ogni tentativo di accesso di un soggetto ad un oggetto COMPONENTE DI UN SECURITY CONTEXT:

in SELAC, uno fra gli attributi di sicurezza identità SELinux, ruolo e

tipo CONFIDENZIALITÀ:

capacità di prevenire che le informazioni siano ottenute da individui non

autorizzati; è alla base della sicurezza dei computer


IV

CONFIGURAZIONE:

nei modelli di controllo degli accessi, stato di assegnamento dei

permessi ai soggetti; può essere vista come un’istanza della matrice degli

accessi; la transizione da una configurazione ad un’altra avviene per

mezzo delle regole specificate nello schema di autorizzazione del

modello CONTROLLO DEGLI ACCESSI DISCREZIONALE:

controllo degli accessi che si basa sul concetto di proprietario di un

oggetto; prevede che sia il proprietario dell’oggetto (in genere il suo

creatore) a decidere quali siano i diritti di accesso garantiti sull’oggetto ai

vari soggetti CONTROLLO DEGLI ACCESSI MANDATORIO:

qualsiasi controllo degli accessi che non sia discrezionale e si basi sul

concetto di etichetta di sicurezza; in letteratura, alcune volte, è sinonimo

del solo controllo degli accessi basato sui reticoli CONTROLLO DEGLI ACCESSI BASATO SUI RETICOLI:

controllo degli accessi mandatorio; impone un’unica direzione al flusso

delle informazioni all’interno di un reticolo di etichette di sicurezza CONTROLLO DEGLI ACCESSI BASATO SUI RUOLI:

controllo degli accessi mandatorio; prevede che gli utenti possano

assumere dei ruoli all’interno del sistema; i permessi sono associati ai

ruoli così che gli utenti, attivando i ruoli ai quali sono autorizzati,

possano accedere agli oggetti

D DATABASE DELLA AUTORIZZAZIONI:

nel concetto del reference monitor, componente che memorizza

l’insieme delle regole di accesso e quindi la logica del controllo degli


V

accessi; le funzioni di riferimento del reference monitor, restituiscono le

informazioni contenute in questo componente; l’alterazione alle

informazioni contenute, può avvenire solamente tramite le funzioni di

autorizzazione del reference monitor DECISIONE DI ETICHETTATURA:

in SELinux, operazione compiuta dal security server alla creazione di un

oggetto nel sistema, o alla trasformazione di un processo; viene presa in

base alle regole della configurazione del sistema e viene imposta dagli

object manager DECISIONE DI SICUREZZA:

in SELinux, operazione compiuta dal security server al tentativo di

accesso di un soggetto ad un oggetto; corrisponde ad una funzione di

riferimento nel concetto del reference monitor; a livello logico, viene

presa ogni qualvolta si voglia accedere ad un oggetto, ma, nella pratica,

per motivi di prestazioni, appena prodotta, viene memorizzata nella

Vector Access Cache, in maniera tale che possa eventualmente essere in

seguito consultata dagli object manager, senza dover comunicare

nuovamente con il security server DIRITTO DI ACCESSO:

esprime l’autorizzazione, per un soggetto, ad accedere ad un oggetto, in

una data modalità; corrisponde quindi ad una modalità di accesso

fornita da una classe di oggetti DISPONIBILITÀ:

capacità di impedire che soggetti non autorizzati possano trattenere

l’informazione e/o le risorse, senza permettere agli altri individui di

poterne usufruire; è una proprietà, in generale, indecidibile DOMAIN AND TYPE ENFORCEMENT:

variante del Type Enforcement, sviluppata per i sistemi Unix; viene

configurato tramite un apposito linguaggio di alto livello


VI

DOMINANZA:

relazione riflessiva, antisimmetrica e transitiva propria degli insiemi

parzialmente ordinati DOMINIO:

nel Type Enforcement, definisce un perimetro all’interno del quale

viene confinato un insieme di soggetti; vengono specificati i diritti di

accesso che i soggetti in esso confinati hanno sugli oggetti aventi

determinati tipi; identifica una etichetta di sicurezza per una classe di

equivalenza di soggetti DOMINIO DI UN SOGGETTO:

insieme di tutti gli oggetti accessibili ad un dato soggetto; per ogni

oggetto sono specificati i diritti di accesso che il soggetto possiede;

corrisponde ad una riga della matrice degli accessi

E ELEMENTO BASE:

in SELAC, uno fra i concetti identità SELinux, ruolo, tipo, attributo,

classe di oggetti, diritto di accesso ENTRYPOINT:

nel Type Enforcement, programma la cui esecuzione causa una

migrazione di dominio del processo che lo esegue ETICHETTA:

sinonimo di etichetta di sicurezza ETICHETTA DI SICUREZZA:

nei controlli degli accessi mandatori, definisce una classe di equivalenza

per i soggetti o per gli oggetti; relativamente ai soggetti, indica la

sensibilità dell’informazione che essi possono accedere; relativamente

agli oggetti, indica la sensibilità dell’informazione in essi contenuta


VII

F FLASK:

architettura di sicurezza flessibile, che permette di realizzare politiche di

controllo degli accessi mandatorie; specifica tre tipi di componenti

principali: un security server, un insieme di object manager ed un

modulo, chiamato Access Vector Cache; il sistema SELinux integra

questa architettura nel sistema operativo Linux FUNZIONI DI AUTORIZZAZIONE:

nel concetto del reference monitor, insieme di primitive che permettono

di alterare il contenuto del database delle autorizzazioni FUNZIONI DI RIFERIMENTO:

nel concetto del reference monitor, insieme di regole che vengono

utilizzate per prendere delle decisioni sul permesso o diniego di accesso

alle informazioni; le decisioni vengono prese in base al contenuto del

database delle autorizzazioni

G GERARCHIA DI RUOLI:

nel controllo degli accessi basato sui ruoli e in SELinux, organizzazione

di ruoli che prevede la possibilità per alcuni di essi, chiamati ruoli senior,

di ereditare le caratteristiche di altri, chiamati ruoli junior; le

caratteristiche ereditate sono gli assegnamenti di utenti e di permessi; è

un ordinamento parziale dei ruoli GRANT:

nei modelli di controllo degli accessi discrezionali, autorità di garantire

l’accesso ad un oggetto; è posseduta in generale dai proprietari degli

oggetti, ma, in alcuni casi, può essere delegata ad altri soggetti


VIII

I IDENTITÀ SELINUX:

in SELinux e in SELAC, componente di una etichetta di sicurezza per

un soggetto o per un oggetto; indica, nel caso di un soggetto, l’identità

dell’utente per il quale il processo è in esecuzione; nel caso di un

oggetto, indica l’identità del suo creatore; non corrisponde

necessariamente ad una identità utente Linux; in generale, il suo valore

non viene alterato durante l’esecuzione dei processi INSIEME PARZIALMENTE ORDINATO:

insieme sul quale è definita una relazione di dominanza, riflessiva,

antisimmetrica e transitiva, tale che, per ogni coppia di elementi x e y, x

domina y, oppure y domina x, oppure x e y sono incomparabili INTEGRITÀ:

capacità di impedire che l’informazione possa essere modificata da

individui non autorizzati; è alla base della sicurezza dei computer INTRUSION DETECTION:

insieme di tecniche di auditing on-line, eseguite in maniera più o meno

real-time ISOLAMENTO:

proprietà che deve essere verificata dalle implementazioni del concetto

di reference monitor; prevede la protezione di tutti i meccanismi che

realizzano il reference monitor, nei confronti di alterazioni non

autorizzate; allo stesso modo si assume protetto il database delle

autorizzazioni


IX

L LIBERAL *-PROPERTY:

nel controllo degli accessi basato sui reticoli, regola mandatoria relativa

alla possibilità di scrivere; permette di scrivere al livello del soggetto e a

tutti i livelli superiori (nel caso di reticoli di confidenzialità) o a tutti i

livelli inferiori (nel caso di reticoli di integrità) LIVELLO:

sinonimo di livello di sicurezza LIVELLO DI SICUREZZA:

nel controllo degli accessi basato sui reticoli e nei sistemi Multilevel-

Security, etichetta di sicurezza; viene utilizzato per intendere

un’etichetta, indipendentemente se essa sia relativa ad un soggetto o ad

un oggetto

M MATRICE DEGLI ACCESSI:

modello che permette di esprimere le autorizzazioni che i soggetti

hanno sugli oggetti; alle righe della matrice sono associati i soggetti, alle

colonne gli oggetti; l’elemento [s,o] contiene i diritti di accesso che il

soggetto s possiede sull’oggetto o

MECCANISMI DI SICUREZZA:

meccanismi interni al sistema che permettono di realizzare la politica di

sicurezza, implementando il controllo degli accessi MIGRAZIONE DI DOMINIO:

nel Type Enforcement, possibilità per un soggetto confinato in un dato

dominio, di spostarsi in un altro dominio; deve essere autorizzata da un

particolare tipo di permesso; ad ogni migrazione, il soggetto acquista i


X

permessi del dominio di destinazione e perde quelli del dominio di

partenza; permette di realizzare il principio dei privilegi minimi MODALITÀ DI ACCESSO:

definisce un modo in cui un soggetto possa accedere ad un oggetto,

appartenente ad una data classe (ad esempio, lettura e scrittura per un

file); ad ogni modalità di accesso, per una classe di oggetti, corrisponde

un diritto di accesso per i soggetti agli oggetti appartenenti a quella

classe MULTILEVEL-SECURITY:

generalizzazione del controllo degli accessi basato sui reticoli; ai soggetti

e agli oggetti viene associata, oltre che un’etichetta di sicurezza, una lista

di categorie; perché un soggetto possa accedere ad un oggetto, è

necessario che siano verificate le proprietà Simple Security e Liberal (o

Strict) *-Property e che, tra le categorie ad esso associate, ci siano tutte

quelle associate all’oggetto; viene utilizzato in ambiente militare e

realizza il principo need to know

N NEED TO KNOW:

principio che, in ambito militare, corrisponde al principio dei privilegi

minimi; viene realizzato nei sistemi Multilevel-Security: ai soggetti

vengono assegnate solamente le categorie relative alla classificazione

delle informazioni che è necessario conoscere per svolgere il compito


XI

O OBJECT MANAGER:

in Flask, sottosistema che si occupa della gestione di una delle astrazioni

del sistema operativo (processi, filesystem,…); ha la responsabilità di

imporre le decisioni di sicurezza e di etichettatura prese dal security

server; implementa un insieme di meccanismi di sicurezza OGGETTO:

entità passiva del sistema, contenitrice di informazioni, alla quale i

soggetti possono accedere secondo le regole imposte dal controllo degli

accessi

P PERMESSO:

indica la capacità di accedere ad un oggetto del sistema, in un dato

modo; in letteratura si trova come sinonimo di modalità di accesso,

diritto di accesso, privilegio, autorizzazione; altre volte è rappresentato

da una coppia, in cui la prima componente indichi un oggetto e la

seconda una modalità di accesso a quell’oggetto; in SELAC, sinonimo di

permesso rispetto al security context PERMESSO AMMINISTRATIVO:

nel controllo degli accessi basato sui ruoli, capacità di modificare gli

insiemi di ruoli, permessi, utenti e le relazioni che tra essi intercorrono PERMESSO RISPETTO AL SECURITY CONTEXT:

in SELAC, coppia in cui la prima componente indica un security

context valido per un oggetto e la seconda, un diritto di accesso

appartenente al vettore di accesso della classe dell’oggetto


XII

PERMESSO RISPETTO AL TIPO:

in SELAC, coppia in cui la prima componente specifica un tipo e la

seconda un diritto di accesso POLITICA APERTA:

nei controlli degli acessi discrezionali, specifica i divieti anziché le

autorizzazioni; tutto ciò che non viene esplicitamente vincolato è

automaticamente autorizzato POLITICA CHIUSA:

nei controlli degli accessi discrezionali, specifica esplicitamente le

autorizzazioni che i soggetti hanno sugli oggetti; tutto ciò che non viene

esplicitamente specificato è automaticamente negato dal meccanismo di

autorizzazione POLITICA DI SUPPORTO:

rappresenta i requisiti riguardanti l’identificazione e l’autenticazione

degli utenti e l’auditing degli accessi PRINCIPIO DEI PRIVILEGI MINIMI:

principio secondo il quale ad ogni soggetto è garantito solamente

l’insieme meno potente di privilegi che gli permetta di eseguire il

proprio compito PRIVILEGIO:

sinonimo di diritto di accesso PROBLEMA CALCOLABILE:

problema per il quale esiste un algoritmo che fornisca una soluzione, in

una serie finita di passi PROBLEMA DELLA SAFETY:

problema che chiede se, a partire da una data configurazione di un

modello di controllo degli accessi, sia decidibile l’esistenza di un’altra

configurazione raggiungibile, nella quale un particolare soggetto

possieda un dato privilegio su un dato oggetto; il problema è in generale

indecidibile


XIII

PROPRIETARIO:

nei controlli degli accessi discrezionali, individuo che possiede il potere

di decidere gli accessi consentiti ai soggetti sull’oggetto; è in generale il

creatore del file, ma in alcuni casi, la proprietà di un oggetto può essere

ceduta o acquistata PUNTO DI INGRESSO:

sinonimo di entrypoint

R REFERENCE MONITOR:

concetto alla base della sicurezza dei computer; è un’astrazione che

divide il sistema in un insieme di entità attive, chiamate soggetti, ed uno

di entità passive, chiamate oggetti; la possibilità di accedere ad un

oggetto da parte di un soggetto è verificata, per mezzo delle funzioni di

riferimento, in base alla regole memorizzate nel database delle

autorizzazioni RUOLO:

costrutto semantico attorno al quale è costruito il controllo degli accessi

basato sui ruoli; può indicare una funzione lavorativa all’interno di

un’organizzazione, o una responsabilità, qualifica o attività; ha associati

un insieme di utenti ed un insieme di permessi ed autorizza quegli utenti

a quei permessi RUOLO JUNIOR:

nel controllo degli accessi basato sui ruoli, ruolo che viene ereditato da

uno o più altri ruoli (senior); presuppone l’esistenza di una gerarchia di

ruoli; l’ereditarità riguarda gli assegnamenti di utenti e di permessi


XIV

RUOLO SENIOR:

nel controllo degli accessi basato sui ruoli, ruolo che eredita uno o più

altri ruoli (junior); presuppone l’esistenza di una gerarchia di ruoli;

l’ereditarità riguarda gli assegnamenti di utenti e di permessi

S SAFETY:

proprietà di una configurazione di un modello di controllo degli accessi;

prevede che sia impossibile, a partire da quella configurazione,

raggiungerne un’altra nella quale venga ceduto un permesso ad un

soggetto non autorizzato SCHEMA DI AUTORIZZAZIONE:

nei modelli di controllo degli accessi, insieme di regole che permettono

di passare da una configurazione del modello ad un’altra SECURITY CONTEXT:

in Flask e in SELAC, sinonimo di etichetta di sicurezza SECURITY CONTEXT VALIDO:

in SELAC, etichetta di sicurezza per un insieme di soggetti o di oggetti,

conforme alle regole di configurazione di SELinux SECURITY IDENTIFIER:

in Flask, rappresentazione interna all’architettura di un’etichetta di

sicurezza; viene associato biunivocamente ad un security context dal

security server SECURITY KERNEL:

implementazione completa del concetto di reference monitor; deve

soddisfare le proprietà di completezza, isolamento e verificabilità SECURITY SERVER:

in Flask, componente del sistema che realizza il concetto di reference

monitor; si occupa di prendere decisioni di sicurezza, decisioni di


XV

etichettatura e di mantenere l’associazione tra security context e security

identifier; implementa la logica di una politica di controllo degli accessi SESSIONE:

nel controllo degli accessi basato sui ruoli, associazione di un utente ad

uno o più ruoli; permette all’utente di attivare i ruoli a cui è associato,

per esercitare i propri privilegi SICUREZZA:

in questa tesi, sinonimo di sicurezza dei computer SICUREZZA DEI COMPUTER:

riguarda la salvaguardia delle informazioni, in un computer, dalle

minacce relative alla confidenzialità e all’integrità; può essere fornita dai

metodi utilizzati per il controllo degli accessi SIMPLE SECURITY:


alla possibilità di leggere; permette di leggere al livello del soggetto e a

tutti i livelli inferiori (nel caso di reticoli di confidenzialità) o a tutti i

livelli superiori (nel caso di reticoli di integrità) SISTEMA SECURITY ENHANCED:

sistema nel quale sono state aggiunte funzionalità relative alla sicurezza,

che implementano un numero più o meno grande di concetti relativi

all’astrazione del refernce monitor SOGGETTO:

entità attiva all’interno del sistema; può essere un utente o un processo,

che agisca per conto di un utente; accede alle informazioni contenute

negli oggetti SOTTOSPAZIO DI SECURITY CONTEXT:

in SELAC, un qualsiasi sottoinsieme dello spazio dei security context SPAZIO DEI PERMESSI AUTORIZZATI:

in SELAC, uno degli insiemi ),( cs∆


XVI

SPAZIO DEI PERMESSI PROIBITI DI PRIMA SPECIE:

in SELAC, uno degli insiemi ),(1 csΠ

SPAZIO DEI PERMESSI PROIBITI DI SECONDA SPECIE:


SPAZIO DEI PERMESSI PROIBITI DI TERZA SPECIE:


SPAZIO DEI PERMESSI SPECIFICATI:

in SELAC, uno degli insiemi ),( csΣ

SPAZIO DEI PERMESSI VINCOLATI:

in SELAC, uno degli insiemi ),( csΧ

SPAZIO DEI SECURITY CONTEXT:

in SELAC, insieme O SPAZIO DEI SECURITY CONTEXT VALIDI PER GLI OGGETTI:

in SELAC, uno degli insiemi O(c) SPAZIO DEI SECURITY CONTEXT VALIDI PER I SOGGETTI:

in SELAC, insieme S SPAZIO DELLE ETICHETTE:

in SELAC, sinonimo di spazio dei security context SPAZIO DELLE ETICHETTE DI SICUREZZA:

in SELAC, sinonimo di spazio dei security context SPAZIO DI ACCESSIBILITÀ:

in SELAC, insieme di permessi (rispetto al security context), relativi ad

una stessa classe di oggetti STRICT *-PROPERTY:


alla possibilità di scrivere; permette di scrivere solamente al livello del

soggetto; è utile ai fini dell’integrità dei dati, nei reticoli di confidenzilità


XVII

T TABELLA DI DEFINIZIONE DEI DOMINI:

nel Type Enforcement, indica le interazioni possibili fra i soggetti e gli

oggetti; è rappresentata da una matrice alle cui righe sono associati i

domini dei soggetti e alle colonne i tipi degli oggetti; un elemento [d,t]

della tabella indica le autorizzazioni che i soggetti confinati nel dominio

d hanno sugli oggetti con tipo t

TABELLA DI INTERAZIONE DEI DOMINI:

nel Type Enforcement, indica le interazioni possibili fra i soggetti; è

rappresentata da una matrice le cui righe e colonne sono associate ai

soggetti; un elemento [d1,d2] della tabella indica le autorizzazioni che

i soggetti confinati nel dominio d1 hanno sui soggetti confinati nel

dominio d2; fra le autorizzazioni possibili, c’è quella per creare soggetti

(migrazione di dominio) TIPO:

nel Type Enforcement, definisce un’etichetta per gli oggetti TRANSIZIONE DI DOMINIO:

nel Type Enforcement, sinonimo di migrazione di dominio TRANSIZIONE DI SECURITY CONTEXT:

in Flask, assegnazione di un’etichetta di sicurezza ad un nuovo oggetto

creato o ad un processo trasformato; corrisponde ad una decisione di

etichettatura del security server TRUSTED COMPUTING BASE:

generico sottoinsieme del sistema operativo, che implementa la totalità

dei meccanismi responsabili della realizzazione della politica di sicurezza TYPE ENFORCEMENT:

modello di controllo degli accessi mandatorio, basato sulle tabelle,

mediante il quale i soggetti vengono confinati in domini e agli oggetti


XVIII

vengono assegnate etichette di sicurezza chiamati tipi; le interazioni

possibili fra soggetti ed oggetti sono specificate tramite la tabella di

definizione dei domini, quelle tra soggetti nella tabella di interazione dei

domini; è particolarmente utile per realizzare politiche che supportino il

principio dei privilegi minimi

U UNIVERSO DELLA CLASSE:

in SELAC, l’insieme )(cΩ

UTENTE:

astrazione che rappresenta un essere umano; può essere anche una

macchina o un programma; agisce nel sistema per mezzo dei soggetti

V VERIFICABILITÀ:

proprietà di un’implementazione del concetto del reference monitor,

che permette la sua analisi, per verificare il suo corretto funzionamento VETTORE DI ACCESSO:

in Flask, insieme delle modalità di accesso di una classe di oggetti;

corrisponde all’insieme di diritti di accesso che possono essere garantiti

o negati ai soggetti, su oggetti appartenenti ad una stessa classe VINCOLO:

esprime un divieto che deve essere imposto, perché una data proprietà

possa essere soddisfatta; può essere applicato a differenti componenti

dei modelli di controllo degli accessi; è, in generale, difficile da

esprimere


XIX

Acronimi

ACL : Access Control List

AVC : Access Vector Cache

DAC : Controllo degli accessi discrezionale

DDT : Tabella di definizione dei domini

DIT : Tabella di interazione dei domini

DTE : Domain and Type Enforcement

LBAC : Controllo degli accessi basato sui reticoli

MAC : Controllo degli accessi mandatorio

MLS : Multilevel-Security

PA : Assegnamento di permessi

RBAC : Controllo degli accessi basato sui ruoli

SID : Security Identifier

TCB : Trusted Computing Base

TE : Type Enforcement

UA : Assegnamento Utenti


XX

Insiemi e funzioni di SELAC

A :

insieme degli attributi che possono essere associati ai domini dei soggetti

e ai tipi degli oggetti

A(t) :

insieme degli attributi associati al tipo t

C :

insieme delle classi di oggetti

Do(s) :

insieme delle decisioni di etichettatura, relative ad oggetti creati da

soggetti con tipo s

Dp(s):

insieme delle decisioni di etichettatura, relative a processi trasformati,

eseguiti da soggetti con tipo s

E(t) :

insieme dei programmi entrypoint per il dominio t

M(s) :

insieme dei permessi rispetto al tipo, posseduti da soggetti aventi

etichetta di sicurezza s

M(t,p) :

insieme dei domini che hanno il diritto di accesso p sugli oggetti con

tipo t

O :

spazio dei security context; è il prodotto cartesiano TRU ×× ; contiene

tutte le etichette di sicurezza del sistema; non tutti i suoi elementi sono

validi


XXI

O(c) :

spazio dei security context validi per gli oggetti della classe c;

sottoinsieme dello spazio dei security context, contenente tutte e sole le

etichette di sicurezza che possono essere assegnate ad oggetti della

classe c

P :

insieme dei diritti di accesso; è formato da coppie in cui la prima

componente indica il diritto di accesso e la seconda la classe sulla quale

è definito il diritto di accesso; è pari all’unione dei vettori di accesso di

tutte le classi di oggetti

P(c) :

insieme delle modalità di accesso sugli oggetti della classe c; definisce il

vettore di accesso per c

R :

insieme dei ruoli che possono essere attivati dai soggetti

R(t) :

insieme dei ruoli che possono entrare nel dominio t

R(u) :

insieme dei ruoli ai quali è autorizzata l’identità SELinux u

)(sR→

:

insieme dei ruoli ai quali è possibile effettuare una transizione, a partire

dal ruolo s

S :

spazio dei security context validi per i soggetti; sottoinsieme dello spazio

dei security context (O), contenente tutte e sole le etichette di sicurezza

che possono essere assegnate ai soggetti

T :

insieme dei domini per i soggetti e dei tipi per gli oggetti


XXII

T(r) :

Insieme dei domini nei quali può essere confinato un soggetto con

ruolo r

)(sT→

:

insieme dei domini ai quali è possibile effettuare una transizione a

partire dal dominio s

)(*

sT→

:

chiusura transitiva di )(sT→

; indica tutti i domini raggiungibili, a partire

da s, mediante una serie di transizioni di dominio autorizzate

)(sT⇒

:

insieme dei domini ai quali è possibile effettuare una transizione

automatica, a partire dal dominio s

)(*

sT⇒

:

chiusura transitiva di )(sT⇒

; indica tutti i domini raggiungibili, a partire

da s, mediante una serie di transizioni automatiche di dominio

U :

insieme delle identità SELinux

U(r) :

insieme delle identità SELinux che possono assumere il ruolo r

2: TA →α :

funzione che restituisce l’insieme dei tipi ai quali è associato un dato

attributo


XXIII

,: falsoveroPOS →××γ :

funzione che permette di verificare se un dato diritto di accesso, su un

oggetto, sia vincolato per un soggetto

ROOR →:# :

funzione che restituisce la componente ruolo di un security context

TOOT →:# :

funzione che restituisce la componente tipo di un security context

UOOU →:# :

funzione che restituisce la componente identità SELinux di un security

context

PPTPTP →×× :# :

funzione che restituisce la componente diritto di accesso di un permesso

rispetto al tipo

TPTPTT →×× :# :

funzione che restituisce la componente tipo di un permesso rispetto al

tipo

↓D(s) :

insieme dei ruoli junior di un ruolo s

↑D(j) :

insieme dei ruoli senior di un ruolo j

),( csΧ :

spazio dei permessi vincolati per il security context s rispetto alla classe

c; contiene tutti e soli i permessi relativi ad oggetti della classe c, che

non sono garantiti ai soggetti con etichetta s, perché sono

esplicitamente vincolati nella configurazione


XXIV

),( cs∆ :

spazio dei permessi autorizzati per il security context s rispetto alla

classe c; contiene tutti e soli i permessi relativi ad oggetti della classe c,

che sono garantiti ai soggetti con etichetta s, perché esplicitamente

specificati e non vincolati nella configurazione

),( csΣ :

spazio dei permessi specificati per il security context s rispetto alla

classe c; contiene tutti e soli i permessi relativi ad oggetti della classe c,

che possono essere garantiti a soggetti con etichetta s; di essi, vengono

autorizzati solamente quelli che non sono esplicitamente vincolati

),(1 csΠ :

spazio dei permessi proibiti di prima specie per il security context s

rispetto alla classe c; contiene tutti e soli i permessi relativi ad oggetti

della classe c, che non sono garantiti ai soggetti con etichetta s, perché

non esplicitamente specificati (e neanche vincolati) nella configurazione

),(2 csΠ :

spazio dei permessi proibiti di seconda specie per il security context s


della classe c, che non sono garantiti ai soggetti con etichetta s, perché,

pur essendo specificati, sono esplicitamente vincolati nella

configurazione

),(3 csΠ :

spazio dei permessi proibiti di terza specie per il security context s


della classe c, che non sono garantiti ai soggetti con etichetta s, perché

non esplicitamente specificati e vincolati nella configurazione


XXV

)(cΩ :

universo della classe c; contiene tutti i possibili permessi relativi ad

oggetti della classe c

Appendice B: Linguaggi di configurazione

XXVI

A p p e n d i c e B

Linguaggi di configurazione

Di seguito riportiamo le produzioni della grammatica del linguaggio di

configurazione di SELinux e quelle del linguaggio chiamato SEL, da noi

analizzato nel capitolo IV.

In minuscolo vengono indicati i simboli non terminali del linguaggio,

mentre in maiuscolo quelli terminali; con λ viene indicata la parola vuota,

utilizzata nei costrutti o parti di costrutti opzionali. Tutti gli identificatori

vengono indicati con due generici simboli terminali, IDENTIFIER e

USER_IDENTIFIER, di cui le seguenti sono le espressioni regolari

caratterizzanti (in formato comprensibile al programma LEX):

IDENTIFIER : letter(letter|digit|_)*

USER_IDENTIFIER : letter(letter|digit|_|"."|"-")*

con

letter [A-Za-z]

digit [0-9]

Con il simbolo terminale PATH si intende una qualsiasi stringa che abbia

un matching con la seguente espressione regolare:

PATH : "/"(letter|digit|_|"."|"-"|"/")*

mentre con NUMBER una qualsiasi espressione che abbia un matching

con:


XXVII

NUMBER : digitdigit*

Infine, sono simboli terminali i seguenti:

== != && || ! , : ; ( ) [ - . ] ~ *

Il linguaggio di configurazione di SELinux

Il seguente è l’insieme completo di tutte le produzioni della grammatica del

linguaggio di configurazione di SELinux. Al momento attuale non sono

noti, all’infuori di [Sm02], documenti che trattino la grammatica del

linguaggio di configurazione di SELinux. [Sm02], del resto, si è dimostrato

un buon documento introduttivo alla specifica di configurazioni di

sicurezza, ma non sufficientemente aggiornato rispetto alle evoluzioni del

linguaggio. È questo il motivo per il quale le seguenti produzioni sono state

desunte direttamente dalla specifica YACC del linguaggio, presente nella

distribuzione di SELinux e scaricabile a partire dall’indirizzo web [WEB-

SELinux].

Nota tipografica: in grassetto indichiamo i simboli iniziali dei costrutti del

linguaggio di configurazione; le regole mediante le quali si configura SELinux

sono istanze di questi costrutti; in grassetto sottolineato indichiamo i

simboli iniziali di quei costrutti da noi presi in considerazione nella nostra

trattazione, a partire dai quali è definito il linguaggio SEL.

policy classes initial_sids access_vectors opt_mls te_rbac users

opt_constraints initial_sid_contexts opt_fs_contexts fs_uses

opt_genfs_contexts net_contexts


XXVIII

classes class_def

| classes class_def

class_def CLASS identifier

initial_sids initial_sid_def

| initial_sids initial_sid_def

initial_sid_def SID identifier

access_vectors opt_common_perms av_perms

opt_common_perms common_perms

| λ

common_perms common_perms_def

| common_perms common_perms_def

common_perms_def COMMON identifier identifier_list

av_perms av_perms_def

| av_perms av_perms_def

av_perms_def CLASS identifier identifier_list

| CLASS identifier INHERITS identifier

| CLASS identifier INHERITS identifier identifier_list

opt_mls mls

| λ

mls sensitivities dominance opt_categories levels base_perms

sensitivities sensitivity_def

| sensitivities sensitivity_def

sensitivity_def SENSITIVITY identifier alias_def ;

| SENSITIVITY identifier ;

alias_def ALIAS names

dominance DOMINANCE identifier

| DOMINANCE identifier_list


XXIX

opt_categories categories

| λ

categories category_def

| categories category_def

category_def CATEGORY identifier alias_def ;

| CATEGORY identifier ;

levels level_def

| levels level_def

level_def LEVEL identifier : id_comma_list ;

| LEVEL identifier ;

base_perms opt_common_base av_base

opt_common_base common_base

| λ

common_base common_base_def

| common_base common_base_def

common_base_def COMMON identifier perm_base_list

av_base av_base_def

| av_base av_base_def

av_base_def CLASS identifier perm_base_list

| CLASS identifier

perm_base_list perm_base

| perm_base_list perm_base

perm_base identifier : identifier

| identifier : identifier_list

te_rbac te_rbac_decl

| te_rbac te_rbac_decl

te_rbac_decl te_decl


XXX

| rbac_decl

| ;

rbac_decl role_type_def

| role_dominance

| role_trans_def

| role_allow_def

te_decl attribute_def

| type_def

| transition_def

| te_avtab_def

attribute_def ATTRIBUTE identifier ;

type_def TYPE identifier alias_def opt_attr_list ;

| TYPE identifier opt_attr_list


| λ

transition_def TYPE_TRANSITION names names : names identifier ;

| TYPE_MEMBER names names : names identifier ;

| TYPE_CHANGE names names : names identifier ;

te_avtab_def allow_def

| auditallow_def

| auditdeny_def

| dontaudit_def

| neverallow_def

allow_def ALLOW names names : names names ;

auditallow_def AUDITALLOW names names : names names ;

auditdeny_def AUDITDENY names names : names names ;

dontaudit_def DONTAUDIT names names : names names ;

neverallow_def NEVERALLOW names names : names names ;

role_type_def ROLE identifier TYPES names ;


XXXI


role_trans_def ROLE_TRANSITION names names identifier ;

role_allow_def ALLOW names names ;

roles role_def

| roles role_def

role_def ROLE identifier ;

| ROLE identifier roles

opt_constraints constraints

| λ

constraints constraint_def

| constraints constraint_def

constraint_def CONSTRAIN names names cexpr ;

cexpr ( cexpr )

| ! cexpr

| cexpr && cexpr

| cexpr || cexpr

| cexpr_prim

cexpr_prim U1 op U2

| R1 roleop R2

| T1 op T2

| U1 op user_names_push

| U2 op user_names_push

| R1 op names_push

| R2 op names_push

| T1 op names_push

| T2 op names_push

| SAMEUSER

| SOURCE ROLE names_push

| TARGET ROLE names_push

| ROLE roleop

| SOURCE TYPE names_push

| TARGET TYPE names_push


XXXII

op ==

| !=

roleop op

| DOM

| DOMBY

| INCOMP

users user_def

| users user_def

user_id identifier

| user_identifier

user_def USER user_id ROLES names opt_user_ranges ;

opt_user_ranges RANGES user_ranges

| λ

user_ranges mls_range_def

| user_range_def_list

user_range_def_list mls_range_def

| user_range_def_list mls_range_def

initial_sid_contexts initial_sid_context_def

| initial_sid_contexts initial_sid_context_def

initial_sid_context_def SID identifier security_context_def

opt_fs_contexts fs_contexts

| λ

fs_contexts fs_context_def

| fs_contexts fs_context_def

fs_context_def FSCON NUMBER NUMBER security_context_def

security_context_def

net_contexts opt_port_contexts opt_netif_contexts opt_node_contexts


XXXIII

opt_port_contexts port_contexts

| λ

port_contexts port_context_def

| port_contexts port_context_def

port_context_def PORTCON identifier NUMBER security_context_def

| PORTCON identifier NUMBER - NUMBER


opt_netif_contexts netif_contexts

| λ

netif_contexts netif_context_def

| netif_contexts netif_context_def

netif_context_def NETIFCON identifier security_context_def


opt_node_contexts node_contexts

| λ

node_contexts node_context_def

| node_contexts node_context_def

node_context_def NODECON ipv4_addr_def ipv4_addr_def


fs_uses fs_use_def

| fs_uses fs_use_def

fs_use_def FSUSEPSID identifier ;

| FSUSETASK identifier security_context_def ;

| FSUSETRANS identifier security_context_def ;

opt_genfs_contexts genfs_contexts

| λ

genfs_contexts genfs_context_def

| genfs_contexts genfs_context_def


XXXIV

genfs_context_def GENFSCON identifier PATH - identifier


| GENFSCON identifier PATH - - security_context_def

| GENFSCON identifier PATH security_context_def

ipv4_addr_def NUMBER . NUMBER . NUMBER . NUMBER

security_context_def user_id : identifier : identifier

opt_mls_range_def

opt_mls_range_def : mls_range_def

| λ

mls_range_def mls_level_def - mls_level_def

| mls_level_def

mls_level_def identifier : id_comma_list

| identifier



names identifier

| nested_id_set

| *

| ~ identifier

| ~ nested_id_set

names_push31 identifier

| identifier_list

| *

| ~ identifier

| ~ identifier_list



31 questo simbolo non terminale si distingue da names solamente per il fatto che non può

riscriversi in un’espressione che contenga parentesi graffe ( e ) annidate


XXXV

nested_id_set nested_id_list

nested_id_list nested_id_element

| nested_id_list nested_id_element

nested_id_element identifier

| nested_id_set


user_identifier USER_IDENTIFIER

user_identifier_list user_identifier

| identifier_list user_identifier

| user_identifier_list identifier

| user_identifier_list user_identifier

user_names_push names_push

| user_identifier

| user_identifier_list

| ~ user_identifier

| ~ user_identifier_list

Il linguaggio di configurazione SEL

Di seguito vengono presentate tutte le produzioni del linguaggio SEL,

descritto nel capitolo IV. Si rimanda al detto capitolo per l’elenco delle

semplificazioni operate rispetto al linguaggio di configurazione di SELinux

originale.

policy classes access_vectors te_rbac users opt_constraints

classes class_def

| classes class_def

class_def CLASS identifier


XXXVI

access_vectors av_perms

av_perms av_perms_def

| av_perms av_perms_def

av_perms_def CLASS identifier identifier_list

te_rbac te_rbac_decl

| te_rbac te_rbac_decl

te_rbac_decl te_decl

| rbac_decl

| ;

rbac_decl role_type_def

| role_dominance

| role_allow_def

te_decl attribute_def

| type_def

| transition_def

| te_avtab_def

attribute_def ATTRIBUTE identifier ;

type_def TYPE identifier opt_attr_list


| λ

transition_def TYPE_TRANSITION identifier identifier: identifier

identifier ;

te_avtab_def allow_def

allow_def ALLOW identifier identifier: identifier identifier ;

role_type_def ROLE identifier TYPES identifier ;



XXXVII

roles role_def

| roles role_def

role_def ROLE identifier ;

| ROLE identifier roles

role_allow_def ALLOW identifier identifier ;

opt_constraints constraints

| λ

constraints constraint_def

| constraints constraint_def

constraint_def CONSTRAIN identifier identifier cexpr ;

cexpr ( cexpr )

| ! cexpr

| cexpr && cexpr

| cexpr || cexpr

| cexpr_prim

cexpr_prim U1 op U2

| R1 roleop R2

| T1 op T2

| U1 op user_id

| U2 op user_id

| R1 op identifier

| R2 op identifier

| T1 op identifier

| T2 op identifier

op ==

| !=

roleop op

| DOM

| DOMBY

| INCOMP

users user_def

| users user_def


XXXVIII

user_def USER user_id ROLES identifier ;

user_id identifier

| user_identifier






user_identifier USER_IDENTIFIER

Bibliografia

XXXIX

Bibliografia

[Age] National Security Agency. Evaluated platforms: Trusted Xenix.

http://www.radium.ncsc.mil/tpep/epl/entries/CSC-EPL-92-001-A.html

[An72] Anderson, J.P. 1972. Computer Security Technology Planning

Study. ESD-TR-73-51, Vol 1, Hanscom AFB, Mass.

[AJP95] Abrams, M.D., Jajodia, S. and Poddel, H.J. 1995. Information

Security: An Integrated Collection of Essays. IEEE Computer Society Press,

pp. 40-97

[ALP02] Archer, M., Leonard, E. and Pradella, M. 2002. Towards a

Methodology and Tool for Analysis of Security-Enhanced Linux Security

Policies. NRL Memorandum Report NRL/MR/5540--02-8629

[AS00] Ahn, G. and Sandhu, R. 2000. Role-based Authorization Constraint

Specification. ACM Trans. of Info. and System Security, 3(4)

[Be91] Bell, D.E. 1991. Putting Policy Commonalities to Work. In

Proceedings of the 14th National Computer Security Conference, Oct, pp 456-471

[Bi77] Biba, K. 1977. Integrity Considerations for Secure Computer

Systems. U.S. Air Force Electronic Systems Division Technical Report 760372.

[BL73] Bell, D.E. and LaPadula, L.J., 1973. Secure Computer Systems:

Mathematical Foundations and Model. M74-244, Mitre Corp., Bedford, Mass.

[BJS93] Bertino E., Samarati P. and Jajodia S. 1993. Authorizations in

relational database management systems. In 1st ACM Conference on Computer

and Communication Security (Fairfax, VA, Nov.)

[BJSS97] Bertino, E., Jajodia, S., Samarati, P. and Subrahmanian, V. S. 1997.

A unified framework for enforcing multiple access control policies. In

Proceedings of ACM SIGMOD Conference on Management of Data (May). ACM,

New York.

Bibliografia

XL

[BK85] Boebert, W. E. and Kain, R. Y. 1985. A practical alternative to

hierarchical integrity policies. In Proceedings of the 8th National Computer Security

Conference (Gaithersburg, Md.).

[BN89] Brewer, D. F. C. and Nash, M. J. 1989. The Chinese wall security

policy. In Proceedings of the IEEE Symposium on Security and Privacy (Oakland,

Calif. May). IEEE Computer Society Press, Los Alamitos, Calif.

[BSSWH95a] Badger, L., Sterne, D. F., Sherman, D. L., Walker, K. M. and

Haghighat, S. A. 1995. Practical Domain and Type Enforcement for Unix.

In Proceedings of the IEEE Symposium on Security and Privacy (Oakland, Calif,

May)

[BSSWH95b] Badger, L., Sterne, D. F., Sherman, D. L., Walker, K. M. and

Haghighat, S. A. 1995. A Domain and Type Enforcement Unix Prototype.

In Proceedings of the 5th USENIX UNIX Security Symposium (Salt Lake City,

Utah, June)

[BTMD89] Brannstad, M., Tajalli, H., Mayer, F. and Dlava, D. 1989. Access

Mediation in a message passing kernel. In Proceedings of the 1989 IEEE

Symposium on Security and Privacy, pp 66-72

[CC97] Cholvy, L. and Cuppens, F. 1997. Analyzing Consistency of Security

Policies. In Proceedings of the 18th IEEE Computer Security Symposium on Research

in Security and Privacy.

[CERT] CERT 1999. CERT Advisory CA-99-02-Trojan-Horses. Online at:

http://www.cert.org/advisories/CA-1999-02.html

[CL03] Crampton, J. and Loizou, G. 2003. Administrative Scope: a

Foundation for Role-Based Administrative Models. In ACM Transactions on

Information and System security (TISSEC). May, Vol 2, No. 2, pp. 201-231

[CLR] Cormen, T.H., Leiserson, C.E. and Rivest, R.L. Introduzione agli

algoritmi. Jackson Libri.

[Com] Secure Computing. Type Enforcement technology for access

gateways and vpns.

Bibliografia

XLI

http://secure-computing.com

[CS96] Cuppens, F. and Saurel, C. Specifying a Security Policy: A Case

Study. In Proceedings of the Computer Security Foundations Workshop, Kenmare,

Co. Kerry, Ireland.

[CW87] Clark, D. D. and Wilson, D. R. 1987. A comparison of commercial

and military computer security policies. In Proceedings of the IEEE Symposium

on Security and Privacy (Oakland, Calif, Apr.). IEEE Computer Society Press,

Los Alamitos, Calif.

[DBY94] Dinollt, G., Benzinger, L. and Yatabe, M. 1994. Combining

Components and Policies. In Proceedings of the Computer Security Foundations

Workshop VII, Franconia.

[FHLMT99] Ford, B., Hibler, M., Lepreau, J., McGrath, R. and Tullmann P.

1999. Interface and execution models in the Fluke Kernel. In Proceedings of

the 3rd USENIX Symposium on Operating System Design and Implementation, pp

101-116, Feb.

[FK92] Ferraiolo, D. and Kuhn, R. 1992. Role-based access controls. In 15th

NIST-NCSC National Computer Security Conference, Baltimore, MD, Oct 13-16,

pp 554-563

[FM93] Fine, T. and Minear, S. E. 1993. Assuring Distributed Trusted

Mach. In Proceedings IEEE Computer Society Symposium on Research in Security

and Privacy, pp 206-218, May

[HK00] Hallyn, S. and Kearns, P. 2000. Domain and Type Enforcement for

Linux. In Proceedings of the 4th Annual Linux Showcase and Conference, Oct.

[HRU76] Harrison, M. A., Ruzzu, W. L. and Ullman, J. D. 1976. Protection

in operating systems. Commun. ACM 19, 8 (Aug.).

[ITSE91] Commission of the European Communities. Information

Technology Security Evaluation Criteria (ITSEC). Provisional Harmonized

Critera: version 1.2, Office for Official Publications of the European Communities,

Luxembourg, June 1991.

Bibliografia

XLII

[JEZ02] Jaeger, T., Edwards, A. and Zhang, X. 2002. Managing Access

Control Policies using Access Control Spaces. SACMAT’02 (Monterey,

Calif. June).

[JT01] Jaeger, T. and Tidswell, J. E. 2001. Practical Safety in Flexible Access

Control Models. ACM Transactions on Information and System Security

(TISSEC), 4, 2 (May), pp 158-190

[K97] Kuhn, D. R. 1997. Mutual exclusion of roles as a means of

implementing separation of duty in role-based access control systems. In

Proceedings of the 2nd ACM Role-Based Access Control Workshop. ACM, New

York.

[KMP00] Koch, M., Mancini, L.V. and Parisi Presicce, F. 2000. A formal

Model for Role-Based Access Control using Graph Transformations. In

Proceedings ESORICS2000 (F.Cuppens et al., eds.) Lect.Notes Comp.Sci.

1895, Springer-Verlag 2000, pp. 122-139

[KMP01a] Koch, M., Mancini, L.V. and Parisi Presicce, F. 2001. On the

Specification and Evolution of Access Control Policies. In Proceedings of the

6th ACM Symposium on Access Control Models And Technologies (SACMAT2001),

pp 121-130, Chantilly, VI, USA

[KMP01b] Koch, M., Mancini, L.V. and Parisi Presicce, F. 2001.

Foundations for a Graph-based approach to the Specification of Access

Control Policies. In Proceedings FoSSaCS 2001 (F.Honsell, M.Miculan, eds.)

Lect.Notes Comp.Sci. 2030, Springer-Verlag 2001, pp. 287-302 [KMP02] Koch, M., Mancini, L.V. and Presicce F. 2002. Decidability of

Safety in Graph-Based Models for Access Control. In Proceedings of the 7th

European Symposium on Research in Computer Security (ESORICS2002), pp229-

243

[La74] Lampson, B. W. 1974. Protection. Oper. Syst. Revi., 8, 1 (Jan.), pp 18-

24

Bibliografia

XLIII

[LA91] Lampson, B.W., Abadi, M., Burrows, M. and Wobber, E. 1991.

Authentication in Distributed Systems: Theory and Practice. Operating

Systems Rev., Vol 25, No5, Oct, pp 165-182

[LDSHS90] Lunt, T., Denning, D., Schell, R., Heckman, M. and Shockley,

W. 1990. The SeaView security model. In IEEE Trans. Softw. Eng., June

[LPI89] Levin, T.E., Padilla, S.J. and Irvine C.E. 1989. A Formal model for

Unix Setuid. In Proceedings of IEEE Computer Society Symposium on Security and

Privacy, IEEE Computer Society Press, Los Alamitos, Calif, May, pp 73-83

[LS01a] Loscocco, P. A. and Smalley, S. D. 2001. Integrating flexible

support for security policies into the Linux operating system. NSA Technical

Report, Feb.

[LS01b] Loscocco, P. A. and Smalley, S. D. 2001. Meeting critical security

objectives with Security-Enhanced Linux. In Proceedings of the 2001 Ottawa

Linux Symposium, July

[LS77] Lipton, R.J. and Snyder L. 1977. A linear time algorithm for deciding

subject security. Journal of the ACM, 24(3):455-464

[LS78] Lipton, R.J. and Snyder L. 1978. On Synchronization and Security. In

Demillo et al., editor, Foundation of Secure Computation. Academic Press,

1978

[LSMTTF98] Loscocco, P. A., Smalley, S. D., Muckelbauer, P. A., Taylor, R.

C., Turner, S. J. and Farrel, J. F. 1998. The Inevitability of failure: The

flawed assumption of security in modern computing environments. In

Proceedings of the 21st National Information Systems Security Conference, pp 303-314,

Oct.

[Mi95] Minear, S. E. 1995. Providing Policy Control Over Object

Operations in a Mach Based System. In Proceedings of the 5th USENIX UNIX

Security Symposium, pp 141-156, June

[NO99] Nyanchama, M. and Osborn, S. 1999. The role graph model and

conflict of interest. ACM Trans Inf. Syst. Sec. 2, 1 (Feb.)

Bibliografia

XLIV

[OFSS96] Olawsky, D., Fine, T., Schneider, E. and Spencer, R. 1996.

Developing and using a “Policy Neutral” Access Control Policy. In

Proceedings of the New security Paradigms Workshop. ACM, Sept.

[OR91] O’Brien, R. and Rogers, C. 1991. Developing Applications on

LOCK. In Proceedings of the 14th National Computer Security Conference,

Washinghton DC, Oct., pp 147-156

[Ot01] Ott, A. 2001. The Rule Set Based Access Control (RSBAC) Linux

Security Extension. In Proceedings of the 8th Internationa Linux Congress, Nov.

[Sa88] Sandhu, R. 1988. The schematic protection model: Its definition and

analysis for acyclic attenuating schemes. Journal of the ACM, 35(2):404-432,

April

[Sa92] Sandhu, R. 1992. The Typed Access Matrix Model. In IEEE

Symposium on Security and Privacy. May

[Sa93] Sandhu, R. 1993. Lattice-based access control models. IEEE

Computer, 26(11):9-19, Nov.

[Sa96] Sandhu, R. 1996. Access Control: The Neglected Frontier. In

Proceedings of the 1st Australasian Conference on Information Security and Privacy,

Wollongong, Australia, June 23-26.

[Sa98] Sandhu, R. 1998. Role-Based Access Control. Advances in Computer

Science, vol 46, Academic Press.

[SaSa97] Sandhu, R and Samarati, P., 1997. Authentication, access control and

intrusion detection. In Allen B. Tucker, editor, the computer Science and

Engineering Handbook, pp 1929-1948. CRC Press.

[Sc74] Schell, R.R. 1974. Effectiveness – The Reason for a Security Kernel.

In Proceedings of the National Computer Conference. pp 975-976

[ShSc81] Shirley, L.J. and Schell, R. 1981. Mechanism Sufficiency Validation

by Assignment. In Proceedings of IEEE Symposium on Security and Privacy, Apr.,

pp 26-32

Bibliografia

XLV

[Sm02] Smalley, S. D. 2002. Configuring the SELinux Policy. Nai Labs

Report #02-007, June

[SBL89] Saydjari, O. S., Beckman, J. M. and Leaman, J.R. 1989. LOCK

Trek: Navigating Uncharted Space. In Proceedings of the 1989 IEEE Symposium

on Security and Privacy, pp 167-175

[SCFY96] Sandhu, R., Coyne, E. J., Feinstein, H. L. and Youman C.E. 1996.

Role-based access control models. IEEE Computer, 29(2):38-47, Feb.

[SF01] Smalley, S. D. and Fraser, T. 2001. A security policy configuration

for the Security-Enhanced Linux. NAI Labs Technical Report, Feb.

[SFV01] Smalley, S. D., Fraser, T. and Vance, C. 2001. Linux Security

Modules: General Security Hooksfor Linux. Available at:

http://lsm.immunix.org. September.

[SG92] Sandhu, R. and Gurpreet, S. Suri 1992. Non Monotonic

Transformation of Access Rights. In Proceedings of the IEEE Symposium on

Research and Privacy, pp 148-161

[SM98] Sandhu, R. and Munawer, Q. 1998. How To do Discretionary

Access Control Using Roles. In Proceedings of 3rd ACM Workshop on Role Based

Access Control, Fairfax, Virginia, Oct.

[SSC97] Secure Computing Corporation. DTOS Generalized Security Policy

Specification. DTOS CDRL A019, 2675 Long Lake Rd, Roseville, MN

55113. June.

http://www.securecomputing.com/randt/HTML/dtos.html.

[SSC99a] Secure Computing Corporation. Assurance in the Fluke

Microkernel: formal security policy model. CDRL A003, 2675 Long Lake

Rd, Roseville, MN 55113. Feb.


[SSC99b] Secure Computing Corporation. Assurance in the Fluke

Microkernel: formal top-level specification. CDRL A004, 2675 Long Lake

Rd, Roseville, MN 55113. Feb.

Bibliografia

XLVI


[SSLHAL99] Spencer, R., Smalley, S. D., Loscocco, P., Hibler, M.,

Andersen, D. and Lepreau, J. 1999. The Flask Security Architecture: System

support for diverse security policies. In Proceedings of the 8th USENIX Security

Symposium, Aug, pp 123-139

[SZ97] Simon, R. and Zurko, M. E. 1997. Mutual exclusion of roles as a

means of implementing separation of duty in role-based access control

systems. In Proceedings of the10th IEEE Computer Security Foundations Workshop

(June). IEEE Computer Society Press, Los Alamitos, Calif.

[TCSE85] Trusted Computer System Evaluation Criteria, DoD

5200.28_STD U.S. Department of Defence, Dec 1985

[TH90] Thomsen, D. J. and Haigh, J. T. 1990. A Comparison of Type

Enforcement and Unix Setuid. Implementation of Well-Formed

Transaction. In Proceedings of 6th Annual Computer Security Applications Conference

(Tucson, Arizona, Dec.)

[TJ00a] Tidswell, J. E. and Jaeger, T. 2000. Integrated constraints and

inheritance in DTAC. In Proceedings of the 5th ACM Role-Based Access Control

Workshop (July) ACM, New York.

[TJ00b] Tidswell, J. E. and Jaeger, T. 2000. An access control model for

simplifying constraint expression. In Proceedings of the 7th ACM Conference on

Computer and Communication Security (Nov). ACM, New York.

[TP97] Tidswell, J. E. and Potter, J. 1997. An approach to Dynamic

Domain and Type Enforcement. In Proceedings of the 2nd Australasian Conference

on Information Security and Privacy (July).

[TP98] Tidswell, J. E. and Potter, J. 1998. A dynamically typed access

control model. In Proceedings of the 3rd Australasian Conference on Information

Security and Privacy (July).

[TT02a] Tresys Technology. Overview of Security-Enhanced Linux Policy

File Structure. http://www.tresys.com/selinux

Bibliografia

XLVII

[TT02b] Tresys Technology. Overview of Security-Enhanced Linux Type

Enforcement and Role-Based Access Control Statements.

http://www.tresys.com/selinux

[Wa01] TrustedBSD: Adding Trusted Operating System Featureson

FreeBSD. In Proceedings of the FREENIX Track: 2001 USENIX Annual

Technical Conference (FREENIX ’01), June

[WCMSK02] Wright, C., Morris, J., Smalley, S. and Kroath-Hartman, G.

2002. Linux Security Modules: General Security Support for the Linux

Kernel. In Proceedings of the USENIX Security Symposium, Usenix Assoc. 2002,

pp17-31

[WSBPSO96] Walker, K. M., Sterne, D. F., Badger, L., Petkac, M. J.,

Sherman, D. L. and Oostendorp, K. A. 1996. Confining Root Programs

with Domain and Type Enforcement (DTE). In Proceedings of the 6th

USENIX UNIX Security Symposium (San Jose, Calif. July)

Siti web:

[WEB-SELinux] : http://www.nsa.gov/selinux

[WEB-TT] : http://www.tresys.com/selinux

[WEB-DTE] : http://www.cs.wm.edu/~hallyn/dte

[WEB-LIDS] : http://www.lids.org

[WEB-LSM] : http://lsm.immunix.org

[WEB-PACUM] : http://spazioinwind.libero.it/paculandia

[WEB-STL1] : http://www.sgi.com/tech/stl

[WEB-STL2] : http://www.yrl.co.uk/~phil/stl/stl.htmlx

[WEB-STL3] : http://www.cs.brown.edu/people/jak/proglang/cpp/

stltut/tut.html

politiche di controllo degli selinux di …spazioinwind.libero.it/paculandia/tesi.pdfil controllo...

Documents