A rchitettura complessiva del sistema

(1)

C ^apitolo 4

A rchitettura complessiva del sistema

Indice del capitolo

4.1 La protezione delle risorse condivise . ...65

4.2 Il modello astratto . . ...67

4.3 Il prototipo .. ..73

4.3.1 - L'integrazione tra NFS ed SELinux . .75

4.3.2 Un nuovo soggetto della politica di SELinux . ...76

4.3.3 L'implementazione della modifica . ..78

Questo capitolo definisce il modello astratto alla base del progetto e della realizzazione della soluzione architetturale adottata per condividere in maniera sicura e protetta le risorse gestite da una macchina virtuale.

4.1 - La protezione delle risorse condivise

La condivisione delle risorse è definita a partire da un insieme di meccanismi che

(2)

Architettura complessiva del sistema

permettono ad un utente su un sistema di accedere in modo semplice e trasparente alle risorse di un altro sistema. Questi meccanismi possono essere implementati mediante strategie diverse, che danno luogo ad un insieme di soluzioni alternative che spaziano dai sistemi completamente centralizzati a quelli totalmente distribuiti.

Negli ambienti virtualizzati, su ciascuna macchina fisica può essere allocato un numero arbitrario di macchine virtuali. Se immaginiamo che una di esse offra, grazie ad un modulo server, un servizio di condivisione delle proprie risorse possiamo avere altre macchine virtuali, residenti sullo stesso host o su host diversi, ognuna delle quali esegue alcune applicazioni che possono accedere alle risorse condivise. Queste macchine virtuali sono definite da un amministratore ed operano per conto di altri utenti. La condivisione è basata sull introduzione in ogni macchina di un modulo client che interagisca per conto dell applicazione con il server che gestisce le risorse condivise. Le applicazioni sfruttano l'interfaccia del modulo client per accedere alle risorse astraendo così dagli specifici meccanismi mediante i quali la condivisione viene implementata.

Se si vuole limitare solo ad alcuni utenti l'accesso a tutte le risorse, allora un parametro importante, oltre alla semplicità e alla trasparenza offerta dal servizio per la condivisione, è la possibilità di definire una politica efficiente per la protezione delle risorse condivise.

La valutazione degli aspetti legati alla sicurezza, senza i quali non si può parlare di un sistema protetto, è spesso critica nella valutazione complessiva del sistema. In particolare, l'entità che mette a disposizione le proprie risorse deve preoccuparsi del controllo e della gestione delle stesse, definendo una opportuna politica che garantisca la confidenzialità, l'integrità e la disponibilità, come descritto nel capitolo precedente.

Questa garanzia richiede l introduzione di meccanismi di sicurezza che permettano di descrivere ed applicare un vasto insieme di politiche delle varie classi Mandatory Access Control o Discrectionary Access Control e di forzarne il rispetto da parte degli utenti del servizio di condivisione. I meccanismi di sicurezza offerti dai sistemi operativi più diffusi permettono però di supportare solo istanze di politiche della classe DAC, che concede privilegi illimitati al ruolo di superuser ed associa alle applicazioni gli stessi privilegi degli utenti per conto dei quali operano. In questo contesto, un utente che invoca il client del servizio di condivisione come superuser, assume lo stesso ruolo sulla macchina virtuale che esporta i file. Ciò può essere impedito solo mediante l adozione di particolari meccanismi sul modulo server.

(3)

In pratica, le politica appartenenti alla classe MAC, limitando i privilegi associati ad un processo, riducendo il rischio e gli impatti dei potenziali attacchi permessi dallo sfruttamento di una o più vulnerabilità presenti nelle applicazioni o nei servizi.

Nel seguito considereremo la condivisione delle risorse nel caso specifico della condivisione di file. Ovviamente, molte delle considerazioni fatte e delle strategie sviluppate sono facilmente generalizzabili. Supporremo inoltre che interessi la trasparenza della condivisione, cioè che gli utenti non siano consapevoli del fatto che stanno accedendo a risorse condivise. Il vincolo sulla trasparenza della condivisione implica, ad esempio, che non possano essere richieste agli utenti ulteriori informazioni oltre a quelle fornite nell'accesso a risorse non condivise.

