问题
I'm designing a system for loading, handling and supporting plugins in Java applications. One feature that I feel is absolutely crucial to this before it can every be deployed is the ability to establish a secure environment where plugins are restricted to what they are allowed to do.
I've failed to understand how to use policy files programmatically without running the -Djava.security.manager argument at launch. So that's out for now.
My next idea was to override all the methods I cared about in SecurityManager in my own SecurityManager subclass and place restrictions on who could execute them.
The problem then arose that the only way to figure out who was asking this permission was through Thread ID checking. So, I devised a system where all plugin threads reside and can ONLY reside in the PluginThreads thread group.
That worked... until everything started blowing up. The problem is that some of the things being blocked are internal operations being executed by Sun's code.
So even the most basic operations such as opening a window would fail because my security manager was denying the access to Sun's code. There is no away around this using my method of Thread checking because Sun's code IS executing within the PluginThreads group.
So what I need to know is:
1) Is there possibly a way I could figure out the context within which the call is coming from using the current thread?
2) Is there a better method to doing this that I don't know about?
3) If that method involves policy files, how do you load them into your code?
4) Is there any other method you can think of to prevent Sun's internal Java code from being blocked?
回答1:
The SecurityManager is a horrible mess. Instead of iteratively granting more possibly abusable authority until it seems to work, you should consider requiring plugins be written in a subset of Java that allows you to soundly reason about what they can do.
Joe-E provides decomposable security. From http://lambda-the-ultimate.org/node/3830 :
We present Joe-E, a language designed to support the development of secure software systems. Joe-E is a subset of Java that makes it easier to architect and implement programs with strong security properties that can be checked during a security review. It enables programmers to apply the principle of least privilege to their programs; implement application-specific reference monitors that cannot be bypassed; introduce and use domain-specific security abstractions; safely execute and interact with untrusted code; and build secure, extensible systems. Joe-E demonstrates how it is possible to achieve the strong security properties of an object-capability language while retaining the features and feel of a mainstream object-oriented language...
回答2:
You need to use java.security.AccessController/AccessControlContext with the SecurityManager. The API has support for a context object of type Object, but in practice you need to be using an AccessControlContext. To give user code the correct permissions, supply a relevant ProtectionDomain through a subclass of SecureClassLoader (URLClassLoader.newInstance is a reasonable example of what you must get right).
For a GUI app (and this includes, for examples, anything using a particular part of java.beans), you will also need handle the AppContext (in the "Sun" implementation of the Java library). This is not a public API.
Threads and thread groups are not a good way to manage security. Unfortunately, this is part of how AppContext isolation works.
来源：https://stackoverflow.com/questions/8281695/how-to-implement-java-plugin-security-safely