I termini sicurezza, protezione e privacy, hanno sovente più di un significato il più delle volte sconosciuto anche agli "esperti" del settore. Volendo dare una definizione funzionale di sicurezza, si potrebbe dire che: un computer è sicuro se esso stesso ed il suo software si comportano come ci si aspetta. Se ci aspettiamo che i dati inseriti nella nostra macchina oggi vi rimangano per diverse settimane senza essere letti da persone non autorizzate, allora la nostra macchina è sicura. Il concetto qui enucleato è quello della fiducia o trust: ci fidiamo di un sistema che preserva e protegge i nostri dati. Ma da chi o cosa dovremo proteggerli? Il problema non è di semplice soluzione. Molte sono le cause che possono mettere a repentaglio i dati memorizzati su di un computer: utenti non autorizzati, impiegati vendicativi, virus o disastri naturali, ma tutti sono ugualmente pericolosi. I problemi nascono quando più persone possono accedere ad un computer in ambienti che consentano la condivisione delle risorse (reti di computer: LAN, MAN, WAN). In questi casi infatti ad ogni utente deve essere garantita la protezione e la privacy delle proprie informazioni. Se il sistema è poi collegato con l'esterno (Internet ad esempio), la sicurezza diventa un dovere.
Nel cuore di ogni computer c'è un insieme di programmi che viene chiamato Sistema Operativo (SO). Questo software controlla i sistemi di input/output di un calcolatore come la tastiera e i dischi e carica ed esegue gli altri programmi (Word processor, fogli di calcolo, giochi etc). Il sistema operativo è anche un insieme di meccanismi e politiche che aiuta a controllare la condivisione delle risorse del sistema. Questi è corredato da una serie di strumenti (tools) che consentono, ad esempio, di copiare file ed elencare il contenuto delle directory. Sebbene questi programmi non fanno parte tecnicamente del sistema operativo, hanno un drammatico impatto sulla sicurezza del sistema.
Data l'importanza strategica di un sistema operativo nell'amministrare praticamente la "ferraglia" di cui è composto un computer, è auspicabile che vi siano tutta una serie di requisiti da soddisfare per poter essere considerato sicuro. Una prima guida nella progettazione di un sistema sicuro, fu elaborata da Saltzer e Schroeder basata sulla loro esperienza con MULTICS (vedi Le radici). In [tanenbaum94] viene riportato un breve sommario delle loro idee:
- Per prima cosa, la progettazione del sistema dovrà essere pubblica. Assumere che l'intruso non sappia come funziona il sistema serve solo a deludere i progettisti.
- Secondo, come regola generale non si consentirà l'accesso. Errori per cui si rifiutano accessi legittimi saranno comunicati molto più velocemente degli errori per cui si permettono accessi non autorizzati.
- Terzo, controllare i diritti di ogni accesso. Il sistema deve controllare i permessi, determinare che l'accesso è consentito e poi mettere da parte questa informazione per utilizzarla successivamente. Molti sistemi controllano i permessi quando si apre un file e non dopo. Questo significa che un utente che apre un file, e lo mantiene aperto per settimane, continuerà ad avere l'accesso anche se il proprietario da tempo ha cambiato la protezione.
- Quarto, dare a ogni processo la quantità minima di privilegi possibili. Se un editor ha solo il diritto di accedere al file da editare (specificato al momento della chiamata dell'editor), gli editor con il Trojan-Horse (Cavallo di Troia) non potranno fare molti danni. Questo principio implica uno schema di protezione molto dettagliato.
- Quinto, il meccanismo di protezione sarà semplice, uniforme e costruito negli strati più bassi del sistema. Provare a riadattare la sicurezza in un sistema esistente non sicuro è quasi impossibile. La sicurezza, come la correttezza, non è una caratteristica che si può aggiungere.
- Sesto, lo schema scelto deve essere accettabile psicologicamente. Se gli utenti sentono che la protezione dei loro file porta troppo lavoro, essi semplicemente non vi provvederanno. Non di meno protesteranno fortemente se qualcosa non andrà bene. Risposte della forma << è colpa tua! >> di solito non saranno ben accolte.
Il sistema operativo Unix, trattato in questo lavoro, fornisce una serie di funzionalità che incontrano i requisiti sopra accennati. Nel seguito vedremo come vengono soddisfatti e come possono essere aggirati!
Il problema della sicurezza dei sistemi operativi è stato affrontato in generale dal National Computer Security Center (NCSC) USA nella pubblicazione "Trusted Computer System Evaluation Criteria" (TCSEC, nota anche come "Orange Book").
Gli scopi che si prefigge questo documento ufficiale sono essenzialmente i seguenti:
- fornire uno standard ai produttori di sistemi per quanto riguarda la realizzazione delle caratteristiche di sicurezza ed i livelli di assicurazione che devono inglobare i loro prodotti affinchè siano rispettati i requisiti di fiducia per le applicazioni sensibili;
- fornire una metrica che può essere usata in un dato sistema di rete per l'elaborazione dell'informazione sensibile;
- fornire una base per decretare i requisiti di sicurezza nelle specifiche di acquisizione.
Secondo l'Orange Book i sistemi operativi sono valutabili in base a quattro classi di "fiducia": da D (meno sicuro) ad A (più sicuro):
- Classe D: detta di protezione minima, è riservata a quei sistemi nei quali non sono stati riscontrati i requisiti necessari per essere inseriti nelle altre classi. In genere nessun sistema viene inserito in questa classe perché la valutazione di un sistema è una operazione molto costosa e quindi i fabbricanti tendono a predisporre sistemi che rientrino nelle classi superiori.
- Classe C: detta di protezione discrezionale, fornisce un controllo discrezionale delle informazioni che può essere stimato per mezzo delle funzioni di auditing (monitoraggio). Questa classe viene divisa in due sottolivelli C1 e C2, dei quali il secondo è ritenuto più sicuro.
- La sottoclasse C1 richiede che siano stabilite alcune forme di controllo per permettere agli utenti di proteggere l'informazione privata da altri utenti. I sistemi inclusi in questa classe richiedono agli utenti di identificarsi attraverso un nome (username) che li riconosce univocamente sul sistema e una password che ne convalida l'identità. Il sistema inoltre deve mantenere l'integrità dei dati utente/password impedendo gli accessi non autorizzati.
- La sottoclasse C2, detta di protezione ad accesso controllato, è un'estensione della classe C1. Gli utenti sono responsabili delle proprie azioni. Il sistema traccia tutti i processi e registra le azioni utente per utente. Inoltre impedisce il riutilizzo di oggetti scartati. Gli utenti possono concedere a terzi l'accesso solo ai propri dati.
- Classe B: in tale classe, detta di protezione obbligatoria, diventano necessari i meccanismi per etichettare la criticità dei dati ed altri che assicurino che utenti non autorizzati non possano passare informazioni vitali per il sistema senza una adeguata autorizzazione. Con il livello B il sistema deve realizzare un controllo di tipo obbligatorio e non più discrezionale.
- La sottoclasse B1, detta protezione di sicurezza etichettata, richiede l'implementazione delle etichette dei dati per importanza in modo da escludere o includere gli utenti individualmente. Il sistema deve garantire omogeneità nelle etichette mentre i dati vengono trasferiti all'interno del sistema. Inoltre gli utenti non possono ignorare l'etichettatura di sicurezza che è obbligatoria.
- La sottoclasse B2, detta di protezione strutturata, richiede un criterio di sicurezza formale strutturato. I sistemi di autenticazione degli utenti risultano essere più severi per garantire la validità e la sicurezza delle informazioni necessarie per autenticare.
- La sottoclasse B3, detta di dominio di sicurezza, richiede al sistema di sicurezza di essere essenziale eliminando qualsiasi codice non inerente la sicurezza. Questo codice viene poi sottoposto ad analisi e test. Sono inoltre richieste funzioni aggiuntive per segnalare all'amministratore le necessarie misure di sicurezza. Il sistema deve essere altamente refrattario alla penetrazione.
- Classe A: detta di protezione verificata ha un'unica sottoclasse. La sottoclasse A1, detta progetto verificato, è funzionalmente equivalente alla classe B3 da cui differisce solo per i test formali molto più rigorosi ai quali il sistema deve essere sottoposto.