OpenSCAP / openscap

NIST Certified SCAP 1.2 toolkit

Home Page:https://www.open-scap.org/tools/openscap-base

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

running oscap against OL8 Appstreams

sipasing opened this issue · comments

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:

  1. dnf module enable virt:kvm_utils
  2. oscap oval eval --verbose DEVEL --verbose-log-file $O_LOGS --results $O_RES --report $O_REP
  3. following elsa definitions fail: 20240135 20235264 20233822 20230099 20225821
  4. dnf module switch-to virt:kvm_utils3
  5. 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

@evgenyz also, can we plz reopen this ticket if you seem fit ?

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.

files-new.zip

@evgenyz Did you get a chance to check out the files ?