Deshabilitar reflejo de Java para el hilo actual

Question

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

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

¿Se puede hacer esto con un SecurityManager, y en caso afirmativo, cómo?

Aclaración/Contexto: Esta es una continuación de another question sobre la restricción de los paquetes que se pueden 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).

En resumen, quiero (desde el código, no el archivo de configuración) desactivar Class.forName() y cualquier acceso al paquete de reflexión completo.

Answer 1

Depende de lo que intente restringir.

En general, la API de acceso público no está restringida. Sin embargo, siempre que no conceda el permiso no confiable al código ReflectPermission("suppressAccessChecks"), no podrá acceder a API que no sea 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 Security, include the restricted package in the package.access list. A continuación, proporcione de confianza código 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 el archivo de políticas al otorgar permisos.

La arquitectura 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.

---

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

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.

Answer 2

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 utilizan 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, debe trabajar con él, no en su contra.

Answer 3

me escribió un reemplazo de ClassShutter que permite el control de acceso de grano fino, por ejemplo, por método, por campo:

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