Complementi di Sicurezza e Privatezza:

Complementi di
Sicurezza e Privatezza
Appunti di Maurizio Fortunati
Università degli Studi di Milano
Facoltà di Scienze e Tecnologie
Corso di Laurea Magistrale in Sicurezza informatica (Classe LM-66)
Esame di Complementi di Sicurezza e Privatezza
Docente: Sabrina De Capitani Di Vimercati
Anno accademico - 2018/2019 e 2019/2020Complementi di Sicurezza e 
Privatezza 
Appunti a cura di Maurizio Fortunati 
Università degli Studi di Milano – Corso Magistrale in Sicurezza Informatica LM-66 
Corso tenuto da Sabrina De Capitani di Vimercati 
 AA 2018/19 
Sito Docente 
Link Ariel - Lucidi 
V2.0 – 21 feb. 2020 
Sommario 
Sommario .......................................................................................................... 2 
Controllo dell'accesso ........................................................................................... 4 
Primi approcci ................................................................................................. 4 
Principi di progettazione di Saltzer e Schroeder ........................................................ 7 
Politiche d’accesso ........................................................................................... 8 
DAC ........................................................................................................... 9 
MAC ......................................................................................................... 13 
RBAC ........................................................................................................ 19 
Administrative policies .................................................................................. 21 
Clark and Wilson model for Integrity .................................................................... 21 
Il modello .................................................................................................. 22 
Regole ...................................................................................................... 23 
Chinese Wall ................................................................................................. 24 
Expanding authorizations .................................................................................. 25 
Apache ..................................................................................................... 26 
Logic based auth languages – FAF – da fare .......................................................... 26 
Recent directions in access control ...................................................................... 26 
Sistemi remoti ............................................................................................ 26 
Basi di dati multilivello ........................................................................................ 27 
OLS ............................................................................................................ 27 
OpenStack Swift ................................................................................................ 28 
Selective encryption ........................................................................................ 28 
Policy-based encryption for OpenStack Swift ....................................................... 29 
Over encryption ............................................................................................. 31 
Integrità delle query ........................................................................................... 32 
Metodi deterministici ...................................................................................... 32 
Merkle hast tree .......................................................................................... 32 
Skip list .................................................................................................... 34 
Probabilistic Approaches ................................................................................... 36 
Fake tuple ................................................................................................. 36 
Computation with multiple providers ................................................................... 37 
Dynamic encryption – “on the fly” .................................................................... 38 
Markers .................................................................................................... 39 
Twins ....................................................................................................... 39 
Salts/Buckets ............................................................................................. 40 
Distributed computational cloud – MapReduce ...................................................... 42 
Query Distribuite ............................................................................................... 47 
Sovereign join ............................................................................................... 48 
Access patterns .............................................................................................. 48 
View-Based authorizations ................................................................................ 49 
Pairwise authorizations .................................................................................... 49 
Distributed query evaluation under protection requirements ....................................... 50 
Data Model ................................................................................................ 50 
Permissions ................................................................................................ 51 
Profilo della relazione ................................................................................... 52 
Authorizations Composition ............................................................................... 52 
Differential Privacy ............................................................................................. 54 
Global Differential Privacy ................................................................................ 56 
Algoritmo non trivial deterministico .................................................................. 56 
Global sensitivity ............................................................................................ 56 
Proprietà Global Differential Privacy ................................................................. 57 
Local Differential Privacy .................................................................................. 57 
Selezione cloud plan e preferenze utente .................................................................. 58 
BROKERAGE-BASED APPROACH ............................................................................ 58 
FUZZY-BASED REQUIREMENTS ............................................................................. 58 
Blockchain ....................................................................................................... 60 
Riferimenti ...................................................................................................... 63 
Indice delle figure .......................................................................................... 63 
Bibliografia ................................................................................................... 64 
Controllo dell'accesso 
Primi approcci 
In questo capitolo vedremo le politiche, modelli e meccanismi del controllo dell’accesso. 
Il controllo di accesso si occupa di valutare le richieste di accesso alle risorse da parte 
dell’utente che è stato autenticato e in base ad alcune regole, determina se i diritti 
d’accesso devono essere rilasciati o meno. 
Il controllo si limita a verificare gli accessi diretti ma si può migliorare il controllo 
effettuando un check su eventuali inferenze e flussi di informazioni.  
La correttezza dell’accesso dipende dalla corretta identificazione del soggetto e dalla 
correttezza delle grant che gli vengono affidate. 
Quindi bisogna esser certi della correttezza delle informazioni sulle quali l’accesso viene 
verificato. 
Quindi: 
La correttezza del controllo di accesso dipende da: 
• Identificazione/autenticazione corretta 
o Nessuno dovrebbe acquisire i privilegi di qualcun altro 
o L’autenticazione oltre ad un discorso di sicurezza, serve anche per effettuare 
Accountability 
1
. 
 
