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

Fix permissions issues while reading keys in PKCS#1 format #3289

Merged

Conversation

cwperks
Copy link
Member

@cwperks cwperks commented Sep 1, 2023

Description

Netty has logic to use the BouncyCastlePemReader if BouncyCastle is located on the class path. The BouncyCastle provider loaded properly in netty, but was failing to read the private key with permissions issues that failed silently. With netty, if one PemReader fails they will fall back to the next which is only capable of reading keys in the PKCS#8 format.

The regression in PKCS#1 keys happened when bouncycastle was upgraded from jdk15on to jdk15to18.

This PR adds permissions to ensure that netty can read the PKCS#1 keys.

This PR also cleans up the policy file to have a single entry for permission java.util.PropertyPermission "*","read,write"; because the other entries are redundant.

Open Questions:

  • There is a test in SSLTest to ensure PKCS#1 keys can be read. Why did that test not catch this?
  • Category (Enhancement, New feature, Bug fix, Test fix, Refactoring, Maintenance, Documentation)

Bug fix

Issues Resolved

#3281

Testing

Used the same certs from the SSLTest for PKCS#1 keys. Before the change the 2.9.0 cluster could not be brought up, after the change the cluster starts successfully.

Check List

  • New functionality includes testing
  • New functionality has been documented
  • Commits are signed per the DCO using --signoff

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.

@cwperks
Copy link
Member Author

cwperks commented Sep 1, 2023

Reverting back to jdk15on for the artifact resolves the PKCS issue, but jdk15on stopped publishing after 1.70 and the artifact has CVEs associated with it which is why the security repo switched from jdk15on to jdk15to18: #2901

@codecov
Copy link

codecov bot commented Sep 1, 2023

Codecov Report

Merging #3289 (6b42451) into main (cd45e78) will decrease coverage by 0.02%.
The diff coverage is 37.50%.

Impacted file tree graph

@@             Coverage Diff              @@
##               main    #3289      +/-   ##
============================================
- Coverage     63.23%   63.22%   -0.02%     
+ Complexity     3450     3449       -1     
============================================
  Files           263      263              
  Lines         20040    20053      +13     
  Branches       3344     3348       +4     
============================================
+ Hits          12673    12678       +5     
- Misses         5740     5747       +7     
- Partials       1627     1628       +1     
Files Changed Coverage Δ
...ensearch/security/ssl/DefaultSecurityKeyStore.java 72.29% <37.50%> (-1.70%) ⬇️

... and 2 files with indirect coverage changes

@cwperks
Copy link
Member Author

cwperks commented Sep 1, 2023

Trying again with jdk15to18. It may not be possible to upgrade bouncycastle in the security plugin alone. A couple core modules also use bouncycastle.

