Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for FIPS compliance mode #14912

Open
wants to merge 17 commits into
base: main
Choose a base branch
from

Conversation

beanuwave
Copy link

@beanuwave beanuwave commented Jul 23, 2024

Description

This PR makes FIPS mode available through the OPENSEARCH_CRYPTO_STANDARD=FIPS-140-3 environmental parameter instead of the tests.fips.enabled setting. It provides FIPS 140-3 support by replacing all BC dependencies with BCFIPS dependencies and making FIPS approved-only mode configurable at launch. Running this mode restricts the BCFIPS provider to rely solely on FIPS-certified ciphers.

  • The fips.gradle build script is removed in order to support a single-build solution.
  • All BC dependencies are replaced by BCFIPS.
  • Fixed creation of password protected internal keystore for valuable settings at node start. The add-string command was made with additional --stdin option, which interferes with password input.
  • The Password Matcher inside Identity-Shiro that relies on BC to check if hashed passwords match with OpenBSDBCrypt is replaced by the password4j implementation.
  • Adds full support for the BCFKS format (*.bcfks) for key and trust stores, also making it the default.
  • KeyStore instantiation was added to forbidden-apis in favour of KeyStoreFactory.
  • Google's truststore is converted to the BCFKS format.
  • Makes the best guess of which store type is provided based on the filename extension.
  • Store types are strictly limited to JKS, PKCS12, PKCS11, and BCFKS.
  • Refactors PemUtils to parse private keys in formats EC, PKCS8, PKCS1, and DSA, with or without encryption, and with or without parameters.
  • dependency ':libs:opensearch-common' was added to rest-client build, to support strict keystore types. It's also the reason for JVM bump JAVA8 to JAVA11.
  • allow ingest-attachment plugin to run in FIPS mode, since BC dependencies find no use.
  • The java.security file is added to the build to distinguish between FIPS and non-FIPS environments.
  • The fips_java.security file is altered due to evolving security standards.
  • The security.policy file is altered to grant necessary security permissions.
  • Increased security standards in KeyTabs and algorithms for Kerberos.
  • SecureRandom gets instantiated in to different way, depending on if it runs with FIPS or not.
  • Uninstalls SunJCE provider from security providers list at runtime when FIPS mode is enabled.

Runtime limitations (known so far) that come with enabling FIPS mode:

Admins can continue to manage their systems without being impacted by this change. However, for those keen on FIPS compliance, the most common obstacle will likely be the requirement to set a stronger password for the internal keystore and also convert key and truststores to *.bcfks format.

  • Does not allow empty passwords for keystores or private keys (they need to be at least 112 bits in strength).
  • The ssl.verification_mode=NONE setting is not permitted.
  • JKS and PKCS12 key and trust store types are not supported at all.
  • The internal keystore cannot be auto-migrated from versions 1 or 2.
  • Azure Classic Discovery plugin -> deprecated.
  • SQL-CLI client.
  • HDFS plugin won't connect since it's using RC4 cipher for token authentication.

Reasons for refactoring PemUtils, which is used by the Reindex API in cases of migrating data from a remote cluster that is TLS protected:

  • Lack of support for evolving standards like PKCS#8.
  • Password-Based Key Derivation Functions such as PBKDF-OPENSSL are not supported in FIPS mode in favor of the PBKDF2 standard.
  • Java type safety.
  • It is generally a good idea to let ASN1 annotation parsing be done by external security libraries.

Related Issues

opensearch-project/security#3420

Check List

  • Functionality includes testing.
  • API changes companion pull request created, if applicable.
  • Public documentation issue/PR created, if applicable.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Copy link
Contributor

❌ Gradle check result for 6016d5d: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

@beanuwave beanuwave changed the title Draft to allow run in FIPS compliace mode Draft to allow run in FIPS compliance mode Jul 24, 2024
Copy link
Contributor

❌ Gradle check result for 8e8ed47: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

Copy link
Contributor

❌ Gradle check result for 6016d5d: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

@dblock
Copy link
Member

dblock commented Jul 24, 2024

Could use some help maybe from @cwperks or @peternied reviewing this, please.

Signed-off-by: Iwan Igonin <[email protected]>

# Conflicts:
#	server/build.gradle

