Sicurezza e privatezza

Controllo degli accessi e matrici

Sono i soggetti di un insieme, invece le colonne sono oggetti, ogni elemento sarà indirizzata da un oggetto e un soggetto, quindi m(p,q) indica le operazioni che il soggetto p può fare sull'oggetto q.

Il problema è che non scalano, in sistemi grandi possono assumere grosse dimensioni, ad esempio una banca con 50 mila dipendenti e 300 file, solo con questi dati la matrice avrebbe 15 milioni di elementi.

C'è un problema di caricamento e si possono anche commettere molti errori non garantendo la protezione, quindi è difficile utilizzabile. Per fare questo bisogna rifarsi a delle modalità che consentano di memorizzare la matrice in memoria. Sono state usate diverse strategie:

• raggruppare gli utenti in user groups
• un'altra soluzione è avere porzioni più piccole, si prendono le righe e le colonne

si salvano inopportune zone di memoria

8.1.1 Groups

È basato sul principio di ridurre il numero di righe, si raggruppano i soggetti per categorie tra loro equivalenti per gli accessi alle risorse del sistema. In un banca abbiamo il cassiera, direttore, ecc. I dipendenti vengono divisi, e possono accedere alle stesse risorse e nelle stesse modalità. Riducendo notevolmente la dimensione della matrice. Molti autori usano il termine role invece di gruppo, in generale il role non è una categoria ma si intende un insieme di attività di permessi di accesso attraverso procedure ben definite, sono mansioni svolte da più soggetti, quindi non bisogna confondere.

8.1.2 Access Control List

È sostanzialmente una colonna della matrice di controllo degli accessi, ogni colonna specifica quali sono le azioni che i soggetti possono svolgere su un ben definito oggetto. L'idea è di memorizzare questa informazione insieme alle informazioni che caratterizzano la risorsa, ogni oggetto/risorsa nel SO

avrà una struttura dati, e ci mettiamo anche l’informazioni relative al controllo degli accessi perl’oggetto. Si risparmia rispetto alla matrice, si suddivide in pezzi associati a ogni risorsa.

Figure 8.2: che utenti accedono e cosa possono fare, /usr/bin può essere r,w,x da root, mentre mikesolo r, w. Per controllare si accede alla access control list per vedere l’utente che diritti ha

Implementazione ACL Devono essere memorizzate in un posto sicuro, devono essere protette damodifiche maligne e accidentali, da esse si decide chi può accedere, quindi gli attacchi possono puntarelı̀. ACL deve essere protetta, sono salvate con le strutture dati dell’oggetto, in UNIX sono salvatenell’inode, che contiene metadati associati ad un file o directory.

8.1.3 CapabilityÈ un altro modo per ridurre la dimensione della matrice, è un token è una chiave di accesso, nei SOè una struttura dati, data ai soggetti, e c’è scritto cosa il soggetto può

fare nel sistema, quali risorsepuò accedere e come. Quindi la capability è una riga della matrice associate ai soggetti. Per esempioil biglietto di ingresso al cinema, oppure la chiave per entrare in casa.

Figure 8.3:Le capability possono essere gestite non solo dal sistema ma anche degli utenti. Nei SO vengono mem-orizzate nel kernel e la garanzia che non vengano modificate è data dal sistema. L’utente non vedele capability. Ma in alcune situazioni la capability è data insieme all’utente che la trasporta, comeil Bancomat, è un token, e digitando ci permette di accedere al sistema. Nel momento in cui vienefornita all’utente, bisogna garantire che non sia modificata, quindi anti-tampering cioè resistente atentativi di modifica.

ACL vs Capability Alice ha diversi valori im 3 cassetti in banca, spesso delega altre persone, labanca deve garantire la sicurezza delle cassette. Strategia 1(ACL) per ogni cassetta avere una listadelle persone che possono accedere.

Strategia 2 (Capability): dare ad Alice delle chiavi, così che possa accedere quando vuole. ACL è necessaria per l'autenticazione, quando qualcuno accede deve autenticare la persona, la banca deve gestire ACL, la banca deve garantire l'integrità. Se vogliamo modificare la lista, Alice dovrà comunicare alle persone e chiedere l'autorizzazione. L'estensione non è facile, deve andare lei. Quando una delegata non è più affidabile, è Alice che dovrà rimuoverla. Abbiamo un grosso coinvolgimento della banca che fa le operazioni più critiche. L'utente ha difficoltà sulle modifiche. Capability nel momento in cui la banca consegna il token di accesso, scarica la responsabilità sul possessore della chiave. Alice deve garantire l'integrità, la banca deve occuparsi solo che la chiave non venga compromessa. La modifica del gruppo delle persone che possono accedere è responsabilità di Alice, il rischio è che un utente possa estendere dando la chiave.

Ad altri, la delega non è facilmente controllabile. Pro e contro ACL sono più facili da implementare, per contro sono laboriose come meccanismo di controllo degli accessi, abbiamo bisogno che il soggetto sia stato precedentemente autenticato e dobbiamo verificare la sua presenza nella lista, mentre la capability consente l'accesso in modo più facile. ACL sono orientate agli oggetti, sono quindi più difficili alcune operazioni, tipo sapere che accessi può avere un utente dovremmo controllare tutta la lista e trovarlo, stessa cosa per fare modifiche o eliminazioni.

