"java.security.AccessControlException: access denied" executing a signed Java Applet

Question

I have a little Java Applet and I have an annoying issue. I have signed my JAR with my own keystore using jarsigner tool (following these instructions).

The Java Applet downloads a signed JAR and tries to launch it with an extended class of URLClassLoader. This JAR tries to execute this line of code:

ClassLoader.getSystemClassLoader().getResource("aResource");

It fails with a large stack trace finished by:

Caused by: java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "getClassLoader")
    at java.security.AccessControlContext.checkPermission(AccessControlContext.java:366)
    at java.security.AccessController.checkPermission(AccessController.java:555)
    at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
    at java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1476)
    at test.SecondJAR.main(SecondJAR.java:8)

(Line 8 of test.SecondJAR corresponds to getResource(...) method

When the Java Applet is launched, the user is prompted to accept the certificate if he/she trusts the publisher:

Even if I accept it, the exception occurred. Even if I install the certificate, and the prompt message is automatically accepted, the exception occurred.

I have tried too this:

AccessController.doPrivileged(new PrivilegedAction<Object>() {
    public Object run() {
        ClassLoader.getSystemClassLoader().getResource("aResource");
        return null;
    }
});

And it fails with the same exception.

Any help would be appreciated!

Solution 1

Finally I have found the answer!

I followed the guidelines of Andrew Thomson and I created a custom SecurityManager. My little security manager looks like this:

private class MySecurityManager extends SecurityManager {
    @Override
    public void checkPermission(Permission perm) {
        return;
    }
}

It is a neglected security manager that accepts all permissions. It should be improved allowing only getting system ClassLoader in runtime.

To use my ugly SecurityManager I added these lines at the beginning of Java Applet start() method:

SecurityManager sm = new MySecurityManager();
System.setSecurityManager(sm);

With this workaround, all the process worked as expected!

Maybe there exist other (better) solutions, but it worked for me.

Thank you all!

Solution 2

The problem is that the JRE only considers code in the original code-base to be trusted. Two possible solutions are:

1. Set a custom security manager that allows the new code to have the privileges it requires.
2. Wrap the new code in a PrivilegedAction & call it from AccessController.doPrivileged(..) method (just occurred to me as a possibility, not sure if I understand the scope of it, completely untested).

Comments

[logoff]

I have edited my question adding the AccessController.doPrivileged(...), but I realized that it fails too. How can I set a custom security manager?

[Brett]

@logoff Setting a security manager in an applet may set it for other applets.

[logoff]

@Tom, the second JAR is not an applet. but anyway, how do I set a security manager to avoid this exception?

[logoff]

@Tom for sure. the applet launches a main method of the other JAR.

[Andrew Thompson]

Glad you got it sorted. :) But I suspect Tom (who knows 100 times more about security than I do), would recommend a more restricted security manager than that. From my limited knowledge, a security manager that allows dynamically loaded code 'all privileges' (which, BTW is a less restrictive SM than applied to a trusted applet) is 'way too much' permission.

[Andrew Thompson]

@Tom Could you look over the OP's answer and comment further?

[Andrew Thompson]

...as a 'for instance'. Imagine the code being launched, creates a JFrame that calls setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE) - seemingly innocent, yet it ends the JVM that is running the frame, or probably also the applet. The typical trusted applet Security Manager (SM) would not permit calling System.exit(n). That applet might be running in a web page where several applets share the same JVM. It is a 'guest' in that JVM, yet it is effectively 'burning the guest house down' by ending the JVM!

[logoff]

I agree 100%, but anyway, as I mentioned, it is possible to create a SecurityManager allowing only specific permissions. I understand the drawbacks of adding these kind of privileges, but it is the only way I found. I expect somebody else show me a correct, better and standard way to achieve my objective: execute signed resources loaded at runtime.

[Brett]

With this security manager any applet (running in the same process) will be able to do anything. That's really quite bad. In Java permissions of code are generally given based on CodeSource delivered through ProtectionDomain (there's also the non-public AppContext mechanism which is really odd).

[Andrew Thompson]

OK. 1) check the code-base of the classes asking for the permission. Is it code that you expect? 2) What permissions does it require? If you are expecting local file-system and printer access, why is it trying to access a foreign site, or code-base..?

[logoff]

I agree with all, but I need a way to execute my trusted signed code. My own code!

[Andrew Thompson]

If it is code you wrote, restrict the SM to packages you expect to see.. (+ more, that is not all of it, since I can create packages of your spec.). I really feel I am doing less here than needed. I am a 'newbie' at security. :(

[logoff]

@Andrew How do I check a my code ? It is generated each moment. It is signed, for me a good mechanism to trust it.