Bug 1465402 - remediation run during anaconda installation shows "notapplicable" for many rules
remediation run during anaconda installation shows "notapplicable" for many r...
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: oscap-anaconda-addon (Show other bugs)
Unspecified Unspecified
high Severity high
: rc
: ---
Assigned To: Watson Yuuma Sato
Release Test Team
Depends On: 1520276
  Show dependency treegraph
Reported: 2017-06-27 08:04 EDT by Marek Haicman
Modified: 2018-02-17 23:16 EST (History)
6 users (show)

See Also:
Fixed In Version: oscap-anaconda-addon-0.8-1.el7
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Marek Haicman 2017-06-27 08:04:42 EDT
Description of problem:
When user selects profile within anaconda, it is expected to have fully compliant system after installation. With the latest SCAP Security Guide, rules which are marked as "machine-only" are not remedied during installation. Thus machine is returned to user with lots of failing rules (for example all audit-related rules)

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. install machine with selecting hardening profile, for example pci-dss
2. scan machine with selected profile
3. check /root/openscap_data/eval_remediate_results.xml

Actual results:
2) big number of failing rules
3) big number of rules with result "notapplicable"

Expected results:
2) no, or small number of rules failing
3) no rule marked as "notapplicable"

Additional info:
Comment 1 Marek Haicman 2017-07-18 10:18:15 EDT
This bug is more likely to be fixed in scap-security-guide.
Comment 2 Marek Haicman 2017-09-27 09:01:57 EDT
PR https://github.com/OpenSCAP/oscap-anaconda-addon/pull/48 fixes the issue.

The real problem was OAA consuming XCCDF by default, and not using CPE shipped with SSG -> Our special 'cpe:/a:machine' has not been understood then.

By using DS, CPE dictionary bundled in is used, thus problem gets away.

Note You need to log in before you can comment on or make changes to this bug.