La security (Parte III)

Pagina 3 di 3

Che succede durante un controllo di sicurezza?

Anche se gli sviluppatori solitamente non si preoccupano troppo delle routine usate durante un controllo di Permissions, capire come funziona il meccanismo puo' aiutare ad implementare un meccanismo migliore.

Gli oggetti importanti in questo controllo sono: SecurityManager, AccessController e AccessControllerContext.

Per prima cosa, SecurityManager entra in scena, quando un metodo richiede una permission per essere eseguito correttamente, il metodo recupera un SecurityManager e richiama il suo checkPermission().

E' possibile aggiungere protezione e controllo alle vostre applicazioni semplicemente aggiungendo una chiamata esplicita al SecurityManager nel vostro codice:

SecurityManager sm = System.getSecurityManager();
If (sm != null) sm.checkPermission(perm);
// if the permission isn't granted, an AccessControlException
// will be thrown.

Se volete utilizzare dei controlli di esecuzione piu' stringenti di quelli standard usati da Java, dovete creare le vostre sottoclassi e richiedere i security check in ogni metodo richiamato. Per esempio se volete verificare/evitare la creazione di stringhe troppo grandi, create la vostra sottoclasse di String e richiamate i controlli necessari nei metodi che volete proteggere. Teoricamente potete forzare un check prima di ogni metodo nella vostra applicazione.

SecurityManager tuttavia, non fa' altro che passare le Permission all'AccessController.

L'AccessController e' quello che fa' effettivamente il lavoro. E' un'arnese piuttosto complesso, che si appoggia su un numero notevole di chiamate native, ed e' difficile rendere appieno cosa fa in poche parole.
Essenzialmente, quando controlla una Permission, l'AccessController prende un'istantanea dello Stack corrente, lo incapsula in un AccessControllerContext che utilizza metodi nativi per recuperare un'array di classi che rappresentano lo stack corrente con tutti i suoi thread. Quindi verifica le Permissions (nella forma di ProtectionDomains) associati con ogni classe dello stack.

Se qualche classe (anche una sola), manca della permission in fase di test, un'eccezione viene eseguita. Altrimenti il metodo ritorna senza dire nulla.

Super poteri: doPrivileged()

In alcuni casi pero', si vuole "cambiare le regole" , anche solo per una classe e solo per un caso. Questo e' fatto usando doPrivileged.

Ipotizziamo che Admin.class abbia i permessi per leggere una stringa "segreta" , mentre User.class non ce li abbia (e non debba averceli).

Nonostante cio', in certe condizioni un'oggetto User deve eseguire dei metodi tipici di Admin che richiedono il valore di tale stringa. E' possibile fornire tali privilegi senza fornire ad User l'accesso permanente alla stringa usando doPrivileged().

Nota: doPrivileged ritorna sempre un'oggetto (se ritorna qualche cosa).

Stabilire quali Permission sono necessarie

A giudicare da vari post su svariate mailing list di Java, decidere quali privilegi aggiudicare al codice comporta parecchi problemi. Questo puo' essere vero se state portando del codice da Jdk 1.1. a Jdk 1.2 o superiore, che improvvisamente richiede delle permission per eseguire dei metodi che prima non li richiedevano.

Non esiste nessun tool (AFAIK) per generare automaticamente le policy necessarie per del codice specifico, la cosa migliore e' quella di pianificare con le Permission gia' in testa fin dall'inizio, e progettare il codice in accordo a questo.

Tenere bene a mente che, senza doPrivileged(), ogni singola classe in un thread richiede le Permission perche' Java sia contento. Se un metodo in A richiama un metodo in B che richiama un metodo in C che richiede una certa permission, tutte e tre le classi devono avere tale Permission perche' possano funzionare.

Conclusioni

L'unica applicazione veramente sicura e' quella che non sta' funzionando, in ogni altro caso non esiste una cosa come "codice sicuro" , ma utilizzando al meglio i meccanismi di protezione ed autorizzazione del codice forniti da Java, e' possibile ridurre di molto i pericoli insiti.