# Conflicts:
#	server/build.gradle
Signed-off-by: Iwan Igonin <[email protected]>

# Conflicts:
#	buildSrc/version.properties
Signed-off-by: Iwan Igonin <[email protected]>
Summery:
- replace unsecure kerberos crypto algorithms
- add 'java.security.KeyStore' to forbidden-apis
- instantiate and use SecureRandom from BCFIPS library
- exclude SunJCE from security providers list at runtime, when running in FIPS JVM
- exclude Azure tests when running in FIPS JVM

Signed-off-by: Iwan Igonin <[email protected]>
Copy link
Contributor

github-actions bot commented Feb 3, 2025

❌ Gradle check result for eabee15: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

Copy link
Contributor

github-actions bot commented Feb 3, 2025

❌ Gradle check result for 663d3f5: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

Copy link
Contributor

github-actions bot commented Feb 3, 2025

✅ Gradle check result for 6a14fdc: SUCCESS

@beanuwave
Copy link
Author

Since the last code review, a few changes were introduced in the most recent two commits. I kindly ask to review them as well:

  • The keystore script can now be executed in a FIPS JVM, which is particularly useful for selecting the appropriate SecureRandom.
  • All testcluster tasks now propagate the keystore password for ITs, when run in a FIPS JVM.
  • The build relies on a new parameter, -Pcrypto.standard=FIPS-140-3, to activate FIPS mode. This is a workaround when testing in IntelliJ. Because gradle builds run via the daemon, and modified environment or JVM parameters might not be recognized unless a fresh build is performed.

@kaimst
Copy link

kaimst commented Feb 3, 2025

@cwperks @andrross, given the high frequency of incoming changes, this PR is becoming increasingly difficult to rebase due to its size. Could we prioritize merging it soon? Alternatively, do we need to address any fundamental issues with the way we use the BC libraries first ?

@cwperks
Copy link
Member

cwperks commented Feb 3, 2025

@kaimst taking another pass at this PR. I think all of my outstanding comments have been addressed. This PR looks like its in a good state w/ the introduction of the -Pcrypto.standard=FIPS-140-3 build param. I would support making this default in the future as long as there is more extensive testing done in the future w/ plugins in the default distribution.

Copy link
Member

@cwperks cwperks left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Took another pass. This PR looks like its in a good state to me. @reta have your comments been addressed with the introduction of a build param?

@@ -113,6 +114,12 @@ dependencies {

// https://mvnrepository.com/artifact/org.roaringbitmap/RoaringBitmap
api libs.roaringbitmap

// bouncyCastle
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Most dependencies in this module reference the gradle version catalog. These could be converted similarly, but can be addressed in a future change.

@@ -0,0 +1,55 @@
# Security Properties for JDK 11 and higher, with BouncyCastle FIPS provider and BouncyCastleJsseProvider in approved-only mode
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are the same properties applicable to JDK 21 which 3.0.0 is planning to target?

@@ -64,6 +67,7 @@
import static org.hamcrest.Matchers.instanceOf;
import static org.hamcrest.Matchers.lessThanOrEqualTo;

@LuceneTestCase.AwaitsFix(bugUrl = "")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Which test is failing in this suite? Is it necessary to mute these tests?

@@ -93,6 +93,26 @@ grant codeBase "${codebase.reactor-core}" {
permission java.net.SocketPermission "*", "connect,resolve";
};

// security
grant {
permission java.lang.RuntimePermission "accessClassInPackage.sun.security.internal.spec";
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: this block and the block below can be consolidated into a single grant block and the comment could be kept for maintainability to group permissions.

I don't expect this comment to be addressed, because JSM is on the deprecation path and there is an RFC open on whether it should be disabled in OpenSearch 3.0.0 entirely: #17181

@@ -122,34 +119,37 @@ private RestClient buildRestClient() {
return RestClient.builder(new HttpHost("https", address.getHostString(), address.getPort())).build();
}

private static SSLContext getSslContext() throws Exception {
SSLContext sslContext = SSLContext.getInstance(getProtocol());
private static SSLContext getSslContext(boolean server) throws Exception {
Copy link
Collaborator

@reta reta Feb 3, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does it make sense to split this test into 2? The one the deals with crt / jks, and a new one with bcfks?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.