Securing the Java Runtime Environment

This forms part of a Java series including:

Java Deployment Rule Set and Active Directory Certificates

Java Deployment Rule Set and Self Signed Certificates

Java Runtime Environment (JRE) is used extensively in the enterprise for Rich Internet Applications (RIA) launched from the browser, and local Java-based desktop applications.

It’s difficult to support Java if every user has a different configuration, and coupled with this it’s not advisable to let users configure Java themselves due to the security implications.

Luckily its easy enough to lock down JRE settings with a few configuration files.

Create the deployment.config file

First start by creating the file: C:\Windows\Sun\Java\Deployment\deployment.config.  The file MUST exist in this location.  And paste and save the following inside the file:

The first setting points to the location of the file – this file will ultimately configure and lock down the Java settings.  We can store this file on a network but it’s advisable to keep it locally (see below), and due to it being a system-wide setting it should be in a per-machine location.  Hence for simplicity we keep it in the same location as the deployment.config file.

The second setting enforces that the file is used.  If the file cannot be located when mandatory is set to true (perhaps the file is stored on a network and the network location isn’t available) then Java will not load the application.

Create the file

Now we can start configuring and locking down the settings.  For JRE 7 (which is what we are locking down) we can see which Java settings are configurable.  Unfortunately not all settings are documented, but it’s a decent guide for most.

Create the file: C:\Windows\Sun\Java\Deployment\, then paste and save the following inside the file:

Create the exception.sites file

Now create the file: C:\Windows\Sun\Java\Deployment\exception.sites.  This file can remain blank for now.  But adding application URLs to this list allows users to run RIAs that would normally be blocked by security checks.  An example of an entry in this file might be:

A limitation of this file is that it cannot accept wildcards.  I recently encountered an issue where a website would use a dynamic port range of around 20,000 ports!  So rather than add 20,000 rows to site.exceptions (not advisable!) I created a Java deployment ruleset with an Active Directory code signing certificate.  You can also create a Java deployment ruleset with a self signed certificate.  With the ruleset.xml file you can specify wildcards for the port in a single rule.

Disable updates via the registry

Finally there are a few registry values that we can, to prevent Java from automatically updating.  Bear in mind that this is for a 32-bit install of Java on a 64-bit platform, and hence the ‘Wow6432Node’ location:

And finally, we’re done!