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 1778661 - Rules rpm_verify_permissions and rpm_verify_ownership fail when installing RHEL7 with additional software
Summary: Rules rpm_verify_permissions and rpm_verify_ownership fail when installing RH...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: scap-security-guide
Version: 7.8
Hardware: Unspecified
OS: Unspecified
medium
low
Target Milestone: rc
: ---
Assignee: Watson Yuuma Sato
QA Contact: BaseOS QE Security Team
Jan Fiala
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-12-02 09:25 UTC by Gabriel Gaspar Becker
Modified: 2020-11-14 07:11 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Known Issue
Doc Text:
.`rpm_verify_permissions` and `rpm_verify_ownership` fail in the Essential Eight profile The `rpm_verify_permissions` rule compares file permissions to package default permissions and the `rpm_verify_ownership` rule compares file owner to package default owner. However, the Australian Cyber Security Centre (ACSC) Essential Eight profile, which is provided by the `scap-security-guide` packages, changes some file permissions and ownerships to be more strict than default. As a consequence, verification of certain files using `rpm_verify_permissions` and `rpm_verify_ownership` fails. To work around this problem, manually verify that the `/usr/libexec/abrt-action-install-debuginfo-to-abrt-cache` file is owned by `root` and that it has `suid` and `sgid` bits set.
Clone Of:
Environment:
Last Closed: 2020-06-18 16:04:39 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Gabriel Gaspar Becker 2019-12-02 09:25:36 UTC 
Description of problem:

The following rules fail to pass when doing fresh installation of RHEL7.8 and selecting "Debugging tools" under the software options:
xccdf_org.ssgproject.content_rule_rpm_verify_permissions
xccdf_org.ssgproject.content_rule_rpm_verify_ownership

Version-Release number of selected component (if applicable):
scap-security-guide-0.1.46-10.el7

How reproducible:
100%

Steps to Reproduce:
1. Start installation
2. Select additional Debugging Tools on Software Options
3. Select Essential Eight profile on Security Policy tab
4. After installation install scap-security-guide
4a. $ yum install -y scap-security-guide
5. Scan machine running:
5.a $ oscap xccdf eval --profile e8 --report e8_report.html /usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml

Actual results:
Rules fail:
xccdf_org.ssgproject.content_rule_rpm_verify_permissions
xccdf_org.ssgproject.content_rule_rpm_verify_ownership

Expected results:
Rules pass.

Additional info:
If the remediation is applied again for these rules, then they pass. It is likely a problem caused by some sub-sequential remediation applied after the ones for these rules during installation that is breaking these rules.

The file that those rules are reporting as a finding is: /usr/bin/abrt-action-install-debuginfo-to-abrt-cache which means that this file installed by abrt-addon-ccpp package is being changed by a remediation from a different rule.
Comment 2 Jan Černý 2020-03-31 07:22:25 UTC 
By analysing the ARF, I have found that the problematic file is /usr/libexec/abrt-action-install-debuginfo-to-abrt-cache. This file causes fails of both rules rpm_verify_ownership and rpm_verify_permissions.

Regarding the rule rpm_verify_ownership: The rule fails because according to the RPM database the file /usr/libexec/abrt-action-install-debuginfo-to-abrt-cache should be owned by user "abrt" but is owned by root user. This ownership change is caused by bash remediation for rule file_ownership_binary_dirs. The rule file_ownership_binary_dirs requires that all files in /usr/libexec (and in multiple other directories) are owned by root user. When a remediation for rule file_ownership_binary_dirs is executed, it changes the owner of /usr/libexec/abrt-action-install-debuginfo-to-abrt-cache from abrt (expected value) to root. In the post-installation scan it causes rule rpm_verify_ownership to fail.

Changing order of rpm_verify_ownership and file_ownership_binary_dirs will not help, because in this situation the file is by RPM database owned by different user than root. In other words, we have 2 contradicting rules: the first rule requires that a file must have the owner as recorded in RPM database and the second rule requires that it must be owned by root. When both rules are used in the same profile, one of them must fail.

I envision multiple ways of addressing the problem with ownership change. We can ask abrt to package the problematic file as root owner. We can ask abrt to move the file to a directory that isn't checked by rule file_ownership_binary_dirs. We can whitelist this file in our content. We can add documentation. We can include warnings. We can extend the rule file_ownership_binary_dirs to skip files that are owned by an RPM and were not changed. We can do some combination.

Regarding the rule rpm_verify_permissions: This rule fails because the RPM reports the file /usr/libexec/abrt-action-install-debuginfo-to-abrt-cache differs in mode. It lacks SUID and SGID bits.

I have discovered that the remediation for rule rpm_verify_permissions doesn't remediate this fail. The remediation uses `rpm --setperms` command, but this command doesn't restore SUID and SGID bits. I have added them manually, and then the rule started to pass.

I haven't found which rule caused the removal of SUID and SGID bits on the aforementioned file. This question needs further investigation. It can be also caused by external things.
Comment 4 ekulik 2020-05-12 11:15:45 UTC 
The ABRT thing is already filed as https://bugzilla.redhat.com/show_bug.cgi?id=1796245. NACKing the proposed fix, because we are trying to come up with something better upstream already.
Comment 11 Matěj Týč 2020-06-18 16:04:39 UTC 
I have "borrowed" the doc text from https://bugzilla.redhat.com/show_bug.cgi?id=1838622 as it describes an almost identical issue.

We have updated the documentation and briefed the ABRT team about this issue, so the work on our part is finished.
Note You need to log in before you can comment on or make changes to this bug.