Distriggers la riflessione Java per il thread corrente

Devo chiamare un codice Java semi-affidabile e voglio disabilitare la possibilità di usare il reflection per la durata dell’esecuzione di quel codice.

try{ // disable reflection somehow someObject.method(); } finally{ // enable reflection again } 

Questo può essere fatto con un SecurityManager e, in caso affermativo, come?

Chiarimento / Contesto: questo è il seguito di un’altra domanda sulla limitazione dei pacchetti che possono essere chiamati da JavaScript / Rhino. La risposta accettata fa riferimento a un post sul blog su come farlo e richiede due passaggi, il primo utilizzando un’API di Rhino (ClassShutter), il secondo che disabilita il reflection e Class.forName (). Stavo pensando di poter fare il secondo passo in modo più pulito usando un SecurityManager (imparando a conoscere SecurityManager, che come è stato sottolineato, è una bestia complessa, lungo la strada).

Per riassumere, voglio (dal codice, non impostare il file) per distriggersre Class.forName () e qualsiasi accesso all’intero pacchetto di riflessione.

    Dipende da cosa stai cercando di limitare.

    In generale, l’API accessibile al pubblico non è limitata. Tuttavia, a condizione che non si conceda il codice non attendibile ReflectPermission("suppressAccessChecks") , non sarà ansible accedere a API non pubbliche in un altro pacchetto.

    Se si dispone di un elenco di pacchetti a cui si desidera limitare tutti gli accessi, ci sono due passaggi. Innanzitutto, nelle proprietà di Security , includi il pacchetto limitato nell’elenco di package.access . Quindi fornire il codice attendibile RuntimePermission("accessClassInPackage." + pkg) .

    Un modo comune per distinguere il codice non attendibile è caricarlo da una posizione diversa e fare riferimento alle diverse codebase nel file della politica quando si concedono le autorizzazioni.

    L’architettura di sicurezza Java è molto potente, ma so che è anche complicata; se vuoi un esempio più concreto, descrivi esattamente quali chiamate vuoi limitare e cercherò di essere più esplicito.


    Fare ciò che vuoi senza modificare il file java.policy e / o il file java.security sarebbe molto difficile, forse imansible. java.security.Policy rappresenta le informazioni in java.policy , ma non offre accesso in scrittura. È ansible creare l’implementazione della propria Policy e installarla in fase di esecuzione a condizione che qualsiasi SecurityManager esistente lo consenta.

    D’altra parte, è ansible specificare un file java.policy personalizzato come opzione della riga di comando. Se stai fornendo un’applicazione completa con una sorta di launcher, questo potrebbe essere facilmente realizzato. Fornisce inoltre una certa trasparenza ai tuoi utenti. Un utente sofisticato può rivedere le autorizzazioni che vorresti avere concesso all’applicazione.

    Bene, è ansible ignorare SecurityManager.checkMemberAccess e fornire una definizione più rigorosa. Tuttavia, non funziona in questo modo. Cosa succede ad esempio se il codice definisce un finalizzatore?

    Sul chiarimento: le altre API utilizzano la riflessione e altre API. Ad esempio, java.beans, LiveConnect e Rhino. Un avversario potrebbe all’interno di una sceneggiatura, ad esempio, creare un nuovo contesto di Rhino senza il pulsante di scatto e quindi eseguire il bootstrap nell’intero JRE. Con un sistema aperto, una lista nera non può mai essere completata.

    In breve: per utilizzare il modello di sicurezza Java è necessario lavorare con esso, non contro di esso.

    Ho scritto una sostituzione di ClassShutter che consente il controllo dell’accesso a grana fine, per istanza, per metodo, per campo:

    http://riven8192.blogspot.com/2010/07/java-rhino-fine-grained-classshutter.html