La security (Parte I)

Pagina 1 di 3

Java e la sicurezza

Esattamente come introduce nuove idee nella programmazione, Java introduce anche nuovi problemi relativi alla sicurezza. Come assicurarsi che un oggetto ottenuto tramite RMI non e' "alterato" lungo la rete prima di essere consegnato al client che lo richiede? Come assicurarsi che un dispositivo JINI-enabled non e' il bersaglio di un attacco DoS?

Le Security API di java sono progettate appositamente per risolvere questo tipo di problemi.

La sicurezza in Java e' gestita da una ridda di piccoli componenti, che sono distribuiti in svariati packages, tutti questi componenti devono riunirsi e cooperare per comporre il giusto puzzle.

Tutte le applicazioni Java sono interessate da questa architettura, non e' importante se la vostra applicazione ha a che fare con crittografia, autenticazione o altro, il "nucleo" del modello di sicurezza e' sempre li', anche se la vostra applicazione lo ignora.

Il modello di Java si basa su Policy e Permission, e' rivolto a risolvere problemi di integrita' (il codice non puo' fare cose che l'autore o l'utente non consentono) e, in misura minore, problemi di DoS e segretezza

Dato che e' richiesto che lo sviluppatore in persona affronti il concetto di sicurezza, applicazioni che devono svolgere operazioni considerate "a rischio" non possono essere sviluppate senza che il programmatore faccia qualche cosa di specifico. Se una applicazione cerca di fare qualche cosa per la quale non e' autorizzata, si otterra' un bell'errore.

Architettura basata su Policy e Permission

In soldoni, una Permission e' semplicemente un modo di dire che qualchecosa puo' fare una certa azione su un certo oggetto.

Questo modello e' derivato direttamente dal meccanismo di protezione di molti sistemi operativi (in particolare Unix): un utente (cosa) puo' avere dei permessi per accedere un particolare file (l'oggetto) e, per esempio, leggerlo (l'azione).

Ecco tutta l'architettura in un paragrafo: del codice specifico (descritto come CodeSource) puo' effettuare una certa azione su un certo oggetto (descritto come una Permission).
Oggetti di tipo Policy gestiscono le relazioni tra il CodeSource e le Permission.

Le Permissions si applicano su classi, non oggetti, dire che la classe Xyz puo' fare una certa cosa implica che tutti le istanze di quella classe possono farla, indipendentemente da chi le ha istanziate.

Per fare le cose ancora piu' semplici: le Permission dicono cosa una classe puo' fare, e mai cosa non puo' fare.

La relazione tra il CodeSource e la Permission e' contenuto in una Policy, ed e' disponibile ancora prima che l'applicazione sia considerata dalla Virtual Machine. Consideriamo il ciclo di vita di un'oggetto:

Quando un'oggetto e' istanziato, la classe deve essere prima definita, basandosi sul CodeSource della classe, e' quindi collegato un set di Permissions che una Policy ha preparato, la VM e' a conoscenza della Policy al suo avvio.

Quando l'istanza e' successivamente "azionata" attraverso uno dei suoi metodi, un SecurityManager puo' verificare le sue Permissions a runtime, richiamando una eccezione se la classe manca della necessaria Permission.

Questa e' una semplificazione notevole di cio' che avviene, "sotto al coperchio" , le cose sono un po' piu' complesse. Per esempio, il ClassLoader raggruppera' tutte le Permissions in un ProtectionDomains e le associera' alla classe che sta' per essere caricata invece di collegare la classe direttamente con una collection. Inoltre (come potete capire da soli), un ClassLoader non e' altro che un'altra classe a sua volta caricata da un ClassLoader...

In effetti c'e' una "catena" di ClassLoaders che risale nella gerarchia fino al ClassLoader della VM stessa, che e' completamente inaccessibile dalle altre classi caricate in seguito (viene ritornato come null). E non abbiamo ancora parlato della complessita' di verificare ogni classe a runtime per le necessarie Permissions.

Come sviluppatori, solitamente non ci dobbiamo preoccupare di questi dettagli, la VM si occupa del lavoro sporco.

Piu' importante e' che questo modello e' estensibile, possiamo creare le nostre Permissions, richiedere controlli quando e' necessario nell'applicazione e creare Policy specializzate. Inoltre possiamo alterare le Policy per i singoli utenti, modificando le capacita' del codice a runtime senza modificare il codice.

Continua >>>