This guide presents a catalog of security-relevant configuration settings for Java Runtime Environment (JRE) of versions 1.6.0, 1.7.0, and 1.8.0 formatted in the eXtensible Configuration Checklist Description Format (XCCDF).

Providing system administrators with such guidance informs them how to securely configure systems under their control in a variety of network roles. Policy makers and baseline creators can use this catalog of settings, with its associated references to higher-level security control catalogs, in order to assist them in security baseline creation. This guide is a catalog, not a checklist, and satisfaction of every item is not likely to be possible or sensible in many operational scenarios. However, the XCCDF format enables granular selection and adjustment of settings, and their association with OVAL and OCIL content provides an automated checking capability. Transformations of this document, and its associated automated checking content, are capable of providing baselines that meet a diverse set of policy objectives. Some example XCCDF Profiles, which are selections of items that form checklists and can be used as baselines, are available with this guide. They can be processed, in an automated fashion, with tools that support the Security Content Automation Protocol (SCAP). The DISA STIG for Red Hat Enterprise Linux 6 is one example of a baseline created from this guidance.

Applicable platforms

  • cpe:/a:oracle:jre:
  • cpe:/a:sun:jre:
  • cpe:/a:redhat:openjdk:
  • cpe:/a:ibm:jre:

Version: 0.1.28

Revision history

  • draft (as of 2016-05-11)

1. Introduction

The purpose of this guidance is to provide security configuration recommendations and baselines for the Java Runtime Environment (JRE) application. The guidance provided here should be applicable to all variants (IBM, OpenJDK, Oracle, Sun) of the product. Recommended settings for the basic application are provided. The guide is intended for system administrators. Readers are assumed to possess basic system administration skills for Unix-like systems, as well as some familiarity with Red Hat's documentation and administration conventions. Some instructions within this guide are complex. All directions should be followed completely and with understanding of their effects in order to avoid serious adverse effects on the system and its security.

link | previous | next | up | toc | home

1.1. How to Use This Guide

Readers should heed the following points when using the guide.

link | previous | next | up | toc | home

1.1.1. Read Sections Completely and in Order

Each section may build on information and recommendations discussed in prior sections. Each section should be read and understood completely; instructions should never be blindly applied. Relevant discussion may occur after instructions for an action.

link | previous | next | up | toc | home

1.1.2. Test in Non-Production Environment

This guidance should always be tested in a non-production environment before deployment. This test environment should simulate the setup in which the system will be deployed as closely as possible.

link | previous | next | up | toc | home

1.1.3. Root Shell Environment Assumed

