Matteo Tirelli Appunti del corso di SICUREZZA 2007/2008

Transcript

1 INDICE GENERALE LEZIONE 1: Introduzione alla sicurezza informatica...7 Complessità dei sistemi e rischi dal punto di vista della sicurezza: non composizionalità della sicurezza, della tolleranza ai guasti e delle prestazioni. 7 Le varie facce della medaglia: disponibilità, affidabilità, segretezza/riservatezza, integrità...8 Classificazione degli attacchi: worm e virus, denial of service, attacchi all'integrità, riservatezza e reputazione..10 Strategie di sicurezza: prevenzione, reazione (immediata) e rappresaglia...11 Misure di sicurezza: fisiche, software e organizzative...11 LEZIONE 2: Sicurezza a livello di sistema...12 Modello generale di controllo degli accessi: utenti, risorse e nucleo di sicurezza; sistemi aperti e chiusi...12 Matrice degli accessi, access list e capability list; sistemi aperti dinamici e politiche di default...13 Mediazione del nucleo mediante identificazione/autenticazione degli utenti e autorizzazione degli accessi...14 Principi di Denning...15 Ridondanza/economia di controllo...15 Minimo privilegio e cambio di contesto...15 Anello debole e stratificazione senza incapsulamento di macchine virtuali...16 LEZIONE 3: Controllo degli accessi...18 Modelli mandatori per garantire segretezza oppure integrità. Problema dei "canali coperti" (o nascosti). Accettabilità da parte degli utenti dei modelli mandatori...18 Modello discrezionale: esempio del file system Unix/Linux...19 proprietario del file, amministratore di sistema, e gli altri...19 privilegi di accesso a discrezione del proprietario (o di root)...20 privilegi non discrezionali...20 implementazione/approssimazione del principio di minimo privilegio e cambio di contesto: "su", "sudo", "set UID", "set GID" / 86

2 LEZIONE 4: Memoria sicura...22 Memoria RAM di un sistema di calcolo; come realizzare integrità, affidabilità e disponibilità a livello hardware e di nucleo del sistema operativo...24 Problemi di segretezza derivanti dalla condivisione della memoria: cancellazione/deallocazione lazy, garbage collection, caching...24 Cancellazione della memoria secondaria (dischi, flash)...24 Cancellazione a livello di file system e journaling...24 Cancellazione a livello applicativo (esempio del word processor)...24 LEZIONE 5: Sicurezza dei processi...25 Sicurezza dei processi...25 meccanismi hardware a supporto del confinamento dei processi da parte del processore: modi di esecuzione user/system, trap, memoria virtuale a segmentazione...26 Struttura del kernel del sistema operativo per l'esecuzione dei processi; punti deboli dal bootstrap fino all'attivazione dei processi utente...26 Processi "privilegiati" (con UID=0) e processi "normali" in Unix/Linux...27 Attacchi di tipo "Buffer Overflow" per far eseguire codice malizioso a processi privilegiati...28 LEZIONE 6: Firewall...30 Definizione di Firewall e possibili implementazioni a seconda dei requisiti:...30 licenza proprietaria o libera...30 sistema operativo...30 architettura hardware...30 costi economici...30 Flessibilità...30 situazione in cui ci si trova...30 Accenni agli application firewall...30 Accenno al ping e al filtering icmp...30 Filtering a livello 3 e Cosa può fare e cosa non può fare un firewall...31 LEZIONE 7 Introduzione alla Crittografia...32 Alice, Bob e Devil; luoghi fisicamente sicuri, canali di comunicazione soggetti ad attacchi; attacchi di tipo attivo e passivo ad integrità, segretezza, ecc...32 Tecniche semplici di cifratura: testo in chiaro, testo cifrato, sostituzione di caratteri, permutazione di caratteri, chiave di cifratura...33 Sicurezza computazionale e sicurezza incondizionata...34 Idea di cripto-analisi ed effetto della ridondanza del testo in chiaro / 86

