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 1886037 - audit_rules_privileged_commands fails in rhel8 CIS
Summary: audit_rules_privileged_commands fails in rhel8 CIS
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: scap-security-guide
Version: ---
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: 8.0
Assignee: Vojtech Polasek
QA Contact: Milan Lysonek
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-10-07 14:20 UTC by Marko Myllynen
Modified: 2021-05-20 09:34 UTC (History)
5 users (show)

Fixed In Version: scap-security-guide-0.1.54-5.el8
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-05-19 14:57:53 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
results-1.xml (651.70 KB, application/octet-stream)
2020-10-09 09:53 UTC, Marko Myllynen
no flags Details
results-2.xml (651.55 KB, application/gzip)
2020-10-09 09:54 UTC, Marko Myllynen
no flags Details
results.xml.gz (651.73 KB, application/gzip)
2020-10-09 11:59 UTC, Marko Myllynen
no flags Details
debug.log.gz (4.27 MB, application/gzip)
2020-10-09 12:00 UTC, Marko Myllynen
no flags Details
audit-dir.tar.gz (6.88 KB, application/gzip)
2020-10-12 11:30 UTC, Marko Myllynen
no flags Details

Description Marko Myllynen 2020-10-07 14:20:11 UTC
Description of problem:
Using ~RHEL 8.3 Beta with

openscap-1.3.3-5.el8.x86_64
openscap-scanner-1.3.3-5.el8.x86_64
scap-security-guide-0.1.50-14.el8.noarch

and commands (as root):

oscap xccdf eval --remediate --profile xccdf_org.ssgproject.content_profile_cis --results /root/results.xml /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml
dracut -f
reboot

Then, repeating the steps seeing these remediations popping up one of the another (so can't get a clean run at all):

1)
 --- Starting Remediation ---
WARNING: Skipping ./security-data-oval-com.redhat.rhsa-RHEL8.xml file which is referenced from XCCDF content
Title   Ensure auditd Collects Information on the Use of Privileged Commands
Rule    xccdf_org.ssgproject.content_rule_audit_rules_privileged_commands
Ident   CCE-80724-8
Result  error

Title   Verify and Correct File Permissions with RPM
Rule    xccdf_org.ssgproject.content_rule_rpm_verify_permissions
Ident   CCE-80858-4
Result  fixed

2)
 --- Starting Remediation ---
WARNING: Skipping ./security-data-oval-com.redhat.rhsa-RHEL8.xml file which is referenced from XCCDF content
Title   Ensure auditd Collects Information on the Use of Privileged Commands
Rule    xccdf_org.ssgproject.content_rule_audit_rules_privileged_commands
Ident   CCE-80724-8
Result  error

Title   Verify /boot/grub2/grub.cfg Permissions
Rule    xccdf_org.ssgproject.content_rule_file_permissions_grub2_cfg
Ident   CCE-80814-7
Result  fixed

Title   Verify Permissions on cron.monthly
Rule    xccdf_org.ssgproject.content_rule_file_permissions_cron_monthly
Ident   CCE-82263-5
Result  fixed

Title   Verify Permissions on crontab
Rule    xccdf_org.ssgproject.content_rule_file_permissions_crontab
Ident   CCE-82206-4
Result  fixed

Title   Verify Permissions on cron.weekly
Rule    xccdf_org.ssgproject.content_rule_file_permissions_cron_weekly
Ident   CCE-82253-6
Result  fixed

Title   Verify Permissions on cron.daily
Rule    xccdf_org.ssgproject.content_rule_file_permissions_cron_daily
Ident   CCE-82240-3
Result  fixed

Title   Verify Permissions on cron.hourly
Rule    xccdf_org.ssgproject.content_rule_file_permissions_cron_hourly
Ident   CCE-82230-4
Result  fixed

Title   Verify Permissions on cron.d
Rule    xccdf_org.ssgproject.content_rule_file_permissions_cron_d
Ident   CCE-82277-5
Result  fixed

It looks like the cron permissions are due to https://bugzilla.redhat.com/show_bug.cgi?id=1843913. But not sure what's causing CCE-80724-8 and CCE-80814-7 pop up.

Version-Release number of selected component (if applicable):
openscap-1.3.3-5.el8.x86_64
openscap-scanner-1.3.3-5.el8.x86_64
scap-security-guide-0.1.50-14.el8.noarch

How reproducible:
Always

Steps to Reproduce:
1. Install minimal RHEL 8.3'ish
2. Repeat the following steps to see the issues:

