ComplianceAsCode / ComplianceAsCode/content
Crypto Policies vs RHEL9 STIG
- Dominant language
- Shell
- Stars
- 2.8k
- Forks
- 828
- Avg merge
- 3d 8m
- Merged PRs (30d)
- 80
Description
The recent (09/2022) RHEL9 STIG proposal twists our rules that work with Crypto Policies.
Our rules fall into two categories - they either
- make sure that a component respects the system-wide Crypto Policy, or they
- set the system Crypto Policy to a certain value.
However, the proposal doesn't follow that division:
- [gnutls_tls](https://github.com/Mab879/content/commit/bc158d4df5695bd9a572bfa023ffe83b90a50aa7?path=linux_os/guide/system/software/integrity/crypto/configure_gnutls_tls_crypto_policy/rule.yml): The proposal is about testing for the current system Crypto Policy (FIPS), not at all about GnuTLS respecting it. The former version of the rule wasn't all right either - It was about contents of the crypto policy file, not about gnutls adhering to the crypto policy. The correct approach could be to rename the rule to "harden crypto policy", but the hardening itself should be consulted with the Crypto team.
- [kerberos](https://github.com/Mab879/content/commit/bc158d4df5695bd9a572bfa023ffe83b90a50aa7?path=linux_os/guide/system/software/integrity/crypto/configure_kerberos_crypto_policy/rule.yml): There is a subtle disconnect - the rule is about Kerberos using FIPS Crypto Policy regardless what is the current system Crypto Policy - that goes against the design of Crypto Policies.
- [openssl](https://github.com/Mab879/content/commit/bc158d4df5695bd9a572bfa023ffe83b90a50aa7?path=linux_os/guide/system/software/integrity/crypto/configure_openssl_crypto_policy/rule.yml): Rule is partially about adhering to the system Crypto Policy, partially it is about setting the FIPS mode - the latter doesn't belong there.
- [openssl_tls](https://github.com/Mab879/content/commit/bc158d4df5695bd9a572bfa023ffe83b90a50aa7?path=linux_os/guide/system/software/integrity/crypto/configure_openssl_tls_crypto_policy/rule.yml): The proposal is about contents of the `opensslcnf.config` file - that file is packaged by the Crypto Policies package. Any changes should be consulted with the Crypto Team, and if changes are needed, they should be put into a different file, as that file is basically generated.
- [libreswan](https://github.com/Mab879/content/commit/bc158d4df5695bd9a572bfa023ffe83b90a50aa7?path=linux_os/guide/system/software/integrity/crypto/configure_libreswan_crypto_policy/rule.yml): The prose mentions concrete ciphers, but the rule should be about configuration of libreswan that assures respecing the system Crypto Policy. However, the `checktext` is fine.
- [openssh](https://github.com/Mab879/content/commit/bc158d4df5695bd9a572bfa023ffe83b90a50aa7?path=linux_os/guide/system/software/integrity/crypto/configure_ssh_crypto_policy/rule.yml): Actually no issue, the proposal is directionally correct, except the fact that RHEL9 OpenSSH Crypto Policy need a facelift.
- [configure_crypto_policy](https://github.com/Mab879/content/commit/bc158d4df5695bd9a572bfa023ffe83b90a50aa7?path=linux_os/guide/system/software/integrity/crypto/configure_crypto_policy/rule.yml): The rule assumes the FIPS Crypto Polic, while before it was parametrized while the STIG profile did the parametrization.
- Moreover: Files in `/etc/crypto-policies/local.d/` can modify policies — they’re appended to `/etc/crypto-policies/back-ends/$backend`. Some of e.g. Red Hat packages ship some,
Contributor guide
Assessment
This issue has not been assessed yet.