3 LEZIONE 8 Sicurezza di rete...37 Uso e abuso della rete wireless da parte degli utenti telelavoratori (tratto da punto informatico)...37 Esempi di phishing del sito ebay e di paypal. Uso del software wireshark per l'intercettazione del traffico TCP/IP e la ricostruzione delle sessioni...37 Firewall: politiche di default permit e default deny...37 LEZIONE 9 Principi della Crittografia moderna...38 Sicurezza incondizionata, cifrario di Vernam (One Time Pad) e problemi pratici legati alla lunghezza della chiave...38 Necessità di cifrari basati su chiave di lunghezza predeterminata. Principi di Shannon...39 Confusione: modifica di un solo bit di chiave cambia ogni bit del codice cifrato con probabilità ½...39 Diffusione: modifica di un solo bit del messaggio in chiaro cambia ogni bit del codice cifrato con probabilità ½...40 Codici di tipo Stream o a Blocchi (necessità di padding)...40 Modi di uso dei codici a blocchi: Electronic Codebook (ECB) oppure Cipher Block Chaining (CBC)...41 LEZIONE 10 Virus...43 Definizione di virus...43 Storia dei Virus (Darwin, Pervade, Elk Cloner, Definizione di Cohen, Brain, Virdem)...43 Meccanismi di infezione: file eseguibili (companion, overwriting, prepending, appending, boot sector[michelangelo]), macro virus (Melissa, Laroux, tristate e mutazioni involontarie), multipartite virus (Navrhar), Scripting virus, Source Code Virus...43 Meccanismi di propagazione: periferiche rimuovibili, , download (Melissa), directory condivise...43 Difese: antivirus (aggiornamenti, signature e anomaly detection, verifica integrità), configuration hardening (POLP etc.), educazione utenti...43 LEZIONE 11 Cifratura e chiavi condivise...44 Esempio di algoritmo di cifratura DES...44 Apertura/Segretezza degli algoritmi...45 Crittografia forte e debole...45 Brevetti...45 Problema del Logaritmo Discreto e protocollo Diffie-Hellman...46 LEZIONE 12 WORM / 86

4 LEZIONE 13 Diffie-Hellman e RSA...49 Attacchi attivi (man-in-the-middle) al protocollo Diffie-Hellman...49 Introduzione ai sistemi a chiave asimmetrica...50 Crittosistema RSA (Rivest, Shamir, Adleman)...51 idea di cifratura e decifratura con due chiavi diverse...51 le formule di cifratura, decifratura e calcolo delle due chiavi...51 uso per firmare documenti integri/autentici...52 uso per cifrare documenti segreti...52 caratteristiche di sicurezza del crittosistema...52 confronto coi crittosistemi a chiave simmetrica...53 LEZIONE 14 Prof. Aiello, in preparazione LEZIONE 15 Funzioni Hash Crittografiche...55 Tabelle Hash e e Funzioni Hash Perfette...55 Ridondanza dei documenti...56 Paradosso del Compleanno...57 Realizzazione di Funzioni Hash Crittografiche...58 LEZIONE 16 Applicazioni delle Funzioni Hash...59 Verifica di Integrità dei documenti...59 Firma Digitale...60 Autorità di certificazione e Certificati...61 Certificati Digitali X509.V LEZIONE 17 Altre applicazioni delle Funzioni Hash...64 Il gioco del "pari o dispari" O testa e croce via rete...65 "cifratura" delle password...65 One-time Password...67 LEZIONE 18 Firewall...68 Consigli pratici per l'implementazione di un firewall...68 Firewall UTM e classici (layer 3-4)...68 Esempi di firewall commerciali...68 Iptables su Linux...68 Logging...68 Firewall stateful e non / 86

5 LEZIONE 19 Meccanismi di Autenticazione e Certificati Digitali...69 Cosa sa l'utente? Login e Password...69 Cosa possiede l'utente? Chiavi di cifratura, schede magnetiche, smart-card...70 Com'è fatto l'utente? Metodi biometrici...70 Ancora firme digitali e certificati: verifica on-line e off-line...71 Marche temporali e validità nel tempo della firma digitale...73 LEZIONE 20 Intrusion Detection...74 Host Intrusion Detection e Network Intrusion Detection...74 ESEMPI DI DUMP TRAFFICO INTERNET E ANALISI DI TRAFFICO NORMALE75 Differenze tra anomaly e misuse detection...76 Port scanning (FIN scan, half connect scan, ACK scan)...76 Three-way handshake...78 OS Fingerprinting...78 LEZIONE 21 Steganografia e Watermarking...79 Idea generale di Steganografia: contenitore e contenuto; ridondanza...79 Contenitori testuali...79 Contenitori audio (tecnica del bit meno significativo)...80 Contenitori immagini (pixmap e formati compressi)...80 Le strutture dati non canoniche come contenitore...80 Cenni alle differenze tra Steganografia e Watermarking...81 LEZIONE 22 Attacchi in rete...82 IP fragmentation allo scopo di effettuare firewall bypassing...82 Man-in-the-Middle...82 Attacco di Mitnick (ip spoofing alla cieca)...82 ARP Cache Poisoning...82 LEZIONE 23 Sniffing...83 NIC in modalità promiscua...83 sniffing detection su host...84 sniffing detection via rete...84 risposta a stimoli...84 test di latenza al variare del traffico di rete...85 DNS query (reverse lookup)...85 anti-anti sniffing...86 Ethernet bus, hub e switch: sniffing su switch / 86