• Correttezza dell’autorizzazioni 
o Rispetto alle quali l’accesso è valutato. 
o Non deve esistere il concetto di account condiviso. 
Studiando il controllo degli accessi è utile separare le Policy dai modelli e dai meccanismi. 
Le policy, definiscono ad alto livello, le linee guida e le regole che gestiscono gli accessi da 
autorizzare al sistema. Si può notare il contrasto tra closed e open policy. 
Il modello, definisce formalmente le specifiche del controllo d’accesso 
I meccanismi implementano le policy a basso livello e considerando le funzioni hardware e 
software. 
La separazione tra policy e meccanismi permette di poter implementare le policy in modo 
indipendente rispetto ai requisiti di accesso e poter progettare meccanismi che riescono ad 
implementare più policy. 
A livello pratico il meccanismo che gestisce il controllo delle policy è il reference monitor. 
Il reference monitor è di solito implementato come un modulo del kernel, e il suo compito è 
quello di controllare tutti gli accessi software a oggetti o devices, decidendo quale processo 
abbia i diritti o meno di poter accedere alla risorsa.  
Il concetto di reference monitor deriva dagli scritti di James Anderson 
2
 del 1972. 
1
 Si potrebbe tradurre con rendicontazione ma accountability è formata dalle parole Account + Ability e 
dalla sua etimologia si riesce a capirne il senso,  si intende quello che viene effettuato da un account, 
cioè l’abilità di poter associare/tracciare le attività di un account. 
2
 (Lewis, 2016) 
Il concetto di reference monitor prevede che un componente del sistema, chiamato 
“Reference validation mechanism”, sarà responsabile dell'applicazione della politica di 
controllo degli accessi del sistema sulle operazioni dei processi dell'utente….” 
Il concetto di reference monitor definisce i requisiti per l'implementazione di un meccanismo 
in modo tale da garantire che gli utenti malintenzionati non possano eludere l'applicazione 
delle policy. Il concetto di reference monitor non è solo responsabile di assicurare che i 
riferimenti siano autorizzati ad accedere a oggetti di risorse condivise, ma anche di 
assicurare che l’operazione sia del tipo giusto (ad esempio, read, read\write, ecc.). 
Figura 1: Ref Mon - Kernel Vs User 
In windows, vengono confrontati i token di accesso del processo assegnati dal DACL 
(discretionary access control list) con I token presenti sull’oggetto che il processo vuole 
accedere. 
Vengono comparati i SID (Security IDentifier) dell’oggetto con quelli del soggetto e nel caso 
in cui durante il confronto si genera un SID negato, l’accesso del processo all’oggetto viene 
negato.  
I SID sono degli identificativi univoci che vengono assegnati ad ogni processo, utente , gruppo 
o qualsiasi Principal (entità) 
3
.
3
 Il principal o security principal  in computer security è una qualsiasi entità che dispone di SID e che 
può essere autenticata, può essere un thread di processi, un user o computer account. 
I SID vengono salvati in un database e vengono gestite da active directory - (Microsoft, 2017) 
 
Figura 2: Authorization and Acce ss control process 
Grazie al Reference monitor si riescono ad effettuare i processi di auditing
4
 per le policy 
locali.  
Un modulo, per esser utilizzato come reference monitor deve garantire alcune proprietà 
spesso riferendosi con l’acronimo NEAT.  
Non bypassable → il meccanismo di validazione deve mediare l’accesso al sistema e alle sue 
risorse e non possono esser violate le policy di sicurezza da parte di un’attaccante  
Evaluable → verificabile, ovvero è possibile fare dei test sul sistema per poterne verificare il 
funzionamento e possa essere abbastanza semplice da poter subire un controllo tramite un 
metodo di verifica formale. 
Always invoked→ Il meccanismo di validazione deve essere sempre invocato, altrimenti è 
possibile che un attaccante violare le policy di sicurezza. 
Tamper proof → non può essere alternato da un’attaccante. 
 
