Running and restricting unsafe code within a safe application

Question

My application (actually a web application) will do the following:
- Obtain Java source code from an untrusted source. One such piece of source code will be a JUnit test class (and another will be the class(es) it is testing).
- Compile the source code in memory, storing the compiled classes into byte[] arrays, using the JSR-199 compiler.
- Load the JUnit test class that was just compiled, using a URLClassLoader.
- Run the JUnit test (using the JUnitCore core class in JUnit 4.4) and report the results to the client.
Since the source code is untrusted, it may do malicious things that I want to prevent. I have wide flexibility in limiting the permissions of the code; for example, I can disallow file reading and writing, network access, etc. However, I do not want to restrict these permissions on my own application, or the JUnit code itself (such as the class JUnitCore, which runs the JUnit test). So the flow will go like this:
1. Allow unrestricted security policy initially.
2. Obtain source code.
3. Compile source code.
4. Apply restricted security policy.
5. Load compiled classes and use JUnitCore to run the JUnit test class. (Loading should be restricted so that static initializers in the unsafe code cannot do harm.)
6. Remove restricted security policy.
7. Report results (in particular, violating the security policy means, "Test failed").
However, my very basic understanding of the security policies in Java is that permission granting within a call stack seems to go the other way; untrusted code is run with a restricted security policy, but it may make a call to a system library, for instance, that runs as a privileged block and has extra permissions that the unsafe calling code does not have. I want to flip that around and say, "My code is okay, but when it executes the method JUnitCore.run, restrict the access of that method". Or, to be even more fine-grained, "My code, and any code from junit-4.4.jar such as JUnitCore, is okay, but somewhere in the bowels of JUnitCore.run, some unsafe code will eventually be called, and I want its access restricted."
I don't even know if this is possible the way I have stated it, and if so, I am having trouble mapping the abstract concepts of a codebase, code signers, etc., on to the specific pieces of code in my project. Someone on another forum suggested that the URLClassLoader used to load the unsafe classes would somehow play the role of a codebase, so that I could state that anything loaded with that class loader should be restricted, but I have not seen a syntax for expressing this in the documentation. Plus, I don't see how using the URLClassLoader used to load the unsafe classes would play a role, since permissions are granted, not denied. It seems that I need a way to map a codebase to the safe code, not the unsafe code, and then grant permissions to the unsafe code.
It seems like it could be as simple as creating a policy file (say, unsafe.policy) with the contents
grant codebase "My Application + supporting classes I wrote + any class in junit-4.4.jar" {
    permission java.security.AllPermission;
};and running java -Djava.security.manager -Djava.security.policy=unsafe.policy MyApp, except that I don't really know how to specify the codebase, or if it is possible to draw a box around my code + junit-4.4.jar in that way.
Thank you,
Dave
Edited by: pexatus on Aug 10, 2008 12:48 PM

Answer 1

>
Have a look at AccessController and AccessControlContext. These are the tools you need for this task.
>
By "this task", do you mean, "writing a custom SecurityManager"? Or do you mean the more general task of creating a security policy (such as by writing a policy file) to ensure untrusted code does no damage?
I'm sorry to be so slow, but I don't see how to use the two classes you mention for my task. I assume that the only reason I need AccessController is to call AccessController.getContext() to get an instance of AccessControlContext, since the other methods of AccessController don't seem to be what I need. AccessController.checkPermission presumes I have successfully written the security policy already, which is the problem I am trying to solve, and the various AccessController.doPrivileged methods appear to grant extra privileges to code that is called, which is the problem I mentioned earlier: I want certain code that I call to have fewer privileges, rather than more.
Similarly, I do not see any methods in AccessControlContext that could tell me whether the current executing code is trusted or not. It, too, has a checkPermission method that will work if I set up the security policy correct, which is what I cannot figure out how to do in the first place, and a getDomainCombiner() method. A DomainCombiner has only a single method, which assumes that I already have an array of ProtectionDomain objects. To create a ProtectionDomain, I need to specify a CodeSource, which is, as the documentation indicates, an extension of "the concept of a codebase". It is at this point I get completely lost in the abstract and generic nouns such as domain, codebase, code source, context, and I do not see how to connect them to concrete nouns that I understand such as class file, package, method, etc. Is it the case that I need to create a CodeSource representing the trusted classes? Is there an elegant way to create a CodeSource representing all the classes in a a project (say, under a given directory, or contained within a given jar file), short of enumerating them or digging into directories and jar files doing a search? And once I create this CodeSource within my program, what do I do with it to specify that I want my security policy to allow all permissions for the classes represented by the CodeSource, and restricted permissions for all classes outside the CodeSource, regardless of call order? (since trusted code will call untrusted code, and I do not want the permissions of the trusted code to be inherited by the untrusted code)
Again, I am sorry to be so ignorant, and I appreciate the help, but I am simply having trouble connecting the concepts described in the documentation to the specific concrete aspects of my application.
Dave