4.2 Il modello astratto

Questo paragrafo descrive l'architettura generale della strategia adottata per garantire il rispetto della politica di protezione delle risorse offerte dalla macchina virtuale dedicata alla condivisione.

La definizione della strategia è partita dalla definizione di un modello astratto che formalizza i requisiti di interesse:

separazione tra meccanismi di condivisione e meccanismi di sicurezza concessione di diritti sulla base di informazioni trusted

minimo privilegio ai soggetti del servizio di condivisione

meccanismi di sicurezza basati su politiche della classe MAC o DAC.

Si assume che esista un cluster di macchine fisiche appartenenti una infrastruttura informatica, ad esempio una rete privata o intranet. Questa intranet è affidabile perché non permette l implementazione di attacchi diretti alla rete fisica, come sniffing o man-in-the- middle. Le applicazioni possono invece implementare attacchi alle risorse di un nodo, ad esempio attaccare le connessioni virtuali su uno stesso nodo. Per questo motivo è necessario implementare un insieme di controlli per prevenire attacchi di sniffing o spoofing tra macchine virtuali residenti sullo stesso host.

Ciascuna macchina fisica esegue un Virtual Machine Monitor, che garantisce il confinamento tra le risorse virtuali, e sul quale, come mostrato in figura 17, sono mappate un insieme di macchine virtuali guest , VM_GUEST e di macchine virtuali dedicate alla

(4)

condivisione del file system, VM_FS. Ogni VM_GUEST esegue un insieme di applicazioni per conto di utenti con lo stesso livello di fiducia. Le applicazioni e gli utenti accedono alle risorse condivise tramite un modulo client. Le VM_FS, in base alla politica di sicurezza adottata, servono le richieste di accesso al file system tramite un modulo server.

Figura 17: mapping tra utenti, applicazioni, macchine virtuali e macchine fisiche

In particolare, come descritto in dettaglio nel paragrafo 3.2, la macchina virtuale dedicata alla condivisione esporta alcuni file del file system da essa implementato agli utenti delle macchine virtuali guest .

In base al modello astratto adottato, non conviene modificare le macchine virtuali guest per introdurvi dei meccanismi di sicurezza. Infatti, poiché si assume che le applicazioni eseguite dalle macchine non siano fidate, qualsiasi meccanismo introdotto può essere invalidato da attacchi degli utenti della macchina virtuale stessa. In un ottica di ridondanza dei controlli di protezione, può essere opportuno prevedere che anche queste macchine siano eseguiti controlli di consistenza e/o strumenti per la rilevazione di intrusioni da parte degli utenti.

In generale, il modulo client del servizio di condivisione è comunque molto semplice.

Infatti, una volta ricevuta una richiesta prodotta da un client, esso deve solamente inviarla alla macchina che gestiste la condivisione insieme all indirizzo IP della macchina virtuale ed ad un identificatore locale dell'utente che richiede di operare sul file system condiviso.

(5)

Figura 18: il modello astratto

Come mostrato in figura 18, la macchina virtuale dedicata al file system condiviso, implementa la condivisione protetta mediante i seguenti componenti fondamentali:

il modulo server del servizio di condivisione. Esso è composto da un demone che riceve le richieste di accesso ai file da parte delle MV_GUEST e le invia al modulo che si occupa di invocare le relative operazioni di accesso al file system, SELinux, il modulo per il controllo degli accessi integrato nel sistema operativo Linux. E stato scelto questo strumento perché, come descritto nel paragrafo 2.1, esso utilizza alcune funzioni inserite nel modulo server per intercettare le chiamate al file system e forzare il rispetto della politica di sicurezza adottata.

