As the Java security model has hardened for browser-based applets, desktop administrators have asked for ways to manage version compatibility and security updates for their end-users.
A new feature is being introduced in Java 7 update 40 called “Deployment Rule Set,” designed to address the issue of security and compatibility in browser applets without affecting normal back-end Java programs like Eclipse, Freemind, or Tomcat. Specifically this deployment rule set addresses two major points:
This feature is geared towards two types of users:
Desktop Administrators, who manage a number of users and need to control version compatibility and default dialogs to specific company applets. Desktop Administrators should learn how to control Java across these user systems. For example, “automatically run browser applets signed by our company” or “run all our browser applets with the latest secure version, except for this one internal system that we know needs Java 1.6.”
Developers, who create Java applets and Web Start applications should be aware of the role that deployment rule sets play on their end-user’s desktop.
By creating a deployment rule set, desktop administrators can control execution and dialog prompts for desktop users and allow them to run known Java applets, either created by the company or used in critical systems.
Creating a deployment rule set involves a set of steps done once that can then scale out to any number of users and continue working in their future Java updates:
Find locations of known applets that your users interact with as part of their normal work. There are many means for gathering this information, from asking/monitoring users to speaking with your director of engineering if their team is creating applets. Ultimately, they can be listed through three means:
For the time being, just create a list of these.
Once you have a list of critical applets, the next step is to create a single file called rulset.xml that will look like this:
<!-- Example Deployment Rule Set that allow a desktop administrator to control end-user's execution of browser applets.
See http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/security/deployment_rules.html -->
<id location="http://payroll.example.org" />
<action permission="run" />
<id location="http://knownvendor.example.com/program" />
<action permission="run" version="SECURE-1.6" /><!-- For example if an application is known not to work on Java 1.7 -->
<id location="http://localhost" />
<action permission="run" />
hash="794F53C746E2AA77D84B843BE942CAB4309F258FD946D62A6C4CCEAB8E1DB2C6" /><!-- Oracle's public certificate hash. Having this will allow things like the Java.com secure version check applet. -->
<action permission="run" />
<action permission="default" version="SECURE" />
<id /><!-- Because this is both blank and shown last, it will be the default policy. -->
<message>Blocked by corporate. Contact email@example.com if you need to run this app.</message>
<message locale="fr">Bloqué par l'entreprise. Contacter firstname.lastname@example.org si vous avez besoin d'exécuter cette application.</message>
Complete details for creating this file can be found in the Deployment Rule Set documentation, but the gist is to specify the default action of which should run (with no interaction from the user), which should perform the default behavior (prompting the user), and which should be automatically blocked (explaining why).
Packaging your ruleset allows the desktop administrator to apply cryptographic signatures and prevent users from overriding your policy. This requires usage of a trusted signing certificate. The easiest route to get a signature is to buy one from a certificate authority like Symantec/Verisign, Comodo, GoDaddy, or any other; but in this case I have instructed my JVM to use a custom costlow-ca certificate authority (which only works on my machine). The default certificate authority list contains about 80 authorities from which you may purchase a signing certificate.
C:\Users\ecostlow\DeploymentRuleSet>jar -cvf DeploymentRuleSet.jar ruleset.xml
adding: ruleset.xml(in = 1492) (out= 612)(deflated 58%)
C:\Users\ecostlow\DeploymentRuleSet>jarsigner -verbose -keystore "c:\Users\ecostlow \javakeystore_keepsecret.jks" -signedjar DeploymentRuleSet.jar DeploymentRuleSet.jar costlow-ca
Enter Passphrase for keystore:
After creating the signed jar, desktop administrators should copy the DeploymentRuleSet.jar to the documented area for their platform so that rules are enforced for all users, across Java updates.
For end-users, simply have them visit a website like http://java.com/en/download/installed.jsp and verify their Java version (this site uses an applet, so see if it runs).
For desktop administrators, test your Deployment Rule Set by opening the Java Control Panel and navigating to the Security tab:
Clicking the “View the active Deployment Rule Set” should show you your same ruleset.xml file.
After performing the steps above, desktop administrators can now better control usage of the Java dialogs and prompts for managed users that will function across Java updates. To make changes in the future, simply roll out a new distribution of the DeploymentRuleSet.jar.
The Deployment Rule Set features is intended for mostly enterprise users to manage their own configurations. It is not meant as a way to simply "whitelist everything just so warning dialogs go away," "force everyone to never update," or "external users please download this file onto your system to use this application." By default, specifying the version="SECURE" attribute is best unless you know specific reasons indicating compatibility with a specific JRE version.
Publicly distributed Deployment Rule Sets found to contain insecure "whitelist everything" configurations may have their signing certificate blacklisted from future use of Deployment Rule Sets.