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:
- The desktop administrator’s ability to control Java version compatibility, and default choices on the end-user’s desktop. For example your users may use most recent security updates for most browser applets but still use an old Java 1.6 for that one legacy application that is no longer maintained.
- The end-user’s awareness of who created the application and their default interaction (ask, run, or block). By seeing the actual company or signer, the user is protected from running code by someone that they do not know. For example, I would trust “My University” or “Erik Costlow” but not “Unknown publisher” or someone else claiming to be me.
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.
How to create a deployment rule set
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:
- Identify critical applets and web start applications, either by location (e.g. http://payroll.example.com), name (e.g. Solitaire), or code-sign hash.
- Create a file called ruleset.xml
- Package your ruleset.xml into a signed DeploymentRuleSet.jar
- Deploy your DeploymentRuleSet.jar to user desktops
- Verify usage of your rule set on a client desktop
Identify critical Applets and Web Start applications
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:
- This is a pattern matcher for URLs. You can identify applets through a simple combination of wildcards and automatic directories.
- The benefit of location is that it is easy to collect the right information.
This will implicitly cover anything located beneath the panel folder
- If you are following the security practice of signing your code so that users know your applets, you can provide a SHA-256 hash of your public certificate.
- The benefit of a certificate hash is that it recognizes a publisher, irrespective of location. The downside is that you must find the appropriate certificate.
- Examples of SHA-256 hashes look like 63 characters of hexadecimal: 794F53C746E2AA77D84B843BE942CAB4309F258FD946D62A6C4CCEAB8E1DB2C6
- To get these hashes, download a signed jar file or obtain one from the developers and run:
- keytool -printcert -jarfile MyProgram.jar > cert.txt
- Open cert.txt and find the earliest relevant signature. For example, I chose ours:
Owner: CN="Oracle America, Inc.", OU=Software Engineering, OU=Digital ID Class 3 - Java Object Signing, O="Oracle America, Inc.", L=Redwood Shores, ST=California, C=US
and then copied the hash line appearing a little later:
- Remove the : separator characters.
- Look at the JNLP launcher to identify the title of the application.
- Title must occur only with another attribute, like location or certificate. Title may not be used alone since it exists outside signed jars and deployed locations.
For the time being, just create a list of these.
Create a file called ruleset.xml
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).
Package your ruleset.xml into DeploymentRuleSet.jar
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:
Deploy your DeploymentRuleSet.jar to user desktops
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.
Verify usage of your rule set on a client desktop
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.
Notes and what Deployment Rule Set is not:
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.