il file system del sistema operativo della MV_FS che, nel caso i controlli di sicurezza abbiano dato esito positivo, effettua le operazioni sul file specificato nella richiesta e ne restituiscono il risultato.

La politica di sicurezza applicata al file system condiviso viene quindi implementata a partire dai meccanismi offerti da SElinux che protegge la MV_FS dai soggetti untrusted, in modo che un soggetto possa accedere solo a quelle risorse per le quali è autorizzato.

Ricordiamo che D(S), il dominio di protezione di un soggetto S, è definito, quindi, come l'insieme di oggetti su cui S può operare, con i relativi diritti per ogni oggetto. Il dominio può essere visto come un insieme di coppie < nome oggetto, insieme di diritti >.

Come mostrato nella tabella 1, SELinux permette di definire soggetti a livelli di astrazione diversi, in base al grado di granularità con cui si vuole descrivere la politica di sicurezza e di associare ad essi un adeguato dominio di protezione.

(6)

Tabella 1: livelli della politica di sicurezza

Il primo caso permette di associare un contesto di sicurezza al modulo server , a cui sono concessi privilegi su determinati file, ad esempio i file di configurazione del servizio ed i file da esso esportati. Se il soggetto della politica di sicurezza fosse il modulo server, però, sarebbe necessario concedere gli stessi diritti a tutti gli utenti del servizio di condivisione del file system. In questo caso la politica di sicurezza ha una granularità troppo elevata nella definizione dei diritti del soggetto, poiché forza ad attribuire a chiunque ha diritto di accedere al servizio lo stesso dominio di protezione del server. Il dominio di protezione del server è definito, ad esempio, come

Nel secondo caso, SELinux permette di assegnare un etichetta di sicurezza all'indirizzo IP che ha generato la richiesta di accesso al file system e di concedere privilegi proporzionati al grado di fiducia della relativa macchina virtuale guest . Se la politica di sicurezza è parametrica rispetto ai diritti della macchina virtuale, allora tutti gli utenti di quella macchina virtuale avranno lo stesso dominio di protezione e quindi potranno accedere agli stessi file e con le stesse modalità.

Il dominio di protezione di una MV_GUEST con indirizzo associato al server è definito, ad esempio, come

L'ultimo caso, invece, descrive uno scenario in cui la politica di sicurezza definita ha un elevato grado di granularità. Infatti essa associa una diversa etichetta a ciascun utente del servizio di condivisione, e ciascuno di essi ha potenzialmente un dominio di protezione diverso.

Il dominio di protezione di un utente di una MV_GUEST con indirizzo è definito, ad esempio, come

La possibilità di scegliere la granularità dei soggetti della politica di sicurezza consente di limitare i privilegi di ogni entità che richiede l'accesso alle risorse condivise a quelli Soggetto Dominio di protezione Granularità della politica

Modulo server diritti del demone servizio - file

IP del client diritti della MV_GUEST MV_GUEST - file

ID utente diritti dell'utente di una MV_GUEST utente - file

(7)

dell'entità il cui dominio ha dimensione immediatamente maggiore tra tutti quelli considerati dalla politica. Ad esempio, il dominio di protezione di un utente è limitato dal dominio di protezione dell'indirizzo IP della macchina a cui esso appartiene; allo stesso modo, i diritti associati ad ogni MV_GUEST sono superiormente limitati dai diritti del demone del servizio di condivisione sulla MV_FS.

Formalizzando, la relazione tra questi soggetti ed i loro domini è la seguente :

La figura 19 illustra un esempio di politica di sicurezza in cui il server ha diritti di lettura e scrittura sui file di configurazione del servizio e sulla directory dove risiedono le sottodirectory da esportare agli utenti delle MV_GUEST. Ad ogni indirizzo IP è invece associato un dominio di protezione, sottoinsieme del precedente, che permette ai processi del nodo con quell indirizzo di eseguire alcune operazioni sul file system remoto. Allo stesso modo, i privilegi di ogni utente sono contenuti in quelli della macchina virtuale su cui l utente stesso risiede.

