Lucidi della terza lezione

Sicurezza dei sistemi
informatici
Master di I° livello in
Sistemi e Tecnologie per la sicurezza
dell'Informazione e della Comunicazione
Terza lezione
19/5/2007
Contenuto della lezione


Linee guida della sicurezza
Sicurezza nei sistemi operativi
Linee guida per la progettazione di
sistemi sicuri

Semplicità




Meno cose possono andare male ...
Un numero minore possibile di inconsistenze
Facile da capire
Restrizioni


Minimizzare gli accessi
Inibire la comunicazione
Minimo Privilegio

Un soggetto deve possedere solo i diritti di cui
ha bisogno per svolgere i propri compiti



I diritti sono concessi in base alla funzione, non
all’identità
I diritti sono aggiunti quando servono e quando
non servono più sono revocati
Non tutti i sistemi, a causa della granularità dei
permessi, sono in grado di soddisfare tale principio
Fail-Safe Defaults

Per default, l’accesso di un soggetto ad un
oggetto deve essere negato


Ogni diritto deve essere concesso esplicitamente
Inoltre se un’azione fallisce il sistema deve
restare sicuro, come se l’azione non fosse stata
svolta
Economia del Meccanismo

Tenere il sistema più semplice possibile:


Semplice significa anche che ci sono meno cose da
controllare


nel progetto, implementazione, numero di operazioni,
interazioni con altre componenti, addirittura nella specifica
In caso di errori è più facile identificarli e correggerli
Particolare attenzione deve essere posta nelle
interfacce ad altri moduli (possono fare assunzioni
non verificate)

esempio: finger
Completa Mediazione


Controllare ogni accesso
Di solito il controllo è fatto al primo accesso


Ad esempio in UNIX il controllo di accesso in
lettura ad un file è fatto solo all’apertura del file e
non ad ogni operazioni di lettura
Se i permessi cambiano durante l’operazione,
si possono generare accessi non validi
Open Design

La sicurezza non dovrebbe dipendere dalla
segretezza nella progettazione o
dell’implementazione del sistema



Si potrebbe intendere che il codice sorgente
dovrebbe essere pubblico
“Sicurezza mediante oscurità” ?
Non va bene con informazioni tipo passwords o
chiavi crittografiche
Separazione dei Privilegi
Non si può concedere un diritto in base ad una
condizione sola


ad esempio in molti Unix per diventare root bisogna
1.
2.
conoscere la password di root
far parte del gruppo wheel
Perciò si devono richiedere più condizioni per
garantire un privilegio



Separazione dei compiti: in un’azienda chi scrive gli
assegni non deve firmarli
“Defense in depth”: mettere più ostacoli ad un eventuale
attaccante
Least Common Mechanism

I meccanismi di accesso alle risorse
dovrebbero essere condivisi il meno possibile



L’informazione può fluire attraverso i canali
condivisi
“Covert channels”
Isolamento


Virtual machines
Sandboxes
Accettabilità psicologica

I meccanismi di sicurezza non dovrebbero
rendere più difficile l’accesso alle risorse



Nascondere la complessità introdotta dai
meccanismi di sicurezza: chiarezza nei messaggi
errori
Facilità di installazione, configurazione e uso
I fattori umani sono critici in questo punto
Sicurezza nei sistemi operativi




Strumenti di protezione hardware
Controllo di accesso a file
Progettazione di S.O. fidati
Esempi di implementazione
Sistema operativo


La sicurezza in un sistema operativo è
essenziale in quanto il software applicativo
agisce (quasi) esclusivamente “sul” sistema
operativo
Ogni falla del sistema operativo è quindi
estremamente grave e può portare a danni
molto maggiori di falle nei programmi
applicativi
Protezione degli oggetti


I maggiori problemi di sicurezza nei sistemi operativi
sono dati (oltre che dalla rete) dalla
multiprogrammazione
Gli oggetti che devono essere protetti sono





memoria
dispositivi condivisibili, come i dischi o le stampanti
programmi e procedure condivisi
rete
dati
Separazione

L’idea di base della sicurezza è tenere separati
gli oggetti di ogni utente





separazione fisica
separazione temporale
separazione logica
separazione crittografica
Questo ordine è crescente in complessità e per
i primi tre decrescente in sicurezza
Condivisione



Non è possibile separare solamente
Gli utenti devono poter condividere alcune
risorse
Il sistema operativo può a tal scopo





Non proteggere le risorse
Isolare i processi
Gestire oggetti pubblici e privati
Gestire le capabilities
Limitare l’uso degli oggetti
Protezione della memoria




Sistemi “fence”: ogni processo ha una zona di
memoria definita dal valore del registro base B
e del registro limite L
In tal modo il processo può accedere solo alle
locazioni comprese tra B e B+L
Ad ogni cambio di contesto B e L devono
essere caricati con i valori relativi al processo
corrente
Si può anche separare zona codice e zona dati
Protezione della memoria



Architettura tagged: ogni locazione di
memoria (o gruppi di locazione) ha uno o più
bit di protezione che indicano i diritti di
accesso
Segmentazione: la memoria è gestita a
segmenti
Ogni segmento ha un indirizzo iniziale e una
lunghezza e viene assegnato ad un processo
Protezione della memoria




Il S.O. mantiene una tabella dei segmenti
Gli indirizzi logici che un programma può
usare sono nella forma <numero segmento,
offset>
L’indirizzo logico viene convertito in indirizzo
fisico aggiungendo all’offset l’indirizzo base
del segmento
Ogni accesso alla memoria è filtrato (hardware
e S.O.)
Protezione della memoria




Ogni segmento può avere una certa classe di
protezione (sola lettura, sola esecuzione, ...)
Paginazione: la memoria è suddivisa in pagine
fisiche della stessa grandezza
Lo spazio accessibile ad un programma è
suddiviso a sua volta in pagine logiche
Ogni pagina logica corrisponde ad una pagina
fisica (se non c’è la memoria virtuale)
Protezione della memoria




Il S.O. mantiene una tabella di corrispondenza
tra pagine logiche e pagine fisiche
Un indirizzo logico è una coppia
<numero_pagina, offset> e viene tradotto in un
indirizzo fisico
Non è semplice associare i diritti sulle pagine
E’ possibile però combinare paginazione e
segmentazione
Controllo di accesso
ad oggetti generali

Scopi della protezione



controllare ogni accesso: si può revocare un diritto
mentre l’utente ha già fatto un accesso
garantire il principio del minimo privilegio
verificare gli usi accettabili di un oggetto
Directory



Creare una sorta di directory per oggetti
generali per ogni utente del sistema
Nella directory dell’utente s si indica per ogni
oggetto o quali operazioni s può fare su o
Problemi



liste molto grandi se ci sonooggetti condivisi da
tutti
revoche di diritti a cascata
pseudonimi
Liste di controllo degli accessi


Ogni oggetto ha una lista di controllo (ACL)
che indica per ogni (o per qualche) utente quali
diritti possiede su tale oggetto
E’ possibile indicare i diritti di default (che
sono validi per tutti gli utenti non specificati
direttamenti)
Forme elementari di protezione



Tutti/nessuno: differenza solo tra file pubblici
e file privati
Permesso al singolo: accesso mediante
password (o altri token)
Protezione orientata alle procedure: non si
possono eseguire accessi arbitrari agli oggetti,
ma vi si può accedere solo mediante procedure
“esposte” (simile alla OOP)
Protezione in UNIX

I file e le directory hanno 9 bit che indicano i
diritti r(ead), w(rite), (e)x(ecute) per





il possessore del file
gli utenti del gruppo associato al file
tutti gli altri utenti
I diritti sono concessi dal possessore (o dal
superuser) con chmod
E’ possibile cambiare proprietario/gruppo del
file con chown e chgrp
Protezione in Unix

I diritti per le directory vanno intesi




r: si può listare il contenuto della directory
w: si può modificare il contenuto della directory
(creando, cancellando e rinominando file o
directory)
x: si può entrare nella directory
E’ possibile proteggere anche i dispositivi di
I/O
Limiti del sistema di protezione


Il limite principale del modello di protezione
in Unix è che non si riesce ad assegnare più di
tre modi diversi di accesso
Anna non può stabilire che




lei può fare tutto sul file X
Barbara può solo leggere ed eseguirlo
Carla lo può solo eseguire
gli altri non possono accedervi
SETUID



In Unix è possibile che il processo di un utente
nell’eseguire un determinato file assuma
momentaneamente l’identità (e quindi i diritti)
del proprietario
Si distingue utente e gruppo di login rispetto a
utente e gruppo attuale
Tale possibilità è data attraverso il comando
setuid
ACL


