Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

New java.security.AccessControlException in Java 8

Previously working network code is throwing java.security.AccessControlException in a fully sandboxed Java applet.

Can't get socket 2255: java.security.AccessControlException: access denied ("java.net.SocketPermission" "50.31.1.13:2255" "connect,resolve")

What has Oracle changed - what new security hoop must be jumped to keep sockets to working?

This worked/works in Java 1.7.0_55 and all previous versions of java.

like image 298
ddyer Avatar asked Apr 21 '14 01:04

ddyer


2 Answers

This has indeed changed… From the documentation

http://docs.oracle.com/javase/8/docs/technotes/guides/jweb/enhancements-8.html

  • For sandbox RIAs, URLPermission is now used to allow connections back to the server from which they were started. URLPermissions is granted based on protocol, host and port of the code source. This change has the following implications:

    • For sandbox RIAs, SocketPermissions for the origin host is no longer granted. Calls from JavaScript code to the RIA are not granted SocketPermissions beginning with JDK 8.

In other words, you cannot create a new Socket in a sandbox anymore. You can only create a URL using the same host, same port, and same protocol as the codebase from a fully sandboxed applet then.

Unless Oracle changes its mind, there is no way for a sandboxed applet to get around this (otherwise it would render the entire security concept broken).

like image 82
Holger Avatar answered Oct 27 '22 13:10

Holger


Well, for me it sounds like Oracle decided to strengthen the applets security requirements. Here is what I found on CodeRanch:

Make SecurityManager accept socket-related permission checks:

System.getSecurityManager().checkPermission(new SocketPermission("50.31.1.13:2255", "accept, connect, listen"));
//I used IP address from your exception

Now, thread-related checks:

System.getSecurityManager().checkPermission(new RuntimePermission("readerThread"));

These lines should be put in the beginning of main() method.

The second thing needs to be done is signing your jar/war/ear file. First, create a keystore:

keytool -genkey -alias philip -keystore keystore  

Now, put the signed by CA in your truststore certificate to it or create self-signed certificate:

keytool -selfcert -alias philip -keystore keystore 

And finally, sign the file:

jarsigner -keystore keystore -signedjar WhatYouWantTheSignedJarToBeNamed.jar ThePreviousJARYouCreated.jar philip   

Actually for signed JAR file the SecurityManager-related magic might be an overhead, but in my opinion it is safer to do both.

Also be advised that sometimes you may need to sign external jars, not only the jar where your applet resides.

like image 32
Alexey Malev Avatar answered Oct 27 '22 12:10

Alexey Malev