Disable Java reflection for current thread

Question

I need to call some semi-reliable Java code and you want to disable the ability to use reflection for the entire duration of this code.

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

Can this be done using the SecurityManager, and if so, how?

Clarification / Context: This is the next question from another question about restricting packages that can be invoked from JavaScript / Rhino. The accepted answer refers to a blog post on how to do this, and it requires two steps, the first of which uses the Rhino API (ClassShutter), the second - disabling reflection and Class.forName (). I thought I could make this second step cleaner using the SecurityManager (learning about the SecurityManager, which was said to be a complex beast along the way).

To summarize, I want to (from the code, not install the file) disable Class.forName () and any access to the entire reflection package.

Answer 1

It depends on what you are trying to limit.

In general, a public API is not limited. However, unless you provide the untrusted ReflectPermission("suppressAccessChecks") code ReflectPermission("suppressAccessChecks") , it will not be able to access the non-open API in another package.

If you have a list of packages for which you want to restrict access, there are two steps. Firstly, in the properties, Security includes a limited package in the package.access list . Then enter your trusted RuntimePermission("accessClassInPackage." + pkg) code RuntimePermission("accessClassInPackage." + pkg) .

The usual way to distinguish your untrusted code is to download it from another place and refer to different code bases in the policy file when granting permissions.

The Java security architecture is very powerful, but I know that it is also complex; if you want a more specific example, please describe which calls you want to limit, and I will try to be more explicit.

---

It would be very difficult, perhaps impossible, to do what you want without modifying the java.policy file and / or the java.security file. java.security.Policy represents information in java.policy but does not provide write access. You can create your own implementation of the Policy and set it at runtime if this allows any existing SecurityManager .

Alternatively, you can specify a custom java.policy file as a command line parameter. If you provide a complete application with a kind of launcher, this can be easily done. It also provides some transparency for your users. A sophisticated user can view the permissions that you would like to grant the application.

Answer 2

Well, you can override SecurityManager.checkMemberAccess and give stricter definitions. However, this is actually not the case. What happens, for example, if the code defines a finalizer?

In clarification: other APIs use reflection and other APIs. For example, java.beans, LiveConnect, and Rhino. An adversary could, within the framework of a script, say, create a new Rhino context without a shutter and thus load it into a full JRE. With an open system, a blacklist can never be completed.

In conclusion: to use the Java security model, you need to work with it, not against it.

Answer 3

I wrote a ClassShutter replacement that allows fine-grained access control per instance for each method per field:

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