Capability-Based Computer Systems

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

2. Indice (1/2) • Introduzione • Problema:Controllo degli accessi • Matrice 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 ACL • EROS: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 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. 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. Problema: Controllo degli accessi (3/4) • Parlando di controllo degli accessi faccio riferimento a quattro concetti: • Preventing access: assicurarsi che una persona non possa danneggiarne un’altra o carpirne informazioni private • Limiting access : Accertarsi che un processo o un utente non faccia più di quello che gli è consentito

9. Problema: Controllo degli accessi (4/4) • 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. • 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. Oggetti o1 o2 o3 o4 o5 o6 .... oN op1 op2 op1 s1 op1 op2 op3 op1 op2 Soggetti op1 op2 s2 op1 op2 op3 s3 op2 op2 Matrice di protezione (3/4)

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 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 quell’oggetto. • Tale token è detto capability

20. Capabilities = Car keys (1/3)

21. Capabilities = Car keys (2/3)

22. Capabilities = Car keys (3/3)

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’oggetto • L’unico 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 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: • Rimuovere interamente l’accesso di un utente • Revocare il corrente accesso di un utente senza rimuovere l’utente • 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 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. 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 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. Client Mediator Database EROS: capability (5/8) • 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.