Stefania Ciarlo
Capability-Based Computer Systems
Corso di Sicurezza a.a.2002/03
2
Indice (1/2)
IntroduzioneProblema:Controllo degli accessiMatrice di protezione– ACL– Lista di capability
Cos’è una capability?Capability-Based Computer Systems
3
Indice (2/2)
Capability : Problemi– Memorizzare le capability– Revocare l’accesso
Capability vs ACLEROS:un sistema operativo basato su capability – Persistenza– Capability
4
Privatezza Integrità Disponibilità Correttezza Robustezza
File System
Sistemi non necessariamente connessi in rete
Introduzione (1/2)
Sicurezza nei Sistemi Operativi stand-alone
5
Introduzione (2/2)
In un Sistema Operativo, la parte file system gestisce informazioni che sono di grande valore per gli utenti
La protezione di queste informazioni verso usi non autorizzati è uno dei problemi principali
6
Problema: Controllo degli accessi (1/4)
Problema base : Controllare a quali oggetti può accedere un dato processo e in quali modiTali oggetti possono essere componenti hardware (CPU, segmenti di memoria, lettori di dischi, stampanti..) o software (processi, file, basi di dati, semafori..)
Accesso = quali operazioni posso fare sugli oggetti (leggere, modificare, cancellare un file...)
7
Problema: Controllo degli accessi (2/4)
determina a cosa un processo può accedere e non a cosa una persona può accedereImportante distinzione perché:– La stessa persona può agire con differenti identità
(login)– Lo stesso programma può girare per conto di utenti
diversi con diritti diversi– Le persone non sempre sanno quali programmi
stanno lanciando
8
Problema: Controllo degli accessi (3/4)
Parlando di controllo degli accessi faccio riferimento a quattro concetti:
1. Preventing access: assicurarsi che una persona non possa danneggiarne un’altra o carpirne informazioni private
2. Limiting access : Accertarsi che un processo o un utente non faccia più di quello che gli è consentito
9
Problema: Controllo degli accessi (4/4)
3. Granting access: Voglio ad esempio consentire a due persone di lavorare contemporaneamente sullo stesso documento oppure consentire l’accesso ad un file ad una persona alla quale voglio delegare un compito.
4. Revoking access: Dopo aver consentito ad una persona l’accesso ad un oggetto, voglio negarglielo
10
Matrice di protezione (1/4)
Una macchina virtuale è composta da:
– Oggetti: implementano un insieme di operazioni– Soggetti: invocano le operazioni implementate dagli
oggetti
Una componente può essere oggetto ad un istante e soggetto ad un istante diverso
11
Matrice di protezione (2/4)
Definisce ad ogni istante lo stato di protezione del sistema : quali operazioni possono essere eseguite da un soggetto del sistema
Ogni sistema che ha tra i suoi obiettivi la robustezza deve avere una rappresentazione di questa matrice
12
Matrice di protezione (3/4)
Oggetti
Sogg
etti
op1
o1op1 op2
o4 o5 o6 .... oNo2 o3
op1op1 op2
op3
op1 op2 op2
s1
s2
s3 op2 op2op1 op2
op3
13
Matrice di protezione (4/4)
Le operazioni che possono essere invocate da un soggetto X all’istante t definiscono i diritti di X in quell’istante (dominio di protezione di X)
La matrice di protezione può essere implementata:– Per colonne(per oggetti):ACL– Per righe (per soggetti): Liste di Capability
14
ACL (1/3)
Idea: associare ad ogni oggetto una lista contente tutti i soggetti che possono accedere all’oggetto e come
Questa lista viene detta ACL(Access Control List)
In Unix: Ciascun elemento della lista di protezione sarà del tipo Nomefile:(uid,gid,permessi)
15
ACL (2/3)
Il controllo è spostato nell’oggetto
Quando un oggetto riceve una invocazione controlla se nella sua lista esiste il diritto corrispondente
Aumenta l’autonomia dell’oggetto rispetto al soggetto
16
ACL (3/3)
Esempio: Quattro utenti Jan, Els, Jelle e Mike che appartengono rispettivamente ai gruppi system, staff, student e student
File0: (Jan,*,RWX)File1(Jan,system, RWX)File2: (Jan,*,RW-), (Els, staff, RW-), (Mike,*,RWX)File3: ( *, student, R--)File4: (Jelle,*,---), (*,student, R--)
17
Lista di capability (1/2)
Idea: associare ad ogni soggetto la lista degli oggetti ai quali ha accesso insieme all’elenco delle operazioni consentite per ciascuno di essi
Nella rappresentazione interna di un soggetto esiste la lista delle capability del soggetto
18
Lista di capability (2/2)
Se il soggetto X può invocare l’operazione op sull’oggetto Y allora X ha una capability(Y,op)
Ad ogni invocazione di un operazione si controlla che esista una capability che lo permetta
Il controllo avviene nell’ambiente del soggetto
19
Cos’è una capability?
Termine introdotto per la prima volta da Dennis e Van Horn nel 1966Idea: Vogliamo progettare un sistema software– Per accedere ad un oggetto un processo deve avere
uno speciale “token”– Questo token descrive un oggetto e conferisce al
processo il diritto di eseguire un insieme di azioni su quell’oggetto.
– Tale token è detto capability
20
Capabilities = Car keys (1/3)
capability chiavi di una macchina
Si riferiscono ad un oggetto specifico (es: file)
Si possono usare solo per una particolare macchina
Chi le possiede può effettuare certe azioni ( R,W,X.. ) su certi oggetti (file, stampanti...)
Chiunque le possiede può effettuare certe azioni (aprire la macchina, far partire la macchina)
Non si preoccupano di chi le sta usando
Non sa chi usa la chiave, l’importante è che la possegga
21
Capabilities = Car keys (2/3)
capability chiavi di una macchina
Possono essere delegate Se mi dai le chiavi della tua macchina è perché sai che io non le darò a nessun altro
Possono essere copiate Se mi dai le chiavi della tua macchina nulla mi vieta di andare a farne un duplicato
22
Capabilities = Car keys (3/3)
capability chiavi di una macchina
Due capability possono riferirsi allo stesso oggetto ma autorizzare diversi insiemi di azioni
Vari tipi di chiavi sulla stessa macchina ( per aprire le porte, per l’accensione)
Un processo può possedere una capability su un insieme di altre capability
Posso avere una chiave che apre una scatola piena di altre chiavi
23
Capability-Based Computer Systems (1/3)
Accesso Capability
L’accesso agli oggetti è realizzato attraverso delle capability
Le capability sono l’unico mezzo di accesso agli oggetti del sistema
24
Capability-Based Computer Systems (2/3)
Un processo che vuole eseguire una certa azione su un oggetto deve possedere una capability su quell’oggettoL’unico modo per ottenere le capability è ottenerle a seguito di una comunicazioneSe il processo A possiede la capability di comunicare con B allora in seguito possono scambiarsi capability l’uno con l’altro
25
Capability-Based Computer Systems (3/3)
Possedere un numero elevato di capability è assurdo
Obiettivo: rendere l’insieme delle capability possedute il più specifico e piccolo possibile (principio del minimo privilegio)
Un processo non può abusare di una autorità che non ha
26
Capability: problemi
Primo problema: conservare le informazioni relative alle capability consentendone un futuro accesso
Secondo problema: revocare l’accesso in modo selettivo
27
Memorizzare le capability (1/2)
Ci chiediamo:– Dove vanno a finire quando il sistema è
shut-down e come vengono recuperate?– Da dove i processi presenti all’avvio del
sistema prendono le loro capability?– Quale autorità le conserva?
28
Memorizzare le capability (2/2)
Problema che affligge i capability systems designers fin dai primi anni ‘70
Principale causa del fatto che pochi capability systems siano stati finora realizzati
29
Soluzione tradizionale (1/2)
Ho una sorta di file system che garantisce di default ad ogni processo il privilegio di accedere al file system
Inoltre, utilizzo una specie di user-identity based system per decidere quale programma può accedere a quali file (Se un programma sta girando per conto dell’utente A potrà accedere soltanto ai file che A ha creato)
30
Soluzione tradizionale (2/2)
Questo tipo di sistema– mi permette di effettuare: Prevent e Revoke
access– non mi consente di effettuare: Limit e Grant
access
Inoltre non mi permette di delegare l’autorità su un oggetto
31
Soluzione migliore: Universal Persistence (1/3)
Non avere un file system comune
Non dare ad ogni processo l’accesso al file system di default (I file system sono molto utili ma molti programmi o sottosistemi non hanno bisogno di accedervi)
Idea : ricordare tutto
32
Soluzione migliore: Universal Persistence (2/3)
Ogni 5 minuti tener traccia degli oggetti su cui il sistema sta lavorando
Se stavo lavorando su un file e avviene il reset del sistema, al riavvio si tornerà all’ultima copia salvata
Poiché viene salvata una copia di tutti i processi non c’è bisogno di capire chi è incaricato di cosa quando il sistema riparte
33
Soluzione migliore: Universal Persistence (3/3)
Si può pensare che sia inefficiente
In realtà:– Ha più velocità di esecuzione di un File System– Richiede meno codice
É usato da EROS (attualmente il più veloce capability system esistente)
34
Revocare l’accesso (1/4)
Non c’è modo di dire: “revoca tutti i permessi che Fred ha su questo oggetto” (revoca selettiva)
Nella realtà questo problema si presenta spesso: ad esempio se un impiegato si trasferisce in un’altra ditta voglio fare in modo che non abbia più accesso ai vecchi file.
35
Revocare l’accesso (2/4)
Tre aspetti:1. Rimuovere interamente l’accesso di un
utente2. Revocare il corrente accesso di un utente
senza rimuovere l’utente3. Revocare l’accesso dell’utente ad un
particolare oggetto
36
Revocare l’accesso (3/4)
Soluzione 1: Si risolve eliminando la login dell’utente
Soluzione 2,3: Creare una nuova login per lo stesso utente e copiare nel nuovo account tutti i documenti personali a cui l’utente vuole accedere
37
Revocare l’accesso (4/4)
Oppure: costruire un “contenitore” che non consenta di copiare i documenti fuori da esso e ne consenta invece l’accesso agli utenti solo dentro al contenitore (n.b. diverso da uno user group)
38
Capability vs ACL (1/4)
Diritti di accesso e persistenza (Cosa succede quando avviene il shut down del sistema e tutti i processi scompaiono?)
– ACL:nessun problema, anche le sessioni di login scompaiono
– Capability:il problema c’è. Soluzioni: associare una lista di capability iniziale ad ogni login oppure rendere persistenti tutti i processi
39
Capability vs ACL (2/4)
Minimo privilegio
– Capability: forniscono una granularità più fine di protezione. Ogni processo ha uno specifico insieme di diritti di accesso
– ACL:ogni processo eseguito da Fred ha gli stessi diritti.
40
Capability vs ACL (3/4)
Revoca dei privilegi
– ACL: posso rimuovere un utente dalla lista ed egli non potrà più accedere ai suoi oggetti
– Capability: non c’è un’ operazione equivalente. Questo è un problema : gli utenti vanno e vengono e dobbiamo essere in grado di rimuoverli affinché non possano più accedere ai vecchi dati.
41
Capability vs ACL (4/4)
Delega dei diritti
– ACL: non possibile trasferire i diritti. Se Fred ottiene il diritto su un oggetto non può trasferirlo a Mary.
– Capability: posso trasferire le capability. Questo è molto utile ( delego ad una persona un compito ) ma anche pericoloso ( se il programma che sto eseguendo è “malizioso” può rubarmi i diritti di accesso )
42
EROS
E’ un nuovo Sistema Operativo basato su capability implementato inizialmente presso l’Università della Pennsylvania, in seguito portato avanti presso la Johns Hopkins University
Team di sviluppatori: Jonathan S. Shapiro, Jonathan Adams, Colin McLean, Mike Laskin, Mike Berry, Daniel Brushteyn
43
EROS: persistenza (1/3)
In molti sistemi operativi le applicazioni muoiono quando il sistema ha un crash. Tutte le informazioni non salvate vengono perse
In EROS questo non succede: una volta che un’applicazione viene lanciata continua ad operare anche dopo il crash del sistema.
44
EROS: persistenza (2/3)
Tutto questo è realizzato mediante una tecnica chiamata checkpointing: ogni 5 minuti viene fatta una fotografia di uno stato consistente del sistema e tutte le informazioni relative vengono salvate.
Il ripristino del sistema avviene agevolmente e rapidamente
45
EROS: persistenza (3/3)
Altri vantaggi del checkpointing:
– Richiede 100ms ogni 5 minuti. – Molte applicazioni non devono più salvare le proprie
informazioni su file– Migliora le prestazioni del disk drive. Il meccanismo
di checkpoint sposta i dati raggruppati in blocchi. I dischi in eros sono più veloci rispetto a Windows e Unix
46
EROS: capability (1/8)
Costituisce il meccanismo del sistema per garantire la sicurezza e il controllo degli accessiCome già detto, una capability consente a chi la possiede di effettuare specifiche operazioni su un determinato oggettoIl possesso della capability è la condizione necessaria e sufficiente per effettuare det. operazioni su un det.oggetto
47
EROS: capability (2/8)
In EROS i processi posseggono le capability per conto dei loro utilizzatoriIn contrasto: Unix e Microsoft Windows in cui:– Ogni programma ha accesso al file system e può
creare, rimuovere, aprire, modificare i file presenti– La protezione è basata sull’identità dell’utente che
sta utilizzando l’applicazione piuttosto che su cosa l’applicazione è autorizzata a fare
48
EROS: capability (3/8)
EROS consente di delegare i diritti , Unix e Microsoft Windows no
EROS risolve ad esempio alcuni problemi che si possono presentare per quanto riguarda il controllo degli accessi e l’integrità
49
EROS: capability (4/8)
Problema 1: A ha un database di un certo valore e non vuole che venga copiato. Vende a B il diritto di eseguire un numero fissato di query e vuole assicurarsi che A non ne lanci più di quelle che ha pagato.Soluzione: nei sistemi tradizionali è difficile da risolvere. In un capability system no.
50
EROS: capability (5/8)
Client Mediator Database
•Interpongo un mediatore tra il Client e il Database. Il Mediatore manterrà un contatore e quando sarà a zero mi impedirà di lanciare ulteriori query.
•In questo modo solo il Mediatore ha accesso al Database, mentre l’utente no. La sicurezza non viene compromessa.
51
EROS: capability (6/8)
Problema 2: B ha un database costoso e A ha implementato un importante algoritmo che B ha bisogno di lanciare– A non vuole che B acceda al codice dell’algoritmo– B non vuole che A acceda al databaseCome possono collaborare?
Soluzione: impossibile in un sistema tradizionale. Piuttosto facile in un capability system.
52
EROS: capability (7/8)
Constructor
Client Application
12
4
3
•Fase1: Il Client chiede al Constructor: ”E’ sicuro se lancio questo programma?”
53
EROS: capability (8/8)
Fase2: Il Constructor risponde si o no basandosi sulle capability che il programma possiede. Il Client decide se lanciare o no il programma. Se si richiede una copia del programma.Fase3: Il Constructor ne prepara una copia e restituisce una capability al ClientFase4: Il Client e l’applicazione possono comunicare liberamente
54
Bibliografia
Anrew S. Tanenbaum, Albert S.Woodhull Sistemi Operativi, Progetto e ImplementazioneCos’è una capability, Capability-Based Computer Systemshttp://www.eros-os.org/essays/00Essays.html
EROShttp://www.eros-os.org/
Altri riferimenti e informazioni sulle capability http://www.capsecure.org/
Stefania Ciarlo
Fine