Open ggbecker opened 3 years ago
The strings mentioned here only change their order, they still contain the same elements, I wonder if the order is important in this case.
This order change is indeed the case. We run into this exact problem when updating from RHEL8.4 to RHEL8.6. Since this file is enabling/disabling crypto policies it is not likely that the order is important. I would suggest to change the check that it is not dependent on the order of the set parameters. The configure_gnutls_tls_crypto_policy rule is failing for me on RHEL8.6.
@jan-cerny @yuumasato maybe if we parametrize the rule to accept the input as a variable could help here.
On the other hand we could just update the oval to accept one or another.
Is there any update on this issue?
This has become a bigger deal for high security environments. The fix is to change the order manually, which then fails in the rpm verify rule, resulting in the inability to appease the scanner. This becomes a big issue for enterprise environments where managing 100k+ secure systems requires automation of security verification.
Can we please get an update on this?
Is this issue still on the radar?
can we please get an update on this?
https://github.com/ComplianceAsCode/content/blob/9fcf8560cf16987306bd8179050ef6660c67bb73/linux_os/guide/system/software/integrity/crypto/configure_gnutls_tls_crypto_policy/rule.yml#L15
This is possibly changing in a upcoming release of RHEL8 and the rule should be adapted accordingly.
New string:
+VERS-ALL:-VERS-DTLS0.9:-VERS-TLS1.1:-VERS-TLS1.0:-VERS-SSL3.0:-VERS-DTLS1.0