Java 7u4 webstart security exception: Class does not match trust level

Question

We began to notice that with Java 7 (particularly with update 4), that all our users began to see this with our Webstart app:

[14:42:58,422] AWT-EventQueue-0(DEBUG) java.lang.SecurityException: class "CLASSNAME" does not match trust level of other classes in the same package
[14:42:58,422] AWT-EventQueue-0(DEBUG) at com.sun.deploy.security.CPCallbackHandler$ChildElement.checkResource(Unknown Source)
[14:42:58,422] AWT-EventQueue-0(DEBUG) at com.sun.deploy.security.DeployURLClassPath$JarLoader.checkResource(Unknown Source)
[14:42:58,422] AWT-EventQueue-0(DEBUG) at com.sun.deploy.security.DeployURLClassPath$JarLoader.getResource(Unknown Source)
[14:42:58,422] AWT-EventQueue-0(DEBUG) at com.sun.deploy.security.DeployURLClassPath.getResource(Unknown Source)
[14:42:58,422] AWT-EventQueue-0(DEBUG) at java.net.URLClassLoader$1.run(Unknown Source)
[14:42:58,422] AWT-EventQueue-0(DEBUG) at java.net.URLClassLoader$1.run(Unknown Source)
[14:42:58,422] AWT-EventQueue-0(DEBUG) at java.security.AccessController.doPrivileged(Native Method)
[14:42:58,422] AWT-EventQueue-0(DEBUG) at java.net.URLClassLoader.findClass(Unknown Source)
[14:42:58,422] AWT-EventQueue-0(DEBUG) at com.sun.jnlp.JNLPClassLoader.findClass(Unknown Source)
[14:42:58,422] AWT-EventQueue-0(DEBUG) at java.lang.ClassLoader.loadClass(Unknown Source)
[14:42:58,422] AWT-EventQueue-0(DEBUG) at java.lang.ClassLoader.loadClass(Unknown Source)...More

Where CLASSNAME = pretty much every class at random points from several jars in the app execution, breaking several behavior. If our users were to use Java 6, they have no problems! Just 7 (update 4). We sign ALL our jars, both the main application jar and it's library jars. i.e Users launching our webstart app see the blue shield instead of yellow or red.

This is obviously an issue as users are more frequently now upgrading to Java 7. I have tried to force our app to use Java 6 on the user machine either by using a previous installation(works), or installing a new one....with the j2se version="1.6" tag around resources but this causes it's own problems that would probably be best to make into it's own thread (the auto-jre-installation part).

Did Oracle break Webstart security with Java 7u4? How do I solve this securityexception issue?

Answer 1

Just the orig author of the jarsigners hack checking in. I was directed here by another dev, to whom I originally shared the hack with.

Based on his continued investigation into this you will need to add the following to calls to the hack

callNoArgMethod("getSigningData", jar);
makeHardLink("signingDataRef", jar);

callNoArgMethod("getManifest", jar);
makeHardLink("manRef", jar, n);

The manifest calls were not part of the solution to this post. They were found when an acceptance test was created to repro the issue.

Based on this new info, we've changed our approach, we now use reflection to call all "get" methods (the calls to the get methods are required to initially populate the softreferences, if they aren't populated already)

And then reflectively discover all softreferences in the CachedJarFile class and create hardlinks to them.

This should future proof the solution from further internal renames/refactors, as long as the CachedJarFile stays in place and the basic premise of the hack stays true. (ie: make softreferences into hardreferences.

Answer 2

I had the same problem with 1.7.07: my webstart application failed randomly with the same error message while loading classes. I found a interesting workaround on this page oracle forums. The last answer describes a workaround for the problem (Java 6) - the reference to the Signature of the jars are hold as soft reference and these may be garbage collected, and this causes the error message. This can be adopted for Java 7 with some additional lines

// Java 1.7
callNoArgMethod("getSigningData", jar);
makeHardLink("signingDataRef", jar); 

Answer 3

I think you may be experiencing this bug.

The bug status says that a fix has been delivered in 7u4. But that doesn't jell with what you are saying. Perhaps the "fix" breaks ....

In the meantime, the comments on the bug by "squaat" mention possible workarounds. For instance, increasing the initial heap size and/or using a preloader to force some JARs to load earlier.

Answer 4

I've the same problem after updating to JRE 8 update 91. With previous releases 1.6, 1.7, 1.8 update 77 my applications runs fine.

Has Oracle reintroduced a bug that was present in JRE 1.6 bug?

The only work around that I've found is to disable mixed code control from Java Control Panel.

---

I fixed it. The problem was in a library used by my applications. The MANIFEST.MF present in the jar was this:

Manifest-Version: 1.0
Ant-Version: Apache Ant 1.7.0
Created-By: 1.5.0_07-87 ("Apple Computer, Inc.")
Built-By: wolf

Name: common
Specification-Title: swixml
Specification-Vendor: swixml.org
Specification-Version: 1.6
Implementation-Title: org.swixml
Implementation-Vendor: swixml.org
Implementation-Version: 1.6 beta 1 (#151)

The "Name" property is used for resource specific entries as stated here http://docs.oracle.com/javase/7/docs/technotes/guides/jar/jar.html#JAR_Manifest

Signing this jar the "Name" entry is interpreted as a resource but there is no resource to sign. When the application is launched javaws finds a mismatch between the resources reported in MANIFEST.MF and the effective resources in the jar blocking the application

Answer 5

I've been struggling with the same symptoms using JRE 7u5. The exact same application web started without problems using JRE 6u33.

In my case the problem was caused by one of my extension jnlp files. The master jnlp file specified all-permissions security, whereas the extension jnlp did not declare any specific security requirement (just an empty security tag).

This caused the extension jars to be loaded in the sandbox. Apparently Java 7 doesn't accept mixing jars with different security requirements, even though they're all signed.

The problem was fixed by making sure all extension jnlp files specified the same security requirements as the master jnlp file.