Recently I encountered a situation whereby a System Administrator needed to adjust thieir systems to run a specific RIA on an older version of Java. By using Deployment Rule Sets, we were able to achieve the desired outcome. The specific RIA ran using the older version of Java with no prompts to the end users, while all other RIA applications used the latest, most secure version of Java.
This post is intended for System Administrators managing a white list within an organization.
In this particular case, the RIA itself was designed to run on Java 6 update 31 (released in February 2012, but public updates for Java SE 6 ended in February 2013). That also means that it does not adhere to the security requirements introduced in a recent Java SE 7 Critical Patch Update. Because this RIA was known to be safe and necessary for business operations, the goal was to be able to execute it with no prompts.
When delegating RIAs to use older Java versions, it is necessary to have at least two installations available:
Information about these installation types can be found within a previous post, Managing Multiple Java Versions. Comprehensive documentation is provided by Oracle about silent installation switches for package management as well as disabling third-party sponsors.
Once items were installed, we had two noteworthy locations on the Windows desktops (others may be available as well, but these are the important ones):
The actual deployment rule set used looks like:
<!-- Example Deployment Rule Set that allow a desktop administrator to control end-user's execution of browser applets.
See http://docs.oracle.com/javase/8/docs/technotes/guides/jweb/security/deployment_rules.html -->
<id location="https://java.com/" />
<action permission="run" version="SECURE" />
<id location="http://internal.example.com/" />
<action permission="run" version="1.6.0_31" />
In this example, we were able to identify and test each item. For example, the first rule checks that users could run the normal Java.com detection applet without any prompts. That demonstrated the correct setup of the DRS. Once successfully set up, the second rule allowed us to target their application.
Most certificates from Certificate Authorities should work out of the box. The certificate used to sign your Deployment Rule Set must be trusted by each Java installation.
After your Deployment Rule Set is in place (in the documented area), the easiest way to check is to look at the control panel. Instructions for checking this are in the previous post, Introducing Deployment Rule Sets, under the “Verify usage of your rule set on a client desktop.”
Although most administrators do not need this step, sometimes the older JRE does not contain the newer root certificate. In that case, it is necessary to locate the CA’s root certificate and explicitly import it:
"C:\Program Files\Java\jre1.6.0_31\bin\keytool" -importcert -keystore "C:\Program Files\Java\jre1.6.0_31\lib\security\cacerts" -alias AuthNameNoSpaces -file TheRootTheyProvided.cer
Once we had the root’s certificate inside both keystores, the RIA launched correctly on the older Java 6.
Testing your Rule Set involves opening the RIA and verifying execution. Other system tools will help check and verify any assumptions. In addition to launching RIAs like the Java.com detection applet, the regular Task Manager will help understand which versions are getting launched.
Within the basic Task Manager, the Processes tab can show a command line column. In the case that you are launching a different version, you can show the Command Line column. In this screenshot, I’ve shrunk the view but it’s easy to see what I am running.
There are other tools available to view a process chain as well, where you will see a chain that looks like:
Once the item was identified as working, we were able to integrate the previous silent installation switches to roll the installations out onto different computers.
Most users or members of staff can run basic installers or scripts as needed. Large enterprises with desktop management systems often combine silent installation switches and customization commands (like the keytool import) with MSI creators, and then roll a single file out for installation.
I will refrain from discussing package creation and roll-out in detail. Use the right mechanism that works within your organization.
The Deployment Rule Set feature is intended for organizations 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 restricting compatibility to 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.
System Administrators new to Java may find the Java console useful to understand what is happening. Most users neither turn on nor see this console.
By turning the console on in the Java control panel, we were able to see execution.
The first line in that file indicates the current version in use: JRE 1.8.0-b132. This is clearly not 1.6.0_31, meaning that it matches the first rule.
When we began using the Deployment Rule Set that delegated to Java 6 update 31, two major things happened:
If you press ‘5’ on that console, it will output a significant amount of log information. I won’t paste a sample log here because they can get long, but the really interesting parts look like:
| Sample from log ||What it tells us |
|Using JRE version 1.8.0-b132 Java HotSpot(TM) 64-Bit Server VM||At the top, this tells us which version is currently in use.|
| Lines beginning with “ruleset:” |
ruleset: RuleSetParser.parse() returning 2 rules:
|These tell what is happening with the DRS, isolated from other information.|
| Lines that talk about “ruleset” and “location” |
ruleset: finding Deployment Rule Set for
title: Java Uninstall Applet
jar location: https://java.com/applet/JavaRemovalTool/JavaRemovalTool.jar
jar version: null
| The location information helps me understand if I told the ruleset to whitelist the right place. |
Sometimes, though not often, the browser URL and actual application URL are different.
In the example to the left, both are on https://java.com
Although my browser visits an area, /en/download/installed.jsp the actual files are hosted in /applet.
That means copying from my browser’s address bar would not have worked.
The two primary ways of creating a deployment rule are by location or certificate hash.
Within the Java Console, there are also ways to locate both of those identifiers.
Those will help identify the items that the RIA plugin is seeing, so then you can look for one of the following messages: