Questa è una storia più o meno vera (sono stati cambiati solo dettagli inessenziali); gli eventi di cui si parla nel seguito sono accaduti circa 11 anni fa1
alla Tymshare, una società che forniva servizi commerciali di timesharing.
In precedenza avevo già sentito parlare di capability, e pensavo che fossero una soluzione pulita e accurata , ma non ero convinto che fossero necessarie;
questa occasione mi dimostrò invece che lo erano.
Il nostro sistema operativo era molto simile, nelle sue strutture di sicurezza, a UNIX; avevamo un compilatore fortran installato in una directory SISX: per utilizzarlo un utente poteva scrivere "RUN (SYSX)FORT nomeprogr", e fornire eventualmente il nome di un file in cui ottenere in output informazioni per il debugging. Inoltre il compilatore creava automaticamente un file (SYSX)STAT in cui scriveva informazioni statistiche sull'uso delle varie caratteristiche sintattiche del linguaggio.
Per permettere al compilatore di scrivere il file (SYSX)STAT, gli era stata fornita l'home file licence, che sul nostro sistema operativo permetteva ad un programma di scrivere nella sua home directory - in questo caso SYSX.
Anche il file contenente la licenza d'acquisto si trovava nella directory SISX, e si chiamava (SYSX)BILL. Ad un utente venne in mente per caso il nome BILL come nome per il file di debug.
Cosa succede quindi? il compilatore passa il nome al sistema operativo, che correttamente ne prende in considerazione l'autorità2: il compilatore ha l'home file licence, che gli permette di scrivere nella directory SISX, e anche di sovrascrivere (SISX)BILL, e cancellare così la licenza d'acquisto.
Di chi è stata la colpa? Cosa potevamo modificare per sistemare il problema? Non ne avremmo così causati altri? Come potevamo prevederli?3
Non si può incolpare il codice che deposita il debug in un file identificato4 dall'utente. Cosa potrebbe fare il compilatore? controllare se il file di debug si trova in una directory diversa? No, è utile poter specificare nel nome del file la directory in cui si vuole l'output.
Dovrebbe controllare se nel nome del file compare SISX? No, il nome SISX non era ancora stato inventato quando il compilatore era stato scritto; è possibile che esso effettui una richiesta legittima di depositare il proprio output in qualche file in SISX, proveniente da qualcuno che ha legittimo accesso a quella directory.
Controllare se viene utilizzato il nome (SISX)BILL? Questo non è l'unico file sensibile in SISX: dovremmo modificare il compilatore ogni volta che vengono aggiunti file a SISX?
Quando era stato scritto, il compilatore era corretto! Cos'è che ha cambiato la situazione?
L'errore è stato dare a (SYSX)FORT la home file licence; per accorgercene, comunque, avremmo dovuto esaminare ogni possibile situazioni in cui il compilatore poteva scrivere un file; e anche quando avessimo identificato tutte queste possibili situazioni, non sarebbe stato chiaro cosa fare.
Un'altra indicazione di potenziali problemi era il fatto che le regole che permettevano ad un programma di aprire un file, come tutte le cose complesse, stavano diventando man mano più complesse.
Ogni volta che aggiungevamo una clausola che permetteva l'apertura di un file in una particolare condizione potevamo introdurre problemi di sicurezza in programmi che prima erano sicuri. Quando, al contrario, aggiungevamo delle restrizioni potevamo potenzialmente creare problemi ad altri programmi che invece dovevano avere un legittimo accesso.
L'ultima volta che scrissi una condizione per l'apertura di un file, richiese 14 operatori booleani (tra and e or).
Il problema fondamentale è che il compilatore viene eseguito con autorità che derivano da due sorgenti diverse ( e per questo è un "deputato confuso").
Chi lancia il compilatore gli fornisce la propria autorità attraverso il comando RUN (SYSX)FORT (questo è ovviamente il meccanismo che sfruttano i trojan horses, che sono un tipico problema delle architetture ACL); l'altra autorità del compilatore deriva dalla sua home file license; il compilatore obbedisce a due superiori, e porta con sé una parte dell'autorità dell'uno e dell'altro per eseguire le loro rispettive richieste: non ha nessun modo per tenerle separate; quando produce le statistiche intende usare l'autorità fornitagli dalla sua home file license; quando produce invece il file di debug, intende usare quella fornitagli dall'utente che l'ha lanciato; ma non ha nessun modo di esprimere queste intenzioni.
Modificammo allora il sistema operativo e aggiungemmo una funzione che permetteva di selezionare l'autorità di cui tener conto in un certo momento, aumentando in questo modo la complessità del sistema. Il compilatore poteva adesso usare esplicitamente le sue due autorità e dire ad es.: "Per l'autorità conferitami dall'utente richiedo l'apertura del file (SISX)BILL", che il sistema operativo gli avrebbe giustamente negato.
Divenne presto chiaro, comunque, che ad alcune applicazioni erano necessarie più di due autorità, e che inoltre esistevano altri meccanismi da considerare oltre all'accesso ai file: le modifiche da apportare al sistema non erano ovvie nè localizzate.
Il fatto che il compilatore necessitasse di due meccanismi diversi per
Il "crimine" era perpetrato applicando in maniera imprevista l'autorità del compilatore su SISX al momento della scrittura dei dati dell'utente. (se si prova a risolvere questo problema senza capabilities bisogna tenere presente che anche il file (SISX)STAT deve essere protetto, nel caso l'utente lo scelga come file di output del debug.)
Una soluzione che utilizzi invece le capabilities, ne fornirebbe una specifica al compilatore che lo autorizzi a scrivere sul file delle statistiche; per identificare il file, il compilatore non farebbe riferimento al suo nome, ma designerebbe semplicemente la capability: essa identifica il file e allo stesso tempo autorizza il compilatore a scriverci5.
Nel produrre il file di debug utilizzerebbe la capability fornitagli dall'utente per il posto esatto in cui salvarlo.
Il metodo usato in questo caso è unico: non è necessario nessun nome in formato ASCII e non viene eseguito nessun controllo sull'accesso; anche per (SISX)STAT deve essere usata la stessa soluzione: non si fornisce al compilatore nessun'autorità sul file, ma una capability che rappresenti esplicitamente tale autorità [v. ancora nota 4].
Prima di implementare i principi rappresentati dalle capabilities, temevamo che un sistema basato su di esse avrebbe usato la maggior parte delle risorse per memorizzarle; scoprimmo invece che sostituivano così tanti altri meccanismi ad hoc che il sistema risultava più compatto del suo equivalente ACL; le capabilities non solo unificavano molte funzioni di assegnazione dei nomi, e individuazione degli oggetti attraverso di essi, ma rendevano anche i vecchi meccanismi di sicurezza completamente inutili, senza per questo danneggiare le prestazioni.
Alcuni sistemi operativi hanno cercato di aggiungere le capabilities ai meccanismi tradizionali, e spesso la somma degli svantaggi dei due metodi non ha compensato la somma dei vantaggi. La nostra 6 implementazione di KeyKOS si basa su questa filosofia più di quanto abbiano fatto altri sistemi in precedenza.
In KeyKOS esistono directory e altre simile "comodità"7 del file system, ma esse sono implementate e rese accessibili attraverso le capabilities.
KeyKOS possiede caratteristiche brevettate per la gestione delle autorità che permettono di evitare efficacemente virus, trojan horses, ed altre comuni minacce per la sicurezza, fornendo allo stesso tempo una flessibilità tale da permettere di gestire un ampio range di politiche, da quelle in stile orange book del DOD a quelle più commerciali, comprese quelle che permetto di risolvere il problema dei mutually suspicious users8.