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.

Sign up for GitHub

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

Add a check to detect the OpenJCEPlus module #924

Open
wants to merge 1 commit into
base: openj9
Choose a base branch
from
Open

Add a check to detect the OpenJCEPlus module #924

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 13 additions & 1 deletion closed/src/java.base/share/classes/openj9/internal/security/RestrictedSecurity.java
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
/*
* ===========================================================================
* (c) Copyright IBM Corp. 2022, 2024 All Rights Reserved
* (c) Copyright IBM Corp. 2022, 2025 All Rights Reserved
* ===========================================================================
*
* This code is free software; you can redistribute it and/or modify it
Expand Down Expand Up @@ -42,6 +42,7 @@
import java.util.List;
import java.util.Map;
import java.util.Objects;
import java.util.Optional;
import java.util.Properties;
import java.util.Set;
import java.util.regex.Matcher;
Expand All @@ -67,6 +68,7 @@ public final class RestrictedSecurity {

private static final boolean isNSSSupported;
private static final boolean isOpenJCEPlusSupported;
private static final boolean isOpenJCEPlusModuleExist;

private static final boolean userSetProfile;
private static final boolean shouldEnableSecurity;
Expand Down Expand Up @@ -137,6 +139,11 @@ public String[] run() {
}
isOpenJCEPlusSupported = isOsSupported && isArchSupported;

// Check whether the OpenJCEPlus module exists.
ModuleLayer layer = ModuleLayer.boot();
Optional<Module> module = layer.findModule("openjceplus");
isOpenJCEPlusModuleExist = module.isPresent();

// Check the default solution to see if FIPS is supported.
isFIPSSupported = isNSSSupported;

Expand Down Expand Up @@ -387,6 +394,11 @@ private static void checkIfKnownProfileSupported() {
+ " on this platform.");
}

if (!isOpenJCEPlusModuleExist && profileID.contains("OpenJCEPlus")) {
Copy link
Member

Choose a reason for hiding this comment

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

This doesn't seem right. Trying to use a profile called "not-OpenJCEPlus" shouldn't demand the presence of the openjceplus module. Also profiles that don't contain that string might actually depend on the openjceplus module.

I would expect to just get "no such provider" or something similar if I try to use an algorithm that requires a module (perhaps openjceplus, but it could be another module) that isn't present in the runtime in use. What are the current symptoms of that situation? Are they really worth potentially breaking legitimate use-cases?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The initially discussion about this is, we want to remove the OpenJCEPlus profile from the java.security file in the OpenJ9 builds. The OpenJCEPlus profile should only appear in the java.security file for the Semeru and personal builds. To do this, our first proposal was to modify how the java.security file is generated by introducing a new variable during the process. But, you suggested keeping the profile in the file and instead using a general mechanism to handle any broken profiles. So I am thinking about this current solution to detect the OpenJCEPlus module.

But after the team discussions last Friday, we realized that using this detect the OpenJCEPlus module solution won’t work for the OpenJCEPlus on z/OS. Since the OpenJCEPlus doesn’t exist as a Java module on z/OS.

So, we still think the best solution is to remove the OpenJCEPlus profile from the java.security file in the OpenJ9 builds. That said, it needs to add a new variable during the java.security file generation process. Or, do you have any other suggestions?

Copy link
Member

Choose a reason for hiding this comment

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

Yes, we could conditionally include sections of java.security depending on whether BUILD_OPENJCEPLUS is true or false, but that wouldn't address the problem of a runtime created via jlink that excludes the openjceplus module.

It's not immediately obvious that we have a serious problem that needs to be solved. What are the symptoms if an algorithm is requested that is not present in the runtime?

printStackTraceAndExit("FIPS 140-3 profile specified. Required OpenJCEPlus"
+ " module not found.");
}

if (debug != null) {
debug.println("RestrictedSecurity profile " + profileID
+ " is supported on this platform.");
Expand Down