Bug 1498859

Summary: openscap CPE based platform detection gives different results in connected and air gapped env
Product: Red Hat Enterprise Linux 7 Reporter: Matus Marhefka <mmarhefk>
Component: openscapAssignee: Jan Černý <jcerny>
Status: CLOSED WONTFIX QA Contact: BaseOS QE Security Team <qe-baseos-security>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.4CC: cww, knakayam, matyc, mhaicman, openscap-maint, wsato
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-03-12 14:32:02 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1594286    
Attachments:
Description Flags
Debug info when the scanned container is online.
none
Debug messages when the container is made offline according to the description. none

Description Matus Marhefka 2017-10-05 12:38:07 UTC
Description of problem:
When scanning a docker image in offline environment, atomic scan exits with error and tracebacks. It looks like unhandled exception in function get_rhel_cve_feed in openscap_daemon/cve_feed_manager.py.


Version-Release number of selected component (if applicable):
openscap-daemon-0.1.6-1.el7.noarch
- issue is also reproducible on the latest upstream release 0.1.8


How reproducible:
100%


Steps to Reproduce:
# ip netns add ns1
# ip netns exec ns1 atomic scan registry.stage.redhat.com/rhel:latest --verbose
docker run -t --rm -v /etc/localtime:/etc/localtime -v /run/atomic/2017-09-15-04-11-30-663912:/scanin -v /var/lib/atomic/openscap/2017-09-15-04-11-30-663912:/scanout:rw,Z -v /etc/oscapd:/etc/oscapd:ro test/openscap_base oscapd-evaluate scan --no-standard-compliance --targets chroots-in-dir:///scanin --output /scanout -j1
INFO:OpenSCAP Daemon one-off evaluator 0.1.7
WARNING:Can't import the 'docker' package. Container scanning functionality will be disabled.
INFO:Creating tasks directory at '/var/lib/oscapd/tasks' because it didn't exist.
INFO:Creating results directory at '/var/lib/oscapd/results' because it didn't exist.
INFO:Creating results work in progress directory at '/var/lib/oscapd/work_in_progress' because it didn't exist.
INFO:Evaluated EvaluationSpec, exit_code=0.
ERROR:Failed to scan target 'chroot:///scanin/4a974767fba69453003f076889906df7531ecdff0a0190797aec49387108fffc' for vulnerabilities.
Traceback (most recent call last):
  File "/usr/bin/oscapd-evaluate", line 144, in scan_worker
    es.evaluate(config)
  File "/usr/lib/python3.6/site-packages/openscap_daemon/evaluation_spec.py", line 506, in evaluate
    wip_result = self.evaluate_into_dir(config)
  File "/usr/lib/python3.6/site-packages/openscap_daemon/evaluation_spec.py", line 503, in evaluate_into_dir
    return oscap_helpers.evaluate(self, config)
  File "/usr/lib/python3.6/site-packages/openscap_daemon/oscap_helpers.py", line 304, in evaluate
    args = get_evaluation_args(spec, config)
  File "/usr/lib/python3.6/site-packages/openscap_daemon/oscap_helpers.py", line 279, in get_evaluation_args
    ret.extend(spec.get_oscap_arguments(config))
  File "/usr/lib/python3.6/site-packages/openscap_daemon/evaluation_spec.py", line 474, in get_oscap_arguments
    ret.append(config.get_cve_feed(self.get_cpe_ids(config)))
  File "/usr/lib/python3.6/site-packages/openscap_daemon/config.py", line 459, in get_cve_feed
    return self.cve_feed_manager.get_cve_feed(cpe_ids)
  File "/usr/lib/python3.6/site-packages/openscap_daemon/cve_feed_manager.py", line 219, in get_cve_feed
    "Can't find a supported CPE ID in %s" % (", ".join(cpe_ids))
RuntimeError: Can't find a supported CPE ID in cpe:/o:suse:linux_enterprise_server:11, cpe:/o:suse:linux_enterprise_desktop:11
INFO:[100.00%] Scanned target 'chroot:///scanin/4a974767fba69453003f076889906df7531ecdff0a0190797aec49387108fffc'

registry.access.stage.redhat.com/rhel:latest (4a974767fba6945)

     registry.access.stage.redhat.com/rhel:latest is not supported for this scan.

Files associated with this scan are in /var/lib/atomic/openscap/2017-09-15-04-11-30-663912.

Comment 2 Matus Marhefka 2017-10-05 12:39:58 UTC
Also reported in upstream: https://github.com/OpenSCAP/openscap-daemon/issues/112

Comment 3 Matus Marhefka 2017-10-05 12:48:42 UTC
I think within this BZ we should also resolve the issue with network communication made by atomic scan when /etc/oscapd/config.ini file is missing and scan is performed. There must be no communication made by atomic scan even if this file is missing. The communication can occur only when it is explicitly allowed in /etc/oscapd/config.ini configuration file.

The /CoreOS/openscap-docker/Sanity/atomic-usability test case covers also this usability issue.

Comment 4 Matěj Týč 2018-02-01 17:04:09 UTC
This is not an openscap-daemon bug. The problem is that the CPE detection doesn't work correctly in offline mode. The CPE detection is handled by openscap scanner.
For example, the test_ref="oval:org.open-scap.cpe.rhel:tst:7" gives different results depending on whether one is online or offline.

Comment 6 Matěj Týč 2018-02-02 16:50:24 UTC
Created attachment 1390239 [details]
Debug info when the scanned container is online.

Comment 7 Matěj Týč 2018-02-02 16:51:42 UTC
Created attachment 1390240 [details]
Debug messages when the container is made offline according to the description.

Comment 8 Marek Haicman 2019-03-12 14:32:02 UTC
This issue was not selected to be included in Red Hat Enterprise Linux 7.7 because it is seen either as low or moderate impact to a small number of use-cases. The next release will be in Maintenance Support 1 Phase, which means that qualified Critical and Important Security errata advisories (RHSAs) and Urgent Priority Bug Fix errata advisories (RHBAs) may be released as they become available. We will now close this issue, but if you believe that it qualifies for the Maintenance Support 1 Phase, please re-open; otherwise, we recommend moving the request to Red Hat Enterprise Linux 8 if applicable.