Policy-setting fighting notes for running outdated applets

Even though Java 11 has been released and applets cannot be used, there is still a demand for new functions to be realized with Java applets. There are various reasons for wanting to use applets, but most of them are "I want to perform native processing from JavaScript". At such times, I'm not the only one who is always addicted to security-related environment settings. I don't really want to use applets, but I had to compromise and use them, and the stress of taking time to set up the environment is not overwhelming. Since such an experience is enough once, I will summarize the addictive points I encountered here so that I will not meet such an experience in the future.

Java.policy misconfiguration

Applets can do native processing that JavaScript cannot do. Those who think so should be careful. Even applets can't be run without any restrictions, so you have to set security exceptions in $ JRE_HOME / lib / security / java.policy. If you don't do this, you will get a runtime exception when trying to perform native processing (such as writing a file) from an applet.

If you want it to work for the time being, give all permissions java.security.AllPermission; to all entries.

grant {
	permission java.security.AllPermission;
}

Limited by codeBase

If you want to set only for a specific entry, describe codeBase. The specification changes depending on whether it is placed on a local drive or downloaded from the Web and executed. For details of the description, refer to the official Java document.

https://docs.oracle.com/javase/jp/8/docs/technotes/guides/security/PolicyFiles.html

Restricted by permission

If you want to give only specific privileges, specify permission java.security. ~ Class name ~;. For details of the description, refer to the official Java document.

https://docs.oracle.com/javase/jp/8/docs/technotes/guides/security/permissions.html

Missing read of java.policy in java.security

If java.policy is described correctly but the settings are not reflected, check if java.policy is read in the first place. The reading order is very important because java.policy splits the definition into multiple files and overwrites the settings in the order they are read. There is a policy.url.n specification to read java.policy in $ JRE_HOME / lib / security / java.security, so check here. By default it should look like this:

policy.url.1=file:${java.home}/lib/security/java.policy
policy.url.2=file:${user.home}/.java.policy

For $ {java.home} and $ {user.home}, after starting the applet, open the "Java console" to check the properties, or create a confirmation program to check.

System.out.println(System.getProperty("user.home"));

For other details of policy.url.n, refer to the official document. https://docs.oracle.com/javase/jp/8/docs/technotes/guides/security/PolicyFiles.html#DefaultLocs

Code for privileged execution

If you get a permission exception even though java.policy is set correctly, make sure that the Java applet is implemented with privileged execution in mind. Processing that becomes a security exception cannot be executed unless APIjava.security.AccessController # doPrivileged for privileged block is used.

As a common case, I set it to work in the test environment (AllPermission is specified without specifying codebase in grant), but it is a pattern that laments that it does not work in the production environment. Since it feels like it has stopped working just because the java.policy has changed, it is misunderstood that "java.policy is wrong", but the applet implementation is actually bad.

public class SampleApplet extends Applet {
	public void hoge() {
		AccessController.doPrivileged(new PrivilegedAction<Object>() {
			@Override
			public Object run() {
				//Processing that requires authority
				//new Robot().createScreenCapture etc.
				return null;
			}
		});
	}
}

The official documentation for privileged blocks is ↓↓ https://docs.oracle.com/javase/jp/8/docs/technotes/guides/security/doprivileged.html