Post on 18-Feb-2019
Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica Elaborato finale in Sistemi Operativi
I meccanismi di controllo degli accessi nei sistemi operativi moderni
Anno Accademico 2011/2012 Candidato: Salvatore Del Prete matr. N46000486
III
Indice
Introduzione 4
Capitolo 1. Il Controllo degli Accessi 6
1.1 Matrice degli accessi 7
1.2 Discretionary Access Control 10
1.3 Mandatory Access Control 12
1.3.1 Lattice Based Access Control 14
1.4 Role Based Access Control 15
Capitolo 2. Il Controllo degli Accessi nei Sistemi Operativi moderni 18
2.1 UNIX 18
2.1.1 Linux 21
2.1.2 Mac OS X 22
2.2 Microsoft Windows 24
2.2.1 Windows NT 25
2.2.2 Windows 2000 28
2.2.3 Windows XP 30
2.2.4 Windows Vista / 7 32
Confronti e Conclusioni 36
Bibliografia 37
I meccanismi di Controllo degli Accessi nei Sistemi Operativi moderni
4
Introduzione
La sicurezza è diventata, col tempo, uno degli obiettivi primari nella progettazione di un
sistema operativo. L‟evoluzione della società ha portato ad un‟estensione dell‟uso dei
mezzi informatici fino agli ambiti più critici, aumentando di pari passo la necessità di
proteggere le informazioni memorizzate. Sapere che i propri dati sono al sicuro è una delle
necessità fondamentali di un utente e, a tale scopo, sono stati introdotti numerosi
meccanismi per assicurarne integrità e confidenzialità. Le politiche di sicurezza applicate
ai sistemi interessano più livelli, dall‟autenticazione degli utenti alla gestione sicura della
memoria fisica. Da questo punto di vista, sono estremamente rilevanti i meccanismi di
Controllo degli Accessi, che permettono di differenziare le possibili interazioni concesse
con un oggetto rispetto a chi ne fa richiesta.
Il Controllo degli Accessi è una delle componenti principali delle politiche di sicurezza dei
sistemi operativi multiutente, e in generale di ogni ambiente contenente informazioni
condivise. Fondamentalmente, il suo scopo è regolamentare quanto meglio possibile
l‟accesso alle risorse del sistema così da impedire che su di esse vengano eseguite delle
operazioni non autorizzate e solitamente maliziose.
Si intuisce facilmente come non esista un modello unico di controllo adatto ad ogni
esigenza di protezione. Proprio per questo, si cerca di rendere i modelli quanto più elastici
possibile, così da poter realizzare per ognuno diverse politiche di controllo, e poter
scegliere quella ritenuta più adatta o, all‟occorrenza, descriverne una ad hoc definendone i
I meccanismi di Controllo degli Accessi nei Sistemi Operativi moderni
5
meccanismi.
Lo studio sui meccanismi di controllo degli accessi ha avuto inizio già negli anni settanta,
trovando però un‟applicazione concreta solo nelle versioni più recenti dei sistemi operativi
commerciali. Dati gli studi trentennali, la letteratura è ricca di modelli teorici eterogenei
anche se, come spesso accade, solo una minima parte di essi ha visto un riscontro
concreto.
Nel prosieguo dell‟elaborato verrà riportata un‟analisi dei meccanismi di controllo degli
accessi nei sistemi operativi recenti, così da metterne in luce pregi e difetti ed evidenziare
come essi si propongono all‟utente finale.
Ai fini di fornire le nozioni necessarie alla comprensione dei meccanismi specifici dei vari
sistemi operativi, nel primo capitolo si avrà una panoramica sui modelli di controllo degli
accessi più noti in letteratura.
Nel capitolo successivo avrà inizio l‟analisi dei sistemi specifici, partendo dai meccanismi
del sistema UNIX. Verranno definite le caratteristiche del modello in esso implementato e
valutate le versioni specifiche di due sistemi da esso derivati, Linux e Mac OS X, che ha
introdotto un meccanismo di controllo degli accessi dalla sua versione 10.4.
Quindi verranno analizzati i sistemi Microsoft, a partire da Windows NT per concludere
con le novità introdotte da Windows Vista e 7.
I meccanismi di Controllo degli Accessi nei Sistemi Operativi moderni
6
Capitolo 1
Il Controllo degli Accessi
Il Controllo degli Accessi è il punto focale dei meccanismi che verificano e rappresentano
le politiche di sicurezza di un sistema. Il suo compito è assicurare che l‟accesso da parte di
un utente, precedentemente autorizzato, ad una risorsa avvenga conformemente alla
politica specificata. Per comprendere al meglio quanto appena detto, è bene osservare la
definizione data in letteratura ([1]) dei concetti di risorsa e dominio di protezione, che
sono fondamentali nello studio dell‟Access Control.
Una risorsa è una qualsiasi entità passiva che richiede protezione. Nell‟ambito di file
system e access control, il termine risorsa può fare riferimenti indifferentemente a file,
directory, programmi, ma anche a porzioni di memoria e oggetti software.
Un dominio di protezione è invece un insieme di coppie <risorsa,diritti d‟accesso> legata
ad un soggetto, e rappresenta le risorse a cui esso è autorizzato ad accedere. In particolare,
per ogni risorsa sono riportati i diritti di cui gode il soggetto, ognuno rappresentante il
permesso ad eseguire una certa operazione sulla risorsa.
I diritti standard riportati in letteratura per file e directory sono quelli di lettura e scrittura.
Ad essi si è soliti aggiungere, in riferimento a programmi, il diritto di esecuzione. Si può
intuire che queste tre operazioni rappresentano solo le tre unità base dell‟insieme di
possibili diritti, che può essere esteso con altre operazioni.
Ne deduciamo che quando un soggetto tenta di eseguire un‟operazione su un oggetto, il
I meccanismi di Controllo degli Accessi nei Sistemi Operativi moderni
7
meccanismo di controllo degli accessi, che assume che l‟identità del soggetto sia già stata
opportunamente verificata, sfrutta le informazioni sul dominio di protezione relativo a
quel soggetto per imporre una propria politica attraverso il cosiddetto reference monitor.
Il reference monitor è definito in [3,4] come un elemento di controllo, solitamente
risiedente nel kernel e/o parzialmente su base hardware, che si occupa dell‟interazione tra
soggetti (utenti) e oggetti (risorse), in accordo alle autorizzazioni concesse.
Nella sua implementazione, un reference monitor deve soddisfare tre requisiti
fondamentali che ne definiscono le principali caratteristiche:
completezza (complete mediation) = il reference monitor deve essere sempre invocato in
caso di richiesta d‟accesso.
inattaccabilità (tamperproof) = il reference monitor deve essere a prova di manomissione.
verificabilità (verifiable) = deve essere possibile verificare facilmente il corretto
funzionamento del reference monitor.
L‟implementazione del concetto di reference monitor non è da subito stata parte dei
sistemi operativi commerciali, ma è stato necessario attendere l‟avvento della serie
Windows NT e Windows XP.
Un‟implementazione completa, che risponde ai requisiti richiesti, del reference monitor in
un sistema viene detta security kernel.
1.1 Matrice degli Accessi
Generalmente si tenta di rappresentare le politiche di protezione in modo tale che le
informazioni relative a utenti e risorse siano tenute in apposite strutture dati che ne
rendano semplice la consultazione. Il modello concettuale più noto ([1,2,6]), è sicuramente
quello che fa uso, per questi fini, della cosiddetta matrice degli accessi.
I meccanismi di Controllo degli Accessi nei Sistemi Operativi moderni
8
Nel modello ad Access Matrix gli elementi base sono denominati subject, object ed access
rights, e si riferiscono rispettivamente ad entità capaci di accedere ad oggetti (utenti),
entità aventi un accesso controllato (risorse), e il modo in cui un subject accede ad un
object (diritti).
Osservando la tabella è facile notare come ogni riga indichi il dominio di protezione di un
dato utente; mentre ogni colonna sia legata ad una risorsa e ne riporta gli accessi ad essa
relativi. Ogni entry della tabella è relativa quindi agli Access Rigths propri di quella
coppia <utente,risorsa> / <subject,object>.
Purtroppo, in un sistema reale il numero di risorse e di utenti è molto elevato, ciò
comporterebbe una matrice d‟accesso di dimensioni insostenibili. Inoltre, siccome ogni
subject generalmente accede ad un sottoinsieme ristretto di objects, l‟access matrix è di
solito una matrice sparsa, cosa che ancora una volta rende controproducente, in termini di
consumo di risorse di sistema, la sua memorizzazione. Per questi motivi nella pratica si
preferisce evitare la rappresentazione matriciale delle politiche di protezione ed affidarsi ai
più comuni approcci che prevedono l‟utilizzo di Access Control Lists (ACL) e Capability
Lists (C-List).
Gli approcci basati su ACL e C-List mirano a rendere più efficiente e meno oneroso in
termini di dimensioni il controllo degli accessi. Essi sono del tutto speculari e a volte sono
utilizzati entrambi contemporaneamente.
I meccanismi di Controllo degli Accessi nei Sistemi Operativi moderni
9
Una Access Control List rappresenta la politica associata ad una data risorsa elencando
gli utenti del sistema e i loro diritti d‟accesso ad essa relativi. In altre parole, una ACL non
è che una singola colonna della matrice degli accessi. Quando un utente tenta un accesso
esso viene identificato e il sistema ne verifica i diritti di accesso scorrendo la lista
specifica. Secondo questo approccio, risulta agevole ricercare le modalità di accesso ad
una risorsa di un dato soggetto e quali soggetti hanno diritto di accedere alla risorsa stessa,
poiché è sufficiente prendere l‟ACL relativa alla risorsa e scorrerla per verificare i diritti
dei vari utenti. Di contro, è difficile ottenere altre informazioni, soprattutto se
maggiormente legate ai soggetti, come ad esempio tutti gli access rights di un dato
soggetto, che possono essere conosciuti solo analizzando le ACL di tutti gli oggetti del
sistema. Le operazioni di revoca dei diritti d‟accesso sono anch‟esse relativamente
semplici, in quanto è sufficiente ricercare l‟apposita entry nelle ACL e modificarla,
cancellandola completamente se la revoca è assoluta.
Ai fini di permettere anche agli utenti “non in lista”, ossia non aventi diritti specifici sulla
risorsa, di non essere completamente tagliati fuori dall‟accesso a quest‟ultima, le ACL
possono prevedere delle entry di default o “pubbliche” che associano ad utenti generici un
set di diritti di base.
La lunghezza delle ACL può rappresentare un problema poiché ne aumenta sensibilmente
le dimensioni. Per cercare di ovviare o quantomeno limitare la cosa, si può pensare di
utilizzare nomi di gruppi, opportunamente definiti, in luogo dei singoli soggetti, così da
riunire in una sola entry un insieme di utenti aventi gli stessi diritti.
Le tecniche di protezione basate su ACL sono utilizzate dai sistemi Linux e Windows.
Una Capability List è una lista di permessi propri di un utente e relativa alle diverse
risorse presenti nel sistema a cui l‟utente può accedere. In pratica, una C-List rappresenta
completamente il dominio di un soggetto e pertanto può essere vista come una riga della
matrice degli accessi. Una C-List è formata da una serie di Capability Ticket di proprietà
dell‟utente relativo a quella lista. Quest‟ultimo può essere autorizzato a prestare o donare
ad altri utenti i suoi tickets. Ogni ticket specifica un oggetto e l‟insieme delle operazioni
I meccanismi di Controllo degli Accessi nei Sistemi Operativi moderni
10
autorizzate per l‟utente sullo stesso. I tickets rappresentano un problema di sicurezza
maggiore rispetto alle ACL, è dunque necessario che essi non siano falsificabili. Per
assicurarsene, il sistema operativo può provvedere al mantenimento dei tickets in luogo
degli utenti, conservandoli in una regione di memoria ad essi inaccessibile.
L‟utilizzo delle C-List, se da un lato è più efficiente rispetto alle ACL relativamente alle
informazioni sui diritti di un soggetto, dall‟altro è oneroso nel trovare tutti i soggetti che
possono accedere ad un dato oggetto, e eseguire operazioni di revoca dei diritti, per le
quali andrebbero analizzate e/o aggiornate tutte le C-List presenti nel sistema.
Per questi motivi nei sistemi operativi si è soliti preferire l‟approccio basato su ACL.
Tuttavia, in alcuni casi, come il sistema operativo MULTICS, vengono adottate soluzioni
ibride che sfruttano entrambi i meccanismi creandone di più complessi che riescano a
garantire maggiore efficienza e ridurre l‟overhead relativo alle politiche applicate.
La matrice degli accessi è sicuramente il modello rappresentativo di controllo degli accessi
più semplice, ma al contempo esso è astratto, puramente teorico e poco adatto ad essere
implementato.
In letteratura sono presenti numerosi modelli concreti, ognuno con le proprie
caratteristiche peculiari, suddivisibili in due macrocategorie: Modelli Discrezionali e
Modelli Mandatori. A queste due va aggiunto il Controllo degli Accessi Basato su Ruoli,
un modello genericamente considerato né discrezionale né mandatorio ma di grande
importanza vista la sua notevole flessibilità.
Di seguito si osservano in particolare le caratteristiche di queste classi di metodi di
controllo degli accessi.
1.2 Discretionary Access Control
Il meccanismo di controllo degli accessi discrezionale, sviluppato da Lampson, Graham, e
Denning, e ben definito in [6], si fonda sull‟accesso in funzione dell‟identità del soggetto
che l‟ha richiesto, e su una serie di autorizzazioni che regolino ciò che un soggetto può o
I meccanismi di Controllo degli Accessi nei Sistemi Operativi moderni
11
meno fare su un oggetto.
Concetto basilare nel modello DAC è quello di possesso di una risorsa da parte di un
soggetto che, in quanto proprietario, può amministrarne a propria discrezione i diritti
d‟accesso. Solitamente, la proprietà di un oggetto è acquisita all‟atto della sua creazione e,
in alcuni varianti del meccanismo, può essere successivamente delegata.
In DAC, quindi, il creatore di un oggetto è il suo primo proprietario; ogni oggetto ha
sempre un solo proprietario, indipendentemente che sia il creatore o qualcuno da esso
delegato; e solo il proprietario può provvedere all‟eliminazione dei propri oggetti.
Di base, solo il proprietario gode del diritto di amministrare i diritti d‟accesso di un
oggetto. In alcune varianti di questa configurazione standard del meccanismo, anche detta
Strict-DAC, è possibile per il proprietario delegare il diritto discrezionale che deriva dal
possesso dell‟oggetto.
In questo caso il meccanismo prende il nome di Liberal-DAC di tipo one level, two level o
multi level rispetto a quanto in profondità possa essere delegato il diritto.
Esiste un‟ulteriore variante, detta DAC con cambio proprietario, che prevede che un
utente possa trasferire la proprietà di un oggetto ad un altro utente. Questa versione è
utilizzabile combinata con strict o liberal DAC, di tutti i livelli, per creare meccanismi più
complessi.
Un‟altra discriminante è rappresentata dalla possibilità che la revoca degli accessi sia
dipendente o meno dall‟utente che li ha garantiti. Solitamente si accetta che colui che può
garantire un diritto d‟accesso sia anche in grado di revocarlo.
Le politiche DAC basate su autorizzazioni sono dette politiche “chiuse”, poiché contrarie,
concettualmente, al modo di operare del reference monitor, che procede per negazioni. In
modo opposto, le politiche DAC basate su negazioni sono dette “aperte”.
Le due tipologie possono essere combinate per ottenere politiche più complesse che,
tuttavia, non sempre garantiscono prestazioni migliori.
I meccanismi di Controllo degli Accessi nei Sistemi Operativi moderni
12
Da un punto di vista funzionale, un meccanismo DAC prevede un access control module
diverso per ogni tipo d‟oggetto. Il modulo valuterà se la richiesta d‟accesso di un soggetto
sull‟oggetto è accettabile o meno.
Nel momento in cui un soggetto effettua una richiesta d‟accesso di un certo tipo su un
oggetto, il sistema invia un messaggio al controllore di quell‟oggetto. Quest‟ultimo
verifica, osservando la matrice degli accessi, se la richiesta deve essere negata o può
essere accettata. In pratica, ogni accesso è mediato dal controller dell‟oggetto.
Al di là dei chiari aspetti positivi, il modello DAC soffre di un grande difetto risiedente
nella mancata imposizione di restrizioni sull‟uso delle informazioni, una volta che queste
siano state acquisite dall‟utente. Ne deriva che un utente malevolo, che gode di determinati
diritti su un oggetto, potrebbe effettuare una copia dello stesso oggetto, rendendolo
disponibile ad altri utenti altrimenti non autorizzati, violando le politiche di sicurezza
vigenti. Questo rende il sistema terreno fertile per gli attacchi di tipo Trojan Horse.
L‟uso di politiche DAC è molto diffuso, viste soprattutto la loro flessibilità e semplicità
concettuale. Basti notare che la politica di controllo degli accessi generica dei sistemi
UNIX è proprio di tipo discrezionale puro.
1.3 Mandatory Access Control
Il controllo degli accessi mandatorio regola gli accessi in base alla classificazione, in
termini di sicurezza, di soggetti ed oggetti del sistema.
Le politiche MAC assicurano integrità e confidenzialità delle informazioni con più
sicurezza rispetto alle DAC poiché riescono a mantenere sotto controllo il flusso di
informazioni nel sistema. Ciò è possibile siccome il MAC coinvolge aspetti non
direttamente controllabili da un utente, e impedisce a soggetti che possono accedere ad un
oggetto, di renderlo accessibile ad altri.
I meccanismi di Controllo degli Accessi nei Sistemi Operativi moderni
13
In una politica mandatoria, ad ogni soggetto e ad ogni oggetto del sistema è associato un
livello di sicurezza. In particolare si parla di:
etichetta di sicurezza (security label) = il livello di sicurezza associato ad un
oggetto, che indica il grado di sensitività dell‟informazione trasportata, ossia
quanto sarebbe pericoloso un accesso non autorizzato su quell‟oggetto.
livello di autorizzazione (clearance level) = il livello di sicurezza associato ad un
soggetto, che indica la sensibilità d‟informazione a cui può accedere, ossia quanto
si è sicuri che quell‟utente non renda accessibili delle informazioni ad utenti non
autorizzati.
Per risolvere una richiesta d‟accesso, il reference monitor confronterà l‟etichetta
dell‟oggetto con la clearance del soggetto, decidendo di conseguenza se concedere o meno
l‟accesso.
Anche il controllo mandatorio non impedisce ad un soggetto, autorizzato ad accedere ad
un file, di farne una copia. Tuttavia, a differenza del DAC, il MAC non consente in alcun
modo di alterare l‟etichetta di sicurezza, che sarà quindi la stessa sia per l‟originale sia per
la copia, rendendo ugualmente nulli i tentativi d‟accesso non autorizzati.
Per essere considerata mandatoria, una politica deve godere di globalità e persistenza.
Si parla di globalità quando una particolare informazione è in grado di mantenere la stessa
sensibilità (e quindi etichetta) indipendentemente da dove essa è situata.
Si parla invece di persistenza quando i livelli di sicurezza di soggetti ed oggetti sono
immutabili, ossia non variano nel tempo.
Solitamente, i livelli di sicurezza fanno parte di una gerarchia. Un classico esempio di
gerarchia è quella di uso in ambito militare che prevede i livelli: Top Secret (TS) – Secret
(S) – Confidential (C) – Unclassified (U).
Una gerarchia, per essere accettabile, deve risultare parzialmente ordinata. Ciò implica
l‟esistenza di una relazione di dominanza tale che due elementi della gerarchia o risultino
incomparabili o uno domini l‟altro.
I meccanismi di Controllo degli Accessi nei Sistemi Operativi moderni
14
La relazione di dominanza deve essere riflessiva, antisimmetrica e transitiva. Se anche una
sola di queste proprietà non fosse soddisfatta, verrebbe a mancare almeno una tra globalità
e persistenza, rendendo la politica non-mandatoria.
In letteratura capita spesso che con MAC ci si riferisca direttamente al controllo degli
accessi basato su reticoli, che è sicuramente il più noto della famiglia mandatoria. Risulta
quindi interessante analizzarlo nel dettaglio.
1.3.1 Lattice Based Access Control (LBAC)
Il controllo degli accessi basato su reticoli, sviluppato da Bell e La Padula ([7]), è nato
soprattutto per applicazioni in ambito militare. Esso prevede l‟utilizzo di un reticolo per
definire i livelli di sicurezza propri di un oggetto e ai quali un soggetto può accedere,
imponendo una direzione al flusso di informazioni.
Un reticolo è un insieme parzialmente ordinato tale che ogni coppia di elementi al suo
interno abbia un estremo superiore e uno inferiore. In LBAC questi estremi sono
rappresentati dai diritti d‟accesso.
In LBAC un utente può accedere alle risorse del sistema solo se il suo livello di sicurezza
è maggiore o uguale a quello delle risorse, ossia l‟accesso è consentito solo al livello
assegnato al soggetto o a quelli da esso dominato.
Si noti come con questo meccanismo si elimina, pur se non del tutto, la pericolosità degli
attacchi di tipo trojan horse, siccome un utente non autorizzato alla lettura avrà
sicuramente un livello più basso rispetto a quello della risorsa, il cui livello non può essere
cambiato dopo una copia.
In un reticolo, solitamente, i soggetti di livello alto hanno un potere elevato nelle
operazioni di lettura e minimo in quelle di scrittura; viceversa per i soggetti di livello
I meccanismi di Controllo degli Accessi nei Sistemi Operativi moderni
15
basso. Tale situazione è espressa dalle regole dei reticoli:
Sicurezza Semplice: un soggetto ad un certo livello di sicurezza può leggere solo oggetti
di livello pari o inferiore. In altri termini, S può leggere R e(S) ≥ e(R);
Proprietà *: un soggetto ad un certo livello di sicurezza può scrivere solo oggetti di
livello pari o superiore. In altri termini, S può scrivere R e(R) ≥ e(S);
Proprietà * Stretta: un soggetto ad un certo livello di sicurezza può scrivere solo oggetti
di pari livello. In pratica, S può scrivere R e(R) = e(S);
LBAC è un meccanismo nato per soddisfare richieste di confidenzialità dei dati, piuttosto
che assicurarne la loro integrità. Tuttavia, ad oggi, esso è in grado di rispondere anche a
queste altre necessità, e può inoltre essere utilizzato in politiche di aggregazione.
Due reticoli possono essere combinati per dar vita ad un unico reticolo composto che
assicuri integrità e confidenzialità. La combinazione di reticoli può causare un problema
nel caso si utilizzino due versioni diverse della regola * che governa la scrittura.
Un esempio diffuso, soprattutto in ambito militare, prevede la possibilità di sfruttare due
reticoli, uno basato su etichette di integrità, l‟altro su etichette di confidenzialità.
1.4 Role Based Access Control
Il Controllo degli Accessi basato su Ruoli è un modello più complesso, ma anche più
potente, dei precedenti, definito in [9,10]. Grazie alle sue caratteristiche, negli ultimi tempi
RBAC è riuscito ad imporsi nella progettazione di architetture di sicurezza di sistemi.
Concetto principe è ovviamente il ruolo, inteso come funzione lavorativa all‟interno di
un‟organizzazione. I ruoli rappresentano il cuore della gestione dei permessi di un sistema.
Ogni ruolo è, infatti, associato da un lato a degli utenti e dall‟altro a dei permessi. Gli
utenti non saranno quindi associati direttamente ai diritti d‟accesso, ma piuttosto ad uno o
più ruoli e, attivandoli, erediteranno i loro permessi. In definitiva, un ruolo svolge la
funzione di intermediario e fa in modo che gli utenti possano esercitare i propri permessi.
I meccanismi di Controllo degli Accessi nei Sistemi Operativi moderni
16
Mentre l‟insieme degli utenti è solito cambiare frequentemente all‟interno di un sistema,
l‟insieme dei ruoli è solitamente statico, salvo occasionali modifiche.
In generale, i componenti di questi insiemi sono legati tra loro da associazioni molti-a-
molti. Distinguiamo in RBAC due relazioni molti-a-molti fondamentali: User Assignment
(UA) e Permission Assignment (PA).
La User Assignment indica che un utente può essere associato a più ruoli, e più utenti
possono essere assegnati allo stesso ruolo.
Similmente, la Permission Assignment specifica che un ruolo può garantire più permessi,
e lo stesso permesso può essere garantito da più ruoli.
L‟associazione che lega un utente a uno o più ruoli è detta sessione. Un utente può attivare
in una sessione un qualsiasi sottoinsieme di ruoli a cui appartiene. Ogni utente può, quindi,
attivare più ruoli simultaneamente e aprire più sessioni in parallelo. Una sessione è
associata ad un solo utente, per tutta la sua durata. Il concetto di sessione equivale a quello
tradizionale di soggetto, presentato in letteratura.
Un buon modo per strutturare i ruoli di un sistema è attraverso una gerarchia. In una
gerarchia, i ruoli possono essere incomparabili o ereditare le caratteristiche di altri ruoli. Il
ruolo che eredita altri ruoli è detto “ruolo senior”, mentre quello ereditato è detto “ruolo
junior”. Un ruolo senior può essere a sua volta junior rispetto ad un altro ruolo.
Matematicamente, le gerarchie sono ordinamenti parziali. In quanto tali, esse risultano
relazioni riflessive, transitive e antisimmetriche. L‟ereditarietà gerarchica è riflessiva
poiché un ruolo eredita i suoi permessi; transitiva per il contesto stesso di una gerarchia; e
antisimmetrica per evitare di risultare ridondante.
Uno degli aspetti più importanti di RBAC è l‟uso dei vincoli. I vincoli sono un ottimo
modo per tracciare una politica organizzativa di più alto livello. Essi permettono, ad
esempio, di rendere ruoli e permessi mutuamente esclusivi, utile per rispettare il principio
della separation of duties.
Tra i vincoli imponibili, particolarmente rilevanti sono sicuramente:
I meccanismi di Controllo degli Accessi nei Sistemi Operativi moderni
17
Ruoli mutuamente esclusivi = dato un insieme di ruoli, definiti mutuamente
esclusivi, un utente può al più essere assegnato ad uno di essi.
Permessi mutuamente esclusivi = dato un insieme di ruoli, un permesso potrà
essere garantito al più da uno solo di essi.
Cardinalità = limita il numero massimo di membri per un ruolo o di ruoli per un
utente o di permessi per un ruolo.
Ruoli prerequisiti = un utente può essere assegnato ad un certo ruolo A se e solo se
è già stato assegnato ad un ruolo B. Imponibile anche sui permessi.
Vincoli sulle sessioni = limita il numero di sessioni aperte in parallelo per un utente.
RBAC è neutrale rispetto alla politica di controllo degli accessi adottata. Al contempo esso
cerca di realizzare alcuni principi di sicurezza, quali i ben noti “principio dei privilegi
minimi”, “separation of duties”, e “Data abstraction”.
In base a quanto detto, è logico riconoscere come uno dei principali vantaggi di RBAC
quello di poterlo configurare per simulare LBAC, che ne è quindi un‟istanza particolare, o
i più comuni modelli DAC. Molto spesso si opera proprio in questo modo.
Non tutti i sistemi operativi supportano completamente RBAC, ma spesso ne sfruttano
solo alcuni aspetti. L‟uso amministrativo dei ruoli, ad esempio, è proprio anche di sistemi
come NetWare e Microsoft Windows NT.
I meccanismi di Controllo degli Accessi nei Sistemi Operativi moderni
18
Capitolo 2
Il Controllo degli Accessi nei Sistemi Operativi moderni
Dopo aver presentato brevemente le caratteristiche dei modelli di controllo introdotti in
letteratura, è possibile affacciarsi all‟analisi dei meccanismi adoperati nei sistemi operativi
moderni, le caratteristiche dei quali sono evidenziate in [1,2,13,15].
Di seguito verranno illustrati separatamente i metodi propri delle due principali famiglie di
sistemi operativi: UNIX e Microsoft Windows NT. L‟analisi si focalizza soprattutto sui
metodi di gestione dei diritti d‟accesso alle risorse, ed offre una panoramica sulle
caratteristiche specifiche dei discendenti delle famiglie sovracitate.
2.1 UNIX
Il sistema di controllo degli accessi classico di UNIX, su cui si basano praticamente tutti i
suoi discendenti, è di tipo discrezionale e sfrutta di base pochi permessi, in una versione
detta minimal delle ACLs.
Ogni file, all‟atto della creazione, è associato all‟utente specifico che l‟ha generato, che
sarà l‟unico a godere della possibilità di amministrare i diritti d‟accesso ad esso relativi.
Ogni utente del sistema è caratterizzato da un identificativo univoco detto „user ID‟ e
possiede un „group ID‟, ossia un identificativo relativo al gruppo di appartenenza, che può
non essere unico. Nel momento in cui un‟applicazione viene eseguita, essa eredita userID
e groupID dall‟utente che l‟ha avviata, ma se necessario può, tramite particolari artifici,
I meccanismi di Controllo degli Accessi nei Sistemi Operativi moderni
19
cambiare temporaneamente dominio.
Si usa il valore 0 come user ID per indicare il supervisore, e come group ID per riferirsi al
root group. Solo il proprietario di un file o un membro del root group possono cambiarne i
permessi, e il loro diritto discrezionale non può essere delegato.
Le minimal ACL, che memorizzano le modalità di accesso di ogni risorsa per ogni utente,
sono sintetizzate su 9 bit divisibili in tre terne. I 3 bit di una terna rappresentano
singolarmente il diritto relativo ad una delle 3 modalità d‟accesso concesse in UNIX:
Lettura (r) = il file può essere acceduto ai fini di leggerne il contenuto;
Scrittura (w) = il contenuto del file può essere modificato;
Esecuzione (x) = qualora il file contenga codice eseguibile, esso può essere avviato.
Questo diritto viene sfruttato anche con le directory per rendere o meno accessibili
i file in esse contenuti.
Le terne rappresentano ognuna una delle categorie alle quali ogni utente di un sistema
UNIX può appartenere relativamente alla risorsa considerata. In particolare, le terne
rappresentano rispettivamente:
User = il proprietario del file;
Group = l‟utente non è il proprietario ma appartiene al suo stesso gruppo;
Others = l‟utente non è il proprietario e non appartiene al suo stesso gruppo;
Se un bit è alto, allora il diritto d‟accesso corrispondente, per quella categoria, è concesso;
in caso contrario è negato ([2]).
Nel momento in cui avviene un tentativo d‟accesso, i bit dei permessi vengono valutati in
ordine. In pratica: se l‟user ID del file combacia con quello del processo che ha effettuato
la richiesta d‟accesso, allora vengono applicati i soli permessi relativi ad User, non
considerando gli altri. Se invece l‟user ID è diverso, ma il group ID combacia con uno dei
group IDs del processo, allora vengono presi in considerazione i permessi della terna
Group, mentre User e Others non vengono valutati. Qualora, infine, né l‟user ID né il
group ID dovessero combaciare con quelli del processo, verrebbero valutati i soli permessi
I meccanismi di Controllo degli Accessi nei Sistemi Operativi moderni
20
relativi ad Ohters. Se questi permessi non consentono l‟operazione, il tentativo d‟accesso
fallisce.
Si considerano parte dei bit di protezione anche 3 bit aggiuntivi che interessano
principalmente i file eseguibili e tracciano comportamenti addizionali. Ci si riferisce ai
„suid‟ (set user ID), „sgid‟ (set group ID), e „sticky‟ bit. I primi due fanno sì, qualora
settati, che un processo all‟atto dell‟esecuzione assuma come effective user (group) ID,
l‟user (group) ID del proprietario piuttosto che quelli dell‟utente chiamante, che saranno
comunque memorizzati come real user (group) ID. I primi vengono usati in aggiunta ai
secondi nel momento in cui vengono prese decisioni relative al controllo degli accessi per
quel programma. L‟uso di suid e sgid è utile in termini di protezione in quanto fa in modo
che le applicazioni godano dei privilegi ristretti dell‟utente proprietario anche se avviati
dal supervisore (root).
Lo sticky bit, invece, se alto indica che il programma va mantenuto in memoria anche
dopo il termine della sua esecuzione, così da rendere più rapida un‟eventuale nuova
chiamata allo stesso.
Questi bit sono utilizzabili anche in associazione alle directory, con effetti, ovviamente,
diversi. Se il sgid è alto, i file creati nella directory ereditano il suo groupID. Lo sticky
invece determina che per ogni file interno alla directory, solo il rispettivo proprietario può
provvedere alle operazioni di rinomina, spostamento e cancellazione. Il suid, invece, viene
semplicemente ignorato.
Molti sistemi operativi UNIX-based moderni sfruttano una versione più ampia di ACL
denominata extended Access Control List ([2]).
Tramite l‟utilizzo delle extended ACLs è possibile associare ad ogni file un numero
qualsiasi di „named users‟ e „named groups‟, ognuno con i propri 3 bit di protezione.
Ovviamente, non è necessario che un file ne faccia uso, ma può ancora essere protetto solo
dal sistema classico. Solitamente viene aggiunto un ulteriore bit di protezione che indichi
I meccanismi di Controllo degli Accessi nei Sistemi Operativi moderni
21
la presenza o meno di una extended ACL per quel file.
La presenza di ulteriori utenti e gruppi con i propri diritti risulta un problema, siccome non
potrebbero essere rappresentati nella stessa struttura a 9 bit delle minimal ACLs. Per
risolvere il problema si sfrutta una „mask entry‟. In pratica, mentre le classi user e others
vengono trattate come nella versione tradizionale, l‟entry della classe group funge in realtà
da maschera. L‟entry effettiva indicherà l‟insieme di diritti “massimi” associabili ai named
users e named groups.
Ogni diritto relativo a questi utenti e gruppi deve essere presente nella maschera per essere
concesso, altrimenti l‟accesso è negato.
Solitamente, tutte le informazioni relative ai permessi, ai proprietari, i gruppi e le ACLs
sono memorizzate, insieme ad altre informazioni, negli inode, strutture di memorizzazione
che svolgono il ruolo di descrittori dei file.
2.1.1 Linux
Di base, Linux sfrutta il meccanismo classico discrezionale di UNIX senza alcuna
variazione. Tuttavia, su alcuni file system concede la possibilità di utilizzare le extended
ACLs.
Linux prevede oltre alle “Access ACLs” , che indicano i permessi di utenti e gruppi su file
e directory, le “Default ACLs” , applicabili solo alle directory.
Per una directory, una default ACL definisce i diritti d‟accesso degli oggetti all‟interno
della directory quando questi vengono creati. I file, quindi, ereditano la default ACL dalla
propria directory madre e la usano come propria Access ACL iniziale. Nel caso delle
sottocartelle, invece, queste ereditano dalla loro directory madre la default ACL
impostandola non solo come Access ACL ma anche come propria default ACL. Quando
viene creato un oggetto, i permessi per esso previsti saranno intersecati con quelli della
Default ACL della directory madre, se prevista.
I meccanismi di Controllo degli Accessi nei Sistemi Operativi moderni
22
Ogni ACL non è nient‟altro che una lista di ACL entries (ACE). Un‟ACL entry contiene
un tipo, un identificativo per l‟utente o il gruppo di riferimento, e i permessi.
Le extended ACLs di linux seguono, ovviamente, il meccanismo con maschera pensato sui
sistemi UNIX in generale.
I permessi relativi a User e Others restano equivalenti al caso base, e sono quindi sempre
validi. I vari named user, owning group e named group, invece, sono validi se la maschera
contiene effettivamente dei permessi.
Uno dei principali vantaggi di Linux è la possibilità di utilizzare dei moduli kernel
aggiuntivi per introdurre nuove funzionalità nel sistema. Tra questi ci sono i Linux
Security Modules, che forniscono una serie di modelli di sicurezza alternativi
implementabili. A fare uso dei LSMs sono diverse strutture aggiuntive, tra le quali il ben
noto SELinux, un‟architettura creata per aumentare la sicurezza del sistema, applicabile a
numerosi sistemi UNIX-like. Esso introduce un meccanismo MAC teso ad incrementare la
granularità del controllo degli accessi e renderlo meno alterabile dagli utenti.
Come detto, però, SELinux non fa parte del meccanismo standard, ma è piuttosto
un‟estensione, per questo non sarà trattato nel dettaglio in questo testo.
2.1.2 Mac OS X
Anche il sistema operativo Apple, appartenendo alla stessa famiglia, sfrutta di default il
meccanismo standard di permessi di UNIX. Tuttavia, dalla versione 10.4 “Tiger”, Mac OS
supporta le ACLs, se applicate ad un file system di tipo HFS+ o NFSv4 (solo in Tiger).
Il funzionamento delle ACLs su Mac OS X è praticamente equivalente a quello su altri
sistemi UNIX. I benefici introdotti sono identici, mentre possono variare leggermente le
tipologie d‟accesso e i metodi d‟implementazione e configurazione, come osservabile in
[19].
I meccanismi di Controllo degli Accessi nei Sistemi Operativi moderni
23
Le categorie utenti in OS X vengono indicate con i nomi “owner”, “group”, “everyone”,
ma le loro caratteristiche non cambiano. Una differenza rispetto al meccanismo
tradizionale UNIX è data dal fatto che, mentre normalmente solo l‟owner può gestire i
diritti dei suoi oggetti, in Mac OS X ogni componente degli administrative users ha il
permesso di modificare non solo i diritti degli oggetti ma anche la loro proprietà.
I permessi standard sono valutati solo dopo aver verificato che l‟oggetto in esame non ha
una ACL. Essi possono essere visti e gestiti direttamente dal Finder in una versione
semplificata per un numero indefinito di utenti e gruppi. Aprendo le proprietà di un file o
una cartella tramite Finder, è possibile assegnarvi i permessi:
Read and Write = l‟utente può aprire un file o sfogliare una cartella e modificarne il
contenuto, salvando i cambiamenti effettuati.
Read Only = l‟utente può aprire un file o sfogliare una cartella, ma in sola lettura,
senza alcuna possibilità di cambiarne il contenuto.
No Access = l‟utente non ha in alcun modo accesso al file o alla cartella.
Inoltre, per le cartelle, in Mac OS X è previsto il permesso “Write only” che indica che un
utente non può sfogliare la cartella ma può copiare o spostare dei file al suo interno.
Grazie all‟uso delle ACLs, Mac OS X prevede più permessi oltre i classici read, write,
execute. Il sistema operativo Apple ha scelto un formato di ACLs simile a quello di
Windows su file system NTFS e UNIX su file system NFSv4. Se si fa uso di queste ACLs
si aggiungeranno i permessi di lettura e scrittura anche su attributi e attributi estesi, oltre
all‟append, i delete su file e cartelle e soprattutto i privilegi di cambio permessi e cambio
proprietario. Solitamente, gli ultimi due sono indicati con il nome di permessi
d’Amministrazione.
Ogni Access Control Entry (ACE) contiene informazioni aggiuntive su come i permessi
che essa definisce sono ereditati da oggetti a livelli più bassi della gerarchia del file
I meccanismi di Controllo degli Accessi nei Sistemi Operativi moderni
24
system. Il meccanismo di ereditarietà utilizzato in Mac OS X è statico e può essere
configurato rispetto ai casi settando degli appositi attributi, tra i quali: no inheritance;
applica ai soli nuovi oggetti creati nella cartella; applica ad ogni nuova sottocartella;
applica ad ogni nuovo file; applica a tutti i discendenti della cartella.
In generale i diritti sono ereditati alla creazione di un file in una directory e possono
successivamente essere cambiati.
La configurazione e la valutazione dei diritti estesi dipendenti dalle ACL non è
direttamente possibile via Finder, dove, prima della versione 10.5 del sistema operativo, si
potevano assegnare i permessi solo alle tre categorie di base UNIX, quindi un singolo
proprietario, un solo gruppo, e tutti gli altri. Per i settaggi completi si possono comunque
utilizzare dei tools appositi.
È bene notare che ogni file o cartella creato da un utente nella root (home folder) avrà, di
default, i permessi di una cartella Pubblica. Per rendere sicuri questi file è necessario
cambiare direttamente i permessi via Finder. Questo tipo di comportamento facilita la
condivisione degli oggetti tra gli utenti, ma ovviamente implica una perdita di sicurezza di
base.
Mac OS X, dalla versione 10.4, prevede anche un‟amministrazione basata su ruoli, che
equivale a dire che un utente può loggarsi nel sistema come amministratore e compiere
un‟operazione privilegiata alla volta. Tra queste operazioni ci sono la possibilità di
richiedere password per ogni operazione di sistema e impostare il logout automatico dopo
un certo numero di minuti di inattività.
2.2 Microsoft Windows
Prima dell‟avvento di Windows NT, i sistemi Microsoft, dalle serie 3.x e 9x di Windows
alle varianti di IBM DOS, non prevedevano alcun meccanismo di controllo degli accessi,
limitandosi ad offrire la gestione di alcuni attributi di file, quale ad esempio il “read only”
che ne impedisce la modifica ma non la cancellazione. Non esisteva, inoltre, alcun modo
I meccanismi di Controllo degli Accessi nei Sistemi Operativi moderni
25
per impedire la lettura di un file.
Con Windows NT, e i suoi discendenti, i sistemi Microsoft iniziano a sfruttare un set di
permessi più complesso associato all‟uso delle ACLs.
La particolarità dei sistemi Windows è che essi offrono un controllo degli accessi a
granularità molto fine, interessando non solo file e directory ma ogni kernel object del
sistema.
In Windows ogni risorsa è vista come oggetto, alcuni dei quali (i kernel object o oggetti di
nucleo) non direttamente accessibili ma utilizzabili e modificabili attraverso le apposite
funzionalità messe a disposizione del sistema. Anche gli oggetti di nucleo possiedono un
insieme di attributi di sicurezza, che ne regola l‟accesso, memorizzato nelle ACLs, a loro
volta trattate come attributi dell‟oggetto ([1]).
In generale, in Windows ogni oggetto ha un proprietario, solitamente l‟utente che l‟ha
generato, che può modificare l‟ACL e permettere ad altri utenti di apportare modifiche ai
permessi o divenire proprietari.
2.2.1 Windows NT
Windows NT è il primo sistema operativo Microsoft a porre particolare attenzione sugli
aspetti di sicurezza, non solo in termini di servizi offerti ma anche di monitoraggio del
sistema.
È interessante far subito notare che Windows NT, a differenza di altri sistemi operativi,
sfrutta un meccanismo di controllo degli accessi uniforme per tutte le componenti di
sistema. Esso è, inoltre, il primo sistema operativo Microsoft ad implementare il concetto
di security reference monitor, disposto nel kernel. Il reference monitor si assicura che gli
algoritmi di access control siano applicati uniformemente su tutte le applicazioni e i servizi
di sistema. NT sfrutta il file system NTFS e vede i file come un insieme di proprietà, tra le
quali le ACLs.
I meccanismi di Controllo degli Accessi nei Sistemi Operativi moderni
26
Ad ogni oggetto che necessita del controllo degli acessi è assegnato un Security
Descriptor. Questi descrittori memorizzano lo stato di sicurezza di un oggetto,
mantenendo informazioni su proprietario, gruppo, ACL e informazioni di auditing. Se un
oggetto è privo di ACL si presume che l‟accesso sia garantito a tutti.
Un Security Descriptor prevede solitamente pochi campi: i flags che definiscono tipo e
contenuto di un security descriptor, oltre ad indicare la presenza o meno di ACLs; il
campo Owner che indica il proprietario di un oggetto, che è solitamente l‟unico a poter
modificare il security descriptor e le ACLs. Il contenuto del campo Owner può fare
riferimento sia ad un SID individuale che ad un group SID; infine le ACLs che si occupano
dei diritti d‟accesso e svolgono un ruolo importante nel monitoraggio del sistema ([2]).
Ogni Subject ha invece associato a sé un Access Token contenente, tra le altre cose, un
SID, ossia un identificativo di 48 bit che sostituisce lo user ID di UNIX.
Un Access Token è un oggetto che incapsula il security context di un processo o un thread.
Il suo scopo è quello di indicare di quali privilegi un utente possa godere.
Il TOKEN viene generato nel momento in cui un utente esegue il log on e associato alla
shell dell‟utente loggato e, conseguentemente, ai processi da esso eseguiti. Solitamente, il
token viene inizializzato con tutti i privilegi disabilitati. Di conseguenza, se uno dei
processi utente che hanno ereditato il token necessita di eseguire una determinata
operazione privilegiata, il processo dovrebbe abilitare l‟apposito privilegio prima di poter
effettuare la richiesta d‟accesso.
Un Access Token contiene diversi parametri. Oltre al Security ID (SID) già brevemente
descritto, si possono ricordare: I Group SIDs, raccolti in una lista. L‟accesso ad un oggetto
può essere definito sulla base dei group SIDs, o sui SIDs dei singoli utenti o su una
combinazione dei due; I privilegi di sistema, ossia una serie di servizi di sicurezza
richiamabili dall‟utente; Il Default Owner, che indica il proprietario di un processo,
solitamente l‟utente che l‟ha generato. Può riferirsi anche ad un group SID; La Default
ACL, applicata alla creazione dell‟oggetto con i permessi iniziali, poi modificabili dal
creatore o da un utente avente diritto ([2]).
I meccanismi di Controllo degli Accessi nei Sistemi Operativi moderni
27
Vale la pena segnalare l‟esistenza di un tipo di token particolare, il cosiddetto
“Impersonation Token”. Quest‟ultimo permette ad un thread o un processo di cambiare
temporaneamente il proprio security context adottandone un altro, solitamente quello di un
altro utente. Il concetto di “impersonation” è unico di NT e riferito soprattutto alla
possibilità concessa al server di “essere” temporaneamente il client così da mettere in
sicurezza gli oggetti. Sarà il client a passare l‟impersonation token al server.
Il client può decidere il livello di impersonation del server tra:
Anonimo = il token non ha informazioni sul client.
Identification = il server può ispezionare l‟identità del client grazie alle informazioni
sui SIDs del client e i suoi privilegi, ma non può prenderne il posto.
Impersonation = il server identifica e imita il client assumendo lo stesso
comportamento.
Delegation = il server può comportarsi da client anche sui sistemi remoti con i quali
interagisce.
Quando viene creato un oggetto, il processo creante vi assegnerà un SID, che può essere il
proprio o uno dei group SID presenti nell‟access token. Non sarà possibile assegnare un
SID non presente nell‟access token.
Per quanto riguarda la gestione dei diritti d‟accesso, il meccanismo è molto simile a quello
di UNIX. Una delle differenze è nel numero e nella tipologia delle modalità d‟accesso
considerabili, siccome in NT si aggiungono ai classici read (r), write (w), execute (x)
anche delete (d), change permissions (p), take ownership (o).
Questi sei diritti possono essere combinati per ottenere dei set di privilegi specifici.
Microsoft ha previsto alcuni set di base, tra questi:
No access - ;
Read only – rx ;
Change – rwxo ;
Full control – rwxdpo ;
I meccanismi di Controllo degli Accessi nei Sistemi Operativi moderni
28
La sintassi più ricca offre più flessibilità e un controllo più profondo. Essa permette di
sistemare i privilegi in modo che non occorra essere l‟amministratore per eseguire alcuni
configurazioni ordinarie; al contempo permette anche di limitare i danni che un utente con
privilegi di amministratore può provocare sul sistema.
Windows NT prevede l‟ereditarietà dei permessi, ed introduce l‟access add on e il No
Access.
Access add on prevede che i diritti concessi possano essere “sommati”. In pratica, se per
una risorsa ad un gruppo è concesso solo il diritto di lettura, ma all‟utente A, appartenente
al gruppo, è concesso il diritto di scrittura, allora A godrà di entrambi i diritti.
No Access è invece un “permesso speciale” che prevale su tutti gli altri. Qualora un file
specifichi il no access per un gruppo, non ci sarà diritto che tenga, il file risulterà
inaccessibile per ogni appartenente al gruppo.
Le versioni precedenti al Service Pack 4 di Windows NT fanno uso di un meccanismo di
Permission Inheritance statico. Esso prevede che all‟atto della creazione, un file o una
directory erediti i permessi dalla sua directory madre, ossia quella in cui è stato creato.
Questo accade una e una sola volta. Dal momento in cui il file ha ereditato, i permessi di
file e directory madre saranno completamente indipendenti, ossia l‟eventuale variazione
dei secondi non influenza i primi. Al di là del comportamento di base appena illustrato, è
possibile fare in modo che eventuali cambiamenti sulla madre si riflettano sui figli. Per
farlo, si può utilizzare l‟opzione “replace permissions on subdirectories/existing files”. In
questo modo i permessi possono essere propagati lungo le gerarchie di directory.
Ovviamente, tramite l‟uso del “replace” si eliminano le differenze nei permessi dei file e
delle directory, e quando si ha una modifica si perdono completamente i set precedenti.
Questo problema è risolto dalla Permission Inheritance dinamica, propria di Windows
2000 e introdotta in NT tramite SP4.
Il meccanismo di controllo degli accessi di Windows NT è potente e flessibile, tuttavia
I meccanismi di Controllo degli Accessi nei Sistemi Operativi moderni
29
non è esente da pecche. I diritti d‟accesso configurabili sono comunque limitati, così come
il meccanismo d‟ereditarietà non è perfetto, e la restrizione e l‟estensione dei privilegi è
comunque complessa.
2.2.2 Windows 2000
Windows 2000 è un sistema operativo a 32 bit sviluppato per lavorare sui server.
L‟obiettivo principale, in ambito di sicurezza, è quello di superare le limitazioni di
Windows NT. Ciò che esso si propone è, dunque, permettere di gestire un numero
arbitrario ed estendibile di diritti d‟accesso; ottimizzare la permission inheritance; e fornire
un buon sistema di auditing.
Ai fini di assicurare e controllare le politiche di sicurezza scelte, Windows 2000 eredita da
NT alcuni componenti come il Security Reference Monitor e l‟Object Manager.
Windows 2000 considera i Gruppi come nodo centrale per la gestione e il controllo del
sistema, piuttosto che affidarsi ai profili individuali. I Gruppi sono definiti nella cosiddetta
Active Directory. Quest‟ultima può essere considerata, in linea molto generica, un
“raggruppamento”, una base di dati, di utenti, gruppi, computer, ed altri oggetti,
organizzati in un unico dominio.
Windows 2000, sfrutta i concetti di Access Token e Security Descriptor in modo del tutto
equivalente a Windows NT.
La sua particolarità è che prevede due distinte tipologie di ACL, con due scopi ben diversi:
le Discretionary ACLs e le System ACLs.
Le Discretionary Access Control Lists contengono la lista di permessi garantiti o negati
agli utenti, e ogni entry (ACE) è formata da un tipo, una dimensione e dei flags. I tipi di
ACE sono quattro, e prevedono concessione e negazione d‟accesso in generale e nello
specifico per oggetti in Active Directory.
Una System Access Control List prevede, invece, due tipologie di ACE: le system audit
ACEs e le system audit-object ACEs. In generale le system ACLs sono utili ai fini di
I meccanismi di Controllo degli Accessi nei Sistemi Operativi moderni
30
auditing ed infatti i proprietari degli oggetti non le controllano direttamente, anzi spesso
non hanno il permesso di leggerle. Lo scopo delle SACLs è quello di indicare quali
operazioni eseguite sull‟oggetto debbano essere tracciate, e possono essere configurate per
agire sia sui fallimenti che sui successi. Le audit-object ACEs contengono le indicazioni
per tutti gli oggetti da tracciare in Active Directory.
Si nota, quindi, che sono le DACLs a specificare gli effettivi Access Rights.
In Windows 2000 sono definite 13 modalità d‟accesso possibili, aggiungendo a quelle
standard anche read e write su attributi e attributi estesi, delete su sottocartelle e files,
append data, read permissions. Come in NT, sono utilizzabili sei combinazioni di
permessi predefinite: Full Control; Modify; Read & Execute; List Folder Contents; Read;
Write.
La differenza principale di Windows 2000 rispetto a NT è l‟uso della Permission
Inheritance dinamica, che complica l‟intero meccanismo di risoluzione dei permessi.
Come accade in NT, all‟atto della creazione, un file o una directory eredita
automaticamente i permessi dalla sua directory madre. Tuttavia, a differenza del caso
statico, stavolta gli oggetti restano legati alla madre e risentono di eventuali cambiamenti
nei permessi. Se capita una variazione dei permessi della directory madre, allora essa sarà
ereditata da tutti i figli che provvederanno ad aggiornare i propri diritti. Questo evento,
però, non è distruttivo siccome i permessi specifici sono conservati separatamente da
quelli ereditati.
Questa soluzione non solo migliora la Permission Inheritance, ma permette di definire
delle opzioni aggiuntive nell‟assegnazione dei permessi, così da poter scegliere se un
oggetto debba o meno ereditare i permessi; specificare su quali oggetti applicarli (solo se
usato su cartelle); decidere di quanto propagare i permessi nelle subdirectory; obbligare la
propagazione sull‟intero albero, con un‟operazione distruttiva.
I meccanismi di Controllo degli Accessi nei Sistemi Operativi moderni
31
2.2.3 Windows XP
Windows XP basa anch‟esso i propri meccanismi di protezione e Access Control su quelli
di NT. Come nei precedenti, anche in XP troviamo l‟uso di Access Tokens, Security
Descriptor, e le Discetional e System ACLs che regolano accessi e auditing. Inoltre,
Windows XP, come 2000, sfrutta un meccanismo di Permission Inheritance dinamico, ed
offre maggior sicurezza per la cartella di root e le sottocartelle in essa create, introducendo
anche una nuova root ACL. Rispetto ad NT notiamo comunque alcune novità.
Nel momento in cui viene creato un nuovo oggetto, il sistema operativo tenta di inserire
una DACL appropriata nel suo security descriptor. Per farlo, vengono prese in
considerazione la DACL specificata dal processo creante, se presente, e le ACEs
ereditabili dall‟oggetto padre, se ce ne sono. In alternativa si può richiedere una default
ACL all‟object manager o prenderne una adatta, se presente, nell‟access token dell‟utente.
Se nessuna di queste soluzioni è applicabile, allora semplicemente non si assegna alcuna
DACL, lasciando l‟accesso sempre garantito. Se invece si assegna una DACL, ma vuota,
l‟accesso viene negato a chiunque. In entrambi i casi è bene fare attenzione, onde incorrere
in malfunzionamenti.
Ovviamente, se è presente una DACL, essa viene letta all‟atto di una richiesta d‟accesso
da parte di un soggetto, alla ricerca di una ACE relativa al SID considerato, per valutare
come rispondere alla richiesta stessa.
Da amministratori è possibile acquisire la proprietà totale di una risorsa, così da evitare
che essa possa divenire, per cause varie, del tutto inaccessibile.
Anche in questo caso, il diritto discrezionale sugli oggetti è affidato irrevocabilmente al
suo proprietario, ma tramite il “Change Permissions”, è possibile concederlo, ed
eventualmente revocarlo, anche ad altri utenti.
Quando un oggetto viene creato, il suo proprietario è identificato dal contenuto del campo
I meccanismi di Controllo degli Accessi nei Sistemi Operativi moderni
32
owner dell‟access token del soggetto generante. Il contenuto sarà copiato nel campo owner
del security descriptor dell‟oggetto.
Windows XP Professional mette a disposizione un buon numero di permessi di default,
così da offrire una certa varietà nei privilegi d‟accesso.
Il numero e il tipo di permessi disponibili per un oggetto dipende dal suo security context.
Dalla documentazione Microsoft ([17]) si legge che su una partizione NTFS si
riconoscono per file e cartelle:
6 permessi di base, tra i quali, oltre ai classici Read e Write, distinguiamo il List
Folder Contents, applicabile solo a cartelle; il Read&Execute; il Modify; ed il Full
Control. Il funzionamento di ognuno di essi è abbastanza chiaro.
Una serie di 12 permessi avanzati predefiniti, spesso dati dalla combinazione dei 6
di base, che permettono, tra le altre cose, di leggere e modificare gli attributi, di
creare file nelle cartelle, di cancellare file e cartelle e, soprattutto, di agire sui
privilegi. I due permessi avanzati fondamentali, infatti, sono sicuramente i
permessi amministrativi di Change Permissions e Take Ownership, che
permettono, rispettivamente, di cambiare i permessi di un oggetto e di assumerne
la proprietà acquisendo il diritto discrezionale.
I privilegi assegnati da Windows XP al gruppo Users sono più ristretti rispetto alle
versioni precedenti. Per questo motivo, qualora si eseguisse un upgrade da Windows NT
4.0, gli utenti preesistenti entrerebbero a far parte del Power Users group, onde evitare che
alcune applicazioni possano smettere di funzionare correttamente. Se Windows XP è
installato da zero, invece, un utente può entrare a far parte dei Power Users solo se è un
utente locale e il suo account viene creato tramite l‟apposita voce nel Pannello di
Controllo.
Anche XP offre un servizio di auditing del sistema. È possibile configurarlo su molteplici
tipologie di eventi, impostandolo sia sui successi che sui fallimenti in base alle necessità.
I meccanismi di Controllo degli Accessi nei Sistemi Operativi moderni
33
Di default l‟auditing è disabilitato, anche perché abbassa le prestazioni del sistema.
Il problema principale della gestione di Windows XP è che si continua ad offrire all‟utente
la possibilità di loggarsi come amministratore e godere di privilegi amministrativi
illimitati, gli stessi che saranno poi ereditati dai processi da esso avviati. Qualora tali
processi si rivelassero maliziosi, la sicurezza del sistema sarebbe compromessa.
2.2.4 Windows Vista / 7
Con Windows Vista, la Microsoft ha deciso di portare avanti un‟opera di ristrutturazione
dei propri meccanismi di sicurezza, aggiungendo una serie di novità, più o meno grandi,
che ne hanno cambiato sensibilmente l‟idea e il funzionamento.
Lo scopo in Vista è quello di ridurre al minimo i privilegi concessi per fare in modo che
nessuno abbia sempre pieni poteri rischiando di mettere a rischio l‟intero sistema.
Vista eredita dalla famiglia NT l‟uso delle Access Control Lists per la gestione dei diritti
d‟accesso. Anche in questo caso, su file system NTFS ne sono previste due tipologie, le
Discretionary ACLs, che si occupano del controllo degli accessi vero e proprio, e le
System ACLs che forniscono le informazioni utili per l‟auditing del sistema.
Le novità riguardano soprattutto la gestione di gruppi e utenti, con l‟introduzione dell‟User
Account Control, in base al quale si impedisce ad un qualsiasi utente di godere di privilegi
illimitati; l‟insieme dei permessi di default ad essi garantiti; e il meccanismo di Mandatory
Integrity Control.
Sfogliando la documentazione ufficiale Microsoft ([16]), è possibile notare come alcuni
gruppi siano stati eliminati, altri modificati nel loro significato ed altri ancora aggiunti ex
novo. In particolare:
1. Il Built-In Administrator account è stato disabilitato di default, pur se viene ancora
considerato una soluzione d‟emergenza utilizzabile nella recovery console. La
scelta di disabilitarlo è perfettamente in linea con l‟idea di base di limitare in
I meccanismi di Controllo degli Accessi nei Sistemi Operativi moderni
34
partenza i privilegi di un singolo utente.
2. I Power User Permissions sono stati disabilitati, ma il gruppo è ancora presente
siccome in caso di upgrade da un sistema meno recente può evitare che alcune
applicazioni smettano di funzionare.
In Vista sono stati introdotti il servizio di Trusted Installer e alcuni nuovi SIDs, tra i quali
quello per gli Owner Rights, applicati a chiunque sia il proprietario al momento
dell‟accesso ad un file. Anche se un utente è proprietario di un oggetto, se nella ACL
dell‟oggetto c‟è un‟entry specifica relativa all‟utente, essa prevale sui privilegi derivanti
dall‟essere proprietari. Se un amministratore cambia il proprietario di un oggetto, gli
owner rights non vengono direttamente trasferiti, ma l‟ACE va riattivata manualmente.
Una delle novità riguarda sicuramente il controllo dei file di sistema. A differenza di
quanto accadeva in XP, in Windows Vista i file di sistema sono sotto il controllo unico del
TrustedInstaller SID. Qualora un processo utente volesse modificare un file di sistema,
dovrebbe prima riuscire a diventarne il proprietario e quindi introdurre un‟apposita ACE.
Questo, solitamente, non può avvenire per processi dal basso livello d‟integrità.
Rispetto a Windows XP, in Vista le ACLs presentano un formato leggermente diverso che
le rende più semplici e chiare. Fondamentalmente si può notare la sostituzione delle ACEs
relative ai Built-in Users con altre relative agli Authenticated Users, e l‟introduzione di
un‟ACE aggiuntiva inherit only per l‟Administrators Group e il Local System.
In Windows XP esistono due ACEs distinte per containters e subfolders ai fini di creare
file e cartelle nella root. In Vista, invece, esiste una sola ACE di tipo inherit-only, per files
e directory, che può garantire: Generic Read (GR); Generic Execute (GX); Generic Write
(GW); Read Security Descriptor (SD);
Esiste poi un‟ulteriore ACE, che è applicata solo alla root, che garantisce il privilegio LC,
in base al quale un utente può eliminare gli oggetti figli di root.
In Windows Vista chiunque, anche un Guest user, può leggere o eseguire i file nella root.
I meccanismi di Controllo degli Accessi nei Sistemi Operativi moderni
35
Tuttavia, solo gli utenti autorizzati possono creare nuovi file e cartelle e modificarne i
permessi.
Innovazione importante di Windows Vista è sicuramente il tanto chiacchierato User
Account Control. Tramite questo modulo di sicurezza, ad ogni utente che accede in Vista
sarà assegnato un access token a privilegi minimi, a parte i Protected Administrators a cui
sono comunque associati i privilegi amministrativi richiesti ma il loro gruppo è “used for
deny only”. Così facendo, ogni processo lanciato, anche se da un Protected
Administrators, agirà in partenza in un contesto di sicurezza ristretto, senza rischiare che
intervenga su risorse critiche senza autorizzazione. Se lanciato da un amministratore, il
processo ignorerà le autorizzazioni esplicite per il gruppo, considerando solo i divieti.
Qualora fosse necessario, i privilegi di un‟applicazione possono essere incrementati in
corso d‟opera, ma solo se l‟utente autorizza l‟operazione. Infatti, non esiste alcun modo di
lanciare un‟applicazione con privilegi elevati, senza il consenso esplicito dell‟utente. In
pratica, anche se un account utente gode di privilegi amministrativi, le applicazioni da esso
lanciato non ereditano questi privilegi. In linea di principio, si parla di una funzionalità
simile, idealmente, al comando „sudo’ dei sistemi UNIX.
Questo meccanismo, se da un lato migliora la sicurezza del sistema, dall‟altro è stato
molto criticato per l‟impatto sulle prestazioni, oltre all‟elevata frequenza di richieste
d‟autorizzazione che per l‟utente medio può risultare frustrante. Per rimediare alla
situazione, Microsoft ha snellito notevolmente il meccanismo presentandone una versione
molto più “leggera” in Windows 7.
Un‟altra nuova feature rilevante è il Mandatory Integrity Control (MIC) ([18]). Esso
introduce una politica mandatoria, che prevede l‟uso di integrity levels, indicati da
integrity labels memorizzate negli access tokens dei soggetti e in ACEs specifiche delle
SACLs degli oggetti. Ogni processo avrà un integrity level e ogni figlio erediterà quello
del padre. Un soggetto di un certo livello d‟integrità non potrà interagire con oggetti o altri
I meccanismi di Controllo degli Accessi nei Sistemi Operativi moderni
36
soggetti di livello superiore; analogamente, soggetti di alto livello non saranno costretti a
fare affidamento su dati di livello inferiore. Vista prevede 4 livelli d‟integrità: system,
high, medium, low; agli utenti è solitamente attribuito il livello “medium”, ai file
eseguibili “low”, e ai servizi di sistema “system”. All‟atto di una richiesta d‟accesso, il
sistema confronterà prima le integrity labels. MIC rende l‟intero meccanismo più robusto,
agendo direttamente sul flusso d‟informazioni nel sistema.
In generale, le differenze tra Vista e 7, per ciò che riguarda i meccanismi di controllo degli
accessi, sono nulle. Nel più recente sistema Microsoft si assiste, fondamentalmente, ad
un‟opera di alleggerimento dell‟infrastruttura di sicurezza, così da migliorare le
prestazioni senza perderne in efficacia.
I meccanismi di Controllo degli Accessi nei Sistemi Operativi moderni
37
Confronti e Conclusioni
Dall‟analisi effettuata nelle pagine precedenti, è possibile notare come, a dispetto di
quanto si possa inizialmente pensare, i meccanismi di controllo degli accessi utilizzati
dalle famiglie di sistemi UNIX e Microsoft Windows non sono poi così distanti.
Osservando il modo d‟agire di Windows, salta subito all‟occhio come in realtà le
funzionalità di base siano estremamente simili ad UNIX. Infatti, anche Windows specifica
l‟accesso per utenti singoli e per gruppi, con una serie di diritti definiti e gestiti quasi allo
stesso modo. Questa somiglianza è appurata anche dal fatto che entrambi sono considerati
sistemi di classe C nell‟Orange Book, documento pubblicato dal Dipartimento della Difesa
americano in cui sono specificate le categorie di sicurezza informatica.
Ovviamente, ci sono anche delle differenze. Windows introduce dei concetti aggiuntivi
quali quelli di Tokens e attributi di sicurezza, ed in generale si può dire che il suo sia un
meccanismo più flessibile rispetto a quello di UNIX, tale da permettere anche la
definizione di nuovi permessi e la concessione di privilegi amministrativi parziali. Uno dei
principali aspetti negativi del meccanismo UNIX, infatti, è che non è possibile concedere
solo alcuni privilegi amministrativi, rendendo troppo frequente l‟uso dei privilegi di root
anche non necessari. La vera distanza, quindi, è più che altro nell‟idea di utente.
In definitiva, da quanto si è avuto modo di osservare, è molto difficile indicare, tra quelli
citati, un sistema “più sicuro” degli altri. Ognuno di essi apporta accorgimenti diversi ad
un meccanismo simile, ma tutti con lo stesso identico fine: difendere al meglio le risorse, a
servizio dell‟utente.
I meccanismi di Controllo degli Accessi nei Sistemi Operativi moderni
38
Bibliografia
[1] Ancilotti, Boari, Ciampolini, Lipari 2004 “Sistemi Operativi”
[2] Stallings W. 2012 “Operating Systems – Internal and Designs Principles 7th
ed.”
[3] Anderson 1972 “Computer Security Technology Planning Study”
[4] U.S. Department of Defence 1985 “Trusted Computer System Evaluation Criteria”
[5] Harrison, Ruzzo, Ullman 1976 “Protection in Operating Systems”
[6] Lampson 1974 “Protection – ACM Operating Systems Rev. 8.1” pp. 18-24
[7] Bell 2005 “Looking Back at the Bell-La Padula Model”
[8] Sandhu 1993 “Lattice-Based Access Control Models”
[9] Ferraiolo, Khun 1992 “Role-Based Access Controls”
[10] Sandhu, Coyne, Feinstein, Youman 1996 “Role Based Access Control Models”
[11] Sandhu, Samarati 1994 “Access Control: Principles and Practice”
[12] Bai Qing-hai, Zheng Ying 2011 “Study on the Access Control Model in Information
Security”
[13] Anderson R. 2008 “Security Engineering: A Guide to Building Dependable
Distributed Systems” pp. 56-61
[14] Swift “Improving the Granularity of Access Control in Windows NT”
[15] Matej Cs´anyi “Access control in operating systems”
[16] Johansson 2007 “New ACLs Improve Security in Windows Vista”
[17] The Microsoft Windows Team, Russel, Crawford 2005 “Microsoft® Windows® XP
Professional Resource Kit”
[18] Conover “Analysis of the Windows Vista Security Model”
[19] White 2009 “Mac OS X Support Essentials v10.6”