• Programmazione » Java » Guida Java base per principianti

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 none' "alterato" lungo la rete prima di essereconsegnato al client che lo richiede? Come assicurarsi che undispositivo JINI-enabled non e' il bersaglio di unattacco DoS?

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

La sicurezza in Java e' gestita da una ridda di piccolicomponenti, che sono distribuiti in svariati packages, tuttiquesti componenti devono riunirsi e cooperare per comporre ilgiusto puzzle.

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

Il modello di Java si basa su Policy ePermission, e' rivolto a risolvere problemi diintegrita' (il codice non puo' fare cose chel'autore o l'utente non consentono) e, in misuraminore, problemi di DoS e segretezza

Dato che e' richiesto che lo sviluppatore in personaaffronti il concetto di sicurezza, applicazioni che devonosvolgere operazioni considerate "a rischio" nonpossono essere sviluppate senza che il programmatore facciaqualche cosa di specifico. Se una applicazione cerca di farequalche cosa per la quale non e' autorizzata, siotterra' un bell'errore.

Architettura basata su Policy e Permission

In soldoni, una Permission e' semplicemente unmodo di dire che qualchecosa puo' fare una certaazione su un certo oggetto.

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

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

Le Permissions si applicano su classi, nonoggetti, dire che la classe Xyz puo' fare unacerta cosa implica che tutti le istanze di quella classepossono farla, indipendentemente da chi le haistanziate.

Per fare le cose ancora piu' semplici: le Permissiondicono cosa una classe puo' fare, e mai cosa nonpuo' fare.

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

Quando un'oggetto e' istanziato, la classe deveessere prima definita, basandosi sul CodeSource della classe,e' quindi collegato un set di Permissions che una Policyha preparato, la VM e' a conoscenza della Policy al suoavvio.

Quando l'istanza e' successivamente"azionata" attraverso uno dei suoi metodi, unSecurityManager puo' verificare le sue Permissionsa runtime, richiamando una eccezione se la classe manca dellanecessaria Permission.

Questa e' una semplificazione notevole di cio' cheavviene, "sotto al coperchio" , le cose sono unpo' piu' complesse. Per esempio, ilClassLoader raggruppera' tutte le Permissions inun ProtectionDomains e le associera' alla classeche sta' per essere caricata invece di collegare laclasse direttamente con una collection. Inoltre (come potetecapire da soli), un ClassLoader non e' altro cheun'altra classe a sua volta caricata da un ClassLoader...

In effetti c'e' una "catena" diClassLoaders che risale nella gerarchia fino al ClassLoaderdella VM stessa, che e' completamente inaccessibile dallealtre classi caricate in seguito (viene ritornato come null).E non abbiamo ancora parlato della complessita' diverificare ogni classe a runtime per le necessariePermissions.

Come sviluppatori, solitamente non ci dobbiamo preoccupare diquesti 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' necessarionell'applicazione e creare Policy specializzate. Inoltrepossiamo alterare le Policy per i singoli utenti, modificandole capacita' del codice a runtime senza modificare ilcodice.

Continua >>>