Bug 1496279
| Summary: | rules listed as failed in 0.1.30 are listed as not applicable in 0.1.33 | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Nick Carboni <ncarboni> |
| Component: | scap-security-guide | Assignee: | Watson Yuuma Sato <wsato> |
| Status: | CLOSED NOTABUG | QA Contact: | BaseOS QE Security Team <qe-baseos-security> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.4 | CC: | mhaicman, ncarboni, 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: | 2017-11-16 16:44:56 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: | 1493193 | ||
| Attachments: | |||
Created attachment 1331237 [details]
Report using verion 0.1.33 before remediating any failures
Created attachment 1331238 [details]
Report using 0.1.33 after remediating failed rules
Created attachment 1331239 [details]
Report using 0.1.30 after downgrade
Hello Nick, I would like to know if you are using the XCCDF file to perform the scan. Would it be possible to test using the DataStream file (ssg-rhel7-ds.xml)? I was using the xccdf file for these tests. I will try to give it a shot using the data stream file today. It looks like the issue is not present when using the DataStream file with version 0.1.33 and the same profile. One thing I noticed is that some additional platforms are highlighted in this report which were grey in the report generated using the XCCDF file. cpe:/o:redhat:enterprise_linux:7::client cpe:/o:redhat:enterprise_linux:7::computenode I will attach the html report generated using the DataStream file. Created attachment 1331477 [details]
Report using 0.1.33 using DataStream file
Is it generally better to use the DataStream file over XCCDF? What are the differences between the two? Content for every given target, as shipped by SSG has 4 parts (rough description) XCCDF, defining Rules and Profiles (and remediations for the rules) OVAL, defining machine readable checks (prescription for scanner) CPE, platform definitions OCIL, questionnaires (not consumable by OpenSCAP just yet) XCCDF references OVAL, thus if you use XCCDF, those two are used from SSG. Unfortunately CPE is not referenced, thus baseline definitions shipped with scanner are used. And that manifests in the problem you observed - some of the rules has now custom platform definition "cpe:/a:machine" which is not present in baseline. Same with cpe:/o:redhat:enterprise_linux:7::client (and ::computenode) So you would have to specify SSG CPE, in scenario like yours: oscap xccdf eval --cpe /usr/share/xml/scap/ssg/content/ssg-rhel7-cpe-dictionary.xml --profile pci-dss /usr/share/xml/scap/ssg/content/ssg-rhel7-xccdf.xml For the datastream - this is a bundle of the components mentioned above, with benefit of being self-contained (and heavily namespaced). So if you use datastream as Watson suggested, you actually use CPE definitions from within, i.e. the correct ones. So I would suggest to use DataStream :) Closing this ticket as not a bug - we understand usability could be better, so proposing inclusion of a specific warning message to the oscap scanner - see Bug 1514109 |
Created attachment 1331236 [details] Profile used for my reports Description of problem: On a RHEL 7.4 system, rules which were previously listed as failed or passing in version 0.1.30 of scap-security-guide are now listed as not applicable in version 0.1.33 In particular the profile I am using for this test is attached. Additionally I've attached html reports generated using the oscap tool for various points in my investigation. The rules that were previously evaluated correctly, but are now listed as not applicable are the following ones: kernel_module_sctp_disabled kernel_module_dccp_disabled require_singleuser_auth disable_interactive_boot bootloader_audit_argument audit_rules_kernel_module_loading audit_rules_mac_modification audit_rules_sysadmin_actions audit_rules_time_adjtimex audit_rules_time_clock_settime audit_rules_time_settimeofday audit_rules_time_watch_localtime audit_rules_unsuccessful_file_modification audit_rules_usergroup_modification sysctl_net_ipv4_conf_all_accept_redirects sysctl_net_ipv4_conf_all_accept_source_route sysctl_net_ipv4_conf_all_log_martians sysctl_net_ipv4_conf_all_rp_filter sysctl_net_ipv4_conf_all_secure_redirects sysctl_net_ipv4_conf_all_send_redirects sysctl_net_ipv4_conf_default_accept_redirects sysctl_net_ipv4_conf_default_secure_redirects sysctl_net_ipv4_conf_default_send_redirects sysctl_net_ipv4_icmp_echo_ignore_broadcasts sysctl_net_ipv4_icmp_ignore_bogus_error_responses sysctl_net_ipv6_conf_default_accept_redirects Version-Release number of selected component (if applicable): RHEL 7.4 + ssg 0.1.33 How reproducible: Always Steps to Reproduce: 1. Generate a report for a RHEL 7.4 system using the attached profile 2. Observe that many rules are not applicable 3. yum downgrade scap-security-guide 4. Generate the report again 5. Observe that the same rules are listed as failed