Figura 19: il confinamento dei domini di protezione

Questa tecnica ha come obiettivo quello di garantire il principio del minimo privilegio poiché permette, a seconda della granularità desiderata della politica, di stabilire le

(8)

dimensioni del dominio di protezione del soggetto che invoca le operazioni. E così possibile minimizzare il dominio di protezione dell'entità che accede alle risorse condivise e limitare a priori i diritti di tutti i clienti del servizio ad un unico dominio, quello che contiene tutti i diritti del modulo server.

Riassumendo, i parametri in base ai quali SELinux può assegnare i diritti sono:

il modulo server

indirizzo della MV_GUEST che effettua la richiesta di accesso identificatore dell'utente che invoca il modulo client

I primi due parametri sono trusted, cioè sono dati posseduti o verificabili dalla macchina virtuale MV_FS e che possono essere considerati come affidabili e sicuri.

Il modulo server del servizio di condivisione è fidato essendo parte integrante della macchina virtuale dedicata alla condivisione e la sua integrità può essere controllata tramite introspezione[77] o tramite applicazioni come Tripwire[78]. Esso rappresenta l'interfaccia del servizio di condivisione verso il mondo esterno e quindi un tipico point of failure , estremamente critico per l'integrità e la protezione dell'intero sistema. Il modulo server deve necessariamente essere associato ad un etichetta di sicurezza e quindi possedere un dominio di protezione limitato ad alcuni privilegi sui file che utilizza per implementare soltanto le proprie funzioni.

Il secondo parametro, ovvero l'indirizzo IP del la MV_GUEST che richiede la risorsa condivisa, è affidabile perché abbiamo supposto, come specificato nei requisiti, che le varie MV ed i VMM implementino un insieme di controlli per prevenire attacchi di tipo spoofing da parte applicazioni o delle MV_GUEST. Questo parametro è opzionale nella descrizione della politica di sicurezza e deve essere utilizzato solo nel caso in cui si decida di distinguere il dominio di protezione di ciascuna MV_GUEST.

L identificatore dell'utente ha lo stesso livello di fiducia delle applicazioni supportate dalla macchina MV_GUEST su cui l utente risiede, cioè untrusted . Anche l'ID dell'utente è un parametro opzionale, che viene considerato quando si vuole differenziare il dominio di protezione di ciascun utente residente su una MV_GUEST.

In base alla granularità scelta, la descrizione della politica di sicurezza di SELinux deve associare un contesto di sicurezza ad ogni soggetto ed assegnare ad esso i relativi diritti.

(9)

Come mostrato in figura 20, il modulo server di MV_FS riceve la richiesta di accesso da parte della MV_GUEST e trasmette ad SELinux i parametri < IP, ID >, specificati nel messaggio. SELinux,quindi, controlla i diritti del soggetto in accordo con la politica specificata.

A tempo di esecuzione, SELinux sfrutta una funzione ( , , ) che restituisce per ogni richiesta ricevuta un Security Identifier, SID, in base al quale il Security Server decide se concedere l'accesso alla risorsa condivisa. Questa funzione è definita componendo altre funzioni:

(tra parentesi quadre i parametri opzionali)

dove restituisce, a partire da uno o più parametri trusted , un SID che identifica in modo univoco un dominio di protezione. Nel caso sia necessario un elevato grado di granularità dei soggetti della politica la funzione g calcola il nuovo SID a partire da quello restituito dalla funzione .

Per ogni richiesta ricevuta, il Security Server associa al demone il SID calcolato dalla funzione f e controlla che il dominio di protezione corrispondente possieda diritti adeguati per accedere al file desiderato. Nel caso in cui i controlli di SELinux abbiano esito positivo il demone può accedere al file richiesto nel file system condiviso e servire la richiesta remota.

Nel prossimo paragrafo descrive in dettaglio l'implementazione del prototipo dell architettura proposta.

