Stefania Ciarlo Capability-Based Computer Systems Corso di Sicurezza a.a.2002/03.

Presentazione sul tema: "Stefania Ciarlo Capability-Based Computer Systems Corso di Sicurezza a.a.2002/03."— Transcript della presentazione:

1 Stefania Ciarlo Capability-Based Computer Systems Corso di Sicurezza a.a.2002/03

2 2 Indice (1/2) Introduzione Problema:Controllo degli accessi Matrice di protezione –ACLACL –Lista di capabilityLista di capability Cosè una capability? Capability-Based Computer Systems

3 3 Indice (2/2) Capability : Problemi –Memorizzare le capabilityMemorizzare le capability –Revocare laccessoRevocare laccesso Capability vs ACL EROS:un sistema operativo basato su capability –PersistenzaPersistenza –CapabilityCapability

4 4 Privatezza Integrità Disponibilità Correttezza Robustezza File System Sistemi non necessariamente connessi in rete Introduzione (1/2) Sicurezza nei Sistemi Operativi stand-alone

5 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 6 Problema: Controllo degli accessi (1/4) Problema base : Controllare a quali oggetti può accedere un dato processo e in quali modi Tali 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 7 Problema: Controllo degli accessi (2/4) determina a cosa un processo può accedere e non a cosa una persona può accedere Importante 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 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 unaltra o carpirne informazioni private 2.Limiting access : Accertarsi che un processo o un utente non faccia più di quello che gli è consentito

9 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 laccesso ad un file ad una persona alla quale voglio delegare un compito. 4.Revoking access: Dopo aver consentito ad una persona laccesso ad un oggetto, voglio negarglielo

10 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 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 12 Matrice di protezione (3/4) Oggetti Soggetti op1 o1 op1 op2 o4o5o6....oNo2o3 op1 op1 op2 op3 op1 op2 op2 s1 s2 s3op2 op1 op2 op3

13 13 Matrice di protezione (4/4) Le operazioni che possono essere invocate da un soggetto X allistante t definiscono i diritti di X in quellistante ( 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 14 ACL (1/3) Idea: associare ad ogni oggetto una lista contente tutti i soggetti che possono accedere alloggetto 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 15 ACL (2/3) Il controllo è spostato nelloggetto Quando un oggetto riceve una invocazione controlla se nella sua lista esiste il diritto corrispondente Aumenta lautonomia delloggetto rispetto al soggetto

16 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 17 Lista di capability (1/2) Idea: associare ad ogni soggetto la lista degli oggetti ai quali ha accesso insieme allelenco delle operazioni consentite per ciascuno di essi Nella rappresentazione interna di un soggetto esiste la lista delle capability del soggetto

18 18 Lista di capability (2/2) Se il soggetto X può invocare loperazione op sulloggetto 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 nellambiente del soggetto

19 19 Cosè una capability? Termine introdotto per la prima volta da Dennis e Van Horn nel 1966 Idea: 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 quelloggetto. –Tale token è detto capability

20 20 Capabilities = Car keys (1/3) capabilitychiavi 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, limportante è che la possegga

21 21 Capabilities = Car keys (2/3) capabilitychiavi 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 22 Capabilities = Car keys (3/3) capabilitychiavi 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 laccensione) 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 23 Capability-Based Computer Systems (1/3) AccessoCapability Laccesso agli oggetti è realizzato attraverso delle capability Le capability sono l unico mezzo di accesso agli oggetti del sistema

24 24 Capability-Based Computer Systems (2/3) Un processo che vuole eseguire una certa azione su un oggetto deve possedere una capability su quelloggetto Lunico modo per ottenere le capability è ottenerle a seguito di una comunicazione Se il processo A possiede la capability di comunicare con B allora in seguito possono scambiarsi capability luno con laltro

25 25 Capability-Based Computer Systems (3/3) Possedere un numero elevato di capability è assurdo Obiettivo: rendere linsieme 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 26 Capability: problemi Primo problema: conservare le informazioni relative alle capability consentendone un futuro accesso Secondo problema: revocare laccesso in modo selettivo

27 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 allavvio del sistema prendono le loro capability? –Quale autorità le conserva?

28 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 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 dellutente A potrà accedere soltanto ai file che A ha creato)

30 30 Soluzione tradizionale (2/2) Questo tipo di sistema – mi permette di effettuare: Prevent e Revoke accessPrevent e Revoke – non mi consente di effettuare: Limit e Grant accessLimit e Grant Inoltre non mi permette di delegare lautorità su un oggetto

31 31 Soluzione migliore: Universal Persistence (1/3) Non avere un file system comune Non dare ad ogni processo laccesso 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 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à allultima 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 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 34 Revocare laccesso (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 unaltra ditta voglio fare in modo che non abbia più accesso ai vecchi file.

35 35 Revocare laccesso (2/4) Tre aspetti: 1.Rimuovere interamente laccesso di un utente 2.Revocare il corrente accesso di un utente senza rimuovere lutente 3.Revocare laccesso dellutente ad un particolare oggetto

36 36 Revocare laccesso (3/4) Soluzione 1: Si risolve eliminando la login dellutente Soluzione 2,3: Creare una nuova login per lo stesso utente e copiare nel nuovo account tutti i documenti personali a cui lutente vuole accedere

37 37 Revocare laccesso (4/4) Oppure: costruire un contenitore che non consenta di copiare i documenti fuori da esso e ne consenta invece laccesso agli utenti solo dentro al contenitore (n.b. diverso da uno user group)

38 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 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 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 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 42 EROS E un nuovo Sistema Operativo basato su capability implementato inizialmente presso lUniversità 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 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 unapplicazione viene lanciata continua ad operare anche dopo il crash del sistema.

44 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 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 46 EROS: capability (1/8) Costituisce il meccanismo del sistema per garantire la sicurezza e il controllo degli accessi Come già detto, una capability consente a chi la possiede di effettuare specifiche operazioni su un determinato oggetto Il possesso della capability è la condizione necessaria e sufficiente per effettuare det. operazioni su un det.oggetto

47 47 EROS: capability (2/8) In EROS i processi posseggono le capability per conto dei loro utilizzatori In 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 sullidentità dellutente che sta utilizzando lapplicazione piuttosto che su cosa lapplicazione è autorizzata a fare

48 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 lintegrità

49 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 50 EROS: capability (5/8) ClientMediatorDatabase 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 lutente no. La sicurezza non viene compromessa.

51 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 dellalgoritmo –B non vuole che A acceda al database Come possono collaborare? Soluzione: impossibile in un sistema tradizionale. Piuttosto facile in un capability system.

52 52 EROS: capability (7/8) Constructor ClientApplication 1 2 4 3 Fase1: Il Client chiede al Constructor: E sicuro se lancio questo programma?

53 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 Client Fase4: Il Client e lapplicazione possono comunicare liberamente

54 54 Bibliografia Anrew S. Tanenbaum, Albert S.Woodhull Sistemi Operativi, Progetto e Implementazione Cosè una capability, Capability-Based Computer Systems http://www.eros-os.org/essays/00Essays.html EROS http://www.eros-os.org/ Altri riferimenti e informazioni sulle capability http://www.capsecure.org/ http://www.capsecure.org/

55 Stefania Ciarlo Fine