6 6 / 86

7 LEZIONE 1: INTRODUZIONE ALLA SICUREZZA INFORMATICA COMPLESSITÀ DEI SISTEMI E RISCHI DAL PUNTO DI VISTA DELLA SICUREZZA: NON COMPOSIZIONALITÀ DELLA SICUREZZA, DELLA TOLLERANZA AI GUASTI E DELLE PRESTAZIONI Per considerare un sistema sicuro bisogna considerare l'unione di tre componenti: Hardware, Software e Utenti. Il corretto funzionamento non e' quindi legato ad una singola componente, ma a tutte e tre. Per realizzare un sistema sicuro occorre quindi analizzare e capire quali sono i punti deboli di ognuna delle singole componenti. I sistemi sono estremamente complessi, tuttavia la complessità e' uno dei maggiori nemici della sicurezza. Il metodo comune per rendere sicuro un sistema e' quello di partire da un sistema completamente insicuro ed aggiungere software, tuttavia questo non fa altro che aumentare la complessità del sistema, e come abbiamo detto precedentemente questo e' un problema. L'approccio da seguire e' invece esattamente l'opposto, ovvero ridurre al minimo le funzionalità del sistema. Tuttavia questo è un approccio di tipo ideale e difficilmente perseguibile soprattutto in sistemi di tipo general porpouse. CAUSE DELLA COMPLESSITA': L'uso del layering L'uso delle componenti (intese come porzioni distinte di sistema ognuna delle quali caratterizzata da minor complessità rispetto al sistema nella sua interezza).... L'uso di componenti ci porta tuttavia a dover introdurre il concetto di composizionalità: nello sviluppo di una componente infatti è necessario tener conto di tutte le possibili interazioni con altre componenti. Questo tuttavia non è possibile. Si possono prevedere innumerevoli situazioni e combinazioni, ma esisterà sempre un caso non previsto. La sicurezza, le elevate prestazioni e la fault tollerance sono proprietà che non possono essere garantite nel momento in cui più componenti vengono composte/integrate, nemmeno se tutte le singole componenti prese in isolamento godono di tali proprietà. In conclusione possiamo quindi dire che la sicurezza NON gode della proprietà di composizionalità 7 / 86

8 LE VARIE FACCE DELLA MEDAGLIA: DISPONIBILITÀ, AFFIDABILITÀ, SEGRETEZZA/RISERVATEZZA, INTEGRITÀ Sicurezza è un termine vago. Per definirla dobbiamo considerare le seguenti caratteristiche: DISPONIBILITA' ( di un sistema, di un apparato dati,... ). Dobbiamo garantire che il sistema risponda immediatamente alle interrogazioni e permetta quindi di ottenere i dati o i servizi richiesti nel momento in cui vengono richiesti. Si può avere mancanza di disponibilità per diversi motivi, quali la rete momentaneamente in down, la macchina spenta, il DB server down, ecc... La disponibilità è una caratteristica che viene normalmente valutata a livello temporale (tempo di disponibilità / uptime) Ci sono chiaramente casi in cui la disponibilità non è una caratteristica essenziale. INTEGRITA': Dobbiamo garantire che i dati memorizzati non vengano alterati o corrotti. Quali sono le cause della corruzione dei dati? L'utilizzatore dei dati commette degli errori Un attacco volontario esterno Un guasto del dispositivo di memorizzazione L'integrità è estremamente importante ad esempio in applicazioni quali un database contenente dati importanti. Invece in casi come le comunicazioni in VOIP l'integrità non è una caratteristica essenziale, poiché la perdita di alcuni bit durante una conversazione è trascurabile e si può quindi sacrificarla dedicando maggiore attenzione in favore di altre caratteristiche. PRIVATEZZA: Dobbiamo garantire che i dati memorizzati rimangano riservati. Ad esempio voglio che dati personali che ho scritto io rimangano accessibili solo a me. La privatezza è una caratteristica essenziale ovunque ci siano dati sensibili e/o riservati. AFFIDABILITA': E' una caratteristica strettamente imparentata con la disponibilità. La differenza tra affidabilità e disponibilità consiste nell'arco di tempo che consideriamo. In questo caso non desideriamo avere un accesso immediato alle funzionalità offerte dal sistema, ma vogliamo che sia possibile prima o poi accedervi. Dobbiamo quindi garantire che prima o poi il sistema risponda. La sicurezza è una qualunque combinazione delle quattro caratteristiche precedenti. La distribuzione delle singole caratteristiche all'interno di tale combinazione dipende dallo scopo per il quale il sistema viene predisposto. 8 / 86

