content
content copied to clipboard
ComplianceAsCode
Review OVAL tests in configure_crypto_policy
Description of problem:
It is not clear the value of the test_crypto_policies_updated OVAL test in configure_crypto_policy considering there is already two tests confirming both /etc/crypto-policy/config and /etc/crypto-policy/state/current files are aligned to the desired content.
If the OVAL tests already confirm that both files are compliant, the update-crypto-policy command won't change the content but only the timestamp of the files. However, different timestamps between these two files doesn't seem to be a problem.
Can anybody confirm the value of this timestamp test in this OVAL check, please?
SCAP Security Guide Version:
master as of 2024-02-02
Operating System Version:
RHEL 9
Additional Information/Debugging Steps:
This issue was file to better investigate if the current rule checks are all necessary or the OVAL assessment can be simplified.
This was initially noticed when investigating the https://github.com/ComplianceAsCode/content/issues/11516
IIRC the check is there to ensure that the policy has really been applied to the system and that the policy is effective at this moment. It would be better to ask the developers of the update-crypto-policies tool about this.
@yuumasato , it seems the test was implemented by you in the past. Do you have more information about why this timestamp test is necessary in OVAL?
If I'm not mistaken the time stamp check is to ensure that the command update-crypto-policy was run.
Although the current and config files themselves may not change, the command alters other relevant backend symlinks.
If I'm not mistaken the time stamp check is to ensure that the command
update-crypto-policywas run. Although the current and config files themselves may not change, the command alters other relevant backend symlinks.
Shouldn't these backend symbolic links be directly checked instead? Checking the timestamp of these two files does not guarantee that update-crypto-policy was executed nor can it, directly or indirectly, guarantee that any backend symlinks are correct.
So, based on the information we have until now, this timestamp test is unnecessary and should be removed. In parallel, if other files should also be checked, new explicit tests should be included for them.
The files in /etc/crypto-policies/back-ends are not always symlinks, nss.config is not, and if I remember correctly they may be regular files as well when there are subpolicies or custom hardenings set.
I know that the binary itself checks the time stamps to assess if the policy is applied. https://gitlab.com/redhat-crypto/fedora-crypto-policies/-/blob/master/python/update-crypto-policies.py?ref_type=heads#L116
As @jan-cerny mentioned, better check with the devs.
Ok. I am very convinced the timestamp test in OVAL is useless. We have to contact the component maintainers to clarify what in fact make sense to be checked.