content
content copied to clipboard
ComplianceAsCode
RHEL 8/9 - `configure_usbguard_auditbackend` results in `notapplicable` and in final scan in `fail`
Description of problem:
The configure_usbguard_auditbackend rule results in notapplicable, because platform: 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 issue got introduced in https://github.com/ComplianceAsCode/content/pull/8445 @Xeicker @jan-cerny
I think this is actually related on how the remediation is generated or applied. Because the remediation for configure_usbguard_auditbackend never runs, even thought it manages the notapplicable scenario.
This would also be an issue on any environment which doesn't have installed by default the package mentioned in the platform section
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.
https://github.com/ComplianceAsCode/content/pull/8452
@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 fail during scan phase. And configure_usbguard_auditbackend doesn't fail.
Workaround is running oscap xccdf eval --remediate twice. That would scan and fix configure_usbguard_auditbackend because usbguard platform gets fulfilled by first remediations run.
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.
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?
CPEs also cover applicability of applications which is usually denoted by the prefix cpe:/a. In our project we already had many of these CPEs, so it's natural that eventually a problem like this would occur. In my opinion we should not assume that applicability stays the same, on the other hand we are still uncertain how to treat properly this kind of issue. In terms of rules passing, usually a second round of remediation solves the it.
First boot remediation doesn't help as this problem is also in remediating already installed systems.
What if we relied on xccdf:requires instead of xccdf:platform for these rules?
With xccdf:platform, rules that configure a package that is not installed will evaluate to notapplicable.
If the profile has a rule to install the package, a second remediation run is necessary.
If the profile doesn't install the package the rule will keep evaluating to not applicable (Basically configure the package if it is installed, but ignore the rule otherwise).
With xccdf:requires, rules that configure a package will evaluate to false (as long as the required rule that installs the package is selected in the profile).
If a profile selects the required rule, both rules will evaluate to fail in the first run, and both rules will be remediated.
If the profile doesn't select the required rule, it means the profile doesn't care about the package, and very likely the rule configuring the package should not even be selected.
The use of xccdf:requires would kill the behavior of "configure a package if it is installed, but ignore it otherwise".
Well, I just realize that another approach is to remove xccdf:platform and not add anything.
What would we lose or miss if configure_usbguard_auditbackend dropped its platform: usbguard?
It looks like there is demand for the behavior of "configure a package if it is installed, but ignore it otherwise":
Note: If the USBGuard daemon is not installed and enabled, this requirement is not applicable.
https://vaulted.io/library/disa-stigs-srgs/red_hat_enterprise_linux_8_security_technical_implementation_guide/V-230470
But the RHEL8 STIG profile selects the rule package_usbguard_installed, so the profile is already making the choice.
Anyone who wants to not install usbgard will have to tailor the rule out, and in this case they could also tailor other usbguard rules out....
Both options - replacing platform with requires or dropping platform - sounds good to me.
All our profiles with configure_usbguard_auditbackend also select package_usbguard_installed so our shipped content doesn't configure not installed package. If anyone wants to tailor it out, then it's theirs responsibility to tailor configuration rules our too.
Closing, reported an issue in openscap - https://github.com/OpenSCAP/openscap/issues/1880