In molti sistemi operativi il sistema operativo
affianca alla normale gestione degli accessi in
differenziata per il possessore e per il gruppo
associato al file, anche diritti ad hoc per singoli
utenti o gruppi
Possono essere anche presenti ulteriori tipi di
diritti, oltre ai semplici r,w,x
Capabilities




Una forma alternativa di gestire gli accessi è
quella della capabilities
Ogni utente può ricevere dei “ticket” che gli
permettono di svolgere certe operazioni su un
determinato oggetto
Il ticket deve essere non falsificabile
E’ possibile, avendone il diritto, trasferire e
propagare una capability ad altri utenti
Capabilities


Le capability devono essere memorizzati in
zone di memoria inaccessibili ai processi
utente e gestiti solo dal S.O.
Una capability può essere revocato

dopo la revoca il diritto non può essere più
esercitato dal possessore del ticket
Sistemi operativi fidati








Autenticazione degli utenti
Protezione della memoria
Controllo di accesso a file e dispositivi di I/O
Allocazione e controllo di accesso ad oggetti
Condivisione
Equità di servizio
Comunicazione e sincronizzazione
interprocesso
Protezione dei dati del S.O.
Caratteristiche





Autenticazione e identificazione degli utenti
Controllo obbligatorio e discrezionale
Protezione sul riutilizzo degli oggetti:
attenzione quando si riutilizza una risorsa,
potrebbe contenere dati di precedenti
esecuzioni
Completa mediazione
Percorso fidato: per evitare spoofing
Caratteristiche

Accountability e Audit




non è possibile loggare ogni istruzione
problema dell’ago nel pagliaio nel cercare tracce di
eventuali attacchi
una soluzione è la riduzione del log
Strumenti di scoperta delle intrusioni

si usano tecniche statistiche per rilevare possibili
intrusioni attraverso la presenza di comportamenti
anomali
Implementazioni

Esistono tre grandi categorie di S.O. fidati

i S.O. kernelizzati (kernelized)


i S.O. isolati


minimo privilegio e economia di meccanismo
estensione del minimo comun meccanismo
i S.O. a struttura ad anello

disegno aperto e mediazione completa
Kernelized Design




Il kernel (nucleo) è la parte del S.O. che
esegue le funzioni al livello più basso
Si usa un security kernel che si occupa di
garantire i meccanismi di sicurezza dell’intero
sistema
Tutti gli accessi ad oggetti protetti devono
passare attraverso il security kernel
E’ più semplice tracciare le operazioni,
modificare e verificare formalmente la
correttezza del security kernel
Monitor



Un primo modo per avere un S.O. kernelizzato
è usare i reference monitor
Controlla tutti gli accessi ad un oggetto
Deve essere



non manomettibile
sempre invocato
piccolo, per essere meglio analizzato e testato
Trusted Computing Base



Porzione del S.O. che rinforza le politiche di
sicurezza del S.O.
Differenza tra software TCB e non TCB
In TCB




attivazione processi
esecuzione di processi in domini diversi
protezione memoria
operazioni di I/O
Isolamento




Il miglior modo per costruire S.O. basati
sull’isolamento è la virtualizzazione
Si basa sull’emulazione, attraverso delle
macchine virtuali, delle risorse di un computer
Ha bisogno di aiuti anche hardware
E’ un’estensione del concetto di memoria
virtuale
Design a livelli




Costruire un S.O. a vari livelli
I livelli più interni sono quelli più fidati, sono
delegati a svolgere le operazioni più delicate
La struttura a livelli garantisce
l’incapsulamento, nascondendo e proteggendo
i dettagli
Inoltre si limitano i danni
Assurance

Verificare che il S.O. rispetta le politiche
desiderate controllando il modello, la
progettazione e l’implementazione
Vulnerabilità frequenti




Gestione dell’I/O: difficile da controllare, in
alcuni casi si scavalca il S.O.
Ambiguità nelle politiche di accesso:
conciliare isolamento e condivisione
Mediazione incompleta
Generalità: utilizzo di pacchetti di terze parti
che devono operare a livello di S.O.
Metodi di accertamento




Testing
“Penetration testing”
Verifica formale
Validazione
Valutazione



Orange Book USA
ITSEC Europa
Combined Federal Criteria USA