oscap xccdf eval --remediate --profile xccdf_org.ssgproject.content_profile_cis --results /root/results.xml /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml
dracut -f
reboot

Actual results:
System remain uncompliant even after several runs.

Expected results:
No remediations after the first oscap run.

Comment 1 Vojtech Polasek 2020-10-09 08:54:08 UTC
Hello,
could you please attach html reports? Just add --report file.html to the command. I think I know what are the problems and if I am right, none of them is caused by our content.
Thank you.

Comment 2 Marko Myllynen 2020-10-09 09:51:21 UTC
Sure, I'll attach the results file for two different runs.

FWIW, you will see this one as well, I didn't mention this earlier since I had manually changed the setting already (and I'm not sure would this be safe to address automatically as you might lock yourself out):

Title   Set Default firewalld Zone for Incoming Packets
Rule    xccdf_org.ssgproject.content_rule_set_firewalld_default_zone
Ident   CCE-80890-7
Result  fail

Thanks.

Comment 3 Marko Myllynen 2020-10-09 09:53:12 UTC
Created attachment 1720193 [details]
results-1.xml

Comment 4 Marko Myllynen 2020-10-09 09:54:06 UTC
Created attachment 1720194 [details]
results-2.xml

Comment 5 Vojtech Polasek 2020-10-09 10:50:20 UTC
Thank you. One more thing, could you please during the run where the rule audit_rules_privileged_commands fails run it with following additional arguments?
--verbose DEVEL --verbose-log-file debug.log
and send me the debug log?
I am investigating the grub.cfg problem, it seems like problem with ordering.

Comment 6 Marko Myllynen 2020-10-09 11:59:36 UTC
Created attachment 1720224 [details]
results.xml.gz

Comment 7 Marko Myllynen 2020-10-09 12:00:21 UTC
Created attachment 1720225 [details]
debug.log.gz

Comment 8 Marko Myllynen 2020-10-09 12:01:08 UTC
Ok, attached results.xml and debug.log from a test run. Thanks.

Comment 9 Vojtech Polasek 2020-10-12 09:15:45 UTC
Hello,
I have tried to reproduce your problem. I partially succeeded.
I managed to reproduce the problem with the Rule    xccdf_org.ssgproject.content_rule_file_permissions_grub2_cfg. The problem is similar to one with cron described at https://bugzilla.redhat.com/show_bug.cgi?id=1843913
The RPM package for grub2-pc expects /boot/grub2/grub.cfg to have permissions 644. This is ensured by the rule xccdf_org.ssgproject.content_rule_rpm_verify_permissions But the rule    xccdf_org.ssgproject.content_rule_file_permissions_grub2_cfg wants permissions 600. So one of these rules will unfortunately always fail. I am not sure if there is any real fix apart from documentation.
I did not manage to reproduce your problem with audit_rules_privileged_commands. From the debug log, it seems as there were no files within the /etc/audit/rules.d directory. Please what is the state of the /etc/audit directories and subdirectories after 1st/2nd/3rd run?
Thank you.

Comment 10 Marko Myllynen 2020-10-12 11:30:42 UTC
Created attachment 1720937 [details]
audit-dir.tar.gz

Comment 11 Marko Myllynen 2020-10-12 11:33:22 UTC
I attached a tarball containing /etc/audit contents after 1st/2nd/3rd run, prior the first run there was nothing except for the default configuration file from the audit package.

I am using a kickstart similar to https://github.com/myllynen/misc/blob/master/rhel-8-base.ks to install my test VM but without IPv6 disable and non-automatic partition table. Perhaps you could try out reproducing on your end by using that kickstart if still unclear what might be causing this?

Thanks.

Comment 13 Vojtech Polasek 2020-10-13 13:25:02 UTC
After investigation, it seems that the problem lies in remediation of the rule audit_rules_privileged_commands. The rule uses this command to search for binaries:
find / -xdev -type f -perm -4000 -o -type f -perm -2000                      
And the -xdev option prevents the command from traversing into other file systems. But in this particular setup, the /usr folder is on a different file system. However, the OVAL check traverses LOCAL file systems. Because the remediation can't find any privileged executables in the root file system, it does not remediate anything and check fails. I will investigate possible fix. I believe we should be able to adapt to various partition layouts.

Comment 14 Watson Yuuma Sato 2021-01-28 15:49:10 UTC
https://github.com/ComplianceAsCode/content/pull/6227

Comment 17 Milan Lysonek 2021-05-19 14:57:53 UTC
The audit_rules_privileged_commands rule passes in the CIS profile on RHEL 8.4. Closing as CURRENTRELEASE.


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