RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1496279 - rules listed as failed in 0.1.30 are listed as not applicable in 0.1.33
Summary: rules listed as failed in 0.1.30 are listed as not applicable in 0.1.33
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: scap-security-guide
Version: 7.4
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: rc
: ---
Assignee: Watson Yuuma Sato
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks: 1493193
TreeView+ depends on / blocked
 
Reported: 2017-09-26 21:52 UTC by Nick Carboni
Modified: 2017-11-16 16:44 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-11-16 16:44:56 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
Profile used for my reports (5.20 KB, text/html)
2017-09-26 21:52 UTC, Nick Carboni 		no flags Details
Report using verion 0.1.33 before remediating any failures (3.37 MB, text/html)
2017-09-26 21:53 UTC, Nick Carboni 		no flags Details
Report using 0.1.33 after remediating failed rules (3.34 MB, text/html)
2017-09-26 21:54 UTC, Nick Carboni 		no flags Details
Report using 0.1.30 after downgrade (2.09 MB, text/html)
2017-09-26 21:55 UTC, Nick Carboni 		no flags Details
Report using 0.1.33 using DataStream file (3.72 MB, text/html)
2017-09-27 15:42 UTC, Nick Carboni 		no flags Details
View All

Description Nick Carboni 2017-09-26 21:52:53 UTC 
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
Comment 2 Nick Carboni 2017-09-26 21:53:57 UTC 
Created attachment 1331237 [details]
Report using verion 0.1.33 before remediating any failures
Comment 3 Nick Carboni 2017-09-26 21:54:43 UTC 
Created attachment 1331238 [details]
Report using 0.1.33 after remediating failed rules
Comment 4 Nick Carboni 2017-09-26 21:55:15 UTC 
Created attachment 1331239 [details]
Report using 0.1.30 after downgrade
Comment 5 Watson Yuuma Sato 2017-09-27 07:09:46 UTC 
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)?
Comment 6 Nick Carboni 2017-09-27 13:13:01 UTC 
I was using the xccdf file for these tests. I will try to give it a shot using the data stream file today.
Comment 7 Nick Carboni 2017-09-27 15:41:29 UTC 
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.
Comment 8 Nick Carboni 2017-09-27 15:42:04 UTC 
Created attachment 1331477 [details]
Report using 0.1.33 using DataStream file
Comment 9 Nick Carboni 2017-09-27 15:45:06 UTC 
Is it generally better to use the DataStream file over XCCDF? What are the differences between the two?
Comment 10 Marek Haicman 2017-09-27 22:18:27 UTC 
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 :)
Comment 11 Marek Haicman 2017-11-16 16:44:56 UTC 
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
Note You need to log in before you can comment on or make changes to this bug.