-
Notifications
You must be signed in to change notification settings - Fork 695
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Set OVAL version from 5.11 to 5.11.2 #11903
Set OVAL version from 5.11 to 5.11.2 #11903
Conversation
Minor OVAL updates in auditd_audispd_configure_sufficiently_large_partition regarding readability only.
Version 5.11.2 was released in 2016 and we are likely using it for a long time, although our files inform simply 5.11. There are rules already using properties from 5.11.2, such as auditd_audispd_configure_sufficiently_large_partition.
🤖 A k8s content image for this PR is available at: Click here to see how to deploy itIf you alread have Compliance Operator deployed: Otherwise deploy the content and operator together by checking out ComplianceAsCode/compliance-operator and: |
Code Climate has analyzed commit ac8dfe0 and detected 0 issues on this pull request. The test coverage on the diff in this pull request is 100.0% (50% is the threshold). This pull request will bring the total coverage in the repository to 59.4% (0.0% change). View more on Code Climate. |
@marcusburghardt that's not entirely true depending on the vendor |
Based on that we will need check that I removed in #11816 needs to be added back. |
I didn't check the oval, but does it have a hard requirement on 5.11.2? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I confirmed that on RHEL 9 that the rule now results in fail in my test box, as expected.
Until we address the comments about Ubuntu I'm holding off merging this for now.
This relevant rule depends on a property ( It is likely that we don't have any other case in the project where we use something only in 5.11.2 but not in 5.11.1. |
@mpurg would you be able to test this rule |
@marcusburghardt Have you tried to use |
Yeah, that's what I got for oval version
|
Oh, okay. The @yuumasato @lbragstad Is the OCP4 CI actually trying to execute/interpet the content or it just builds it? |
Apparently it does work. If I use But! I wonder if it will make sense to have OVAL version set to |
Well, schematron validation dies on a data stream with OVAL |
@marcusburghardt I've tested it and with the change from #11816 the rule started to fail, while previously it would return I think because we still need to build the profiles on versions that don't support 5.11.2, it would be nice to still maintain 5.11 and/or add 5.11.1 to the build system. Regarding the OVAL maybe reverting the PR mentioned above is a good idea, until we land a fix specific to Ubuntu. |
It could be a product feature (property), actually. With 5.11.2 (the latest) being the default. |
Thanks @Mab879 @dodys @mpurg @evgenyz and @jan-cerny for the review, comments and tests. We are starting the stabilization phase for 0.1.73 and I concluded a change in the OVAL version deserves more investigation and tests. Doing so now would be premature. This is the reason I moved this PR to Draft now. In the meantime I believe it is reasonable to revert the #11816 , which basically means the |
Thanks to ComplianceAsCode#11816 it were releaved more issues related to OVAL version. After discussions in ComplianceAsCode#11903 it was concluded to revert this change for now so we can better work a long-term solution.
Thanks to ComplianceAsCode#11816 it were revealed more issues related to OVAL version. After discussions in ComplianceAsCode#11903 it was concluded to revert this change for now so we can better work a long-term solution.
PR needs rebase. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
@evgenyz The OCP4 CI runs an e2e test, it executes scans with the profiles and assesses the rule results. |
This Draft is open for some time and I have no plans to work on this soon. I am also considering how worth would be to create this mechanism consider the issue affects only one rule. So, I am closing it now. It can be reopened if we have stronger demand for this in the future. |
Description:
Investigating the issue #11891 it was noticed that OpenSCAP scanner was returning error for rule
auditd_audispd_configure_sufficiently_large_partition
because the OVAL in this rule was using an OVAL property only present in OVAL 5.11.2, but our content was defined as version5.11
(without .2).OVAL version 5.11.2 was released in 2016 and we are likely already using it for long time.
Rationale:
Review Hints:
First take a look in #11891
There is no test scenario or remediation for this rule because it is about partition and tests are not that simple to be created. Therefore, we should test it in the traditional way using a RHEL9 VM, for example.
./build_product rhel9
Copy the generated DataStream to this RHEL9 VM:
scp build/ssg-rhel9-ds.xml root@<ip or host>:
Start a SSH session to this VM and executes a scan for the rule
auditd_audispd_configure_sufficiently_large_partition
:oscap xccdf eval --profile stig --rule xccdf_org.ssgproject.content_rule_auditd_audispd_configure_sufficiently_large_partition --results-arf /tmp/arf.xml --report /tmp/report.html --oval-results ssg-rhel9-ds.xml
After this PR, the result will be "Pass" or "Fail" based on the partition size mounted on
/var/log/audit
. Before this PR, the error shown in #11891 is reproduced.A good way to confirm the check is accurate is examining the
/tmp/arf.xml
file.For example, in the VM I used this was the relevant information about the partition table:
and this was the result of the scan:
To confirm the result, this was the relevant information in
/tmp/arf.xml
file:In this case, 531267584 is the partition size in bytes, or 507M.