4.3 Il prototipo

Questo paragrafo presenta un primo prototipo, mostrato in figura 20, che è stato implementato per verificare la fattibilità dell architettura astratta proposta. Oltre a verificare la fattibilità dell architettura astratta proposta, la disponibilità di un prototipo permette anche delle prime valutazioni dell efficienza e dell efficacia del modello proposto.

(10)

Figura 20: il prototipo

I passi necessari per la creazione del prototipo possono cosi essere riassunti:

a) setup del software di virtualizzazione, Xen, su un host e creazione di un dominio di controllo, il Dom0, di un dominio dedicato alla condivisione, il DomFS e di un insieme di domini utente , i DomGuest. Si sono utilizzate le distribuzioni Fedora[89] e Debian[88] di Linux come sistemi operativi in esecuzione sulle macchine virtuali.

b) creazione di due bridge virtuali.

c) installazione sul DomFS del modulo server NFSv3 e sui domini utente del modulo client NFSv3

d) installazione sul DomFS del modulo SELinux

e) implementazione di uno script anti-IPspoofing per IPtables[82], che associa a ciascun interfaccia del bridge virtuale un indirizzo IP. Nel caso in cui il bridge riceva una richiesta su una interfaccia con un indirizzo diverso da quello assegnato allora IPtables la scarta.

f) sviluppo e applicazione di una modifica del kernel di Linux sul DomFS. Questa modifica permette di integrare NFS ed SELinux in modo tale da poter assegnare diritti ai DomGuest, che eseguono i client NFS, come se fossero dei normali soggetti di SELinux.

(11)

g) implementazione sul DomFS di una politica di sicurezza per la condivisione protetta dei file, utilizzando i costrutti offerti da SELinux e le estensioni appena citate, e applicazione della stessa.

Questo paragrafo si focalizza sulla descrizione delle ultime due fasi in quanto tutte le altre coinvolgono applicazioni e servizi standard. Nei prossimi sottoparagrafi mostrerò in dettaglio l'implementazione della patch del kernel di Linux che integra NFS con SELinux e la descrizione di una politica di esempio per SELinux che sfrutti la nuova architettura di sicurezza.

4.3.1 - L'integrazione tra NFS ed SELinux

Come descritto in dettaglio nel paragrafo 2.1, NFS sfrutta una architettura client-server per implementare un file system distribuito e consente all'amministratore del server di esportare ai client una o più directory del file system condiviso.

In particolare, supponiamo che ogni macchina virtuale esegua uno ed un solo client NFS, a cui è associato un indirizzo IP, e che esistano dei controlli per impedire lo spoofing delle comunicazioni.

L'indirizzo IP permette quindi di identificare in maniera affidabile la macchina virtuale che ha generato la richiesta di accesso ad un file remoto e, come tale, coincide con il soggetto di una politica di sicurezza per la protezione di file memorizzati su un file system condiviso.

L'idea di integrare NFS con SELinux nasce dall'esigenza di controllare, nel server, l'accesso dei client ai file condivisi. Nel contesto che è stato delineato nei capitoli precedenti, i client NFS rappresentano sorgenti di informazioni untrusted e quindi i server non può utilizzare le informazioni che essi trasmettono per implementare i controlli di una qualsiasi politica di sicurezza. La versione attuale del server NFS sfrutta le informazioni, contenute nelle richieste RPC, generate dai client per autorizzare o negare l'accesso al file condiviso, secondo le regole definite per le politiche della classe DAC.

La modifica implementata in questa tesi ha come obiettivo quello di poter definire politiche di sicurezza della classe MAC anche ai soggetti che sfruttano il servizio NFS per la condivisione dei file. Questa soluzione permette di limitare i privilegi dei soggetti e quindi da mitigare il rischio associato ad un possibile attacco con successo da parte dei

(12)

client.

4.3.2 Un nuovo soggetto della politica di SELinux

