Java security evolution and concepts, Part 3: Applet security

Tackle Java applet security with confidence

1 2 3 4 Page 4
Page 4 of 4

In summary, the Java plug-in checks for the permission entry usePolicy and will pop up the dialog box described earlier only if that entry is not present. If that entry is present, the plug-in quietly accords permission based on the installation's policy. The policy file entry can override the security decisions made by the plug-in, thus permitting greater access. Of course, if the code is not signed, it's confined to the sandbox.

Fine-tuning the policy file

In the examples above, the policy was set at a very coarse level. You may want to fine-tune the policy to incorporate the origin of the code and the signer, as we saw in the example with Java 2.1.2.

As a first step, import the public-key certificate into the keystore.

C:\signtool> keytool -printcert -file rags.cer
Owner: CN=Raghavan N. Srinivas, OU=Sun Microsystems (MDDR), O=Raghavan N. Srinivas, L=Burlington, ST=MA, C=US
Issuer: EmailAddress=server-certs@thawte.com, CN=Thawte Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA
Serial number: 7c093
Valid from: Wed Dec 13 16:18:38 EST 2000 until: Fri Dec 21 17:20:22 EST 2001
Certificate fingerprints:
         MD5:  34:6C:32:F9:2E:0D:0D:B3:99:13:FC:EC:F3:D9:8B:AF
         SHA1: 77:5D:D9:EC:62:4D:C7:47:D9:58:05:73:B9:34:60:F6:38:A8:36:94
C:\signtool> keytool -import -file rags.cer -alias rags
Enter keystore password: 
Owner: CN=Raghavan N. Srinivas, OU=Sun Microsystems (MDDR), O=Raghavan N. Srinivas, L=Burlington, ST=MA, C=US
Issuer: EmailAddress=server-certs@thawte.com, CN=Thawte Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA
Serial number: 7c093
Valid from: Wed Dec 13 16:18:38 EST 2000 until: Fri Dec 21 17:20:22 EST 2001
Certificate fingerprints:
         MD5:  34:6C:32:F9:2E:0D:0D:B3:99:13:FC:EC:F3:D9:8B:AF
         SHA1: 77:5D:D9:EC:62:4D:C7:47:D9:58:05:73:B9:34:60:F6:38:A8:36:94
Trust this certificate? [no]:  yes
Certificate was added to keystore

Change the key and the origin of the code in the policy file to look something like this:

C:\signtool> type c:\windows\.java.policy
/* AUTOMATICALLY GENERATED ON Mon Dec 04 21:19:33 EST 2000*/
/* DO NOT EDIT */
keystore ".keystore", "jks";
grant signedBy "rags" codeBase "http://www.javaworld.com/jw-12-2000/security/writeFile.jar" {
  permission java.lang.RuntimePermission "usePolicy";
  permission java.io.FilePermission "C:${/}tmpfoo", "write";
};

The keystore is relative to the URL of the policy file. In this particular case, the keystore file -- .keystore -- is in the same directory as the policy file.

As alluded to before, fine-grained policy can be achieved by according separate permissions based on the CodeSource that comprises both the signedBy and codeBase properties. In the example above, permissions to write a file on the local filesystem are provided to the code based on its signature and its origin. Similarly, other permissions can be accorded in the policy file.

Automatic deployment of policy files

Looking at the role of policy file above, it seems like a chicken and egg problem -- if we could only modify the policy files, the policy files could then provide the optimal access to an applet that we deploy. It's unreasonable to expect unsophisticated users to modify their policy files. The user has to provide initial access for the applet to be able to modify the policy file anyway. Assuming this happens -- that is, even if the user grants access just for the session -- the applet can modify the policy file to provide the appropriate level of access to itself without popping up the dialog box in the future.

Given all this, is it a reasonable approach for an applet to modify the policy file directly without informing the user? I personally think that approach is akin to sneaking up behind an unsuspecting friend. The approach may not always work, especially when a similar approach is used by more than one applet. Also, the user may always modify the policy file explicitly in the future, invalidating some of the changes made. You may also lose some friends and business due to your covert action.

A more acceptable approach might be to deploy a separate applet that informs the user and updates the policy file with his or her consent, clearly outlining the potential risk in the operation. Since the initial step can happen only with the permission of the user, it's a reasonable way to work with the user to modify the policy file -- the applet aids the user in providing the necessary permissions via the policy file.

In intranet scenarios, separate policy files can be maintained for each applet. These can be added to the ${java.home}lib/security/java.security file via an entry which looks like this:

policy.url.3=http://www.javaworld.com/javaworld/jw-12-2000/security/writeFile.policy

For a Solaris or Linux system, add the following entry:

policy.url.3=http://www.javaworld.com/javaworld/jw-12-2000/security/writeFile-unix.policy

The writeFile.policy file's contents are:

/* AUTOMATICALLY GENERATED ON Fri Nov 10 17:07:18 EST 2000*/
/* DO NOT EDIT */
keystore "writeFile.keystore", "jks";
grant signedBy "rags" codeBase "http://www.javaworld.com/jw-12-2000/security/writeFile.jar" {
  permission java.lang.RuntimePermission "usePolicy";
  permission java.io.FilePermission "C:${/}tmpfoo", "write";
};

Correspondingly, the file contents of writeFile-unix.policy are:

/* AUTOMATICALLY GENERATED ON Fri Nov 10 17:07:18 EST 2000*/
/* DO NOT EDIT */
keystore "writeFile.keystore", "jks";
grant signedBy "rags" codeBase "http://www.javaworld.com/jw-12-2000/security/writeFile.jar" {
  permission java.lang.RuntimePermission "usePolicy";
  permission java.io.FilePermission "/tmp/foo", "write";
};

after the policy.url.1 and policy.url.2 entries. This policy will affect multiple users that run the plug-in from the same path. The content of all the policy files will be used to administer the overall policy.

Conclusion

In earlier articles, we discussed the different aspects of Java security, starting with its evolution. This article aimed to combine the concepts presented earlier with get-your-hands dirty applet code, a frequently misunderstood aspect of Java security. As we've seen, by signing the code once, the applet can be run identically on a variety of operating systems -- Linux, Solaris, and Windows -- and under a variety of browsers and browser versions. Keep in mind that code signing should not be construed as a silver bullet to solving all security problems. It's a critical link in the whole security chain.

In my next article in this series, I'll discuss the Java Security extensions, also referred to as optional packages. I'll also touch upon the Java 2 Platform, Enterprise Edition (J2EE) and RMI security, both of which take a different approach to security. Under these schemes, it is no longer left to the developer to assemble the building blocks to provide security; instead, the developer and the deployer share responsibility in providing overall system security with lesser emphasis on programming and more emphasis on customization via a declarative model.

Raghavan Srinivas is a Java technology evangelist at Sun Microsystems who specializes in Java and distributed systems. He is a proponent of Java technology who teaches graduate and undergraduate classes in the evening. Srinivas holds a master's degree in computer science from the Center of Advanced Computer Studies at the University of Southwestern Louisiana. He likes hiking, running, and traveling, but most of all loves to eat, especially spicy food.

Learn more about this topic

1 2 3 4 Page 4
Page 4 of 4