Java Restricted Security Mode

[taoliult]

Signed-off-by: Tao Liu [email protected]

This PR is for adding the codes of Java Restricted Security Mode.

The Java Restricted Security Mode is used to restrict the providers and algorithms, by the properties configured in the java.security file.

The properties will be of the following format:

RestrictedSecurity(n).desc.name = This string would be presented to the user when the audit setting is turned on, used to identify the policy in a helpful manner
RestrictedSecurity(n).desc.number = Security policy number
RestrictedSecurity(n).desc.policy = Policy details link
RestrictedSecurity(n).desc.sunsetDate = Date by which the policy will sunset

RestrictedSecurity(n).tls.disabledNamedCurves = Map to jdk.disabledNamedCurves
RestrictedSecurity(n).tls.disabledAlgorithms = Map to jdk.tls.disabledAlgorithms
RestrictedSecurity(n).tls.ephemeralDHKeySize = Map to jdk.tls.ephemeralDHKeySize
RestrictedSecurity(n).tls.legacyAlgorithms = Map to jdk.tls.legacyAlgorithms

RestrictedSecurity(n).jce.certpath.disabledAlgorithms = Map to jdk.certpath.disabledAlgorithms
RestrictedSecurity(n).jce.legacyAlgorithms = Map to jdk.security.legacyAlgorithm
RestrictedSecurity(n).jce.provider.1 = Map to security.provider
RestrictedSecurity(n).jce.provider.2 = Map to security.provider
RestrictedSecurity(n).jce.provider.3 = Map to security.provider
RestrictedSecurity(n).jce.provider.4 = Map to security.provider

RestrictedSecurity(n).keystore.type = Map to keystore.type 
RestrictedSecurity(n).javax.net.ssl.keyStore = System property javax.net.ssl.keyStore

RestrictedSecurity(n).securerandom.provider = Secure random provider
RestrictedSecurity(n).securerandom.algorithm = Secure random algorithm

The new runtime command line arguments:

-Dsemeru.restrictedsecurity = (n)
    This flag will select the settings for the user specified fips policy.
-Dsemeru.restrictedsecurity= audit 
    This will list the name and number of all configured fips policies. it will NOT cause the jvm to terminate after printing the fips policies.
-Dsemeru.restrictedsecurity = trace
    This will list all properties relevant to the fips mode, including the existing default properties and the FIPS restrictions.
-Dsemeru.restrictedsecurity = help
    This will print help message.

The options can be combined: e.g. -Dsemeru.restrictedsecurity=1,trace,audit

During the process of reading the java.security properties file, the JDK will detect if Restricted Security mode as selected and the selected policy. This detection will be done as a check in the JCA code to see if the flag "semeru.restrictedsecurity" was used, if it is used, the specific policy number will be extracted, the code will then check the properties file to see if such a policy number exist. If a valid policy is selected, two configuration steps will occur:

1. JSSE Configuration during start up. If a valid policy was selected, the properties in java.security file will be read and mapped during the start up.

2. Cryptography available. The existing providers will be removed and only the compliant providers (defined by “SecurityRestrict(n).jce.provider”) will be added. And also, a list of permitted services that each provider may provide. A provider without any additional constraints will have all its services enabled. A provider with the constraints will only register the allowed constraints. For example:

RestrictedSecurity1.jce.provider.3 = SunEC [{KeyFactory, EC, ImplementedIn=Software: \
SupportedKeyClasses=java.security.interfaces.ECPublicKey|java.security.interfaces.ECPrivateKey: \
KeySize=256}, {AlgorithmParameters, EC, *}]

[taoliult]

@keithc-ca Java Restricted Security Mode PR for JDKnext, please help to review and advice.

[taoliult]

@keithc-ca

The pushes in last two days are for git rebase the branch, because the head had new commits, so I rebase the branch to accept the new commits from the head to make sure there is no any conflict.

Right now, the PR is ready for review. Please help to review and advice.

[keithc-ca]

The pushes in last two days are for git rebase

Please stop doing that. I'll let you know if it needs to be rebased or otherwise updated.

[taoliult]

@keithc-ca Ok, sure. Right now the codes are ready for review.

[taoliult]

@keithc-ca

Changed the class name from “RestrictedSecurityConfigurator” to “RestrictedSecurity”. And also update class “RestrictedSecurityProperties” as a nested class of “RestrictedSecurity”.

The PR is ready for review. Please help to review and advice.

[taoliult]

@keithc-ca The PR is ready for review. Please help to review and advice.

[taoliult]

@keithc-ca
The PR is ready for review. For some review suggestions I updated the codes, others I replied the questions. Please help to review and advice. Thanks so much.

[taoliult]

@keithc-ca The PR is ready for review. Please help to review and advice. Thanks so much.

[taoliult]

@keithc-ca

As we talked in slack, I added the checks in three methods of ProviderList.java.

In the ProviderList.insertAt() method, even we had the provider checks in ServiceLoader.java and ProviderConfig.java, to stop the non-FIPS provider loading. But adding the isProviderAllowed() checks in insertAt() will avoid NPE, when the customer try to add their own provider by calling ProviderList.insertAt() or ProviderList.add() methods, and then calling ProviderList.remove() to remove it. Because the provider will be added into the list but it can not be loaded, so the provider in the list will be as null.

When running the extended.openjdk tests, I can see the test case failure changed from NPE to “java.lang.Exception: Provider not added” which is more readable, in those test cases which add and remove the test dummy providers.

In the ProviderList.newList(), add the similar checks with the same reason as ProviderList.insertAt() method.

In the getService() method, and the inner class ServiceList’s tryGet() method, add the isServiceAllowed() check, to stop the non-FIPS services returned.

Right now, the PR is ready for review. Please help to review and advice. Thanks so much.

@jasonkatonica @WilburZjh FYI.

[taoliult]

@keithc-ca
The PR is ready for review. For some review suggestions I updated the codes, others I replied the questions. Please help to review and advice. Thanks so much.

@jasonkatonica @WilburZjh
FYI.

[taoliult]

@keithc-ca
The PR is ready for review. Please help to review and advice. Thanks so much.

@jasonkatonica @WilburZjh
FYI.

[keithc-ca]

I think this looks good. I want to convince myself that the updated java.security file leads to the same set of security providers, in the same order, offering the same algorithms as would be the case before this change in the presence of -Dsemeru.fips=true.

[taoliult]

@keithc-ca

Yes, I listed and compared all the security providers and their algorithms, between the Java Restricted Security Mode by using FIPS policy (-Dsemeru.restrictedsecurity=1) and the current released Semeru FIPS by using “-Dsemeru.fips=true”. The listed security providers are in the same order, offering the same algorithms.

And I also compared the 5 OpenJDK and JCK test results (sanity.openjdk, extended.openjdk, sanity.jck, extended.jck and special.jck) between the Java Restricted Security Mode by using FIPS policy (-Dsemeru.restrictedsecurity=1) and the current released Semeru FIPS by using “-Dsemeru.fips=true”. There are more expected failures since the test cases are trying to create its own providers which is not allowed in Java Restricted Security Mode FIPS. Except these expected failures, other test results are same as before. So, the tests look good.

@jasonkatonica @WilburZjh FYI.

[keithc-ca]

Jenkins compile alinux64 jdknext

[pshipton]

Will this be backported to jdk8?

[taoliult]

@pshipton Yes, I am working on the backport to OpenJDK8.

@keithc-ca @jasonkatonica @WilburZjh fyi.