Pro e contro Capability sono centrate sul soggetto, quindi le operazioni su oggetti sono più difficili, se voglio modificare un file, devo modificare tutte le capability di riferimento, non basta modificare il file, devo vedere tutti i soggetti e modificare per ognuno le capability. Security check a runtime è più efficiente, automaticamente ha i diretti di accesso, è un token, permette così di accedere.

Si possono effettuare i processi di delega in modo quasi immediato. Però i SO hanno sposato ACL la facilità di implementazione ha vinto.

8.2 Caso di studio: UNIX

Come i meccanismi di sicurezza vengono utilizzati, noi introdurremo il modello base dei meccanismi di protezione Unix.

Filosofia di design Unix è stato pensato per essere gestito da amministratori consapevoli con competenze informatiche. Infatti unix viene gestito a linea di comando e con scripting. Difficilmente si hanno interfacce grafiche. La sintassi è arcaica. Unix è multiutente multi-programmato. Gli obiettivi di sicurezza sono di proteggere gli utenti uno dall'altro, e proteggersi dagli attacchi della rete. Il modello di sicurezza è un approccio duck con granularità di accesso a 3 componenti: owner, group, other.

Users sono memorizzati all'interno di un file /etc/passwd. Il formato di questo file: username:password:UID:GID:name:homedir:shell. UID identifica univocamente l'utente, GID 16 bit

associati univocamente. Tra gli utenti si distingue il Superuser che ha UID 0. Le password sono opzioni a volte vengono memorizzate in /etc/shadow. Superuser è un utente privilegiato con UID 0, il suo user name è root ed è un utente che può fare tutto sul sistema. Ha tutti i poteri ma il ring 0 è diverso però. Con root:

• tutti i controlli sono spenti
• un superuser può diventare qualsiasi user
• un superuser può cambiare il clock di sistema.

NON può scrivere su un file read only, ma può copiarlo e modificare i diritti, non può decifrare le password ma le può modificare. È l'utente padrone del SO, senza alcun controllo.

Gruppi servono per raggruppare gli utenti, ma in unix non servono per ridurre la matrice, ma per rendere più preciso il controllo degli accessi, ogni utente può appartenere a uno o più gruppi. I gruppi sono descritti in un file /etc/group che contiene i nomi di tutti i file con il corrispondente

identificativo:groupname:password:GID:lista degli utenti.

Soggetti Sono i processi distinti da un identificativo univoco di 16 bit detto PID, sono correlati agli utenti, ovviamente ci sono processi di sistema detti demoni lanciati dal boot, poi ogni volta che un utente di logga genera un processo shell. Tutti i processi poi eseguiti dall'utente sono figli della shell.

I processi sono generati da una fork e poi eventualmente da un esec. Oltre al pid per i processi di autorizzazione hanno:

• real UID/GID sono ereditati da UID/GID dell'utente loggato sul sistema e che poi ha generato i processi successivi, quando l'utente manda in esecuzione nuovi processi, generati dalla shell, ed eriditano UID/GID dell'utente a cui la shell è associata. UID/GID si propagano con la fork e si trovano nel file che ha generato i processi
• effective UID/GID sono ottenuti o ereditati dal processo genitore, oppure da un file mandato in esecuzione dell'exec.

54Figure 8.4: file

1. bin
2. root
3. demon

Ci sono gruppi di sistema che non hanno utenti come mem e kmem che rappresentano la memoria del kernel.

Gli oggetti sono tutte le risorse del sistema: file, directory, dispositivi di memoria e I/O. In Unix, tutte le risorse sono viste come file. La politica generale di controllo si riduce alla politica di controllo del file system, dove ogni risorsa è un file. Gli oggetti di access control sono i file, ognuno dei quali è rappresentato da una directory.

La directory mappa un nome logico su uno fisico (numero inode del file) e indirizza nella tabella degli inode, che contiene informazioni sulla risorsa. Quello che ci interessa sono i permessi, quindi le operazioni consentite. Quindi, ad ogni oggetto è associato un ACL (Access Control List).

Unix semplifica notevolmente l'enumerazione dei soggetti che hanno accesso al file (intendiamo qualunque risorsa). Per avere ACL maneggevoli, riduce a 3 il numero di soggetti che possono accedere al file:

1. bin
2. root
3. demon

Possono accedere a un oggetto, e quindi raggruppa i soggetti in categorie diverse è un raggruppamento logico (nongroup):

• il proprietario dell'oggetto
• tutti gli utenti che insieme al proprietario appartengono al gruppo primario
• il resto del mondo

Sono le 3 categorie di soggetti che possono accedere al file, sono le entry ad ACL. Costituiscono l'interouniverso dei soggetti. ACL avranno solo 3 soggetti. Ciascuno dei soggetti può svolgere read write ed execute. Quindi sono sufficienti 3 bit. 0 operazione non autorizzata 1 autorizzata. ACL è costituita da 9 bit, per descrivere logicamente le operazioni che i soggetti possono fare sugli oggetti, sono divisi in 3 gruppi:

• il primo gruppo descrive le operazioni di accesso del proprietario
• il secondo gruppo descrive le operazioni di accesso del gruppo a cui owner appartiene
• il terzo gruppo operazioni di accesso per il resto del mondo

Figure 8.6: type 2 bit per descrivere il tipo del file, r=read,

w=write, x=execute, è ACL di unixdrwr-xr-x , dr è directory, owner può leggere e scrivere, group invece execute e