Applet Restrictions and How to Overcome Them

Oracle's slow reaction to security bugs in the applet runtime environment has thrown a bad light on Java in general, although the problem is restricted to applets. The flaws allow them to break out of their sandbox which should restrict access to the computer on which they are running. A normal Java program running on your machine can do what any other local program can do on your machine: basically everything which you can do yourself.

As a reaction most modern browser and even the runtime environment itself restrict execution of applets by showing scary message boxes and complicated questions. So what can you do if you want to use an applet like the DXF Applet provided here and spare the user at least most of the message boxes and questions? The answer is that there are basically two ways:

  1. Sign the applet with a signature backed by an official certificate authority (CA). This is the only useful way when you want to allow the applet to be run by anybody from the internet, and it will cost you money.
  2. Change security policies. This only requires a bit of work and is otherwise free, but is useful only in a restricted environment where you have access to the computers running the applet, either in an intranet or when you have a very special user base which you can convince of installing a small file on their computer.

Signing the Applet

Signing the applet means that you acquire a signing certificate and use that to sign the applet. That basically means that you make sure that the applet is provided by you and you stand in for it with your name. You can create such a certificate on your own, but that will not help as browser will not accept such self-signed applets any better than unsigned applets. I have a self-signed applet here on some pages like this one, so you can try out what happens when you access that. What you need is a backup by a certificate authority which is accepted by browsers. Such a code signing certificate costs some 200US$/year or more. As I don't make any money with the free applet I'm currently not willing to pay these amount of money year after year, although obviously it would be the simplest solution. But anybody can sign an applet, all what you need is the jar file you can download from my web page and an official code signing certificate.

If you are willing to pay here's Oracle's official information on how to sign. You stand in for me, so you'll have to trust that I didn't include any mischief in my code. I didn't, but that is hard to proof.

Setting the Permissions Attribute

Latest changes in the security system require that a Permissions attribute appears in the Manifest gfile contained in the applet's jar. It can be set either to sandbox or to all-permissions. What has to be set depends on the circumstances. If you want to use the applet just to display DXF files you may be well off with the sandbox setting, but as I have to set something starting with applet version 1.50.22 I'm using all-permissions. If you want to change that you'll have to open the jar file (which is just a ZIP archive, so renaming it to have a .zip extension temporarily might help), locate the META-INF directory inside which contains a file called MANIFEST.MF. Open this file with a text editor, locate the line

  Permissions: all-permissions

and exchange it with

  Permissions: sandbox

All this has to happen before signing the applet! More information on the MANIFEST.MF file and the attributes inside can be found here.

Twiddling With Policies

A not well-known fact is that Java already includes everything to fine-tune restrictions of applets by changing or adding policy files. There is a global policy file in the Java install directory under lib/security/java.policy and a user specific one called .java.policy in an operation system dependent directory which is read by the Java runtime. If you are in an intranet you can change the global one for all users, but take care because your changes might not survive Java updates. Otherwise you can setup a user specific one (or make your users install one). See this page for more information, eg to find the location where the user specific file is expected for the OS you are using. Basically you can edit the policy file with any editor, but the Java runtime comes with a program called policytool which makes the job a lot easier, so you should add that.

Here's an example .java.policy file for the applets on my page. It allows applets provided here to write and delete files (you can restrict that even to a specific directory, but that is complicated to get right in general), and to access the printer. The first two are necessary if the applet needs to save PDFs, PNGs or similar from the displayed DXF (delete is needed so you can overwrite a file), the latter for printing. Here is what the file contains:

/* AUTOMATICALLY GENERATED ON Thu Feb 06 14:20:16 CET 2014*/

grant codeBase "" {
  permission "<>", "write";
  permission "<>", "delete";
  permission java.lang.RuntimePermission "queuePrintJob";