La sintassi di SELinux permette di associare a ciascun oggetto del kernel di Linux un contesto di sicurezza. A partire dal contesto, ogni istanza di una politica di sicurezza permette di definire i privilegi del soggetto della politica sugli oggetti presenti nel sistema.

I soggetti della politica di SELinux coincidono con i processi, identificati da un dominio , eseguibili dal sistema operativo e la descrizione della politica specifica sia quali programmi possono essere eseguiti da un determinato processo sia le possibili transizioni di dominio.

Nella prima fase dello sviluppo del prototipo è stato necessario modificare le regole di etichettatura e di accesso, introducendo nella politica di SELinux un nuovo soggetto, che corrisponde al client NFS, e di definire l'insieme delle operazioni che esso può effettuare.

A questo scopo, è stato sfruttato un elemento già definito nella sintassi di SELinux, il tipo Nodo, solitamente utilizzato per controllare il traffico di rete, cioè per concedere o negare ad un processo il permesso di scambiare dati con uno specifico indirizzo IP attraverso le interfacce di rete[79].

Ad esempio,

nodecon 10.33.10.66 255.255.255.255 system_u:object_r:node_mv1_t allow process_t node_mv1_t:node { tcp_recv tcp_send };

associa all'indirizzo IP 10.33.10.66 il tipo node_mv1_t e permette al processo etichettato con il dominio process_t di scambiare pacchetti attraverso il protocollo TCP con il nodo con contesto di sicurezza node_mv1_t.

Questo tipo SElinux è stato esteso inserendo nella classe corrispondente, descritta nel file /etc/selinux/refpolicy/src/policy/policy.conf, le operazioni necessarie al server NFS per implementare le operazioni invocate dai client NFS, come se queste fossero un soggetto della politica di sicurezza; ad esempio lettura, scrittura e creazione di file o directory.

(13)

class node {

tcp_recv tcp_send udp_recv udp_send rawip_recv rawip_send enforce_dest dccp_recv dccp_send read write create getattr setattr lock

relabelfrom relabelto append unlink link rename execute swapon quotaon }

Questa tecnica permette all amministratore del DomFS di realizzare un elevato livello di granularità della politica e di gestire in maniera centralizzata gli accessi al file system condiviso, assegnando a ciascuna macchina virtuale DomGuest un insieme di diritti su specifici file.

nodecon 10.0.0.101 255.255.255.255 system_u:object_r:node_mv101_nfs_t allow nfsd_t node_mv101_nfs_t:node { tcp_recv tcp_send };

allow node_mv101_nfs_t dir_mv101_roperm: dir r_dir_perms;

Nel precedente esempio di frammento di una possibile configurazione della politica di SELinux, si nota come sia possibile assegnare al client NFS con indirizzo 10.0.0.101 privilegi di lettura sugli oggetti di una directory etichettata con il tipo dir_mv101_roperm.

Il prossimo paragrafo descrive come SELinux associa temporaneamente al processo server NFS il contesto di sicurezza del client NFS per cui opera, il cui indirizzo IP è etichettato con il tipo appena definito. I controlli sugli accessi ai file condivisi implementati da SELinux dipendono da questo contesto e dalle operazioni invocate.

(14)

4.3.3 L'implementazione della modifica

Questo paragrafo descrive gli elementi fondamentali che sono stati sviluppati per implementare la politica di protezione dei file condivisi da parte del server NFS . La politica di sicurezza consente di gestire in maniera centralizzata sul DomFS gli accessi ai file ivi memorizzati, sfruttando i controlli offerti da SELinux.

Lo sviluppo del prototipo, che supporta il sistema operativo Linux, ha richiesto una serie di modifiche del kernel di Linux, in particolare ai moduli SELinux, RPC ed NFSv3.

Per illustrare le modifiche sviluppate seguiremo l ordine in cui le nuove funzioni sono invocate durante il flusso di esecuzione di una richiesta al server NFS da parte di un client. Nel seguito il server NFS è inteso come l insieme dei task, o demoni NFS nfsd, ciascuno dei quali serve in maniera concorrente le richieste del client ad esso associato.

