Download in corso

Softwareone.it

La Sicurezza in Java SandBox

Sin dalla sua introduzione, la tecnologia Java ha riservato un importante ruolo alle tematiche di sicurezza. Sebbene con esiti alterni, i progettisti hanno cercato di fornire la piattaforma di sistemi di sicurezza implementati direttamente a livello di linguaggio, disponibili agli sviluppatori.

In un continuo processo di evoluzione e raffinamento la JVM è divenuta una delle più importanti infrastrutture per applicazioni stand-alone, web, mobile e altro ancora; in questo articolo ci focalizzeremo sull’evoluzione del modello di sicurezza, comunemente detto a sandbox, commentandone gli errori di progettazione e lo stato attuale.

Prerequisiti

Questo articolo è rivolto a tutti, siano essi esperti programmatori Java che lettori totalmente digiuni dell’argomento. Alcune considerazioni saranno maggiormente comprensibili a coloro che possiedano già una minima esperienza con questo linguaggio, ciononostante la lettura di questo articolo è adatta a qualunque lettore.

La sandbox

Il modello originale

Il modello originale, noto come sandbox, fu progettato per confinare codice potenzialmente dannoso in un ambiente isolato e fortemente restrittivo. Java, sin dalla sua nascita, fu fortemente orientato alla rete e questa considerazione spinse ad ideare un modello di esecuzione in cui il codice veniva direttamente scaricato da remoto, esponendo il client a notevoli problematiche di sicurezza.Nella sua prima implementazione, schematizzata in figura, la sandbox distingueva grossolanamente solo tra codice locale e codice remoto: il primo godeva di accesso completo a tutte le risorse “critiche” del sistema quali, ad esempio, il filesystem e i vari devices; il codice remoto, al contrario, aveva un limitato accesso alle risorse, mediato dalla sandbox stessa: le applet, ormai sostanzialmente scomparse dal panorama web, ne sono stato il più noto esempio.

Questo modello include una serie di meccanismi di sicurezza a diverso livello. Prima di tutto, Java è un linguaggio type-safe, cioè esiste una relazione esplicita e controllata tra una variabile e il suo tipo (intero, virgola mobile, stringa, ecc..).

Coloro che hanno programmato in linguaggi a basso/medio livello quali il C e il C++ conoscono quanti problemi possa evitare questo controllo: quell’insieme di conversioni implicite tra tipi, ad esempio interi a booleani o puntatori void ad altri puntatori, che sono caratteristiche di quei linguaggi divengono al tempo stesso la principale sorgente di errori di programmazione, ugualmente commessi sia da principianti sia da esperti. Per minimizzare le possibilità che gli sviluppatori compiessero strafalcioni, i progettisti della Sun introdussero alcuni aspetti fino ad allora presenti solo in linguaggi di nicchia o a livello universitario quali, ad esempio, la gestione automatica della memoria (il garbage collector) e i controlli a run-time sull’accesso in memoria (a puntatori, elementi di array, ecc…).

Il secondo livello di protezione è garantito dal compilatore e, a run-time, dalla virtual machine. Ciò assicura che il bytecode, l’assembler della VM Java, sia eseguito con gli appropriati permessi di esecuzione. In particolare due componenti fondamentali, il ClassLoader e il SecurityManager, definiscono uno spazio di nomi locale per evitare interferenze tra diverse istanze della VM e gestiscono i controlli di accesso alle risorse critiche.

JDK 1.1 – Codice firmato

Il modello presentato è poco flessibile e già nel primo update del JDK (la versione 1.1) fu introdotto il concetto di codice trusted per permettere ad applicazioni remote, se corredate di una firma elettronica riconosciuta dal client, di accedere alle risorse di sistema. La soluzione, schematizzata nella figura seguente, è poco più di un hack della precedente architettura e pertanto necessiterà una completa riscrittura nelle successive release.

06-05-2017
Pubblicità