From a5d5ea1acf1072eda2d227cf22956792367e06b4 Mon Sep 17 00:00:00 2001 From: coffeys Date: Tue, 26 Sep 2017 07:11:37 -0700 Subject: [PATCH] 8170157: Enable unlimited cryptographic policy by default in OracleJDK Reviewed-by: wetmore --- .../classes/javax/crypto/JceSecurity.java | 12 +- src/share/lib/security/java.security-aix | 86 ++++++------ src/share/lib/security/java.security-linux | 85 ++++++------ src/share/lib/security/java.security-macosx | 85 ++++++------ src/share/lib/security/java.security-solaris | 85 ++++++------ src/share/lib/security/java.security-windows | 85 ++++++------ .../CryptoPolicyFallback.java | 123 ++++++++++++++++++ .../CryptoPermission/TestUnlimited.java | 88 ++++++++++--- 8 files changed, 419 insertions(+), 230 deletions(-) create mode 100644 test/javax/crypto/CryptoPermission/CryptoPolicyFallback.java diff --git a/src/share/classes/javax/crypto/JceSecurity.java b/src/share/classes/javax/crypto/JceSecurity.java index 5def2779e..e7e3a99f5 100644 --- a/src/share/classes/javax/crypto/JceSecurity.java +++ b/src/share/classes/javax/crypto/JceSecurity.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 1997, 2016, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1997, 2017, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -257,12 +257,12 @@ final class JceSecurity { * user edit or an application call is required. * * Otherwise, if user has policy jar files installed in the legacy - * jre/lib/security/ directory, the JDK will honor whatever + * /lib/security/ directory, the JDK will honor whatever * setting is set by those policy files. (legacy/current behavior) * * If none of the above 2 conditions are met, the JDK will default - * to using the limited crypto policy files found in the - * jre/lib/security/policy/limited/ directory + * to using the unlimited crypto policy files found in the + * /lib/security/policy/unlimited/ directory */ private static void setupJurisdictionPolicies() throws Exception { // Sanity check the crypto.policy Security property. Single @@ -300,9 +300,9 @@ final class JceSecurity { !importJar.exists())) { // Compatibility set up. If crypto.policy is not defined. // check to see if legacy jars exist in lib directory. If - // they don't exist, we default to limited policy mode. + // they don't exist, we default to unlimited policy mode. cpPath = Paths.get( - javaHomeProperty, "lib", "security", "policy", "limited"); + javaHomeProperty, "lib", "security", "policy", "unlimited"); // point to the new jar files in limited directory exportJar = new File(cpPath.toFile(),"US_export_policy.jar"); importJar = new File(cpPath.toFile(),"local_policy.jar"); diff --git a/src/share/lib/security/java.security-aix b/src/share/lib/security/java.security-aix index 1d7a8d981..f3e534ce4 100644 --- a/src/share/lib/security/java.security-aix +++ b/src/share/lib/security/java.security-aix @@ -737,69 +737,71 @@ jdk.tls.legacyAlgorithms= \ # Cryptographic Jurisdiction Policy defaults # -# Due to the import control restrictions of some countries, the default -# JCE policy files allow for strong but "limited" cryptographic key -# lengths to be used. If your country's cryptographic regulations allow, -# the "unlimited" strength policy files can be used instead, which contain -# no restrictions on cryptographic strengths. +# Import and export control rules on cryptographic software vary from +# country to country. By default, the JDK provides two different sets of +# cryptographic policy files: # -# YOU ARE ADVISED TO CONSULT YOUR EXPORT/IMPORT CONTROL COUNSEL OR ATTORNEY -# TO DETERMINE THE EXACT REQUIREMENTS. +# unlimited: These policy files contain no restrictions on cryptographic +# strengths or algorithms. # -# (below) refers to the directory where the JRE was -# installed. It is determined based on whether you are running JCE -# on a JRE or a JRE contained within the Java Development Kit, or -# JDK(TM). The JDK contains the JRE, but at a different level in the -# file hierarchy. For example, if the JDK is installed in -# /home/user1/jdk1.8.0 on Unix or in C:\jdk1.8.0 on Windows, then -# is: +# limited: These policy files contain more restricted cryptographic +# strengths, and are still available if your country or +# usage requires the traditional restrictive policy. # -# /home/user1/jdk1.8.0/jre [Unix] -# C:\jdk1.8.0\jre [Windows] +# The JDK JCE framework uses the unlimited policy files by default. +# However the user may explicitly choose a set either by defining the +# "crypto.policy" Security property or by installing valid JCE policy +# jar files into the traditional JDK installation location. To better +# support older JDK Update releases, the "crypto.policy" property is not +# defined by default. See below for more information. # -# If on the other hand the JRE is installed in /home/user1/jre1.8.0 -# on Unix or in C:\jre1.8.0 on Windows, and the JDK is not -# installed, then is: +# The following logic determines which policy files are used: # -# /home/user1/jre1.8.0 [Unix] -# C:\jre1.8.0 [Windows] +# refers to the directory where the JRE was +# installed and may be determined using the "java.home" +# System property. # -# On Windows, for each JDK installation, there may be additional -# JREs installed under the "Program Files" directory. Please make -# sure that you install the unlimited strength policy JAR files -# for all JREs that you plan to use. +# 1. If the Security property "crypto.policy" has been defined, +# then the following mechanism is used: # -# The policy files are jar files organized into subdirectories of +# The policy files are stored as jar files in subdirectories of # /lib/security/policy. Each directory contains a complete # set of policy files. # -# The "crypto.policy" Security property controls the directory selection, -# and thus the effective cryptographic policy. +# The "crypto.policy" Security property controls the directory +# selection, and thus the effective cryptographic policy. # # The default set of directories is: # # limited | unlimited # -# however other directories can be created and configured. -# -# To support older JDK Update releases, the crypto.policy property -# is not defined by default. When the property is not defined, an -# update release binary aware of the new property will use the following -# logic to decide what crypto policy files get used : -# -# * If the US_export_policy.jar and local_policy.jar files are located -# in the (legacy) /lib/security directory, then the rules -# embedded in those jar files will be used. This helps preserve compatibility +# 2. If the "crypto.policy" property is not set and the traditional +# US_export_policy.jar and local_policy.jar files +# (e.g. limited/unlimited) are found in the legacy +# /lib/security directory, then the rules embedded within +# those jar files will be used. This helps preserve compatibility # for users upgrading from an older installation. # -# * If crypto.policy is not defined and no such jar files are present in -# the legacy locations, then the JDK will use the limited settings -# (equivalent to crypto.policy=limited) +# 3. If the jar files are not present in the legacy location +# and the "crypto.policy" Security property is not defined, +# then the JDK will use the unlimited settings (equivalent to +# crypto.policy=unlimited) # # Please see the JCA documentation for additional information on these # files and formats. -#crypto.policy=unlimited # +# YOU ARE ADVISED TO CONSULT YOUR EXPORT/IMPORT CONTROL COUNSEL OR ATTORNEY +# TO DETERMINE THE EXACT REQUIREMENTS. +# +# Please note that the JCE for Java SE, including the JCE framework, +# cryptographic policy files, and standard JCE providers provided with +# the Java SE, have been reviewed and approved for export as mass market +# encryption item by the US Bureau of Industry and Security. +# +# Note: This property is currently used by the JDK Reference implementation. +# It is not guaranteed to be examined and used by other implementations. +# +#crypto.policy=unlimited # The policy for the XML Signature secure validation mode. The mode is # enabled by setting the property "org.jcp.xml.dsig.secureValidation" to diff --git a/src/share/lib/security/java.security-linux b/src/share/lib/security/java.security-linux index 9643a099a..6d402bc82 100644 --- a/src/share/lib/security/java.security-linux +++ b/src/share/lib/security/java.security-linux @@ -737,67 +737,70 @@ jdk.tls.legacyAlgorithms= \ # Cryptographic Jurisdiction Policy defaults # -# Due to the import control restrictions of some countries, the default -# JCE policy files allow for strong but "limited" cryptographic key -# lengths to be used. If your country's cryptographic regulations allow, -# the "unlimited" strength policy files can be used instead, which contain -# no restrictions on cryptographic strengths. +# Import and export control rules on cryptographic software vary from +# country to country. By default, the JDK provides two different sets of +# cryptographic policy files: # -# YOU ARE ADVISED TO CONSULT YOUR EXPORT/IMPORT CONTROL COUNSEL OR ATTORNEY -# TO DETERMINE THE EXACT REQUIREMENTS. +# unlimited: These policy files contain no restrictions on cryptographic +# strengths or algorithms. # -# (below) refers to the directory where the JRE was -# installed. It is determined based on whether you are running JCE -# on a JRE or a JRE contained within the Java Development Kit, or -# JDK(TM). The JDK contains the JRE, but at a different level in the -# file hierarchy. For example, if the JDK is installed in -# /home/user1/jdk1.8.0 on Unix or in C:\jdk1.8.0 on Windows, then -# is: +# limited: These policy files contain more restricted cryptographic +# strengths, and are still available if your country or +# usage requires the traditional restrictive policy. # -# /home/user1/jdk1.8.0/jre [Unix] -# C:\jdk1.8.0\jre [Windows] +# The JDK JCE framework uses the unlimited policy files by default. +# However the user may explicitly choose a set either by defining the +# "crypto.policy" Security property or by installing valid JCE policy +# jar files into the traditional JDK installation location. To better +# support older JDK Update releases, the "crypto.policy" property is not +# defined by default. See below for more information. # -# If on the other hand the JRE is installed in /home/user1/jre1.8.0 -# on Unix or in C:\jre1.8.0 on Windows, and the JDK is not -# installed, then is: +# The following logic determines which policy files are used: # -# /home/user1/jre1.8.0 [Unix] -# C:\jre1.8.0 [Windows] +# refers to the directory where the JRE was +# installed and may be determined using the "java.home" +# System property. # -# On Windows, for each JDK installation, there may be additional -# JREs installed under the "Program Files" directory. Please make -# sure that you install the unlimited strength policy JAR files -# for all JREs that you plan to use. +# 1. If the Security property "crypto.policy" has been defined, +# then the following mechanism is used: # -# The policy files are jar files organized into subdirectories of +# The policy files are stored as jar files in subdirectories of # /lib/security/policy. Each directory contains a complete # set of policy files. # -# The "crypto.policy" Security property controls the directory selection, -# and thus the effective cryptographic policy. +# The "crypto.policy" Security property controls the directory +# selection, and thus the effective cryptographic policy. # # The default set of directories is: # # limited | unlimited # -# however other directories can be created and configured. -# -# To support older JDK Update releases, the crypto.policy property -# is not defined by default. When the property is not defined, an -# update release binary aware of the new property will use the following -# logic to decide what crypto policy files get used : -# -# * If the US_export_policy.jar and local_policy.jar files are located -# in the (legacy) /lib/security directory, then the rules -# embedded in those jar files will be used. This helps preserve compatibility +# 2. If the "crypto.policy" property is not set and the traditional +# US_export_policy.jar and local_policy.jar files +# (e.g. limited/unlimited) are found in the legacy +# /lib/security directory, then the rules embedded within +# those jar files will be used. This helps preserve compatibility # for users upgrading from an older installation. # -# * If crypto.policy is not defined and no such jar files are present in -# the legacy locations, then the JDK will use the limited settings -# (equivalent to crypto.policy=limited) +# 3. If the jar files are not present in the legacy location +# and the "crypto.policy" Security property is not defined, +# then the JDK will use the unlimited settings (equivalent to +# crypto.policy=unlimited) # # Please see the JCA documentation for additional information on these # files and formats. +# +# YOU ARE ADVISED TO CONSULT YOUR EXPORT/IMPORT CONTROL COUNSEL OR ATTORNEY +# TO DETERMINE THE EXACT REQUIREMENTS. +# +# Please note that the JCE for Java SE, including the JCE framework, +# cryptographic policy files, and standard JCE providers provided with +# the Java SE, have been reviewed and approved for export as mass market +# encryption item by the US Bureau of Industry and Security. +# +# Note: This property is currently used by the JDK Reference implementation. +# It is not guaranteed to be examined and used by other implementations. +# #crypto.policy=unlimited # diff --git a/src/share/lib/security/java.security-macosx b/src/share/lib/security/java.security-macosx index 84fcdbec4..f2f13b99d 100644 --- a/src/share/lib/security/java.security-macosx +++ b/src/share/lib/security/java.security-macosx @@ -740,67 +740,70 @@ jdk.tls.legacyAlgorithms= \ # Cryptographic Jurisdiction Policy defaults # -# Due to the import control restrictions of some countries, the default -# JCE policy files allow for strong but "limited" cryptographic key -# lengths to be used. If your country's cryptographic regulations allow, -# the "unlimited" strength policy files can be used instead, which contain -# no restrictions on cryptographic strengths. +# Import and export control rules on cryptographic software vary from +# country to country. By default, the JDK provides two different sets of +# cryptographic policy files: # -# YOU ARE ADVISED TO CONSULT YOUR EXPORT/IMPORT CONTROL COUNSEL OR ATTORNEY -# TO DETERMINE THE EXACT REQUIREMENTS. +# unlimited: These policy files contain no restrictions on cryptographic +# strengths or algorithms. # -# (below) refers to the directory where the JRE was -# installed. It is determined based on whether you are running JCE -# on a JRE or a JRE contained within the Java Development Kit, or -# JDK(TM). The JDK contains the JRE, but at a different level in the -# file hierarchy. For example, if the JDK is installed in -# /home/user1/jdk1.8.0 on Unix or in C:\jdk1.8.0 on Windows, then -# is: +# limited: These policy files contain more restricted cryptographic +# strengths, and are still available if your country or +# usage requires the traditional restrictive policy. # -# /home/user1/jdk1.8.0/jre [Unix] -# C:\jdk1.8.0\jre [Windows] +# The JDK JCE framework uses the unlimited policy files by default. +# However the user may explicitly choose a set either by defining the +# "crypto.policy" Security property or by installing valid JCE policy +# jar files into the traditional JDK installation location. To better +# support older JDK Update releases, the "crypto.policy" property is not +# defined by default. See below for more information. # -# If on the other hand the JRE is installed in /home/user1/jre1.8.0 -# on Unix or in C:\jre1.8.0 on Windows, and the JDK is not -# installed, then is: +# The following logic determines which policy files are used: # -# /home/user1/jre1.8.0 [Unix] -# C:\jre1.8.0 [Windows] +# refers to the directory where the JRE was +# installed and may be determined using the "java.home" +# System property. # -# On Windows, for each JDK installation, there may be additional -# JREs installed under the "Program Files" directory. Please make -# sure that you install the unlimited strength policy JAR files -# for all JREs that you plan to use. +# 1. If the Security property "crypto.policy" has been defined, +# then the following mechanism is used: # -# The policy files are jar files organized into subdirectories of +# The policy files are stored as jar files in subdirectories of # /lib/security/policy. Each directory contains a complete # set of policy files. # -# The "crypto.policy" Security property controls the directory selection, -# and thus the effective cryptographic policy. +# The "crypto.policy" Security property controls the directory +# selection, and thus the effective cryptographic policy. # # The default set of directories is: # # limited | unlimited # -# however other directories can be created and configured. -# -# To support older JDK Update releases, the crypto.policy property -# is not defined by default. When the property is not defined, an -# update release binary aware of the new property will use the following -# logic to decide what crypto policy files get used : -# -# * If the US_export_policy.jar and local_policy.jar files are located -# in the (legacy) /lib/security directory, then the rules -# embedded in those jar files will be used. This helps preserve compatibility +# 2. If the "crypto.policy" property is not set and the traditional +# US_export_policy.jar and local_policy.jar files +# (e.g. limited/unlimited) are found in the legacy +# /lib/security directory, then the rules embedded within +# those jar files will be used. This helps preserve compatibility # for users upgrading from an older installation. # -# * If crypto.policy is not defined and no such jar files are present in -# the legacy locations, then the JDK will use the limited settings -# (equivalent to crypto.policy=limited) +# 3. If the jar files are not present in the legacy location +# and the "crypto.policy" Security property is not defined, +# then the JDK will use the unlimited settings (equivalent to +# crypto.policy=unlimited) # # Please see the JCA documentation for additional information on these # files and formats. +# +# YOU ARE ADVISED TO CONSULT YOUR EXPORT/IMPORT CONTROL COUNSEL OR ATTORNEY +# TO DETERMINE THE EXACT REQUIREMENTS. +# +# Please note that the JCE for Java SE, including the JCE framework, +# cryptographic policy files, and standard JCE providers provided with +# the Java SE, have been reviewed and approved for export as mass market +# encryption item by the US Bureau of Industry and Security. +# +# Note: This property is currently used by the JDK Reference implementation. +# It is not guaranteed to be examined and used by other implementations. +# #crypto.policy=unlimited # diff --git a/src/share/lib/security/java.security-solaris b/src/share/lib/security/java.security-solaris index 2d53ad050..462af6842 100644 --- a/src/share/lib/security/java.security-solaris +++ b/src/share/lib/security/java.security-solaris @@ -739,67 +739,70 @@ jdk.tls.legacyAlgorithms= \ # Cryptographic Jurisdiction Policy defaults # -# Due to the import control restrictions of some countries, the default -# JCE policy files allow for strong but "limited" cryptographic key -# lengths to be used. If your country's cryptographic regulations allow, -# the "unlimited" strength policy files can be used instead, which contain -# no restrictions on cryptographic strengths. +# Import and export control rules on cryptographic software vary from +# country to country. By default, the JDK provides two different sets of +# cryptographic policy files: # -# YOU ARE ADVISED TO CONSULT YOUR EXPORT/IMPORT CONTROL COUNSEL OR ATTORNEY -# TO DETERMINE THE EXACT REQUIREMENTS. +# unlimited: These policy files contain no restrictions on cryptographic +# strengths or algorithms. # -# (below) refers to the directory where the JRE was -# installed. It is determined based on whether you are running JCE -# on a JRE or a JRE contained within the Java Development Kit, or -# JDK(TM). The JDK contains the JRE, but at a different level in the -# file hierarchy. For example, if the JDK is installed in -# /home/user1/jdk1.8.0 on Unix or in C:\jdk1.8.0 on Windows, then -# is: +# limited: These policy files contain more restricted cryptographic +# strengths, and are still available if your country or +# usage requires the traditional restrictive policy. # -# /home/user1/jdk1.8.0/jre [Unix] -# C:\jdk1.8.0\jre [Windows] +# The JDK JCE framework uses the unlimited policy files by default. +# However the user may explicitly choose a set either by defining the +# "crypto.policy" Security property or by installing valid JCE policy +# jar files into the traditional JDK installation location. To better +# support older JDK Update releases, the "crypto.policy" property is not +# defined by default. See below for more information. # -# If on the other hand the JRE is installed in /home/user1/jre1.8.0 -# on Unix or in C:\jre1.8.0 on Windows, and the JDK is not -# installed, then is: +# The following logic determines which policy files are used: # -# /home/user1/jre1.8.0 [Unix] -# C:\jre1.8.0 [Windows] +# refers to the directory where the JRE was +# installed and may be determined using the "java.home" +# System property. # -# On Windows, for each JDK installation, there may be additional -# JREs installed under the "Program Files" directory. Please make -# sure that you install the unlimited strength policy JAR files -# for all JREs that you plan to use. +# 1. If the Security property "crypto.policy" has been defined, +# then the following mechanism is used: # -# The policy files are jar files organized into subdirectories of +# The policy files are stored as jar files in subdirectories of # /lib/security/policy. Each directory contains a complete # set of policy files. # -# The "crypto.policy" Security property controls the directory selection, -# and thus the effective cryptographic policy. +# The "crypto.policy" Security property controls the directory +# selection, and thus the effective cryptographic policy. # # The default set of directories is: # # limited | unlimited # -# however other directories can be created and configured. -# -# To support older JDK Update releases, the crypto.policy property -# is not defined by default. When the property is not defined, an -# update release binary aware of the new property will use the following -# logic to decide what crypto policy files get used : -# -# * If the US_export_policy.jar and local_policy.jar files are located -# in the (legacy) /lib/security directory, then the rules -# embedded in those jar files will be used. This helps preserve compatibility +# 2. If the "crypto.policy" property is not set and the traditional +# US_export_policy.jar and local_policy.jar files +# (e.g. limited/unlimited) are found in the legacy +# /lib/security directory, then the rules embedded within +# those jar files will be used. This helps preserve compatibility # for users upgrading from an older installation. # -# * If crypto.policy is not defined and no such jar files are present in -# the legacy locations, then the JDK will use the limited settings -# (equivalent to crypto.policy=limited) +# 3. If the jar files are not present in the legacy location +# and the "crypto.policy" Security property is not defined, +# then the JDK will use the unlimited settings (equivalent to +# crypto.policy=unlimited) # # Please see the JCA documentation for additional information on these # files and formats. +# +# YOU ARE ADVISED TO CONSULT YOUR EXPORT/IMPORT CONTROL COUNSEL OR ATTORNEY +# TO DETERMINE THE EXACT REQUIREMENTS. +# +# Please note that the JCE for Java SE, including the JCE framework, +# cryptographic policy files, and standard JCE providers provided with +# the Java SE, have been reviewed and approved for export as mass market +# encryption item by the US Bureau of Industry and Security. +# +# Note: This property is currently used by the JDK Reference implementation. +# It is not guaranteed to be examined and used by other implementations. +# #crypto.policy=unlimited # diff --git a/src/share/lib/security/java.security-windows b/src/share/lib/security/java.security-windows index d7db1d389..3b993bbe8 100644 --- a/src/share/lib/security/java.security-windows +++ b/src/share/lib/security/java.security-windows @@ -740,67 +740,70 @@ jdk.tls.legacyAlgorithms= \ # Cryptographic Jurisdiction Policy defaults # -# Due to the import control restrictions of some countries, the default -# JCE policy files allow for strong but "limited" cryptographic key -# lengths to be used. If your country's cryptographic regulations allow, -# the "unlimited" strength policy files can be used instead, which contain -# no restrictions on cryptographic strengths. +# Import and export control rules on cryptographic software vary from +# country to country. By default, the JDK provides two different sets of +# cryptographic policy files: # -# YOU ARE ADVISED TO CONSULT YOUR EXPORT/IMPORT CONTROL COUNSEL OR ATTORNEY -# TO DETERMINE THE EXACT REQUIREMENTS. +# unlimited: These policy files contain no restrictions on cryptographic +# strengths or algorithms. # -# (below) refers to the directory where the JRE was -# installed. It is determined based on whether you are running JCE -# on a JRE or a JRE contained within the Java Development Kit, or -# JDK(TM). The JDK contains the JRE, but at a different level in the -# file hierarchy. For example, if the JDK is installed in -# /home/user1/jdk1.8.0 on Unix or in C:\jdk1.8.0 on Windows, then -# is: +# limited: These policy files contain more restricted cryptographic +# strengths, and are still available if your country or +# usage requires the traditional restrictive policy. # -# /home/user1/jdk1.8.0/jre [Unix] -# C:\jdk1.8.0\jre [Windows] +# The JDK JCE framework uses the unlimited policy files by default. +# However the user may explicitly choose a set either by defining the +# "crypto.policy" Security property or by installing valid JCE policy +# jar files into the traditional JDK installation location. To better +# support older JDK Update releases, the "crypto.policy" property is not +# defined by default. See below for more information. # -# If on the other hand the JRE is installed in /home/user1/jre1.8.0 -# on Unix or in C:\jre1.8.0 on Windows, and the JDK is not -# installed, then is: +# The following logic determines which policy files are used: # -# /home/user1/jre1.8.0 [Unix] -# C:\jre1.8.0 [Windows] +# refers to the directory where the JRE was +# installed and may be determined using the "java.home" +# System property. # -# On Windows, for each JDK installation, there may be additional -# JREs installed under the "Program Files" directory. Please make -# sure that you install the unlimited strength policy JAR files -# for all JREs that you plan to use. +# 1. If the Security property "crypto.policy" has been defined, +# then the following mechanism is used: # -# The policy files are jar files organized into subdirectories of +# The policy files are stored as jar files in subdirectories of # /lib/security/policy. Each directory contains a complete # set of policy files. # -# The "crypto.policy" Security property controls the directory selection, -# and thus the effective cryptographic policy. +# The "crypto.policy" Security property controls the directory +# selection, and thus the effective cryptographic policy. # # The default set of directories is: # # limited | unlimited # -# however other directories can be created and configured. -# -# To support older JDK Update releases, the crypto.policy property -# is not defined by default. When the property is not defined, an -# update release binary aware of the new property will use the following -# logic to decide what crypto policy files get used : -# -# * If the US_export_policy.jar and local_policy.jar files are located -# in the (legacy) /lib/security directory, then the rules -# embedded in those jar files will be used. This helps preserve compatibility +# 2. If the "crypto.policy" property is not set and the traditional +# US_export_policy.jar and local_policy.jar files +# (e.g. limited/unlimited) are found in the legacy +# /lib/security directory, then the rules embedded within +# those jar files will be used. This helps preserve compatibility # for users upgrading from an older installation. # -# * If crypto.policy is not defined and no such jar files are present in -# the legacy locations, then the JDK will use the limited settings -# (equivalent to crypto.policy=limited) +# 3. If the jar files are not present in the legacy location +# and the "crypto.policy" Security property is not defined, +# then the JDK will use the unlimited settings (equivalent to +# crypto.policy=unlimited) # # Please see the JCA documentation for additional information on these # files and formats. +# +# YOU ARE ADVISED TO CONSULT YOUR EXPORT/IMPORT CONTROL COUNSEL OR ATTORNEY +# TO DETERMINE THE EXACT REQUIREMENTS. +# +# Please note that the JCE for Java SE, including the JCE framework, +# cryptographic policy files, and standard JCE providers provided with +# the Java SE, have been reviewed and approved for export as mass market +# encryption item by the US Bureau of Industry and Security. +# +# Note: This property is currently used by the JDK Reference implementation. +# It is not guaranteed to be examined and used by other implementations. +# #crypto.policy=unlimited # diff --git a/test/javax/crypto/CryptoPermission/CryptoPolicyFallback.java b/test/javax/crypto/CryptoPermission/CryptoPolicyFallback.java new file mode 100644 index 000000000..403266608 --- /dev/null +++ b/test/javax/crypto/CryptoPermission/CryptoPolicyFallback.java @@ -0,0 +1,123 @@ +/* + * Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. Oracle designates this + * particular file as subject to the "Classpath" exception as provided + * by Oracle in the LICENSE file that accompanied this code. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + */ + +/** + * @test + * @bug 8169335 + * @summary Add a crypto policy fallback in case Security Property + * 'crypto.policy' does not exist. + * @run main/othervm CryptoPolicyFallback + */ +import java.io.*; +import java.nio.file.*; +import java.util.stream.*; +import javax.crypto.*; + +/* + * Take the current java.security file, strip out the 'crypto.policy' entry, + * write to a new file in the current directory, then use that file as the + * replacement java.security file. This test will fail if the crypto.policy + * entry doesn't match the compiled in value. + */ +public class CryptoPolicyFallback { + + private static final String FILENAME = "java.security"; + + public static void main(String[] args) throws Exception { + + String javaHome = System.getProperty("java.home"); + + Path path = Paths.get(javaHome, "lib", "security", FILENAME); + + /* + * Get the default value. + */ + String defaultPolicy; + try (Stream lines = Files.lines(path)) { + /* + * If the input java.security file is malformed + * (missing crypto.policy, attribute/no value, etc), throw + * exception. split() might throw AIOOB which + * is ok behavior. + */ + String s = lines.filter(x -> x.startsWith("crypto.policy=")) + .findFirst().orElse(""); + if (!s.isEmpty()) { + defaultPolicy = s.split("=")[1].trim(); + } else { + defaultPolicy = s; + } + } + + /* + * We know there is at least one crypto.policy entry, strip + * all of them out of the java.security file. + */ + try (PrintWriter out = new PrintWriter(FILENAME); + Stream lines = Files.lines(path)) { + lines.filter(x -> !x.trim().startsWith("crypto.policy=")) + .forEach(out::println); + } + + /* + * "-Djava.security.properties==file" does a complete replacement + * of the system java.security file. i.e. value must be "=file" + */ + System.setProperty("java.security.properties", "=" + FILENAME); + + /* + * Find out expected value. + */ + int expected; + switch (defaultPolicy) { + case "limited": + expected = 128; + break; + case "": + case "unlimited": + expected = Integer.MAX_VALUE; + break; + default: + throw new Exception( + "Unexpected Default Policy Value: " + defaultPolicy); + } + + /* + * Do the actual check. If the JCE Framework can't initialize + * an Exception is normally thrown here. + */ + int maxKeyLen = Cipher.getMaxAllowedKeyLength("AES"); + + System.out.println("Default Policy: " + defaultPolicy + + "\nExpected max AES key length: " + expected + + ", received : " + maxKeyLen); + + if (expected != maxKeyLen) { + throw new Exception("Wrong Key Length size!"); + } + + System.out.println("PASSED!"); + } +} diff --git a/test/javax/crypto/CryptoPermission/TestUnlimited.java b/test/javax/crypto/CryptoPermission/TestUnlimited.java index 25d29f8ec..ff0242cb1 100644 --- a/test/javax/crypto/CryptoPermission/TestUnlimited.java +++ b/test/javax/crypto/CryptoPermission/TestUnlimited.java @@ -25,12 +25,13 @@ /** * @test - * @bug 8157561 - * @summary Ship the unlimited policy files in JDK Updates + * @bug 8061842 + * @summary Package jurisdiction policy files as something other than JAR + * @run main/othervm TestUnlimited use_default default * @run main/othervm TestUnlimited "" exception - * @run main/othervm TestUnlimited limited fail - * @run main/othervm TestUnlimited unlimited pass - * @run main/othervm TestUnlimited unlimited/ pass + * @run main/othervm TestUnlimited limited limited + * @run main/othervm TestUnlimited unlimited unlimited + * @run main/othervm TestUnlimited unlimited/ unlimited * @run main/othervm TestUnlimited NosuchDir exception * @run main/othervm TestUnlimited . exception * @run main/othervm TestUnlimited /tmp/unlimited exception @@ -40,9 +41,39 @@ */ import javax.crypto.*; import java.security.Security; +import java.nio.file.*; +import java.util.stream.*; public class TestUnlimited { + private enum Result { + UNLIMITED, + LIMITED, + EXCEPTION, + UNKNOWN + }; + + /* + * Grab the default policy entry from java.security. + * + * If the input java.security file is malformed + * (missing crypto.policy, attribute/no value, etc), throw + * exception. split() might throw AIOOB which + * is ok behavior. + */ + private static String getDefaultPolicy() throws Exception { + String javaHome = System.getProperty("java.home"); + Path path = Paths.get(javaHome, "lib", "security", "java.security"); + + try (Stream lines = Files.lines(path)) { + String s = lines.filter(x -> x.startsWith("crypto.policy=")) + .findFirst().orElse(""); + if (!s.isEmpty()) + return s.split("=")[1].trim(); + return s; + } + } + public static void main(String[] args) throws Exception { /* * Override the Security property to allow for unlimited policy. @@ -53,16 +84,38 @@ public class TestUnlimited { throw new Exception("Two args required"); } - boolean expected = args[1].equals("pass"); - boolean exception = args[1].equals("exception"); - boolean result = false; + String testStr = args[0]; + String expectedStr = args[1]; + if (testStr.equals("use_default")) { + expectedStr = getDefaultPolicy(); + } + + Result expected = Result.UNKNOWN; // avoid NPE warnings + Result result; - System.out.println("Testing: " + args[0]); + switch (expectedStr) { + case "": + case "unlimited": + expected = Result.UNLIMITED; + break; + case "limited": + expected = Result.LIMITED; + break; + case "exception": + expected = Result.EXCEPTION; + break; + default: + throw new Exception("Unexpected argument"); + } - if (args[0].equals("\"\"")) { + System.out.println("Testing: " + testStr); + if (testStr.equals("\"\"")) { Security.setProperty("crypto.policy", ""); } else { - Security.setProperty("crypto.policy", args[0]); + // skip default case. + if (!testStr.equals("use_default")) { + Security.setProperty("crypto.policy", testStr); + } } /* @@ -74,21 +127,20 @@ public class TestUnlimited { System.out.println("max AES key len:" + maxKeyLen); if (maxKeyLen > 128) { System.out.println("Unlimited policy is active"); - result = true; + result = Result.UNLIMITED; } else { System.out.println("Unlimited policy is NOT active"); - result = false; + result = Result.LIMITED; } } catch (Throwable e) { - if (!exception) { - throw new Exception(); - } + //ExceptionInInitializerError's + result = Result.EXCEPTION; } System.out.println( "Expected:\t" + expected + "\nResult:\t\t" + result); - if (expected != result) { - throw new Exception(); + if (!expected.equals(result)) { + throw new Exception("Didn't match"); } System.out.println("DONE!"); -- GitLab