Bug 1778661

Summary:	Rules rpm_verify_permissions and rpm_verify_ownership fail when installing RHEL7 with additional software
Product:	Red Hat Enterprise Linux 7	Reporter:	Gabriel Gaspar Becker <ggasparb>
Component:	scap-security-guide	Assignee:	Watson Yuuma Sato <wsato>
Status:	CLOSED WONTFIX	QA Contact:	BaseOS QE Security Team <qe-baseos-security>
Severity:	low	Docs Contact:	Jan Fiala <jafiala>
Priority:	medium
Version:	7.8	CC:	ekulik, ggasparb, jcerny, matyc, mhaicman, openscap-maint
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
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.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-06-18 16:04:39 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:

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.