Sono come quelle sopra: un oggetto ha la sua classe, idem per un soggetto. Le classi però rappresentano il grado di fiducia nelle modifiche che un utente può fare, o di fiducia nell'informazione contenuta nell'oggetto.

L'idea è di impedire flussi di informazioni che vadano da classi di informazioni basse verso classi alte. Questo perché le info di classe bassa sono poco accurate, e non dovrebbero sporcare le info di classe alta.

Se ci pensate, la mandatoria per la sicurezza garantisce sì la sicurezza, ma permette a un qualsiasi utente di scrivere in classi superiori alla sua: un utente poco fidato, invece, secondo la mandatoria per l'integrità non dovrebbe essere in grado di usare le informazioni di cui dispone per alterare qualcosa ad alto livello.

Quindi, le proprietà sopra citate vengono invertite:

• no write up = un soggetto può modificare solo oggetti con classe minore o uguale alla sua
• no read-down = un soggetto può leggere solo oggetti con classe uguale o superiore alla sua

Questo vuol dire che le operazioni che un utente fa non possono basarsi su info poco pregiate e meno corrette di quelle a cui può accedere.

Modelli di Biba

Biba si legge bàiba. Va beh. Costui, similmente a Bell - La Padula ha il reticolo delle classi e così via. Le proprietà cui si riferisce sono la

• simple property = no read down
• star property = no write up

Un utente non può leggere in una classe inferiore alla sua, e non può scrivere in una classe superiore alla sua. Una specie di fusione delle 2 politiche mandatorie viste qui sopra.

E allora anche la lista della spesa di un dirigente deve rimanere un info di alto livello, pur trattandosi di roba poco pregiata? No. Biba risolve il problema con il low water mark per soggetti.

Il low water mark per soggetti dice che, se qualcuno con una certa λ(s) vuole scrivere su qualche oggetto con una certa λ(o), allora l'utente viene temporaneamente declassato ad una classe che è il glb(λ(s), λ(o)). Ricordo che glb = greatest lower bound.

Ma nemmeno quest'idea è del tutto brillante, perché l'ordine delle operazioni determina il buon esito di un'operazione.

Per esempio, se devo scrivere su un livello basso, e poi leggere ad un livello alto, NON posso farlo, perché mi abbassa la classe per poter scrivere. Al contrario, se prima scrivo e poi leggo, sì che posso farlo.

Esiste poi la low water mark per oggetti, in cui abbasso o alzo la classe dell'oggetto. Ma l'integrità se ne va a ramengo.

Esempio

 S > C > U
 λ(Alice) = S
 λ(Bob) = C
 λ(O1) = C
 λ(O2) = U

Alice può scrivere su O1? NO, perché la classe di 01 è minore della classe di Alice. Però Alice può leggerlo. Idem per O2. Bob può scrivere su O1, e anche leggerlo, mentre può solo leggere O2.

System Z

Nell'esempio qui sopra, Alice non può scrivere su O1. Un particolare sistema detto System Z fa in modo tale che, se voglio compiere un'azione non permessa, allora abbasso temporaneamente la classe del soggetto o quella dell'oggetto, in modo che l'accesso sia concesso.

Quindi, per poter permettere ad Alice di scrivere su O1, avremmo potuto cambiare la classe di O1 e farlo diventare S.

Ma non è molto ragionevole cambiare le classi all'occorrenza, non si sa mai come va a finire. In questo caso, certo, lo stato è sicuro secondo le proprietà dette prima, ma nel frattempo è stata cambiata la classe di un oggetto.

Tranquillity property

Posso introdurrre la tranquillity property , che non permette di cambiare classificazione ad oggetti o soggetti.

Però, anche questa introduce problemi, in quanto non è sempre possibile rispettarla. Ad esempio, un dirigente non potrebbe mai scrivere oggetti di classe inferiore, anche se volesse. Allo stesso modo, un processo di un certo livello sarebbe costretto ad utilizzare dati di livello più basso, e quindi potenzialmente meno attendibili, per poi scrivere su un livello più alto.

Altri problemi delle politiche mandatorie

Problemi di associazione. Se ho due classi U, può anche darsi che l'associazione tra elementi delle 2 classi debba essere di un altro livello.

Per intenderci, se il nome dei dipendenti è in un file classificato U, così come gli stipendi non associati al nome, l'associazione del nome agli stipendi potrebbe essere di classe S, quindi superiore alla classe di partenza dei due oggetti associati!

Problemi di aggregazione. Un singolo elemento può avere un valore U, ma l'aggregazione dei singoli elementi può avere classe S. Esempio: la posizione di una nave sola è U, ma la posizione di TUTTE le navi è S.

Inoltre, le politiche mandatorie non offrono niente per scoprire eventuali canali coperti.

Comunque, è sempre possibile applicare una politica discrezionaria all'interno di una politica mandatoria.

Politica mandatoria per l'integrità

(:title ESP - Lezione 13 germile 216:)

Altrimenti noto come 2 aprile 2008

Torna alla pagina di ESP

Modello di Bell e La Padula

Questo modello comprende le nozioni di stati e di transizioni di stato.

Uno stato è una tripla (b, M, λ) dove;

• b = tutti gli accessi eseguiti nello stato corrente, quindi una SxOxA (soggetti x oggetti x azioni)
• M = matrice di accesso: le righe indicano gli utenti, le colonne gli oggetti. La cella indica le azioni di quell'utente su quell'oggetto.
• λ = funzione che, dato un soggetto od un oggetto, mi restituisce la classe di sicurezza cui esso appartiene

Stato sicuro

Adesso parliamo delle politiche mandatorie per la sicurezza.

Uno stato è detto sicuro se soddisfa le seguenti proprietà:

• simple security property (ssp)
• *-property (star property)

La ssp mi dice che, se il soggetto S ha eseguito un'azione A sull'oggetto O, allora la classe dell'utente deve dominare l'oggetto in caso di lettura.

 λ(S) >= λ(O)

La star property dice invece che, in caso di scrittura

 λ(O) >= λ(S)

Ciò vuol dire che un utente può leggere solo oggetti classificati più in basso di lui, e scrivere solo oggetti classificati più in alto di lui!

Funzione di transizione di stato

 T: V * R -> V
 R = richieste di accesso
 V = stato

Deve andare da uno stato sicuro ad uno stato sicuro. Un sistema (V₀, R, T) è sicuro se e solo se

 V0 è sicuro
 T(V0 * R) è uno stato sicuro

Il teorema di sicurezza dice che uno stato è sicuro se sono rispettate le proprietà là sopra quando si eseguono gli accessi.

...continua...

Torna alla pagina di ESP