Nel materiale della docente, viene riportata una definizione leggermente diversa, viene 
definito Tamper proof, e Non bypassable  alla stessa maniera ma sdoppia il concetto di 
Evaluable in Security Kernel e Small 
Security kernel → il kernel del reference monitor è confinato in una parte limitata del 
sistema e le funzioni di sicurezza diffuse in tutto il sistema implicano che il codice viene 
verificato. 
Small → il modulo deve essere piccolo abbastanza per poter subire una verifica formale. 
 
4
 Processo di valutazione delle policy 
 
L’implementazione di un meccanismo non è semplice e deve far fronte a due problemi: 
Storage Channel : gli elementi di memoria e porzioni di disco devono essere cancellate prima 
di essere rilasciate per impedire la ricerca dei dati. 
Covert channels: canali che non sono studiati per il passaggio di informazioni che vengono 
sfruttati per farlo. 
Quindi come si fa? 
Principi di progettazione di Saltzer e Schroeder 
Progettare un sistema sicuro è impossibile in quanto ci sarà sempre qualche difetto di 
progettazione ma questi due signori, nel 1975 
5
 hanno definito alcuni principi che possono 
essere utili per la progettazione e contribuire a un'implementazione senza difetti di 
sicurezza.  
Ecco otto esempi di principi di progettazione che si applicano in particolare ai meccanismi di 
protezione. 
1. Economia del meccanismo: mantieni il design il più semplice e piccolo possibile, 
perché più è semplice meno errori ci sono e più facilmente si può condurre 
un’ispezione line per linea del codice. 
2. Impostazioni predefinite a prova di errore: di base tutti sono esclusi tranne quelli 
permessi. Qusto metodo permette una maggiore sicurezza che definire chi è escluso. 
Simile alle acl dove alla fine c’è un deny any – tutti esclusi tranne quelli che elenco 
io. 
3. Mediazione completa: ogni accesso a ogni oggetto deve essere verificato per 
l'autorità. Forza una visione a livello di sistema del controllo degli accessi, che oltre 
al normale funzionamento include l'inizializzazione, il ripristino, l'arresto e la 
manutenzione. Implica che deve essere escogitato un metodo infallibile per 
identificare la fonte di ogni richiesta. 
4. Design aperto: il design non deve essere segreto. I meccanismi non dovrebbero 
dipendere dall'ignoranza di potenziali aggressori, ma piuttosto dal possesso di chiavi o 
password specifiche, più facilmente protette. Questo disaccoppiamento dei 
meccanismi di protezione dalle chiavi di protezione consente ai meccanismi di essere 
esaminati da molti revisori senza preoccuparsi che la revisione stessa possa 
compromettere le garanzie. Inoltre, a qualsiasi utente scettico può essere permesso 
di convincersi che il sistema che sta per usare è adeguato al suo scopo. Infine, non è 
realistico tentare di mantenere il segreto per qualsiasi sistema che riceva ampia 
distribuzione. 
5. Separazione dei privilegi: ove possibile, un meccanismo di protezione che richiede 
due chiavi per sbloccarlo è più robusto e flessibile di uno che consente l'accesso al 
presentatore di una sola chiave. 
6. Privilegio minimo: ogni programma e ogni utente del sistema dovrebbe operare 
utilizzando il minor numero di privilegi necessari per completare il lavoro. 
7. Meccanismo meno comune: ridurre al minimo la quantità di meccanismi comuni a più 
di un utente e dipendente da tutti gli utenti. Ogni meccanismo condiviso (in 
particolare uno che coinvolge variabili condivise) rappresenta un potenziale percorso 
5
 (SCHROEDER, 1975) 
informativo tra gli utenti e deve essere progettato con grande cura per essere sicuro 
che non comprometta involontariamente la sicurezza. 
8. Accettabilità psicologica: è essenziale che l'interfaccia umana sia progettata per 
facilità d'uso, in modo che gli utenti applichino regolarmente e automaticamente i 
meccanismi di protezione correttamente. 
 
Gli analisti dei sistemi di sicurezza fisica hanno suggerito altri due principi di progettazione 
che, purtroppo, si applicano solo in modo imperfetto ai sistemi informatici. 
 
9. Fattore di lavoro: confrontare il costo di aggirare il meccanismo con le risorse di un 
potenziale attaccante. 
 
10. Registrazione di compromesso: a volte viene suggerito che al posto di meccanismi più 
elaborati che prevengono completamente la perdita si possano usare meccanismi che 
registrano in modo affidabile che si è verificato un compromesso di informazioni. un 
esempio, molti sistemi informatici registrano la data e l'ora dell'utilizzo più recente di 
ciascun file. Se questo record è a prova di manomissione e segnalato al proprietario, 
può aiutare a scoprire un utilizzo non autorizzato. 
 
