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.

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 theupdate-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.

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.

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

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

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 theupdate-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.