Fix crypto policy settings in CIS

[jan-cerny]

This PR adds these rules:

• configure_custom_crypto_policy_cis
• configure_custom_crypto_policy_cis_mac
• configure_custom_crypto_policy_cis_ssh_cbc
• configure_custom_crypto_policy_cis_ssh_ciphers
• configure_custom_crypto_policy_cis_ssh_macs

The rules configure multiple custom crypto sub policy modules for RHEL CIS. The new rule is very similar to fips_custom_stig_sub_policy. It configures new modules for system wide crypto policies that reduces the set of usable ciphers in sshd, MACs, and others.

The rule is templated by a new template crypto_sub_policies that is also introduced in this commit so that the code can be reused in other similar rules.

This change aligns the RHEL 8 CIS profiles in CaC with the requirements requested in CIS RHEL 8 Benchmark v4.0.0, CIS RHEL 9 Benchmark v2.0.0 and CIS RHEL 10 Benchmark v1.0.1.

All crypto requirements of this profile are now covered by this single rule. The reason for merging all of the sub module configuration is to prevent overriding crypto policy settings. If there would be multiple rules, each of them would call the update-crypto-policies commands with a different sub policy, overriding each other.

This supersedes #14050

Resolves: https://issues.redhat.com/browse/RHEL-111896
Also, it resolves some of the items from https://issues.redhat.com/browse/RHEL-76009.

[openshift-ci]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[ggbecker]

I believe the same should apply for all other CIS RHEL (9/10) major versions.

And would be ideal if the rule would not be RHEL8 centric. We could in theory set the sub_policies variable according to the RHEL version.

Also I believe that it is still valid to check for particular submodules in the crypto policy, for example there would still have a need for the rule that checks if the current crypto policy respects a given security requirement (e.g. no weak mac), this rule would simply check if the submodule contains the right algorithm restriction, and the remediation can simply be reapply the expected sub crypto policy in case of deviation.

This would not imply a change in the CIS benchmarks for example, where they have a requirement for each of the restriction they expect.

I also don't like the name of the rule, instead of crypto_sub_policies_cis_rhel8,
maybe something like configure_custom_crypto_policy_cis

[jan-cerny]

@ggbecker

I believe the same should apply for all other CIS RHEL (9/10) major versions.

Great idea! I have checked the latest versions of RHEL 9 and RHEL 10 CIS Benchmarks and I found they also use the approach to configure cryptography by creating custom crypto policy sub modules. They are very similar to the RHEL 8 bu sometimes with different values. I think I will extend this change to use the new rule also on RHEL 9 and RHEL 10.

And would be ideal if the rule would not be RHEL8 centric. We could in theory set the sub_policies variable according to the RHEL version.

Yes, that makes sense.

Also I believe that it is still valid to check for particular submodules in the crypto policy, for example there would still have a need for the rule that checks if the current crypto policy respects a given security requirement (e.g. no weak mac), this rule would simply check if the submodule contains the right algorithm restriction, and the remediation can simply be reapply the expected sub crypto policy in case of deviation.

I'm not sure if I follow. Can you try to rephrase or explain this a little more? The current code in this PR contains OVAL that checks the contents of the submodule file (.pmod) file, I believe that this way it checks if the current crypto policy respects a given security requirement (e.g. no weak mac).

This would not imply a change in the CIS benchmarks for example, where they have a requirement for each of the restriction they expect.

Is your concern about the fact that after this change we would cover multiple controls with a single rule?

I'm concerned about covering multiple requirements by single rule as well. The previous PR #14050 has the configuration split into 4 different rules. That's better for the granularity, and I'd prefer that. However, it has a problem that when the remediation of a rule runs the update-crypto-policies command it adds the crypto policy sub module configured by the rule but removes the others because it has no information that there are other rules adding other modules. That's a blocker because the test fails and the final state after all 4 rules are applied isn't compliant. I couldn't find a solution for this.

I also don't like the name of the rule, instead of crypto_sub_policies_cis_rhel8,
maybe something like configure_custom_crypto_policy_cis

OK, makes sense once I incorporate the change to RHEL 9 and RHEL 10 CIS profiles.

[jan-cerny]

I have rebased this PR on the top of the latest upstream master branch. I have renamed the rule and started using it in RHEL 9 and RHEL 10 CIS control files.

[jan-cerny]

I have rebased this PR on the top of the latest upstream master branch.

[jan-cerny]

I have rebased this PR on the top of the latest upstream master branch.

[ggbecker]

Also I believe that it is still valid to check for particular submodules in the crypto policy, for example there would still have a need for the rule that checks if the current crypto policy respects a given security requirement (e.g. no weak mac), this rule would simply check if the submodule contains the right algorithm restriction, and the remediation can simply be reapply the expected sub crypto policy in case of deviation.

I'm not sure if I follow. Can you try to rephrase or explain this a little more? The current code in this PR contains OVAL that checks the contents of the submodule file (.pmod) file, I believe that this way it checks if the current crypto policy respects a given security requirement (e.g. no weak mac).

That is correct, I believe my concern is related to what I wrote on the following remark.

This would not imply a change in the CIS benchmarks for example, where they have a requirement for each of the restriction they expect.

Is your concern about the fact that after this change we would cover multiple controls with a single rule?

I'm concerned about covering multiple requirements by single rule as well. The previous PR #14050 has the configuration split into 4 different rules. That's better for the granularity, and I'd prefer that. However, it has a problem that when the remediation of a rule runs the update-crypto-policies command it adds the crypto policy sub module configured by the rule but removes the others because it has no information that there are other rules adding other modules. That's a blocker because the test fails and the final state after all 4 rules are applied isn't compliant. I couldn't find a solution for this.

Yes, my concern was that this change would cover multiple controls with a single rule.

I think one approach is for these fine granular rules to have the same remediation as the rule proposed in this pull request, so it would simply reapply the same custom crypto-policy (with all the requirements from the individual controls) if any of the individual rule is failing. You lose a bit the control of what is remediating and may lose some more customization made by the user, but on the other hand you can't really remediate them individually.