9 Bisogna quindi chiedersi sempre come prima cosa quali sono le caratteristiche che è necessario garantire e successivamente determinare a quali invece si è disposti a rinunciare (o tenere in minor considerazione). Questo perché alcune caratteristiche sono conflittuali tra loro. es. Privatezza Disponibilità Per ottenere disponibilità dovrei introdurre un sistema di ridondanza, ma questo provoca un aumento del flusso di dati sulla rete. Questo tuttavia favorisce l'intercettabilità delle comunicazioni e quindi riduce la privatezza dei dati E' necessario quindi stabilire sempre un ordine di importanza delle caratteristiche (una gerarchia che si adatti alle esigenze del sistema che stiamo sviluppando) Un punto di partenza è la CORRETTEZZA della realizzazione, seguendo delle specifiche che prendano in considerazione gli aspetti di sicurezza. I bug infatti possono avere effetti negativi sulla sicurezza. Tuttavia la correttezza da sola non è sufficiente. Un altro aspetto importante è la ROBUSTEZZA. Un sistema robusto è un sistema che in qualunque situazione (prevista e / o imprevista) fa quello che deve. La robustezza è necessaria poiché dobbiamo sempre assumere di essere immersi in un ambiente ostile Per ambiente ostile si intende un ambiente soggetto a guasti, danni involontari, attacchi deliberati, ecc... La robustezza è estremamente correlata alla fault tollerance: quando avviene un guasto dobbiamo sempre chiederci quali possono essere gli effetti del guasto sulla sicurezza del sistema perdo la disponibilità es. rottura di un disco: conservo la privatezza dei dati conservo l'affidabilità solo se ho i backup posso allora introdurre ridondanza: sia fisica che software fisica: posizionando le macchine in ambienti differenti, con impianti elettrici e contatori separati, ecc... software: utilizzo parallelamente sistemi differenti, sviluppati da team distinti. In questo modo le probabilità che i due team abbiano introdotto lo stesso bug si riducono notevolmente 9 / 86