Signed-off-by: Craig Perkins <[email protected]>
@cwperks cwperks changed the title Upgrade to bc jdk18on and fix permissions issues while reading keys in PKCS#1 format Fix permissions issues while reading keys in PKCS#1 format Sep 1, 2023
@@ -37,7 +37,6 @@ grant {
permission java.util.PropertyPermission "*","read,write";
Copy link
Member Author

@cwperks cwperks Sep 1, 2023

Choose a reason for hiding this comment

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

This permission covers read and write for all properties so anything else is redundant

Copy link
Member

Choose a reason for hiding this comment

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

Can we investigate these other policy lines separately to minimize the surface area of this change?

Copy link
Member Author

Choose a reason for hiding this comment

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

The only PropertyPermission this code change removes is permission java.util.PropertyPermission "org.apache.xml.security.ignoreLineBreaks", "write";, but this explicit permission isn't required since there's already an item for permission java.util.PropertyPermission "*","read,write"; near the top of this file. I removed another permission that was commented out as well.

@stephen-crawford
Copy link
Collaborator

Are the CI failures from something else or are you still working on this?

@cwperks
Copy link
Member Author

cwperks commented Sep 1, 2023

@scrawfor99 I think they be from something else. I am looking into it now.

Caused by:
java.lang.IllegalStateException: HTTP/2 expected for HTTPS communication but HTTP/1.1 was used
at org.opensearch.security.test.helper.rest.RestHelper.executeRequest(RestHelper.java:286)

Copy link
Member

@peternied peternied left a comment

Choose a reason for hiding this comment

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

Used the same certs from the SSLTest for PKCS#1 keys. Before the change the 2.9.0 cluster could not be brought up, after the change the cluster starts successfully.

So you can reproduce it, but our test behaves differently? Is it running with the security manager disabled?

Comment on lines 1008 to 1009
.sessionCacheSize(0)
.sessionTimeout(0)
Copy link
Member

Choose a reason for hiding this comment

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

Where did these values come from, how can we confirm these are correct?

Copy link
Member Author

Choose a reason for hiding this comment

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

I just noticed that this is different on 2.x and main. I was testing with changes on the 2.9 branch where the error was seen, but then stashed my changes and applied them on main. I updated this to accommodate for the differences on main now. These values come from here: https://github.com/opensearch-project/security/blob/main/src/main/java/org/opensearch/security/ssl/DefaultSecurityKeyStore.java#L1009-L1035

@@ -37,7 +37,6 @@ grant {
permission java.util.PropertyPermission "*","read,write";
Copy link
Member

Choose a reason for hiding this comment

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

Can we investigate these other policy lines separately to minimize the surface area of this change?

Signed-off-by: Craig Perkins <[email protected]>
Signed-off-by: Craig Perkins <[email protected]>
@cwperks
Copy link
Member Author

cwperks commented Sep 1, 2023

So you can reproduce it, but our test behaves differently? Is it running with the security manager disabled?

That's my hunch as well, but I don't see where/if its disabled for SSLTest

Signed-off-by: Craig Perkins <[email protected]>
ciphers,
authMode
);
try {
Copy link
Member

Choose a reason for hiding this comment

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

Refactor 'doPrivileged(...) with try catch into a function so you can rewrite this block as the following?

final SslContextBuilder _sslContextBuilder = this.doPrivilegedSslAction(() ->
   configureSSLServerContextBuilder(SslContextBuilder.forServer(_key, _cert), sslProvider, ciphers, authMode));

@willyborankin
Copy link
Collaborator

I think this problem related to this one as well: #3213

Copy link
Collaborator

@stephen-crawford stephen-crawford left a comment

Choose a reason for hiding this comment

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

This change seems good @cwperks, but how do we know it works? It seems like changes the permission behavior by it is not clear where that gets tested...

I am going to approve but open a fast follow issue and link this.

@stephen-crawford
Copy link
Collaborator

Follow-up issue: #3318

@stephen-crawford stephen-crawford added the backport 2.x backport to 2.x branch label Sep 5, 2023
@stephen-crawford stephen-crawford merged commit 1034cef into opensearch-project:main Sep 5, 2023
56 of 58 checks passed
@opensearch-trigger-bot
Copy link
Contributor

The backport to 2.x failed:

The process '/usr/bin/git' failed with exit code 128

To backport manually, run these commands in your terminal:

# Navigate to the root of your repository
cd $(git rev-parse --show-toplevel)
# Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add ../.worktrees/security/backport-2.x 2.x
# Navigate to the new working tree
pushd ../.worktrees/security/backport-2.x
# Create a new branch
git switch --create backport/backport-3289-to-2.x
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 1034cef92eaa20a360c4863106f96b0ae06ab1af
# Push it to GitHub
git push --set-upstream origin backport/backport-3289-to-2.x
# Go back to the original working tree
popd
# Delete the working tree
git worktree remove ../.worktrees/security/backport-2.x

Then, create a pull request where the base branch is 2.x and the compare/head branch is backport/backport-3289-to-2.x.

@cwperks
Copy link
Member Author

cwperks commented Sep 6, 2023

I will open a manual backport

cwperks added a commit that referenced this pull request Sep 6, 2023
willyborankin added a commit to willyborankin/security that referenced this pull request Sep 25, 2023
DarshitChanpura pushed a commit that referenced this pull request Oct 2, 2023
…rmat (#3406)

Backport to 1.x from #3289

We did not do it, while 1.x version has the same problem as 2.x branch.
Moved only permissions.

Signed-off-by: Andrey Pleskach <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport 2.x backport to 2.x branch
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants