Deshabilitar la reflexión de Java para el hilo actual

Necesito llamar a un código Java semi-confiable y quiero desactivar la capacidad de usar el reflection durante la ejecución del código.

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

¿Se puede hacer esto con un SecurityManager? De ser así, ¿cómo?

Aclaración / contexto: esta es una continuación de otra pregunta sobre la restricción de paquetes a los que se puede llamar desde JavaScript / Rhino. La respuesta aceptada hace referencia a una entrada de blog sobre cómo hacerlo, y requiere dos pasos: el primero usa una API de Rhino (ClassShutter), el segundo desactiva reflexión y Class.forName (). Estaba pensando que puedo hacer ese segundo paso más limpiamente usando un SecurityManager (aprendiendo sobre SecurityManager, que como se ha señalado, es una bestia compleja, en el camino).

Para resumir, quiero (desde el código, sin configurar el archivo) desactivar Class.forName () y cualquier acceso al paquete de reflexión completo.

Depende de lo que trates de restringir.

En general, la API de acceso público no está restringida. Sin embargo, siempre que no conceda al código poco confiable el ReflectPermission("suppressAccessChecks") , no podrá obtener acceso a la API no pública en otro paquete.

Si tiene una lista de paquetes a los que desea restringir todo el acceso, hay dos pasos. Primero, en las propiedades de Security , incluya el paquete restringido en la lista package.access . A continuación, proporcione su código de confianza RuntimePermission("accessClassInPackage." + pkg) .

Una forma común de distinguir el código que no es de confianza es cargarlo desde una ubicación diferente y consultar las diferentes bases de código en su archivo de política al otorgar permisos.

La architecture de seguridad de Java es muy poderosa, pero sé que también es complicada; si desea un ejemplo más concreto, describa exactamente qué llamadas desea restringir e intentaré ser más explícito.


Hacer lo que quiera sin modificar el archivo java.policy y / o el archivo java.security sería muy difícil, quizás imposible. java.security.Policy representa la información en java.policy , pero no ofrece acceso de escritura. Puede crear su propia implementación de Policy e instalarla en tiempo de ejecución mientras que SecurityManager existente lo permita.

Por otro lado, puede especificar un archivo java.policy personalizado como una opción de línea de comandos. Si está proporcionando una aplicación completa con algún tipo de iniciador, eso podría lograrse fácilmente. También proporciona cierta transparencia a tus usuarios. Un usuario sofisticado puede revisar los permisos que le gustaría otorgar a la aplicación.

Bueno, puede anular SecurityManager.checkMemberAccess y obtener una definición más estricta. Sin embargo, realmente no funciona así. ¿Qué ocurre, por ejemplo, si el código define un finalizador?

En la aclaración: otras API usan reflexión y otras API. Por ejemplo, java.beans, LiveConnect y Rhino. Un adversario podría desde dentro de un script, por ejemplo, crear un nuevo contexto de Rhino sin el obturador y, por lo tanto, iniciarse en el JRE completo. Con un sistema abierto, una lista negra nunca se puede terminar.

En resumen: para usar el modelo de seguridad de Java, necesita trabajar con él, no en su contra.

Escribí un reemplazo de ClassShutter que permite un control de acceso de grano fino, por instancia, por método y por campo:

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