Come è evidente, questi principi non rappresentano regole assolute: servono come 
avvertimenti.  
Se una parte di un progetto viola un principio, la violazione è un sintomo di potenziale 
problema e il progetto deve essere attentamente esaminato per essere sicuri che il problema 
sia stato contabilizzato o che non sia importante. 
L’approccio multifase dalle policy ai meccanismi passa attraverso la definizione di un 
modello. 
Il modello del controllo d’accesso deve essere completo e consistente. 
Completo, che comprende tutti i requisiti di sicurezza che deve rappresentare. 
Consistente, libero dalle contradizioni, cioè non può negare e garantire l’accesso allo stesso 
tempo. 
La definizione formale di un modello consente la prova delle proprietà sul sistema. Provando 
che il modello sia formalmente sicuro e che i meccanismi siamo implementati correttamente, 
si può dire che il sistema sia sicuro (secondo la definizione di sicuro). 
Politiche d’accesso 
intro  
I sistemi di controllo dell’accesso si distinguono a seconda del tipo della politica che tali 
sistemi supportano, e tali politiche si possono distinguere in politiche del controllo 
dell’accesso e politiche amministrative. 
Le politiche di controllo dell’accesso definiscono chi può o non può accedere alle risorse e in 
generale è possibile dividere i modelli del controllo dell’accesso in discrezionali (DAC) e non. 
La differenza tra i due è basata sull’entità di chi applica le policy.  
In un DAC è il proprietario dell’oggetto che decide a chi concedere l’accesso, mentre nei 
modelli non DAC è un ente centrale che decide al posto del proprietario. 
Vedremo tre modelli  
Discrezionali -Discretionary access control (DAC) 
Mandatorie - Mandatory access control (MAC) 
Basate sul ruolo – Role-based access control (RBAC)  
Le politiche amministrative definiscono chi può concedere le autorizzazioni che regolano gli 
accessi, vengono realizzate grazie al DAC e RBAC. 
 
 
 
Figura 3: Panoramica dei modelli di controllo dell'accesso 
 
Figura 4: pro e contro dei modelli 
DAC 
Nel modello DAC ogni risorsa ha un proprietario ben definito. Un utente che crea un file ne 
diventa il proprietario e può decidere a propria DISCREZIONE a chi fornire i permessi per 
accedere al file. Gli utenti si possono organizzare in gruppi e l’utente può rilasciare i 
permessi al gruppo intero. Uno dei maggiori svantaggi del modello DAC è che le politiche di 
sicurezza vengono affidate alla discrezione degli utenti. 
Spesso si ci riferisce al modello HRU (Harrison, Ruzzo, Ullman) che definisce il modello di 
sicurezza di un sistema, dove tramite la tripla (S,O,A) dove: 
S è il soggetto, O è l’oggetto e A la matrice d’accesso che ha tante righe quanti sono i 
soggetti e tante colonne quanti sono i file. Con A[s,o] si indicano i privilegi (azioni) del 
soggetto s sull’oggetto o. 
 
Figura 5: Esempio Access Matrix 
La modifica avviene tramite comandi primitivi  
• enter r into A[s, o] 
• delete r from A[s, o] 
• create subject s′ 
• destroy subject s′ 
• create object o ′ 
• destroy object o′ 
Le politiche amministrative possono esser attuate tramite l’associazione di opportuni flag ad 
alcune azioni, ad esempio si può associare il flag (*) alla copia del privilegi e il flag (+) al loro 
trasferimento
6
. 
Copy flag (*): the subject can transfer the privilege to others 
command TRANSFERread(subj,friend,file) 
if Read* in A[subj,file] 
then enter Read into A[friend,file] end. 
 
Transfer-only flag (+): the subject can transfer to other the privilege (and the flag on it); but 
so doing it loses the authorization. 
command TRANSFER-ONLYread(subj,friend,file) 
if Read+ in A[subj,file] 
then delete Read+ from A[subj,file] 
enter Read+ from A[friend,file] end. 
 
L’esecuzione di un comando causa la transizione da uno stato di protezione Q ad un altro 
stato di protezione Q’. 
La flessibilità dei comandi amministrativi, come copy flag e trasnfer only flag, introduce il 
problema della safety, 
Il problema della safety si pone questo dubbio: è possibile che l'esecuzione di una sequenza 
di comandi legittimi conduca il sistema in uno stato non lecito per le mie politiche?  
6
 Trasferire i privilegi indica che l’utente originario perde i propri privilegi a favore di un altro. 
