-
Notifications
You must be signed in to change notification settings - Fork 694
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
RHEL 8/9 - configure_usbguard_auditbackend
results in notapplicable
and in final scan in fail
#8487
Comments
The issue got introduced in #8445 |
Relevant also on RHEL8 |
configure_usbguard_auditbackend
results in notapplicable
and in final scan in fail
configure_usbguard_auditbackend
results in notapplicable
and in final scan in fail
I think this is actually related on how the remediation is generated or applied. Because the remediation for This would also be an issue on any environment which doesn't have installed by default the package mentioned in the |
Thanks for reporting this problem. Do you think that this can be solved by ordering of rules? |
We're experiencing this in the OCP4 CI for fedramp high and moderate profiles. |
@jan-cerny I don't think this can be solved by ordering. Correct me if I'm wrong, but openscap-scanner remediates only rules that resulted in Workaround is running |
In the OCP case, we have an end-to-end test that ensures we have the same number of checks at the start and end of the test, which scans and remediates an environment using various profiles. The test applies the remediation after the first scan, which results in two additional rules in subsequent scans, breaking the assumption we had that checks shouldn't increase, or decrease, during the test. We don't update content in-between scans. If a remediation installs a package, and if CPEs are used for package checks, then we can't say checks won't change between scans. Is that the intended usage for CPEs? I was under the impression CPEs were for immutable system details, but maybe that's wrong? |
@mildas thanks, that sounds likely Ordering would help if the remediation would be executed right after rule is evaluated before evaluating the next rule. Then, a remediation for package_usbguard_installed could be executed before configure_usbguard_auditbackend is evaluated. But OpenSCAP doesn't work this way. So ordering doesn't help and you need to remediate twice. |
CPEs also cover applicability of applications which is usually denoted by the prefix |
First boot remediation doesn't help as this problem is also in remediating already installed systems. |
What if we relied on With With |
Well, I just realize that another approach is to remove What would we lose or miss if |
It looks like there is demand for the behavior of "configure a package if it is installed, but ignore it otherwise": But the RHEL8 STIG profile selects the rule |
Both options - replacing All our profiles with |
There is no easy fix - must be fixed on scanner side. |
@mildas Can you explain how it should be fixed? |
Closing, reported an issue in openscap - OpenSCAP/openscap#1880 |
Description of problem:
The
configure_usbguard_auditbackend
rule results innotapplicable
, becauseplatform: usbguard
is not met.Then during remediations, usbguard is installed which causes
configure_usbguard_auditbackend
fail
results in final scan.SCAP Security Guide Version:
a8eee3a
Operating System Version:
RHEL 9
Steps to Reproduce:
python3 tests/test_suite.py profile --libvirt qemu:///system test_suite_vm --datastream /tmp/ssg-rhel9-ds.xml --xccdf-id scap_org.open-scap_cref_ssg-rhel9-xccdf-1.2.xml --mode online --remediate-using oscap xccdf_org.ssgproject.content_profile_ospp
Actual Results:
xccdf_org.ssgproject.content_rule_configure_usbguard_auditbackend - fail
Expected Results:
xccdf_org.ssgproject.content_rule_configure_usbguard_auditbackend - pass
The text was updated successfully, but these errors were encountered: