I've implemented an applet and so far has been working with no hassle with Java 6. Recently, when I switched to Java 7 the applet stopped working, showing the following exception in javascript console:
Uncaught Error: java.security.AccessControlException: access denied ("java.util.PropertyPermission" "user.home" "read")
This behavior is consistently reproductible, just switching from one Java version to the other with the Linux command update-java-alternatives.
The applet is self-signed and all its public methods invoke AccessController.doPrivileged(), for example:
public File chooseFile() {
return AccessController.doPrivileged( new PrivilegedAction<File>() {
public File run() {
JFileChooser chooser = new JFileChooser();
chooser.setMultiSelectionEnabled(false);
return chooser.showOpenDialog(null) == JFileChooser.APPROVE_OPTION ?
chooser.getSelectedFile() : null;
}
} );
}
I've solved the problem using a java.policy local file, but requiring special installation procedures is not an option.
Does anybody know which are those Java 7 new security restrictions and/or how to circumvent them?
Some information can be found in Do java applets have to be signed with trusted cert authority with new v7 update 21? and http://www.oracle.com/technetwork/java/javase/7u21-relnotes-1932873.html
There will be more restrictions in the next scheduled security update in October 2013.
One requirement will be to switch from a selfsigned applet to a certificate from a trusted authority.
Related
In converting an ACF website to Lucee, we're facing some configuration issues. Our environment is Lucee5, Tomcat7, and Java.
There seems to be something not configured correctly for Lucee to be able to access an endpoint webservice via SSL. The same code works without any issues on CF9 on the same sever in a different Tomcat container.
The test call:
cfhttp(method="GET", charset="utf-8", url="https://our_lucee_server.org/wf/webservice/wf_webservice.cfc?wsdl", result="result") {
}
writeDump(result);
results in a:
java.security.cert.CertificateException: No X509TrustManager implementation available
It's been suggested that the endpoint serving the WSDL is the issue and that either Tomcat or Apache needs to be configured. Since Lucee is the program throwing the error, how can I determine what's preventing Lucee from accessing the endpoint?
The WSDL can be accessed no problem from a browser.
Things we've tried.
importing the SSL into Lucee from the target domain using Lucee server admin and restarting.
Spinning up an instance of Lucee using CommandBox, and then copying the cacerts file from CommandBox to the Lucee Server.
i think this can be solved by importing the cert for the site you are trying to access and adding it to the java home / jre / lib / security folder ...
for reasons unknown the cert for the site you are trying to access is not trusted so need to add it to trust store.
the final solution for us was running the following two commands.
this is for a CentOS7, Java 8, Tomcat, Lucee5 set up ...
step 1: back up the lucee keystore:
mv /opt/tomcatxxx/webapps/xxxx/WEB-INF/lucee-server/context/security/cacerts /opt/tomcatxxx/webapps/xxxx/WEB-INF/lucee-server/context/security/cacerts.bak
(where /opt/tomcatXXX/webapps/XXX/WEB-INF/ is the path to the lucee instance)
step 2: make a symbolic link between the java keystore and the lucee keystore
ln -s /opt/tomcatxxx/conf/s2s-ubertruststore_01_10_18.jks /opt/tomcatxxx/webapps/xxxx/WEB-INF/lucee-server/context/security/cacerts
Essentially, the keystore that came with Lucee5 didn't work out of the box.
Pointing the lucee keystore to the working Java keystore fixed it.
Step 3:
Restart Tomcat and lucee
I have a Java desktop app that uses JAX-WS to call some web services using the default Metro JAX-WS implementation in Java SE -- it's an SWT app that's launched via Java Web Start (.jnlp). The web services haven't had any problems until recently, when several instances started having errors when the web service calls are initialized:
WARNING: MASM0010: Unable to unmarshall metro config file from location [ jar:file:/C:/Program%20Files%20(x86)/Java/jre1.8.0_31/lib/resources.jar!/com/sun/xml/internal/ws/assembler/jaxws-tubes-default.xml ]
java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "accessDeclaredMembers")
Which ultimately leads to:
SEVERE: MASM0003: Default [ jaxws-tubes-default.xml ] configuration file was not loaded.
All of the clients experiencing this issue are on Windows using the JRE 1.8.31-45, both x86 and x86_64. I've been scouring this site and google, but haven't been able to find any information about this issue.
Thanks for any insight to this problem!
after upgrading from jre 1.7_80 to 1.8.0_51 we received the "MASM0003" error when we tried to start our webservices.
setting the ContextClassLoader before publish solved the problem:
Thread.currentThread().setContextClassLoader(getClass().getClassLoader());
endpoint = Endpoint.publish(wsdlUrl, engine);
I think you meet the same issue as me.
private static JAXBContext createJAXBContext() throws Exception {
return isJDKInternal()?(JAXBContext)AccessController.doPrivileged(new PrivilegedExceptionAction<JAXBContext>() {
public JAXBContext run() throws Exception {
return JAXBContext.newInstance(MetroConfig.class.getPackage().getName());
}
}, createSecurityContext()):JAXBContext.newInstance(MetroConfig.class.getPackage().getName());
}
private static AccessControlContext createSecurityContext() {
PermissionCollection perms = new Permissions();
perms.add(new RuntimePermission("accessClassInPackage.com.sun.xml.internal.ws.runtime.config"));
perms.add(new ReflectPermission("suppressAccessChecks"));
return new AccessControlContext(new ProtectionDomain[]{new ProtectionDomain((CodeSource)null, perms)});
}
that's code in JDK MetroConfigLoader, it will load the resource with specific privilege, and that's the root cause, so you can use jaxws-rt which is a third part lib to implement it,
Or you can load your resource in your class loader with AccessController.doPrivileged, so that's you can access your resource.
From my Java application I want to create a symbolic link. However my application can run in different circumstances, not all of those permit the creation of symbolic links. I have the following situations:
Linux - can always make a symlink
Windows - can make a symlink if you are running the application as an administrator.
To create the symlink I use Files.createSymbolicLink(). This throws an IOException under Windows when it doesn't have permission. To be precise the exception is:
java.nio.file.FileSystemException: test\link: A required privilege is not held by the client.
I want to be able to tell if I have this permission from the application (Java 7 or newer) before trying to make the symlink. How can I do this?
This code bellow will work only for Windows and comes with Java.
public static boolean AdminAuth() {
String groups[] = (new com.sun.security.auth.module.NTSystem()).getGroupIDs();
for (String group : groups) {
if (group.equals("S-1-5-32-544"))
return true;
}
return false;
}
The SID S-1-5-32-544 is the id of the Administrator group in the Windows operating system.
You can also take a look at this documentation regarding Application Manifest for Windows.
I have an applet I want to get running with Java 1.7.0_55. It works currently with Java 1.6.0_43
I dummy signed all jars as per Signing jar files with jarsigner. I run the applet now in java 1.7.0_55 but when I go to login to the applet I get the below error:
Caused by: java.security.AccessControlException: access denied
("java.lang.RuntimePermission" "getClassLoader")
I have added the domain and port to the exception site list so I don't think manifest permissions should be a problem? But maybe I am wrong.
Had to wrap code in this:
AccessController.doPrivileged(new PrivilegedAction<Object>() {
public Object run() {
return AppletService.validateLoginCredentials(Login);
}
});
I'm trying to read a envrionment varaible from a applet, here is my code
String env = System.getenv("TWS");
System.out.println(env);
Runtime rt = Runtime.getRuntime();
String s = env + "\\WebStart.bat " ;
System.out.println(s);
try {
Process p = rt.exec(s);
} catch (Exception e) {
}
when i run the code from netbeans by right click and run, it is running without a problem.
but when i put it to a jar file, add it to my web application and try to run it from a html page using the following code
<applet code="draw.class" archive='AppletTest.jar'>
<param name="shape" value="triangle"/>
</applet>
i'm getting a error saying access denied , java.lang.RuntimePermission
i am running this web application using tomcat 6.
i have read some guides and added the following entry to catalina.policy file in tomcat 6 and restarted tomcat
permission java.lang.RuntimePermission "accessDeclaredMembers";
but still the same warning. can some one please suggest a solution for this problem?
--rangana
When you run your applet from netbeans, Java virtual machines runs it under a different security regime than when you run it through browser.
Applets, downloaded through browsers, that are not signed using a security certificate, are considered to be untrusted and referred to as unsigned applets. When running on a client, unsigned applets operate within a security sandbox that allows only a set of safe operations. You can check if a perticular permission is granted to you applet or not by using SecurityManager. For example in your case :
System.getSecurityManager().checkPermission(new RuntimePermission("accessDeclaredMembers"));
You can know more about applet security here and here. A very nice tutorial on making signed applets can be found here.