Dal JDK 1.0 a Java 2

Dal JDK 1.0 a Java 2

Java è un linguaggio studiato implementato in modo che fosse sicuro, nei confronti di qualsiasi tipo di pericolo. Il modello fondamentale su cui si appoggia è quello della Sandbox [1]. La Sandbox è un ambiente in cui un certo codice può eseguire un numero limitato di operazioni che permettono l'accesso al sistema, inteso come file system e connessioni di rete. Partendo dalle origini del linguaggio, la prima versione, il JDK 1.0 prevedeva che un codice cosiddetto "locale", cioè in esecuzione sulla macchina locale, avesse libero accesso alle risorse del sistema, mentre un codice cosiddetto "remoto" avesse accesso soltanto alle operazioni definite nella Sandbox.

Figura : Modello della sicurezza nel JDK 1.0 - tratta da [1]

Il principio fondamentale che stava dietro alla Sandbox era quello di prevenire ogni pericolo che potesse provenire da un codice non ritenuto sicuro, quindi le funzionalità permesse all'interno della Sandbox erano praticamente ridotte al minimo. Un'Applet, per esempio, poteva solamente accedere ad una connessione con il server da cui proveniva, ed eseguire semplici operazioni senza però avere accesso alla macchina locale o ad altre risorse. A partire dal JDK 1.1, invece, si ha l'introduzione del concetto di "Applet firmata". La novità consiste nel fatto che il codice viene eseguito come se fosse un codice locale, quindi con libero accesso alle risorse del sistema, con condizione che la chiave pubblica utilizzata per la verifica della firma sia considerata valida. Le Applet non firmate, invece, continuano ad essere eseguite con le limitazioni della versione precedente.

Figura : Modello della sicurezza nel JDK 1.1 - tratta da [1]

Per quanto riguarda le Applet firmate, queste vengono scaricate all'interno di una rete, e quindi eseguite in remoto, sulla macchina dell'utente, insieme alla loro firma, impacchettate in file JAR, cioè un archivio Java. L'archivio JAR permette il trasferimento di un file unico, in cui sono contenute tutte le informazioni necessarie all'esecuzione dell'Applet, oltre alla possibilità di apportare la firma alle varie classi Java una sola volta. Con l'avvento del JDK 1.2, conosciuto anche come Java 2, sparisce la distinzione tra codice remoto e codice locale, per lasciare spazio alle politiche di sicurezza. La politica di sicurezza definisce un insieme di permessi validi per codici provenienti da parti differenti e configurabili dall'utente o da un amministratore di sistema. Lo scopo dei permessi è quello di specificare l'accesso ad una particolare risorsa, che può essere la scrittura o lettura di un file posto nel file system della macchina locale, come la connessione ad una macchina o una porta remota. La gestione dei permessi avviene a runtime, ovvero vengono individuati da parte del Security Manager [2] dei domini, a tempo di esecuzione, in cui vengono inserite tutte le istanze di quelle classi che hanno gli stessi permessi. In questo modo è possibile definire dei domini che sono delle Sandbox avanzate, cioè in cui solo delle particolari classi hanno delle restrizioni alla loro esecuzione mentre altre continuano ad avere libero accesso alle risorse. Di default le applicazioni vengono eseguite senza alcuna restrizione, ma possono essere soggette, come detto, all'applicazione delle politiche di sicurezza.

La versione più recente della piattaforma Java, al momento della stesura di questa tesi, è JDK 1.4.2. In questa versione di Java 2 rispetto alle precedenti, le novità sono rappresentate dall'integrazione della JCE[2] all'interno delle API di Java, oltre alle integrazioni di altre estensioni per la sicurezza nei socket, JSSE e per la gestione dei servizi di autenticazione e autorizzazione JAAS .

Figura : Modello della sicurezza nel JDK 1.2 - tratto da [1]

Oltre a queste innovazioni vengono introdotti anche gestori per la catena di certificazione JCP[6]e per la gestione della sicurezza generica JGSS .

Il componente architetturale che riveste un ruolo di prestigio nella sicurezza in Java è il Security Manager, il quale è l'artefice della creazione e suddivisione dei domini. Il compito del Security Manager è quello di monitorare continuamente le azioni svolte, o più correttamente, che dovrebbero essere svolte, dai thread delle applicazioni. Nel JDK 1.1 le API del linguaggio Java al momento dell'esecuzione chiedevano al Security Manager attivo, il permesso di compiere l'operazione ritenuta pericolosa. Quindi l'esecuzione di una certa operazione a rischio era lasciata decidere al Security Manager. Ogni volta che dovevano essere eseguite azioni di un certo tipo, veniva richiamato un metodo, presente all'interno del Security Manager, denominato checkAzione, dove Azione stava ad indicarne il tipo, a cui era delegato il compito di effettuare il controllo. Con il JKD 1.2 tutte le chiamate a questi metodi si sono tradotte nella chiamata al metodo checkPermission. Come abbiamo già detto in precedenza, all'avvio un'applicazione non ha un Security Manager installato, quindi non ha restrizioni; questa cosa non è vera per le Applet per le quali è il browser, sulle quali girano, che installa automaticamente un Security Manager, il quale rimarrà attivo per tutto il tempo di esecuzione dell'Applet, in modo da evitare l'installazione di un nuovo Security Manager. Questa procedura è una tecnica di sicurezza molto importante per evitare che durante l'esecuzione un'Applet, installando un proprio Security Manager, si dia da sola i permessi per effettuare qualsiasi azione.

Per quanto riguarda i permessi, questi rappresentano oggetti che definiscono delle risorse. Un permesso è definito all'interno del programma, specificando un target, cioè l'identificativo di una risorsa e l'operazione eseguibile sulla risorsa stessa. Questa operazione di assegnamento di un permesso di per sé non ha senso se prima non è stata definita il medesimo permesso anche nel Policy File. Il Policy Files[3] è un file in cui sono memorizzati tutti i permessi; ce ne sono di due tipi, uno utente e uno di sistema. Sono entrambi modificabili e sono posizionati nella cartella libsecurityjava.policy relativamente al path restituito dalla proprietà user.home rispettivamente dell'utente e del sistema. Questi file sono ampiamente commentati, quindi per ulteriori informazioni su contenuto e scrittura si rimanda alla lettura di questi file presenti nelle distribuzioni standard di Java.