10 CLASSIFICAZIONE DEGLI ATTACCHI: WORM E VIRUS, DENIAL OF SERVICE, ATTACCHI ALL'INTEGRITÀ, RISERVATEZZA E REPUTAZIONE Non pensiamo tanto ai guasti quanto ad azione e attacchi deliberati. Inizialmente i sistemi operativi ed i protocolli di comunicazione sono stati sviluppati e progettati senza considerare la possibilità di attacchi. 1988: Worm di Morris (primo attacco) Morris prese un'idea (pubblicata nell'82) di calcolo distribuito che prevedeva l'utilizzo della cpu di altre macchine, senza alcun intervento da parte dell'operatore, nel momento in cui la cpu della macchina su cui era stato lanciato il processo originale era satura. L'attacco di Morris ha di fatto sfruttato una leggerezza dei protocolli di rete. Il suo worm saturava i processi eseguiti in remoto per potersi così diffondere a cascata su altre macchine. I Worm: I virus e i trojan: hanno un comportamento di tipo attivo e si diffondono autonomamente invece hanno bisogno dell'intervento di un utente sprovveduto o abilmente ingannato. Attacchi DoS Denial of Service: l'obbiettivo di un attacco DoS è quello di monopolizzare le risorse di un sistema in modo che questi diventi indisponibile agli utenti legittimi Attacchi all'integrità: Attacchi alla privatezza dei dati: Attacchi alla reputazione: l'attaccante modifica deliberatamente i dati o le applicazioni di un sistema (ad esempio per violare l'accesso e poter accedere al sistema senza credenziali, o per spiare) l'attaccante sfrutta debolezze del sistema o bug per accedere a dati riservati ad es. un defacement del sito di un'azienda rivale per sminuirne la reputazione 10 / 86

11 STRATEGIE DI SICUREZZA: PREVENZIONE, REAZIONE (IMMEDIATA) E RAPPRESAGLIA PREVENZIONE: progettare un sistema robusto REAZIONE IMMEDIATA: è necessaria l'osservazione continua del sistema per capire se si è sotto attacco. La reazione dipende ovviamente dalla tipologia di attacco al quale siamo sottoposti: nel caso di un DoS potremmo iniziare a scartare pacchetti per uscire dalla situazione di DoS nel caso di un worm dovremmo interrompere il processo, cancellarne i file e ripulire il sistema RAPPRESAGLIE: l'attacco è stato ormai subito allora indago su chi è stato e... o gli mando la polizia postale o gli restituisco il favore la minaccia di una rappresaglia talvolta può essere un'ottima misura di prevenzione raccolta informazioni, non in tempo reale. L'analisi dei log è più approfondita rispetto a quella utilizzata durante la reazione immediata (dove l'analisi è più superficiale), ma è costante MISURE DI SICUREZZA: FISICHE, SOFTWARE E ORGANIZZATIVE Dal punto di vista operativo invece dobbiamo considerare le misure di sicurezza su tre distinti livelli di egual importanza: Fisico: ad esempio un pc posizionato in una stanza chiusa, la cui chiave è affidata a persone fidate ed autorizzate all'uso della macchina Software: difese di tipo logico, ad esempio un firewall Organizzativo: implica il coinvolgimento, l'informazione e l'addestramento degli utenti che interagiscono con il sistema Occorre ricordare che un attaccante non cercherà mai di violare il livello più difficile, ma sceglierò sempre quello più facilmente violabile. E' quindi opportuno suddividere le risorse economiche destinate alla messa in sicurezza di un servizio/sistema in maniera quanto più possibile paritetica rendendo in egual misura sicuri i tre livelli. Se noi ci limitassimo a proteggere un sistema tramite firewall e lasciassimo la macchina che lo ospita liberamente accessibile e posizionata in un ambiente ostile il firewall potrebbe essere inutile. Eviterebbe attacchi remoti ma non garantirebbe alcuna protezione da attacchi diretti (anche solo ad un DoS perpetrato spegnendo la macchina) 11 / 86

12 LEZIONE 2: SICUREZZA A LIVELLO DI SISTEMA MODELLO GENERALE DI CONTROLLO DEGLI ACCESSI: UTENTI, RISORSE E NUCLEO DI SICUREZZA; SISTEMI APERTI E CHIUSI Abbiamo delle risorse di tipo hardware e software e degli utenti (persone / processi) che le vogliono utilizzare. Come dobbiamo allora organizzare il sistema? Dobbiamo impedire quindi l'accesso diretto alle risorse. Per fare questo, interponiamo una barriera detta nucleo di sicurezza (kernel) che faccia da mediatore tra gli utenti e le risorse. Potremmo però avere alcuni problemi utilizzando questa tecnica: problemi di efficienza (rapidità dei tempi di risposta): si aggiunge latenza nel passaggio attraverso il kernel (e sono necessarie ulteriori risorse per la gestione del kernel) garantire accessi contemporanei da parte di più utenti alla medesima risorsa quanti utenti possiamo gestire? quante risorse possiamo gestire? risorse e utenti possono variare di volta in volta o devono essere predeterminati? Un sistema aperto permette la variazione nel tempo della quantità di utenti e risorse, viceversa un sistema che non offra queste possibilità è detto sistema chiuso. L'introduzione di un sistema di controllo in grado di mediare tra utenti e risorse porta ad avere una centralizzazione. Un approccio differente è invece quello di isolare ogni utente ed ogni risorsa in modo tale da garantire che non possano esserci interferenze tra utenti e risorse. Lo scopo del kernel diventa quindi quello di discriminare quello che è lecito da quello che non lo è. Una soluzione perseguibile potrebbe essere quella di predisporre una matrice di accesso dove vengono memorizzati per ogni utente i diritti di accesso in rapporto ad ogni risorsa. 12 / 86

13 Problema: chi definisce questa matrice? Bisogna innanzitutto considerare che le operazioni su una singola risorsa non sono semplicemente liquidabili con un si/no, ma occorre specificare i permessi per ogni operazione possibile. A seconda del tipo di risorsa infatti potrei avere da una ad n modalità di accesso. In un sistema chiuso, avendo una conoscenza pregressa di tutti gli utenti autorizzati su quel sistema e di tutte le risorse in esso disponibili, questa matrice è definita una volta per tutte. Valutare quindi se un utente può accedere in una data modalità ad una data risorsa significa semplicemente consultare tale matrice. MATRICE DEGLI ACCESSI, ACCESS LIST E CAPABILITY LIST; SISTEMI APERTI DINAMICI E POLITICHE DI DEFAULT In un sistema aperto invece la matrice è soggetta a continui cambiamenti; ho quindi due possibili alternative su cui operare: pensare alle colonne. In questo modo determino per ogni risorsa quali operazioni ogni utente può compiere su tale risorsa. Definisco quindi una lista di accesso (access list) che indica chi può accedere. Se aggiungo una nuova risorsa dovrò espandere la matrice aggiungendo una colonna caratterizzata da una nuova access list. pensare alle righe focalizzando il ragionamento sugli utenti. Questa modalità è detta capability list. Per ogni utente definisco quindi quali risorse egli può utilizzare. Problemi della gestione dinamica: Gli utenti e le risorse possono cambiare frequentemente, quindi i valori delle matrici devono essere costantemente aggiornati. A tale proposito introduco allora il concetto di default che indica il permesso di accesso 13 / 86

14 predefinito. Si può quindi parlare di: default grant: se nella matrice non ho indicazioni specifiche allora acconsento l'accesso alla risorsa. Default deny: se nella matrice non ho indicazioni specifiche allora nego l'accesso alla risorsa. Quale politica è più sicura? La risposta a questa domanda dipende dal tipo di sicurezza che è di primaria importanza per il sistema: integrità: DENY privacy: DENY affidabilità: GRANT Che cosa scegliere invece tra access list e capability list? Dipende da che cosa valuto possa cambiare con maggior frequenza. Se penso di variare frequentemente le risorse utilizzerò le access list, in caso contrario le capability list. Ad ogni modo devo sempre far uso delle politiche di default quando varia il parametro opposto a quello fissato. MEDIAZIONE DEL NUCLEO MEDIANTE IDENTIFICAZIONE/AUTENTICAZIONE DEGLI UTENTI E AUTORIZZAZIONE DEGLI ACCESSI Consideriamo le risorse come entità passive e gli utenti come entità attive. Il Kernel diventa così scomponibile in 2 fasi: identificazione mediante accesso alla matrice, access list, capability list: si cerca nella struttura dati scelta la posizione indicizzata da processo e risorsa autorizzazione: si legge il permesso e si concede / nega l'operazione Cosa può rendere più o meno sicuro il controllo degli accessi? Devo essere sicuro di aver identificato correttamente l'utente Devo essere sicuro che l'utente esegua solo le operazioni per cui è stato autorizzato 14 / 86

15 PRINCIPI DI DENNING Si tratta di una lista di preoccupazioni da tenere a mente durante la realizzazione di un sistema sicuro. RIDONDANZA/ECONOMIA DI CONTROLLO E' necessario trovare un compromesso ragionevole tra economia di controllo e ridondanza. La ridondanza di controllo dovrebbe contribuire a garantire la robustezza del kernel. Implica quindi il dover passare attraverso una sequenza di controlli e non uno solo prima di poter acconsentire l'accesso ad una risorsa. In pratica devo assumere sempre che il kernel possa fallire, quindi eseguendo molteplici controlli e verificando che tutti i risultati siano coerenti posso avere maggiori garanzie. Se uno dei controlli della sequenza dovesse fallire allora verrebbe negato l'accesso alla risorsa. Ciononostante se non avessimo introdotto ulteriori controlli ed il kernel avesse risposto positivamente al primo ed unico controllo, l'utente avrebbe avuto accesso alla risorsa. Quindi la ridondanza di controllo ha aumentato la complessità del kernel ed ha conseguentemente ridotto la robustezza. Il principio di economia di controllo invece mi dice che il tempo destinato a sviluppare controlli equivalenti se fosse destinato a sviluppare un singolo controllo renderebbe quest'ultimo più solido e sicuro. Entrambi i ragionamenti sono convincenti, per questa ragione il principio richiede di valutare un giusto compromesso. Per quanto riguarda l'efficienza è meglio basarsi sul principio di economia. Per la fault-tollerance la ridondanza aiuta, tuttavia la probabilità che su molteplici controlli uno si guasti è maggiore della probabilità di guasto di un singolo controllo. Per quanto riguarda invece l'accettazione da parte degli utenti e l'usabilità di un sistema sarebbe preferibile la presenza del minor numero di controlli possibili. MINIMO PRIVILEGIO E CAMBIO DI CONTESTO Il concetto di minimo privilegio è strettamente legato all'attribuzione dei permessi nelle matrici di controllo. Il concetto base è quello di concedere il livello minore possibile di privilegio necessario affinché l'utente possa portare a termine i propri compiti. 15 / 86

16 Minimo privilegio : dare lo stretto necessario numero di privilegi ad ogni utente Scrittura : un ridotto numero di permessi preserva l'integrità Lettura : un ridotto numero di permessi preserva la privatezza Questo comporta l'applicazione di una politica di tipo default deny. Tuttavia nel momento in cui varia l'esigenza di un utente dovrei aggiornare i permessi assegnati ad esso. Per questa ragione adotto il meccanismo del cambio di contesto. In questo modo ho una gestione dinamica delle risorse. Non associo le modalità di accesso in modo statico ad ogni utente, ma solo quando l'utente ne ha una reale necessità di utilizzo. In pratica viene concesso l'uso della risorsa solo quando serve, al termine del suo utilizzo il permesso viene revocato. Come posso passare da un contesto ad un altro? Deve esistere una fase di negoziazione delle risorse. Ogni sessione di utilizzo delle risorse deve essere quanto più possibile limitata nel tempo. Tuttavia occorre fare alcune considerazioni: se le sessioni fossero troppo corte un utente impiegherebbe più tempo a negoziare le risorse piuttosto che ad utilizzarle effettivamente. se le sessioni fossero invece lunghe il minimo privilegio legato ad un utente rischierebbe di essere un po' troppo esteso. Bisogna quindi trovare il giusto compromesso: sessioni quindi brevi, ma non troppo. ANELLO DEBOLE E STRATIFICAZIONE SENZA INCAPSULAMENTO DI MACCHINE VIRTUALI Devo organizzare le risorse e garantirne sicurezza in maniera equa. Ogni componente deve essere sicura quanto le altre componenti che costituiscono il sistema. E' necessario quindi bilanciare lo sforzo dedicato ad ogni componente del sistema per evitare componenti deboli che compromettono la sicurezza totale. 16 / 86

17 In un sistema incapsulato se lo strato esterno è sicuro allora l'intero sistema è sicuro. Un attacco infatti potrebbe essere diretto solo al livello più esterno del sistema. In sistemi a strati invece è spesso possibile accedere direttamente agli strati inferiori. Ne consegue quindi che è necessario proteggere tutti gli strati. Esempi: Anche se rendessi un sistema sicurissimo, ma lo lasciassi privo di password di bios la sicurezza implementata potrebbe risultare inutile. Se si realizza un nuovo protocollo di comunicazione sicuro, ma lo si estende in modo da essere retro compatibile, questi sarebbe soggetto a tutte le vulnerabilità precedenti. 17 / 86

18 LEZIONE 3: CONTROLLO DEGLI ACCESSI MODELLI MANDATORI PER GARANTIRE SEGRETEZZA OPPURE INTEGRITÀ. PROBLEMA DEI "CANALI COPERTI" (O NASCOSTI). ACCETTABILITÀ DA PARTE DEGLI UTENTI DEI MODELLI MANDATORI Si distinguono due modelli : mandatorio e discrezionale. Mandatorio : L'uso delle risorse viene codificato da un'entità superiore in modo da dare garanzie dal punto di vista della sicurezza. Consideriamo due aspetti principali: Privatezza : Definiamo delle classi di segretezza organizzate gerarchicamente ( Esempio Top Secret > Riservato > Pubblico ). Usiamo quindi queste classi per classificare utenti e risorse in modo da poter discriminare gli accessi per appartenenza. Nc = non classificata,generica. Per la lettura gli utenti possono accedere anche alle classi inferiori ma in scrittura gli utenti non possono accedere a risorse di classe inferiore ( Altrimenti un processo top secret potrebbe scrivere su file pubblici!! ). Questo si spiega semplicemente perchè in questo momento ci stiamo occupando del fattore privatezza e non di quello dell'integrità. Per cui per la privatezza dei dati è perfettamente legittimo per un processo qualsiasi scrivere su una risorsa top secret. Come vedremo in seguito, i due modelli non possono essere applicati in maniera concorrente poiché sono mutualmente esclusivi. E' necessario individuare quale requisito sia considerato più importante e scegliere il modello opportuno. Integrità : Classifichiamo risorse e utenti in due modi possibili (Integre Non integre) a seconda della (non) affidabilità che si attribuisce alla risorsa e all'utente. 18 / 86

19 Privatezza Problema : Anche se assicuriamo la privatezza dei dati e l'impossibilità di comunicazione di un processo top secret con processi di classe inferiore, non è detto che non si possa riuscire a trasmettere dati sensibili fuori controllo. Immaginiamo un processo top secret e un processo pubblico con una risorsa condivisa. Anche se il modello della privatezza impedisce la trasmissione di dati sensibili verso il processo pubblico, il processo top secret può codificare informazioni attraverso fenomeni esterni ( Ad esempio la latenza delle operazioni fattore influenzabile dal processo top secret e rilevabile dal processo pubblico ) MODELLO DISCREZIONALE: ESEMPIO DEL FILE SYSTEM UNIX/LINUX Discrezionale : Il controllo viene delegato agli utenti ( Ed è bene tenere in mente che gli utenti non amano negarsi le risorse --> classi di utenti in conflitto ) Un esempio di modello discrezionale è il filesystem Unix : Discriminiamo innanzitutto un utente in particolare : il proprietario del file ( Di default viene impostato l'id utente del processo che genera il file ). Questa situazione tuttavia si presta poco a una gestione più raffinata dei permessi. Consideriamo anche il gruppo : un insieme di utenti che condividono gli stessi permessi. Assegnami quindi i permessi (Read,Write,Execute,Set) per utente,gruppo e tutti gli altri Un file quindi conterrà un bit vector per user,group e other per i permessi e due campi per l'uid ( User Indentifier ) e il Gid ( Group Identifier ). Sia il proprietario che l'amministratore del sistema possono variare i permessi di accesso come pure l'owner o il group del file. Tuttavia perchè tenere bit per i permessi dell'owner dato che questi può modificarli a piacere? Avere bit in più è indubbiamente uno spreco, ma assicura il minimo privilegio unito al cambio di contesto (Vd Lez.2). Permette infatti di mantenere i permessi al minimo e di variarli solo nel momento in cui richiede una risorsa ( resettandoli dopo l'uso ). PROPRIETARIO DEL FILE, AMMINISTRATORE DI SISTEMA, E GLI ALTRI Fase di Autenticazione delle risorse Si confronta l'uid del processo con l'uid dell'owner nel file. Se corrispondono si applicano i permessi registrati per l'owner. Se non c'è corrispondenza si cerca di verificare il gruppo: si confronta il Gid indicizzato nel file passwd dal Uid del processo e lo si confronta con il Gid registrato nel file. Si controlla quindi il file dei gruppi nella posizione indicizzata dal Gid del file e si guarda se nella lista degli utenti appartenenti al gruppo c'è corrispondenza con l'uid del processo. Se una di queste due verifiche ha successo si assegnano i permessi del gruppo registrati nel file. Se le verifiche dell'owner e del gruppo falliscono allora si assegnano i permessi registrati per tutti gli altri. 19 / 86

20 PRIVILEGI DI ACCESSO A DISCREZIONE DEL PROPRIETARIO (O DI ROOT) PRIVILEGI NON DISCREZIONALI Minimo privilegio e cambio di contesto Per il principio del minimo privilegio si assegnano permessi minimi agli utenti e quando c'è la necessità di usare una risorsa si scatena un cambio di contesto per l'utente atto a garantirgli i privilegi necessari ( E non più di questi ) riportando i privilegi allo stato originale non appena termina l'utilizzo della risorsa da parte del processo. E' necessario poter effettuare questa operazione senza dover passare per l'amministratore di sistema altrimenti è molto facile che al processo vengano assegnate tutte le risorse disponibili per evitare lunghe fasi di negoziazione ( Vedere Sessioni Lunghe/Corte e relative conseguenze Lez. 2 ). A questo scopo in ambiente unix esistono due strumenti a disposizione dell'utente: su e sudo Su : Apre una nuova sessione con privilegi da amministratore di sistema in cui l'utente può eseguire i propri programmi. Autentica l'utente attraverso la password del super user. Poiché i privilegi durano per la durata della sessione che dipende solo dalla volontà dell'utente questa scelta risulta più delicata di sudo. Inoltre non permette di raffinare la concessione dei permessi: l'utente li riceve direttamente tutti. Sudo : Esegue un comando con privilegi da amministratore, dopodiché l'utente è di nuovo nel suo contesto. Sudo autentica usando la password dell'utente, così da non dover rivelare quella del super user. Questa autenticazione ha due significati: in primo luogo ricorda all'utente (e lo avverte dei possibili rischi ) che sta per eseguire un'azione in un contesto tale da poter fare danni; in secondo luogo per confermate l'identità e la presenza dello stesso utente per la sessione. Sudo permette una gestione più raffinata dei permessi poiché è possibile definire quali 20 / 86