Adobe Reader X fa un importante passo avanti dal punto di vista della sicurezza, implementando un insieme di ottimi principi di segregazione. Prima di entrare nel merito una considerazioni a margine. È difficile non ricollegare questo passo avanti nella sicurezza con la sempre maggiore disponibilità e diffusione di reader PDF alternativi ad Acrobat. Per essere un lettore di documenti, AR ha sempre avuto una quantità di vulnerabilità molto alta, ma il picco recente, oltre al considerevole “peso” del programma, ha convinto molti a cercare soluzioni alternative. Finché queste soluzioni alternative non si sono trovate, lo sviluppo di AR è stato più che altro nella direzione di un aumento di funzionalità, molte delle quali rischiose. Ma torniamo all’architettura. È un tema sul quale ho ragionato spesso, non tanto perché non ci siano soluzioni note e banali, quanto perché queste soluzioni sono generalmente poco comode per l’utente, il che le rende impraticabili nella maggior parte dei casi. Partiamo dalla base. Un utente ha dei diritti su un sistema, diciamo per semplicità su un filesystem: in lettura e scrittura tipicamente sui suoi file e su pochi altri, in lettura ed esecuzione sulla maggior parte dei file del sistema (esclusi quelli di altri utenti(, che sono eseguibili, librerie, file di configurazione ecc. Pochi file escono da queste due categorie, alcuni ad esempio non sono nemmeno leggibili da un utente generico perché contengono dati riservati del s.o. Perché un utente può leggere la maggior parte dei file? Perché uno qualunque dei suoi programmi potrebbe avere bisogno di quei file. Tuttavia, se guardiamo il singolo programma, in realtà ha esigenze molto più limitate: leggere ed eseguire il proprio codice e le librerie linkate dinamicamente, leggere i file di configurazione (i suoi e alcuni di sistema), leggere e scrivere nella propria directory di lavoro (per file temporanei o altro), e infine leggere e/o scrivere i file sui quali l’utente ha deciso di lavorare con quel programma. L’elenco è lungo ma in realtà il numero di file è molto più piccolo di quelli ai quali può accedere l’utente. Invece, dato che ogni processo eredita normalmente i diritti dell’utente che lo esegue, ogni programma può accedere a tutti i file del primo elenco. Questo vuole dire che quando ha qualche comportamento dannoso, i canali attraverso cui fare danno e i dai ai quali può accedere sono moltissimi. Una soluzione a questo problema, forse la più vecchia, è l’uso del chroot in Unix: un programma vede solo una directory, che per lui diventa la root del filesystem, e in quella directory gli vengono copiati tutti e soli i file che gli servono per la sua esecuzione. Funziona bene per alcuni programmi, come ad esempio molti servizi di rete, ma per i programmi utente si pone il problema di come dare accesso al programma ai singoli file utente sui quali deve lavorare. Ad esempio, se io mettessi Acrobat Reader in chroot, non avrebbe modo di accedere ai file da visualizzare, o glieli dovrei copiare nella sua directory di chroot ogni volta che mi serve vederli. Questo è il problema di tutti i meccanismi di sandbox (e di tanti altri meccanismi di sicurezza): che ci sono quasi sempre dati e file che devono entrare/uscire dalla sanbox,jail,macchina virtuale o altro meccanismo di segregazione, e quel canale diventa da una parte il veicolo di attacchi, dall’altra un’operazione scomoda che, se si vuole che sia controllata, coinvolge (disturba?) l’utente. Quello che si può fare è realizzare un programma (broker) che faccia questo passaggio di dati in modo automatico quando è definito come legittimo in una politica, e chieda il permesso all’utente negli altri casi. Si noti che c’è una leggera differenza rispetto a una policy di accesso: quando il personal firewall ci chiede se un’applicazione può accedere a Internet, o un antispyware ci chiede se un’applicazione può modificare un registro, di fatto poi l’applicazione accede direttamente, e non è in una vera sandbox. In particolare, in questo modo può modificare l’oggetto originale, anziché una copia che gli viene fornita. Quando invece un broker fornisce i dati ad un’applicazione in una sandbox, l’applicazione opera su una copia, eventuali modifiche dovranno a loro volta passare dal broker, essere validate ed eventualmente autorizzate dall’utente prima di modificare la copia originale. Un ulteriore vantaggio, sfruttato da Acrobat Reader, è che a questo punto il programma non ha più bisogno di essere eseguito con i privilegi dell’utente, perché ai dati dell’utente non accede più direttamente. Può quindi essere eseguito come un utente specifico, con privilegi molto limitati. Naturalmente, quando le cose vanno implementate sono molto più complicate di quello che sembra, come minimo perché non c’è solo il filesystem a cui accedere, ma una serie di altri componenti che possono essere molto meno “lineari” da affrontare (dispositivi di input/output, ad esempio), e l’utilizzo di un broker può rendere più difficili alcune ottimizzazioni in termini di efficienza, ma è una logica che potrebbe diventare parte di molti altri programmi. Il punto più importante è poter isolare le componenti del programma che interagiscono con il sistema, o come minimo con il filesystem, in modo da poterle adattare. A questo punto, vi invito a leggere la presentazione dell’architettura data da Adobe (le parti successive sono qui, qui e qui). naturalmente, sarà il tempo a dirci quanto la soluzione di Adobe sarà efficace, e anche quanto è stat implementata correttamente. Il punto importante è che si tratta di una soluzione architetturale, secondo una logica condivisibile.
Secondo una logica simile, uno dei progetti che ho dato ai miei studenti l’anno scorso era realizzare un programma che potesse essere definito come “browser di default”, e che proseguisse attraverso un canale sicuro le URL ad un vero browser in una macchina virtuale, che ne costituisce la sandbox.