Most of the actions listed in this document are written with the assumption that they will be executed by the root user running the /bin/bash shell. Commands preceded with a hash mark (#) assume that the administrator will execute the commands as root, i.e. apply the command via sudo whenever possible, or use su to gain root privileges if sudo cannot be used. Commands which can be executed as a non-root user are are preceded by a dollar sign ($) prompt.

link | previous | next | up | toc | home

1.1.4. Formatting Conventions

Commands intended for shell execution, as well as configuration file text, are featured in a monospace font. Italics are used to indicate instances where the system administrator must substitute the appropriate information into a command or configuration file.

link | previous | next | up | toc | home

2. Java

Java is a general-purpose computer programming language. It is intended to let application developers "write once, run anywhere." Java applications are typically compiled to bytecode that can run on any Java virtual machine (JVM) regardless of computer architecture. As such, the Java runtime environment (JRE) is required to be installed so that Java applications can run. This section provides settings for configuring Java policies to meet compliance settings for Java running on Red Hat Enterprise Linux systems.

  • https://docs.oracle.com/javase/6/docs/technotes/guides/deployment/deployment-guide/properties.html

  • https://docs.oracle.com/javase/7/docs/technotes/guides/jweb/jcp/properties.html

  • https://docs.oracle.com/javase/8/docs/technotes/guides/jweb/jcp/properties.html

link | previous | next | up | toc | home

2.a. The Java Properties File Exists

If the Java properties file does not exist, it can be added by running: 

$ sudo mkdir -p -m 755 /etc/.java/deployment
$ sudo touch /etc/.java/deployment/deployment.properties
$ sudo chmod 644 /etc/.java/deployment/deployment.properties

Each option in the Java control panel is represented by property keys. These keys adjust the options in the Java control panel based on the value assigned to that key. By default no deployment.properties file exists; thus, no system-wide exists. Without the deployment.properties file, setting particular options for the Java control panel is impossible.

Remediation script

                JAVA_PROPERTIES="/etc/.java/deployment/deployment.properties"
JAVA_DIR="/etc/.java/deployment"

if [ ! -d ${JAVA_DIR} ] ; then
  mkdir -p -m 755 ${JAVA_DIR}
fi

if [ ! -e ${JAVA_PROPERTIES} ]; then
  touch ${JAVA_PROPERTIES} && chmod 644 ${JAVA_PROPERTIES}
fi

chmod 644 ${JAVA_PROPERTIES}

Security identifiers

  • CCE-
  • JRE0080-UX

link | previous | next | up | toc | home

2.b. Disable Java Execution From Untrusted Sources

To ensure that Java cannot execute from untrusted sources, set deployment.security.askgrantdialog.notinca to equal false in /etc/.java/deployment/deployment.properties.

Permitting execution of signed Java applets from un-trusted sources may result in acquiring malware, and risks system modification, invasion of privacy, or denial of service.

Remediation script

                JAVA_PROPERTIES="/etc/.java/deployment/deployment.properties"

grep -q "^deployment.security.askgrantdialog.notinca=false$" ${JAVA_PROPERTIES} && \
sed -i "s/deployment.security.askgrantdialog.notinca=.*/deployment.security.askgrantdialog.notinca=false/g" ${JAVA_PROPERTIES}
if ! [ $? -eq 0 ] ; then
  echo "deployment.security.askgrantdialog.notinca=false" >> ${JAVA_PROPERTIES}
fi

Security identifiers

  • CCE-
  • JRE0001-UX

link | previous | next | up | toc | home

2.c. Disable User Access to Untrusted Sources Settings

To ensure that users cannot change the untrusted sources settings, add deployment.security.askgrantdialog.notinca.locked to /etc/.java/deployment/deployment.properties.

Permitting execution of signed Java applets from un-trusted sources may result in malware running on the system, and risks system modification, invasion of privacy, or denial of service. As such, ensuring users cannot change the permission settings which control the execution of signed Java applets contributes to a more consistent security profile.

Remediation script

                JAVA_PROPERTIES="/etc/.java/deployment/deployment.properties"

grep -q "^deployment.security.askgrantdialog.notinca.locked$" ${JAVA_PROPERTIES} && \
sed -i "s/deployment.security.askgrantdialog.notinca\..*/deployment.security.askgrantdialog.notinca.locked/g" ${JAVA_PROPERTIES}
if ! [ $? -eq 0 ] ; then
  echo "deployment.security.askgrantdialog.notinca.locked" >> ${JAVA_PROPERTIES}
fi

Security identifiers

  • CCE-
  • JRE0010-UX

link | previous | next | up | toc | home

2.d. Enable Revocation Checks for Publisher Certificates

To ensure that certificate revocation checks are enabled, set deployment.security.validation.crl to equal true in /etc/.java/deployment/deployment.properties.

Certificates may be revoked due to improper issuance, compromise of the certificate, and failure to adhere to policy. Therefore, any certificate found on a CRL should not be trusted. Permitting execution of an applet published with a revoked certificate may result in spoofing, malware, system modification, invasion of privacy, and denial of service.

Remediation script

                JAVA_PROPERTIES="/etc/.java/deployment/deployment.properties"

grep -q "^deployment.security.validation.crl=true$" ${JAVA_PROPERTIES} && \
sed -i "s/deployment.security.validation.crl=.*/deployment.security.validation.crl=true/g" ${JAVA_PROPERTIES}
if ! [ $? -eq 0 ] ; then
  echo "deployment.security.validation.crl=true" >> ${JAVA_PROPERTIES}
fi

Security identifiers

  • CCE-
  • JRE0020-UX

link | previous | next | up | toc | home

2.e. Disable User Access to Revocation Check Settings

To ensure that users cannot change certificate revocation check settings, add deployment.security.validation.crl.locked to /etc/.java/deployment/deployment.properties.

Permitting execution of an applet published with a revoked certificate may result in spoofing, malware, system modification, invasion of privacy, and denial of service. As such, ensuring users cannot change settings contributes to a more consistent security profile.

Remediation script

                JAVA_PROPERTIES="/etc/.java/deployment/deployment.properties"

grep -q "^deployment.security.validation.crl.locked$" ${JAVA_PROPERTIES} && \
sed -i "s/deployment.security.validation.crl\..*/deployment.security.validation.crl.locked/g" ${JAVA_PROPERTIES}
if ! [ $? -eq 0 ] ; then
  echo "deployment.security.validation.crl.locked" >> ${JAVA_PROPERTIES}
fi

Security identifiers

  • CCE-
  • JRE0030-UX

link | previous | next | up | toc | home

2.f. Enable Online Certificate Validation

To ensure that online certificate verification is enabled, set deployment.security.validation.ocsp to equal true in /etc/.java/deployment/deployment.properties.

Online certificate validation provides a greater degree of validation of certificates when running a signed Java applet. Permitting execution of an applet with an invalid certificate may result in malware execution , system modification, invasion of privacy, and denial of service.

Remediation script

                JAVA_PROPERTIES="/etc/.java/deployment/deployment.properties"

grep -q "^deployment.security.validation.ocsp=true$" ${JAVA_PROPERTIES} && \
sed -i "s/deployment.security.validation.ocsp=.*/deployment.security.validation.ocsp=true/g" ${JAVA_PROPERTIES}
if ! [ $? -eq 0 ] ; then
  echo "deployment.security.validation.ocsp=true" >> ${JAVA_PROPERTIES}
fi

Security identifiers

  • CCE-
  • JRE0040-UX

link | previous | next | up | toc | home

2.g. Disable User Access to Online Certificate Validation Settings

To ensure that users cannot change the online certificate verification settings, add deployment.security.validation.ocsp.locked to /etc/.java/deployment/deployment.properties.

Online certificate validation provides a greater degree of validation of certificates when running a signed Java applet. Permitting execution of an applet with an invalid certificate may result in malware execution , system modification, invasion of privacy, and denial of service. As such, ensuring users cannot change settings contributes to a more consistent security profile.

Remediation script

                JAVA_PROPERTIES="/etc/.java/deployment/deployment.properties"

grep -q "^deployment.security.validation.ocsp.locked$" ${JAVA_PROPERTIES} && \
sed -i "s/deployment.security.validation.ocsp\..*/deployment.security.validation.ocsp.locked/g" ${JAVA_PROPERTIES}
if ! [ $? -eq 0 ] ; then
  echo "deployment.security.validation.ocsp.locked" >> ${JAVA_PROPERTIES}
fi

Security identifiers

  • CCE-
  • JRE0050-UX

link | previous | next | up | toc | home

2.h. Ensure Java Patches Installed

If the system is joined to the Red Hat Network, a Red Hat Satellite Server, or a yum server, run the following command to install updates: 

$ sudo yum update
If the system is not configured to use one of these sources, updates (in the form of RPM packages) can be manually downloaded and installed using rpm.

Running an older version of the JRE can introduce security vulnerabilities to the system.

Security identifiers

  • CCE-
  • JRE0090-UX

link | previous | next | up | toc | home

2.9. Configure the deployment.config File

The deployment.config file if used for specifying the System-level deployment.properties file. The System-level configuration for Java is configured in /etc/.java/deployment. By default, no deployment.config file exists. To ensure that the Java /etc/.java/deployment/deployment.config file is configured correctly, deployment.system.config and deployment.system.config.mandatory need to be set correctly.

link | previous | next | up | toc | home

2.9.a. The Java Configuration File Exists

If the Java configuration file does not exist, it can be added by running: 

$ sudo mkdir -p -m 755 /etc/.java/deployment
$ sudo touch /etc/.java/deployment/deployment.config
$ sudo chmod 644 /etc/.java/deployment/deployment.config

The deployment.config file is used for specifying the location and execution of system-level properties for the Java Runtime Environment. By default no deployment.config file exists; thus, no system-wide deployment.properties file exists. Without the deployment.config file, setting particular options for the Java control panel is impossible.

Remediation script

                  JAVA_CONFIG="/etc/.java/deployment/deployment.config"
JAVA_DIR="/etc/.java/deployment"

if [ ! -d ${JAVA_DIR} ] ; then
  mkdir -p -m 755 ${JAVA_DIR}
fi

if [ ! -e ${JAVA_CONFIG} ]; then
  touch ${JAVA_CONFIG} && chmod 644 ${JAVA_CONFIG}
fi

chmod 644 ${JAVA_CONFIG}

Security identifiers

  • CCE-
  • JRE0070-UX

link | previous | next | up | toc | home

2.9.b. Configure the deployment.properties File Path

To ensure that the Java properties file is set in /etc/.java/deployment/deployment.config, add or modify deployment.system.config to equal file:///etc/.java/deployment/deployment.properties.

Without a proper path for the properties file, deployment would not be possible. If the path specified does not lead to a properties file, the value of the 'deployment.system.config.mandatory' key determines how to handle the situation. If the value of this key is true, JRE will not run if the path to the properties file is invalid.

Remediation script

                  JAVA_CONFIG="/etc/.java/deployment/deployment.config"
JAVA_PROPERTIES="/etc/.java/deployment/deployment.properties"

grep -q "^deployment.system.config=file://${JAVA_CONFIG}$" ${JAVA_CONFIG} && \
sed -i "s;deployment.system.config=.*;deployment.system.config=file:\/\/${JAVA_PROPERTIES};g" ${JAVA_CONFIG}
if ! [ $? -eq 0 ] ; then
  echo "deployment.system.config=file://${JAVA_PROPERTIES}" >> ${JAVA_CONFIG}
fi

Security identifiers

  • CCE-
  • JRE0060-UX

link | previous | next | up | toc | home

2.9.c. Configure The Java Deployment Mandatory Setting

To configure the Java mandatory deployment setting, add or modify deployment.system.config.mandatory to equal false in /etc/.java/deployment/deployment.config.

Without a proper path for the properties file, deployment would not be possible. If the path specified does not lead to a properties file, the value of the 'deployment.system.config.mandatory' key determines how to handle the situation. If the value of this key is true, JRE will not run if the path to the properties file is invalid.

Remediation script

                  JAVA_CONFIG="/etc/.java/deployment/deployment.config"

grep -q "^deployment.system.config.mandatory=false$" ${JAVA_CONFIG} && \
sed -i "s/deployment.system.config.mandatory=.*/deployment.system.config.mandatory=false/g" ${JAVA_CONFIG}
if ! [ $? -eq 0 ] ; then
  echo "deployment.system.config.mandatory=false" >> ${JAVA_CONFIG}
fi

Security identifiers

  • CCE-
  • JRE0060-UX

link | previous | next | up | toc | home

Rule Selection

Based on profile: Java Runtime Environment (JRE) STIG (stig-java-upstream)

The Java Runtime Environment (JRE) is a bundle developed and offered by Oracle Corporation which includes the Java Virtual Machine (JVM), class libraries, and other components necessary to run Java applications and applets. Certain default settings within the JRE pose a security risk so it is necessary to deploy system wide properties to ensure a higher degree of security when utilizing the JRE. The IBM Corporation also develops and bundles the Java Runtime Environment (JRE) as well as Red Hat with OpenJDK.

Rule selection
The Java Configuration File Exists selected
Configure the deployment.properties File Path selected
Configure The Java Deployment Mandatory Setting selected
The Java Properties File Exists selected
Disable Java Execution From Untrusted Sources selected
Disable User Access to Untrusted Sources Settings selected
Enable Revocation Checks for Publisher Certificates selected
Disable User Access to Revocation Check Settings selected
Enable Online Certificate Validation selected
Disable User Access to Online Certificate Validation Settings selected
Ensure Java Patches Installed selected

Colophon

Red Hat and Red Hat Enterprise Linux are either registered trademarks or trademarks of Red Hat, Inc. in the United States and other countries. All other names are registered trademarks or trademarks of their respective companies.