Torna alla pagina di ESP

Capability List: detto anche ticket, memorizza per riga, cioè ogni riga è un utente con una lista di operazioni consentite.

ACC VS Capability List

ACC è efficiente quando si effettuano controlli per oggetto, perché ogni oggetto ha subito la sua lista di permessi. Se invece voglio controllare per soggetto, allora dovrei scandire tutta la lista prima di trovare tutte le risorse accessibili a quel soggetto.

Capability List lavora al contrario: è efficiente nelle ricerche per soggetto, ma molto inefficiente nelle ricerche per oggetto. Lavorare sui soggetti cone la Capability List è semplice, perché li trovo subito, e posso aggiungere o togliere permessi o creare o eliminare soggetti con facilità. Con ACC è più complesso.

Capability List però porta con sé il problema della non falsificabilità. Siccome ogni utente ha la sua lista di privilegi, questa lista deve essere ben sicura e dall'integrità garantita, altrimenti ci sono seri rischi di sicurezza. Il fatto che Capability List sia poco usato deriva proprio dalla difficoltà di mantenere una tale lista gigantesca in modo sicuro.

Problema della safety

Abbiamo detto prima che, tramite le primitive, si può passare da uno stato di autorizzazione ad un altro stato. Le transizioni tra stati sono segnate così:

 Q = Q0 ⊢ c1 Q1 ⊢ ... ⊢ cnQn = Q' 

in cui c_n sono i comandi primitivi, con certi parametri. Se ci sono delle parti condizionali nei comandi, e le condizioni non sono soddisfatte, allora lo stato finale è identico allo stato iniziale.

Ma c'è un problema. Tramite questi comandi, perfettamente legali, è possibile passare da uno stato che le mie politiche considerano lecito, ad uno che invece non è lecito? Infatti, c'è il problema che sia possibile avere una sequenza di comandi che alla fine mi porta in uno stato dove anche l'utente brutto ha accesso al sistema, per rimanere con l'esempio di prima.

La cosa brutta è che, a priori, questo è un problema non decidibile. Ovvero, in base allo stato iniziale ed ai comandi permessi non so dire prima di attivare il sistema se sarà possibile aggirare la mia politica tramite opportuni comandi sulla matrice di accesso. Non decidibile vuol dire che il tempo per scoprirlo è polinomiale, cioè costoso, e per ridurlo occorre assumere che i comandi siano tutti mono-operazionali (cioè che facciano una sola cosa) e che soggetti ed oggetti siano in numero finito.

Torna alla pagina di ESP

Lo stato di protezione è modificabile nel tempo: abbiamo quindi a che fare con un sistema dinamico. Le transizioni tra uno stato e l'altro sono affidate a delle primitive. Eccole:

• enter R into A[S,O] => il privilegio R viene infilato in una cella
• delete R from A[S,O]
• create subject S'
• destroy subject S'
• create object O'
• destroy object O'

Come implementare il modello a matrice di accesso

Non è un problema da poco. Se facessi letteralmente una tabella così, sarebbe gigantesca. Pensiamo ad un sistema con 1000 files e 10 utenti. La tabella sarebbe grossa 1000 * 10. Inoltre, gran parte della tabella stessa conterrebbe celle vuote, che rappresentano quelle risorse dove quell'utente non ha voce in capitolo. Ci sono alcune alternative, in proposito.

Tabelle di autorizzazione: salvo solamente le triple SOA definite.

ACC: memorizzo per colonne, cioè ogni riga è una risorsa, e ogni cella della colonna contiene la lista dei permessi per ogni utente.

Un esempio è il filesystem delle macchine unix, in cui ogni file è così presentato.

 nomefile proprietario gruppo -rwxr-xr-x

Della stringa -rwxr-xr-x, il primo trattino ci dice se si tratta di una cartella o no (in questo caso no, se no avremmo avuto una d), ma i restanti nove caratteri sono divisi in tre gruppi di tre: i primi tre ci dicono i permessi del proprietario sulla risorsa, i secondi tre i permessi del gruppo e gli ultimi tre i permessi di tutti gli altri. I tipi di permesso sono 3, r = read, w = write e x = execute.

Capability List: detto anche ticket, memorizza per riga, cioè ogni riga è un utente con una lista di operazioni consentite.

Le primitive

Inventato da Lampson nel 1971, ma usato bene o male ancora adesso. Ci sono tre insiemi: S è l'insieme dei soggetti, O è l'insieme degli oggetti, e A è la matrice di accesso.

La matrice di accesso è una tabella in cui le righe sono i soggetti, e le colonne sono gli oggetti. Una singola cella contiene i privilegi che l'utente di quella riga ha sulle risorse di quella colonna.

Per qualche oscura ragione che mi è sfuggita, l'insieme S è un sottinsieme dell'insieme O, perché in qualche modo i processi che un utente lancia sono un estensione del soggetto. E con ciò? Boh, mi documenterò.

Lo stato di protezione è modificabile nel tempo: abbiamo quindi a che fare con un sistema dinamico. Le transizioni tra uno stato e l'altro sono affidate a delle primitive

