ComplianceAsCode / ComplianceAsCode/content
harden_openssl_crypto_policy rule edits configs it shouldn't to enable things it shouldn't
- Dominant language
- Shell
- Stars
- 2.8k
- Forks
- 828
- Avg merge
- 3d 8m
- Merged PRs (30d)
- 80
Description
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](https://github.com/ComplianceAsCode/content/blob/8812908c51e7c71a9903d3a5ec256eae62cba8fe/linux_os/guide/system/software/integrity/crypto/harden_openssl_crypto_policy/ansible/shared.yml#L11) 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](https://gitlab.com/redhat-crypto/fedora-crypto-policies/-/blob/rhel8/tests/outputs/FIPS:OSPP-opensslcnf.txt) 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.
Contributor guide
Assessment
This issue has not been assessed yet.