Group
Guide to the Secure Configuration of Java Runtime Environment
Group contains 3 groups and 26 rules |
Group
Java
Group contains 2 groups and 26 rules |
[ref]
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.
|
Group
Configure the exception.sites File
Group contains 2 rules |
[ref]
Utilizing a whitelist provides a configuration management method for
allowing the execution of only authorized software. Using only authorized
software decreases risk by limiting the number of potential vulnerabilities.
The exception.sites file is used for ensuring that authorized
software is allowed to be executed. To ensure that the Java
/etc/.java/deployment/deployment.properties file is configured
correctly, deployment.user.security.exception.sites must be configured
to point to a valid exception.sites file. |
Rule
The Java exception.sites File Exists
[ref] | By default, no exception.sites file exists which means that there is no prevention of
unauthorized software. The exception.sites file is a text file containing single-line URLs for
accepted risk sites. If the Java accepted sites list file does not exist, it can be added
by running:
$ sudo mkdir -p -m 755 /etc/.java/deployment
$ sudo touch /etc/.java/deployment/exception.sites
$ sudo chmod 644 /etc/.java/deployment/exception.sites | Rationale: | Utilizing a
whitelist provides a configuration management method for allowing the
execution of only authorized software. Using only authorized software
decreases risk by limiting the number of potential vulnerabilities. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_java_jre_accepted_sites_exists | Identifiers and References | References:
CCI-001774, CM-7(5)(b), SRG-APP-000386, JRE8-UX-000130 | |
|
Rule
Configure the Path to the exception.sites File
[ref] | To ensure that the accepted sites list file is set in
/etc/.java/deployment/deployment.properties , add or modify
deployment.user.security.exception.sites to equal
/etc/.java/deployment/exception.sites . | Rationale: | Without a proper path for the accepted sites list file, unauthorized
software programs are able to be executed. Using only authorized software
decreases risk by limiting the number of potential vulnerabilities. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_java_jre_accepted_sites_properties | Identifiers and References | References:
CCI-001774, CM-7(5)(b), SRG-APP-000386, JRE8-UX-000120 | |
|
Group
Configure the deployment.config File
Group contains 3 rules |
[ref]
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. |
Rule
The Java deployment.config File Exists
[ref] | If the Java deployment 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 | Rationale: | By default no deployment.config file exists; thus, no system-wide deployment.properties file
exists. The file must be created. The deployment.config file is used for specifying the
location and execution of system-level properties for the Java Runtime Environment. Without
the deployment.config file, setting particular options for the Java control panel is
not possible. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_java_jre_deployment_config_exists | Identifiers and References | References:
CCI-000366, CM-6(b), SRG-APP-000516, JRE8-UX-000010 | |
|
Rule
Configure The Java Deployment Mandatory Setting
[ref] | To configure the Java mandatory deployment setting, add or modify
deployment.system.config.mandatory to equal true
in /etc/.java/deployment/deployment.config . | Rationale: | 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 allow Java applications to run if
the path to the properties file is invalid. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_java_jre_deployment_config_mandatory | Identifiers and References | References:
CCI-000366, CM-6(b), SRG-APP-000516, JRE8-UX-000020 | |
|
Rule
Configure the Path to the deployment.properties File
[ref] | To ensure that the Java properties file is set in
/etc/.java/deployment/deployment.config , add or modify
deployment.system.config to equal
/etc/.java/deployment/deployment.properties . | Rationale: | 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 allow Java applications to run if
the path to the properties file is invalid. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_java_jre_deployment_config_properties | Identifiers and References | References:
CCI-000366, CM-6(b), SRG-APP-000516, JRE8-UX-000020 | |
|
Rule
Prevent the Download of Prohibited Mobile Code
[ref] | To ensure that Java prevents the download of prohibited mobile code, set
deployment.security.blacklist.check to equal true in
/etc/.java/deployment/deployment.properties . | Rationale: | Mobile code has the potential to cause damage to information systems within
an organization if used maliciously. Therefore it is important to allow vetted
mobile code and prevent potentially malicious execution of mobile code.
Mobile code has the potential to cause damage to information systems within
an organization if used maliciously. Therefore it is important to allow vetted
mobile code and prevent potentially malicious execution of mobile code. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_java_jre_blacklist_check | Identifiers and References | References:
CCI-001169, SC-18(3), SRG-APP-000209, JRE8-UX-000110 | |
|
Rule
Disable User Access to Prohibited Mobile Code Setting
[ref] | To ensure that users cannot change the download of prohibited mobile code
setting, add deployment.security.blacklist.check.locked to
/etc/.java/deployment/deployment.properties . | Rationale: | Mobile code has the potential to cause damage to information systems within
an organization if used maliciously. Therefore, it is important to allow vetted
mobile code and prevent potentially malicious execution of mobile code.
As such, ensuring
users cannot change the permission settings which control the downloading of
prohibited mobile code contributes to a more consistent security profile. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_java_jre_blacklist_check_locked | Identifiers and References | References:
CCI-001169, SC-18(3), SRG-APP-000209, JRE8-UX-000110 | |
|
Rule
Ensure yum Removes Previous Package Versions
[ref] | yum should be configured to remove previous versions of Java after
new versions have been installed. To configure yum to remove the
previous versions of Java after updating, set the clean_requirements_on_remove
to 1 in /etc/yum.conf .
| Rationale: | Previous versions of software components that are not removed from the information
system after updates have been installed may be exploited by some adversaries. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_java_jre_clean_previous_version | Identifiers and References | References:
CCI-002617, SI-2(6), SRG-APP-000454, JRE8-UX-000190 | |
|
Rule
The Java deployment.properties File Exists
[ref] | If the Java deployment 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 | Rationale: | 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 deployment exists. Without the deployment.properties file, setting particular
options for the Java control panel is impossible. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_java_jre_deployment_properties_exists | Identifiers and References | References:
CCI-000366, CM-6(b), SRG-APP-000516, JRE8-UX-000030 | |
|
Rule
Disable Execution of Signed Java Applets From Untrusted Sources Setting
[ref] | To ensure that Java cannot execute from untrusted sources, set
deployment.security.askgrantdialog.notinca to equal false
in /etc/.java/deployment/deployment.properties . | Rationale: | 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. Block users from granting permissions to
certificates that are not issued by a CA in the Root/JSSE CA certificate
store. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_java_jre_disable_untrusted_sources | Identifiers and References | References:
CCI-001695, SC-18 (3), SRG-APP-000112, JRE8-UX-000080 | |
|
Rule
Disable User Access to Disabling Untrusted Sources Setting
[ref] | To ensure that users cannot change the untrusted sources settings,
add deployment.security.askgrantdialog.notinca.locked to
/etc/.java/deployment/deployment.properties . | Rationale: | 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. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_java_jre_disable_untrusted_sources_locked | Identifiers and References | References:
CCI-001695, SC-18 (3), SRG-APP-000112, JRE8-UX-000080 | |
|
Rule
Enable Java Web Start Applications to Run
[ref] | To ensure that Java allows applets or Java Web Start (JWS) applications to
run, set deployment.webjava.enabled to equal true in
/etc/.java/deployment/deployment.properties . | Rationale: | Due to the popularity of Java Web Start (JWS) applications, denying these
applications could have a negative impact to the user experience. Whitelisting,
blacklisting, and signing of applications help mitigate the risk of running
JWS applications. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_java_jre_enable_jws | Identifiers and References | References:
CCI-000366, CM-6(b), SRG-APP-000516, JRE8-UX-000070 | |
|
Rule
Disable User Access to Java Web Start Application Setting
[ref] | To ensure that users cannot change the Java Web Start (JWS) application
setting, add deployment.webjava.enabled.locked to
/etc/.java/deployment/deployment.properties . | Rationale: | Due to the popularity of Java Web Start (JWS) applications, denying these
applications could have a negative impact to the user experience. Whitelisting,
blacklisting, and signing of applications help mitigate the risk of running
JWS applications. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_java_jre_enable_jws_locked | Identifiers and References | References:
CCI-000366, CM-6(b), SRG-APP-000516, JRE8-UX-000070 | |
|
Rule
Prompt User Prior to Executing Mobile Code
[ref] | To ensure that Java prevents mobile code from executing without prompting
the user, set deployment.insecure.jres to equal
PROMPT in /etc/.java/deployment/deployment.properties . | Rationale: | Mobile code has the potential to cause damage to information systems within
an organization if used maliciously. It can execute without explicit action
from, or notification to, a user. Requiring Java to enforce prompting the user prior
to executing mobile code will strenghten the security posture of the system. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_java_jre_insecure_prompt | Identifiers and References | References:
CCI-002460, SC-18(4), SRG-APP-000488, JRE8-UX-000170 | |
|
Rule
Disable User Access to Insecure Prompt of Mobile Code Setting
[ref] | To ensure that users cannot change the mobile code setting for insecure
prompts, add deployment.insecure.jres.locked to
/etc/.java/deployment/deployment.properties . | Rationale: | Mobile code has the potential to cause damage to information systems within
an organization if used maliciously. It can execute without explicit action
from, or notification to, a user. Requiring Java to enforce prompting the user
prior to executing mobile code will strengthen the security posture of the
system. As such, ensuring users cannot change the permission settings which
control the insecure prompts for mobile code execution contributes to a more
consistent security profile. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_java_jre_insecure_prompt_locked | Identifiers and References | References:
CCI-002460, SC-18(4), SRG-APP-000488, JRE8-UX-000170 | |
|
Rule
Lock Execution of Signed Java Applets From Untrusted Sources Setting
[ref] | To ensure that Java cannot execute from untrusted sources, set
deployment.security.askgrantdialog.show to equal false
in /etc/.java/deployment/deployment.properties . | Rationale: | 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. Block users from granting permissions to
applets and JWS applications. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_java_jre_lock_untrusted_sources | Identifiers and References | References:
CCI-001695, SC-18 (3), SRG-APP-000112, JRE8-UX-000090 | |
|
Rule
Disable User Access to Locking Untrusted Sources Setting
[ref] | To ensure that users cannot change the untrusted sources settings,
add deployment.security.askgrantdialog.show.locked to
/etc/.java/deployment/deployment.properties . | Rationale: | 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. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_java_jre_lock_untrusted_sources_locked | Identifiers and References | References:
CCI-001695, SC-18 (3), SRG-APP-000112, JRE8-UX-000090 | |
|
Rule
Enable Revocation Checks for Publisher Certificates
[ref] | To ensure that certificate revocation checks are enabled, set
deployment.security.revocation.check to equal ALL_CERTIFICATES
in /etc/.java/deployment/deployment.properties . | Rationale: | 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. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_java_jre_security_revocation_check | Identifiers and References | References:
CCI-001991, IA-5(2)(d), SRG-APP-000401, JRE8-UX-000160 | |
|
Rule
Disable User Access to Revocation Check Settings
[ref] | To ensure that users cannot change certificate revocation check settings,
add deployment.security.revocation.check.locked to
/etc/.java/deployment/deployment.properties . | Rationale: | 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. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_java_jre_security_revocation_check_locked | Identifiers and References | References:
CCI-001991, IA-5(2)(d), SRG-APP-000401, JRE8-UX-000160 | |
|
Rule
Disable Execution of Unsigned Applications
[ref] | To ensure that Java does not allow unsigned applications to run, set
deployment.security.level to equal VERY_HIGH in
/etc/.java/deployment/deployment.properties . | Rationale: | Unsigned applications could perform numerous types of attacks on a system.
Applications that are signed with a valid certificate and include the
permissions attribute in the manifest for the main JAR file are allowed to
run with security prompts. All other applications are blocked. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_java_jre_unsigned_applications | Identifiers and References | References:
CCI-000366, CM-6(b), SRG-APP-000516, JRE8-UX-000060 | |
|
Rule
Disable User Access to Unsigned Applications Setting
[ref] | To ensure that users cannot change the unsigned applications setting, add
deployment.security.level.locked to
/etc/.java/deployment/deployment.properties . | Rationale: | Unsigned applications could perform numerous types of attacks on a system.
As such, ensuring users cannot change the permission settings which control
the execution of unsigned Java applications contributes to a more consistent
security profile. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_java_jre_unsigned_applications_locked | Identifiers and References | References:
CCI-000366, CM-6(b), SRG-APP-000516, JRE8-UX-000060 | |
|
Rule
Ensure Java Patches Installed
[ref] | 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 .
NOTE: U.S. Defense systems are required to be patched within 30 days or sooner as local policy
dictates. | Rationale: | Running an older version of the JRE can introduce security
vulnerabilities to the system. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_java_jre_updated | Identifiers and References | References:
CCI-002605, SI-2(c), SRG-APP-000456, JRE8-UX-000180 | |
|
Rule
Enable Use of Certificate Revocation Lists
[ref] | To ensure that certificate revocation lists are enabled, set
deployment.security.validation.crl to equal true
in /etc/.java/deployment/deployment.properties . | Rationale: | A certificate revocation list is a directory which contains a list of
certificates that have been revoked for various reasons. 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. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_java_jre_validation_crl | Identifiers and References | References:
CCI-001991, IA-5(2)(d), SRG-APP-000401, JRE8-UX-000150 | |
|
Rule
Disable User Access to Certificate Revocation List Settings
[ref] | To ensure that users cannot change certificate revocation list settings,
add deployment.security.validation.crl.locked to
/etc/.java/deployment/deployment.properties . | Rationale: | Permitting execution of an applet published with a revoked certificate may
result in spoofing, malware, system modification, invasion of privacy, and
denial of service. This is why it is important to ensure to check against a
Certificate Revocation List. As such, ensuring users cannot change settings
contributes to a more consistent security profile. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_java_jre_validation_crl_locked | Identifiers and References | References:
CCI-001991, IA-5(2)(d), SRG-APP-000401, JRE8-UX-000150 | |
|
Rule
Enable Online Certificate Validation
[ref] | To ensure that online certificate verification is enabled, set
deployment.security.validation.ocsp to equal true
in /etc/.java/deployment/deployment.properties . | Rationale: | 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. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_java_jre_validation_ocsp | Identifiers and References | References:
CCI-000185, IA-5(2)(a), SRG-APP-000175, JRE8-UX-000100 | |
|
Rule
Disable User Access to Online Certificate Validation Setting
[ref] | To ensure that users cannot change the online certificate verification setting,
add deployment.security.validation.ocsp.locked to
/etc/.java/deployment/deployment.properties . | Rationale: | 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. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_java_jre_validation_ocsp_locked | Identifiers and References | References:
CCI-000185, IA-5(2)(a), SRG-APP-000175, JRE8-UX-000100 | |
|