OpenSCAP
running oscap against OL8 Appstreams
Description of Problem:
on Oracle linux 8 systems, oscap oval eval command returns true for certain ELSA definitions that are related to Appstreams. In such cases, if an older Appstream (virt:kvm_utils) is installed on the system, oscap flags the system as non-compliant. but if stream is switched to a newer version (virt:kvm_utils3) of the same Appstream, then oscap does NOT complain about it. We expect oscap to evaluate a system based on actual fixes (backported commits etc) rather than simply looking at version number of packages.
OpenSCAP Version:
openscap 1.3.8-1.0.1.el8_8
Operating System & Version:
Oracle Linux 8.9
Steps to Reproduce:
- dnf module enable
virt:kvm_utils - oscap oval eval --verbose DEVEL --verbose-log-file $O_LOGS --results $O_RES --report $O_REP
- following elsa definitions fail: 20240135 20235264 20233822 20230099 20225821
- dnf module switch-to
virt:kvm_utils3 - no elsa definitions fail.
Actual Results:
oscap complains about 5 different elsas(20240135 20235264 20233822 20230099 20225821) , all related to virt module
Expected Results:
Even though the virt:kvm_utils stream has older versioned packages, they are patched with all needed CVE fixes. oscap seems to only look at package versions instead of looking at actual committed fixes in the stream or going through rpm changelogs to verify that the commits are in place.
Additional Information / Debugging Steps:
OpenSCAP scanner interprets and evaluates SCAP/XCCDF/OVAL content. Where and what to look for is defined by the content.
I'd recommend getting in touch with content authors.
@evgenyz Sorry if my language was unclear in the OP. English is my second language, so bear with me for just a second.
I thought the question/issue I was raising was how oscap evaluates OVAL content, specifically when its evr string comparions for OL8 Appstreams. The OVAL definitions do NOT contain package level details.
If you believe that oscap evaluates an OVAL check incorrectly: please, attach the check (OVAL definition), DEVEL log of its evaluation and the OVAL result file. And describe what you think the result should be instead of what you get.
attach the check (OVAL definition), DEVEL log of its evaluation and the OVAL result file. And describe what you think the result should be instead of what you get.
Sure. To reduce zip file sizes, I am attaching logs/defn for a single elsa. files.zip
Yeah, now it maybe make some sense. But please also add the OVAL result file (xml, the one from --results). The HTML report in not enough.
Unfortunately the team couldnt find results file for that set of logs.
So I have attached a new set of logs that include the results file. The definition file and log file are still curtailed only for a single elsa ELSA-2023-0099, but the results file is in its entirety since I wasnt sure how to curtail that one.
@evgenyz let me know if you need more information for this. We are seeing lot of such cases in the field, so want to make sure our content is NOT improper.
@sipasing reviewing provided results I may conclude referenced OVAL definitions have issues and need to be fixed.
For example https://linux.oracle.com/oval/com.oracle.elsa-20240135.xml for virt:kvm_utils3 module installed.
Expected:
Set of OVAL package verification criteria starting from "qemu-kvm-tests" (oval:com.oracle.elsa:tst:20240135200) expected to be verified only if "Module virt:ol is enabled" (oval:com.oracle.elsa:tst:20235264003) returns True. When virt:kvm_utils3 module is enabled this OVAL definition supposed to return False.
Result: In the current OVAL file implementation "virt:ol" condition is missing. As a result, checking "qemu-img: 15:4.2.1-28.module+el8.8.0+21148+e83324c8" installed with module virt:kvm_utils3 enabled returns false positive.
Please refer to Oracle team responsible for OVAL content generation to resolve this issue. It is not related to openscap tool and should be addressed on content level.