Come mostrato in figura 21, in fase di configurazione del kernel di Linux[90], è possibile inserire il supporto per l'integrazione tra SELinux ed NFS. Questo permette di definire un kernel, per la macchina virtuale dedicata al file system, che prevede tutte le modifiche proposte.

Figura 21: configurazione del kernel di Linux

(15)

SELinux utilizza un insieme di strutture dati che contengono tutte le informazioni sulla sicurezza degli oggetti del kernel, quali task, inode e file. In una di queste strutture, indicata nel seguito come SecTaskStruct, SELinux memorizza tutte le informazioni che riguardano la sicurezza dei processi e dell'esecuzione dei programmi sul sistema operativo. Questa struttura, che viene utilizzata per implementare il controllo degli accessi, è stata modificata in modo da poter memorizzare l identificatore di sicurezza associato all'indirizzo IP e alla net-mask del client NFS che ha effettuato la richiesta di accesso ad un file remoto.

Ogni volta che il server NFS elabora una richiesta, il servizio RPC in esso contenuto invoca una nuova funzione f(SSID,IP) di SELinux che calcola il SID associato alla richiesta a partire dal SID del processo NFS server e dall'indirizzo IP del client NFS che ha generato la richiesta. Il comportamento della funzione dipende dal contenuto del Database Security Server di SELinux che memorizza la politica di sicurezza corrente. Se questa possiede in corrispondenza all indirizzo IP che richiede il file remoto un tipo Nodo, allora la funzione f restituisce il rispettivo SID, altrimenti calcola un SID a cui non associa alcun privilegio sul file system condiviso.

Prima di invocare la chiamata di sistema che implementa l'accesso al file condiviso, una funzione memorizza il SID appena ottenuto nella struttura SecTaskStruct, relativa al demone NFS che serve la richiesta invocata da un client.

Come descritto nel paragrafo 2.2.2, SELinux è basato su un modulo LSM, Linux Security Module, che inserisce in opportuni punti del codice del sistema operativo chiamate a particolari funzioni critiche per la sicurezza del sistema, dette hook , sugli oggetti del kernel. Queste funzioni permettono di attivare i controlli di SELinux sulle operazioni relative ad un particolare oggetto del kernel. Ogni volta che il server NFS opera sul file system condiviso, il kernel invoca gli hook per eseguire i controlli di sicurezza delegati ad SELinux. In particolare, sono stati modificati i LSM hook per forzare il controllo degli accessi sulle operazioni invocate dai nuovi soggetti, si controlla se esistono i permessi, quando il task nfsd, per conto di un client NFS:

usa una capability accede ad un inode accede a un file crea o rimuove

(16)

o un file o una directory o un link ad un file o un link ad una directory rinomina un file o una directory opera sul file system (superblock)

Tutti questi hook sono stati modificati in modo che, se al demone NFS è associato un SID relativo all'indirizzo IP del client NFS che richiede l'accesso al file condiviso, il Security Server applica la politica di sicurezza di SELinux considerando il SID come il soggetto. Se, invece, al demone NFS che serve la richiesta è associato un SID senza privilegi nella politica di sicurezza, allora si applicano i normali controlli di SELinux sui diritti del processo nfsd.

In entrambi i casi, il Security Server decide, in base alla politica di sicurezza corrente, se autorizzare o negare l'accesso al file.

Una volta eseguita la chiamata di sistema, il valore del SID associato al demone nfsd che ha servito la richiesta viene resettato ad un valore predefinito, corrispondente ad un dominio a cui non è associato alcun privilegio . In questo modi si limitano i privilegi del client NFS soltanto all intervallo di tempo in cui il kernel elabora la richiesta di accesso al file system.

A rchitettura complessiva del sistema

C apitolo 4

A rchitettura complessiva del sistema

C ^apitolo 4