(:title ESP Lezione del 29 ventoso 216:)

 :: ESP - Lezione del 29 ventoso 216 ::

... altrimenti noto come 19 marzo

Controllo dell'accesso

C'è un modulo, nel sistema, che si occupa di controllarne l'accesso. Valuta se dire SI o NO alle richieste che gli vengono fatte, in base all'identità del richiedente ed ai suoi permessi.

Accountability: = l'esigenza di sapere CHI ha fatto CHE COSA, e QUANDO. Queste informazioni sono importanti soprattutto in quei sistemi dove gli utenti sono noti a priori, anche se non tutti i sistemi sono così.

Come al solito, possiamo distinguere tra politica, ovvero le linee guida da applicare, e meccanismi, ovvero i modi concreti con cui attuerò le mie politiche. Occorre stare attenti che spesso le autorizzazioni, ovvero le regole di controllo, sono spesso chiamate politiche, ma sono due cose diverse.

Ci sono dei vantaggi nel separare concettualmente le politiche dai meccanismi:

1. Posso analizzare la politica senza preoccuparmi di come implementarla
2. Posso confrontare politiche diverse senza preoccuparmi di come sono implementate
3. Posso confrontare meccanismi diversi senza preoccuparmi delle politiche
4. Posso usare un unico meccanismo per implementare diverse politiche.

I meccanismi

I meccanismi presuppongono l'esistenza di un reference monitor, che è una parte fidata del nostro sistema. Deve essere fidata per poter gestire in tutta sicurezza gli accessi al sistema. Le sue caratteristiche sono quindi:

• tamper proof: nessuno può modificarlo;
• non bypassabile: non esiste un modo di entrare nel sistema senza passare per lui;
• confinato in un piccolo modulo del SO, inaccessibile ai più;
• resistente ai covert channel.

È ovvio che queste caratteristiche sono volute e ricercate, ma non sempre ottenute al 100%.

Progettazione del controllo dell'accesso

Sopra abbiamo visto che c'è distinzione tra politiche e meccanismi. La Politica è la linea guida generale a cui mi ispiro per realizzare la sicurezza del mio sistema. Il Meccanismo è come fisicamente implementerò quelle linee guida. Ad esempio, posso scegliere come politica un accesso in base all'identità: i belli possono entrare, i brutti no. E il meccanismo dovrà gestire le identità, magari prevedendo un nome diverso ed una password diversa per ogni utente diverso.

Ma non si passa direttamente da politica a meccanismo: in mezzo ci sta il modello. Un modello è una rappresentazione formale delle linee guida della mia politica. L'aggiunta di questa fase mi permette di realizzare i meccanismi a partire da regole certe, ovvero da regole formali e non da parole un po' vaghe. Un po' la differenza che passava tra la descrizione del sistema e la realizzazione dell'ER.

Il modello è

• completo se rappresenta tutte le richieste previste dalla mia politica,
• consistente se no ncontiene contraddizioni al suo interno, ad esempio, "nega l'accesso a tutti i brutti", e poi sotto ha una regola "Ronaldinho può entrare". Eh no, non ci siamo.

Quando il mio modello rispetta la completezza e la consistenza, allora va tutto bene, il mio modello è sicuro. Se poi anche il mio meccanismo è corretto rispetto al modello, allora anche il mio sistema è sicuro.

Politiche di sicurezza

Ci sono 3 categorie fondamentali di politiche di sicurezza:

• DAC = Controllo dell'accesso discrezionale
• MAC = Controllo dell'accesso mandatorio
• RAC = Controllo dell'accesso basato sui ruoli

Sono i modi per definire chi può e chi non può spaciugare nel sistema.

Le politiche di amministrazione mi dicono invece chi può specificare le regole. Ad esempio, in una macchina UNIX tipica l'utente root decide per tutti gli altri.

Modelli di sicurezza

I modelli di cui parlavamo prima sono descritti facendo ricorso a queste tre entità:

• soggetti: chi può accedere;
• oggetti: le risorse da proteggere;
• azioni: che cosa si può fare ad una risorsa o ad un soggetto.

In un dato momento, l'insieme dei permessi dati o negati ad ogni soggetto costituisce lo stato di autorizzazione del mio sistema, ovvero lo stato di protezione del sistema stesso.

Le regole di identificazione sono invece degli assiomi che vanno verificati affinché un accesso sia negato o permesso.

Politiche discrezionarie

Le politiche discrezionarie si chiamano così perché prevedono che un utente possa passare dei privilegi ad un altro utente a sua discrezione.

Il controllo dell'accesso viene effettuato in base all'identità dell'utente, e si confronta l'identità con l'insieme di regole che mi dicono che cosa quell'utente può o non può fare.

Ad esempio, SQL implementa una politicha discrezionaria: un utente con GRANT e REVOKE può concedere a sua discrezione privilegi ad altri utenti.

Modello a matrice di accesso

Inventato da Lampson nel 1971, ma usato bene o male ancora adesso