Cioè se partendo da uno stato di protezione Q è possibile eseguire una serie di richieste al 
fine di far evolvere il sistema in uno stato Q’ dove l’azione A[s,o] che non era lecita in Q 
diventi lecita (erroneamente) in Q’ 
Sì, è possibile, ma se non vengono fissate alcune limitazioni sui comandi, rilevare a priori 
quale successione di comandi mi porti in uno stato in cui si violano le politiche si rivela un 
problema non decidibile. 
Lo si può rendere decidibile imponendo alcuni vincoli: i comandi devono essere mono-
operazionali (possono eseguire un'unica operazione primitiva), sia i soggetti che gli oggetti 
devono essere in numero finito. 
Data la quantità di soggetti e oggetti che caratterizzano un sistema, è facile immaginare 
quanto una matrice degli accessi possa diventare vasta e memorizzarla come array 
bidimensionale sarebbe un enorme spreco di spazio.  
Utilizzando una matrice d’accesso, la maggior parte delle celle rimarrebbero vuote (non sono 
definiti privilegi per ogni coppia di entità). 
Le tecniche implementative più utilizzate sono dunque la tabella di autorizzazione, le Access 
Control List e le Capability list. 
• Authorization table: Memorizza tabella di triple non nulle (s, o, a). Generalmente 
utilizzato nei DBMS ( Oracle, Mysql, MongoDB). 
• ACL: Archivia per colonna, cioè per file 
• Capability lists : Archivia per riga, cioè per utente 
Auth Table 
Le tabelle di autorizzazione memorizzano in una tabella a tre colonne tutte e solo quelle 
triple (S,O,A) non vuote. Ad esempio: 
Soggetto Azione Oggetto 
Ann own File1 
Bob read File1 
Ann write File1 
... ... ... 
ACL 
Nelle Access Control List (ACL) la memorizzazione avviene per colonne. Ogni riga rappresenta 
una risorsa, poi avrò tante colonne quanti sono i soggetti che possono interagirvi, nelle cui 
celle apparirà la lista dei loro permessi. Richiedono di autenticare i soggetti ad ogni richiesta 
di accesso. Una possibile rappresentazione grafica è la seguente: 
 
Figura 6: Esempio ACL 
 
Capability List  
Infine le Capability List (ticket) memorizzano per riga, ovvero ogni riga rappresenta un 
utente con una lista di azioni consentite per i vari oggetti. Ad esempio: 
 
 
Figura 7:Esempio Capability List 
Differenze tra ACL e capability list: 
 
Figura 8: ACL Vs capability list 
Le ACL sono preferibili per quei sistemi in cui le operazioni sugli oggetti sono prevalenti, dal 
momento che rendono particolarmente efficiente il controllo dell'accesso su tali entità. 
Mentre sono meno efficienti per il controllo dei soggetti, in quanto per controllarli dovrei 
infatti scandire tutti gli elementi della lista.  
Le capability list al contrario hanno alte prestazioni nel controllo dell'accesso e nella 
gestione dei soggetti, ma devono garantire la non falsificabilità della lista per garantire la 
sicurezza, il che non è affatto semplice data la loro lunghezza.  
Per questo motivo le capability list sono l'implementazione meno diffusa delle matrici 
d'accesso. 
Una debolezza delle politiche discrezionali è che sono in grado di poter verificare solamente 
l’accesso diretto e il DAC non controlla a cosa accade alle info dopo che sono state rilasciate. 
Un esempio è la debolezza ai trojan horse, l’utente estende i permessi al trojan horse, il 
quale copia il contenuto del file che prima non poteva accedere e ricopia le informazioni in 
un nuovo file accessibile ad altri. 
Più di 40.000 tesi pubblicate:
         leggi il riassunto, l'indice,
la preview;
         puoi acquistare la
consultazione integrale.
 
Non sai da dove iniziare a
cercare?
- individua con precisione le
parole chiave;
- amplia la ricerca con termini
via via più generici;
- ti suggeriamo noi una lista di
argomenti tra cui cercare;
- scopri quali sono gli
argomenti più discussi nelle
tesi o quelli più ricercati.
Ti stai preparando per la tesi? Hai bisogno di materiali?
Appunti
universitari
Consultabili liberamente,
selezionati e pubblicati dalla
nostra redazione.
Divisi per ateneo, facoltà,
esame e argomento.
Puoi scaricarli gratuitamente.
Hai degli appunti interessanti?
Vendili a noi: li valutiamo e ti
paghiamo subito.
Scopri come »
Tesi di laurea
Come scrivere
una tesi di
laurea
I nostri consigli per
ottimizzare tempo e risorse.
Scarica la guida gratuita »
Ti senti perso?
Ecco i nostri consigli passo-
passo per iniziare.
Ascolta il podcast ed esegui i
compiti assegnati:
Podcast 1 
Figura 9: Esempio trojan horse 
MAC 
Meccanismo attraverso il quale le decisioni di accesso sono basate su delle etichette che 
contengono informazioni rilevanti circa la sicurezza di un oggetto. 
Le politiche mandatorie impongono restrizioni sul flusso di informazioni e fanno distinzione 
tra utenti e soggetti e considera gli utenti delle entità fidate mentre i soggetti (processi) 
sono entità non fidate. 
I sistemi DAC ignorano questa distinzione e quando vengono eseguiti i processi, vengono 
tenute in considerazione l’identità dell’utente che esegue un determinato processo. 
Gli utenti sono entità passive per cui sono definite autorizzazioni e possono collegarsi al 
sistema dando luogo all’esecuzione dei soggetti (processi) che sottomettono delle richieste al 
sistema. 
Le politiche mandatorie realizzano il controllo dell’accesso in base a delle regole stabilite da 
un‘ entità centrale, la politica più comune è quella multilivello con un ordinamento 
parzialmente ordinato basato sulla classificazione di soggetti e oggetti. 
Soggetti e oggetti creano una classe di sicurezza, composta da il livello di sicurezza e dalla 
categoria. 
Il livello di sicurezza sono elementi gerarchici che definiscono il livello di sicurezza, ad 
esempio possono essere TopSecret(TS) > Secret(S) > Confidential(C) > Unclassified(U) mentre 
le categorie sono un set di tag non gerarchici utilizzati per partizionare i dati, ad esempio, 
finance, IT, HR, accounting. 
Le due classi politiche più comuni sono  
• Secrecy-based (e.g., Bell La Padula model) 
7
 
• Integrity-based (e.g., Biba model) 
7
 (Rushby, 1986) 
Il modello di Bell La Padula si concentra su riservatezza di dati e accesso a informazioni 
classificate, in contrasto con il modello BIBA che descrive regole per la protezione dell’ 
integrità dei dati. 
MAC - Bell La Padula 
Lo scopo di questo modello è quello di garantire la sicurezza delle informazioni 
(confidentiality)  e viene garantita tramite un reticolo di sicurezza e la creazione di una 
cleareance. 
La clearance è la classe assegnata ad un utente, ed è il livello di autorizzazione dell'utente e 
i settori su cui ha questa autorità.  
Ogni utente ha un livello di segretezza a cui può accedere, ed un'area di competenza data 
dalle categorie a cui può accedere. 
Un utente può collegarsi al sistema utilizzando una qualsiasi classe che sia ≤ della sua 
clearance. Per garantire la segretezza, vanno rispettate queste due proprietà: 
La segretezza viene garantita impedendo flussi di informazione verso classi di accesso più 
basse o non compatibili.  
Ciò è assicurato da due proprietà vincolanti: 
• no write down, il soggetto s può scrivere solo su oggetti o che hanno SC dominante: λ
(o) ≥ λ(s). Se è vero che da una parte ciò impedisce l'acquisizione di informazioni 
riservate da parte di oggetti a cui ne è precluso l'accesso, dall'altra non garantisce 
l'integrità delle informazioni. 
• no read up, il soggetto s può leggere solo da oggetti o di SC inferiore: λ(s) ≥ λ(o). 
 
Figura 10: BLP Information Flow 
In questo modello esiste il concetto di stato sicuro, ovvero il sistema si effettua delle 
transizioni da uno stato sicuro all’altro, uno stato è considerato sicuro se vengono rispettate 
due proprietà, la simple security property e la *(start) property che sono il no read up e il no 
write down.  
La transizione T è l’insieme di richieste di accesso e T si può considerare sicura se e solo se 
tutti i cambiamenti di stato in mezzo avvengano tra stati sicuri. 
Successivamente bisogna verificare che lo stato di partenza domini lo stato di destinazione, 
cioè bisogna considerare le categorie.