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

harden_openssl_crypto_policy rule edits configs it shouldn't to enable things it shouldn't #12646

Open
t184256 opened this issue Nov 27, 2024 · 1 comment

Comments

@t184256
Copy link

t184256 commented Nov 27, 2024

A harden_openssl_crypto_policy has been brought to my attention, and I couldn't help but note it does several things it outright shouldn't:

  1. Remove configuration from backend file /etc/crypto-policies/back-ends/opensslcnf.config directly edits a /etc/crypto-policies/back-ends/opensslcnf.config, which is always a bad idea no matter whether it's generated or a symlink to /usr/share
  2. [Ensure that the correct crypto policy configuration exists in /etc/crypto-policies/local.d/opensslcnf-ospp.config](enables Chacha20Poly1305). If the ospp in the path is an indication of FIPS:OSPP being the poor policy being 'hardened', the line actually relaxes it
  3. to enable an algorithm that's not even FIPS-certified!

Please investigate and get rid of this and any similar rules that modify files in /etc/crypto-policies/back-ends. Custom policies or subpolicies should be used to achieve the desired effect instead; worst case it could be local.d dropins, but not carving live files.

@jan-cerny
Copy link
Collaborator

Fortunately, the rule harden_openssl_crypto_policy isn't a part of any existing profile. The rule was used in history but we can't remove existing rules because of backwards compatibility. Unless users explicitly opt-in for this rule they don't use it.

I think we should at least add a warning text to this rule.

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

No branches or pull requests

2 participants