How to safely implement Java plugin security?

Question

I am developing a system for loading, processing and supporting plugins in Java applications. One of the features that I feel is absolutely important for this before each of them can be deployed is the ability to create a safe environment in which plugins are limited to what they are allowed to do.

I did not understand how to use program files programmatically without running the -Djava.security.manager argument at startup. So for now.

My next idea was to override all the methods that I was worried about in the SecurityManager in my own subclass of SecurityManager and set limits on how they are executed.

Then the problem arose that the only way to find out who asked for this permission was to check the thread ID. So, I developed a system in which all plug-in threads are located and can ONLY be in the PluginThreads thread group.

It worked ... until it exploded. The problem is that some of the locked objects are internal operations performed by Sun code.

Thus, even the most basic operations, such as opening a window, will fail because my security manager refused access to the Sun code. There is no method around this using my thread verification method, because Sun code runs in the PluginThreads group.

So what I need to know:

1) Is it possible that I could figure out the context in which the call comes from using the current thread?

2) Is there a better way to do this that I don't know about?

3) If this method includes policy files, how do you load them into your code?

4) Is there any other method you can think of to prevent blocking of the Java internal code?

Answer 1

SecurityManager is a terrible mess. Instead of iteratively providing a more plausible credibility until it works, you should consider writing plugins in a subset of Java, which allows you to reasonably talk about what they can do.

Joe-E delivers sustainable security. From http://lambda-the-ultimate.org/node/3830 :

We introduce Joe-E, a language designed to support the development of secure software systems. Joe-E is a subset of Java that simplifies archiving and implementing programs with strong security features that can be verified during a security check. This allows programmers to apply the principle of least privilege to their programs; apply control monitors for specific applications that cannot be bypassed; implementation and use of domain security abstractions; Safely execute and interact with untrusted code and create secure, extensible systems. Joe-E demonstrates how to achieve the strong security features of an object language, while preserving the functions and sensations of the main object-oriented language ...

Answer 2

You need to use java.security.AccessController / AccessControlContext using SecurityManager . The API supports a context object of type Object , but in practice you need to use AccessControlContext . To give the user code the correct permissions, put the appropriate ProtectionDomain through a subclass of SecureClassLoader ( URLClassLoader.newInstance is a reasonable example of what you should get correctly).

For a GUI application (and this includes, for example, anything using a specific part of java.beans ), you will also need to process 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 AppContext .