|
|
Java Security Applets |
|
|
The Java security manager is designed to run programs inside of a "sandbox" so that they cannot delete files and cause havoc. The following applets test the security manager in various ways. These applets require Java version 1.2 and later. If you are using Internet Explorer or Netscape 4 you will need to download Sun's Java Plugin to run the applets or use Java WebStart and click on the JNLP links.
Source / Jar / JNLP / Signed JNLP / GPL
The Security Manager Test applet tests the security manager by requesting permission for many different operations. It can be used to test new security managers and security policies or just as a reference list, though there are a few permissions it does not test yet. Obviously it cannot test all combinations, but it tries to cover the bases.
Source 1 2 / Jar / JNLP / Signed JNLP / GPL
This applet will attempt to determine the ProtectionDomains for the classes on the stack and then print out the invidual permissions granted to each domain. A permission must be granted in all domains in order to pass the security checks. This applet should fail to get access to the ProtectionDomain objects when running in the browser, but can be downloaded and run as an application. It's also an example of several ways to examine the stack.
These test were written in preparation for writing a dynamic security policy for Java, where security checks may bring up dialogs asking the user to permit operations. In the 'Security Test' applet, permissions are listed as they are tested instead of all at once to help test these dialogs. If you use Sun's Java plugin you can see this kind of security policy in action - running the applet will bring up a dialog asking the user whether to allow the applet to print.
Currently, code executed from the web either has to either not perform any secure operation at all or has to be digitally signed and trusted. If an applet ever wants to save a file then you have to grant it permission to save a file at any time. Personally, I would rather have the program start running so that I can see it running before granting it permissions; if I never cause the code to save a file there's no reason to even ask me whether to allow it. Even if the applet is trusted, having a log of secure operations attempted would be a valuable addition.
An interactive security manager should balance security with not bothering the user. There shouldn't be a dialog for each and every test line in the first applet! One possibility is to group permissions together into categories and allow users to grant or deny permissions for the category as a whole. Another possibility is a 'smart' security manager that automatically allows harmless permissions like reading a file but then asks the user if the code thereafter tries to possibly communicate the information (by opening a network connection, say). This would certainly be more convenient but may be error-prone and complicated. Probably the best solution overall is to simply remember the user's choice so that even if there are several annoying dialogs they only have to answered once.