i meccanismi di controllo degli accessi nei sistemi ... · i meccanismi di controllo degli accessi...

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


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.


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


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.


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.


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


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


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.


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.


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.


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


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.


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:


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.


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,


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


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


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.


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


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


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


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.


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]).


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 ;


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


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


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.


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


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


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


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.


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


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.


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.


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”

i meccanismi di controllo degli accessi nei sistemi ... · i meccanismi di controllo degli accessi...

Documents