Bug 1878119
| Summary: | Actual permissions/ownership of files owned by gdm package diverge from RPM records. | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Milan Lysonek <mlysonek> | ||||
| Component: | gdm | Assignee: | Ray Strode [halfline] <rstrode> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Michal Odehnal <modehnal> | ||||
| Severity: | low | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 8.3 | CC: | ggasparb, hdegoede, matyc, mhaicman, thistlesl1234, tpelka, wsato | ||||
| Target Milestone: | rc | Keywords: | Triaged | ||||
| Target Release: | 8.0 | Flags: | pm-rhel:
mirror+
|
||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | gdm-40.0-19.el8 | Doc Type: | If docs needed, set a value | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | |||||||
| : | 1976233 1999586 2209266 (view as bug list) | Environment: | |||||
| Last Closed: | 2022-05-10 13:34: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: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 1976233, 1999586, 2209266 | ||||||
| Attachments: |
|
||||||
Milane, can you expand a bit on the details of failure? What does it mean? What is the real state of the gdm file and what is the expected state? I have a feeling we had a bug like this already. It's not something we can really fix on our side, unless we implement some kind of additional whitelisting for these rpm_verify rules. So as you provide more detailed report of the situation, we can move the issue to gdm :) Sure. rpm_verify_permissions (rpm_verify_ownership) rule from security-guide-component is a rule that checks file access (ownership) permissions of installed software packages. For the check, the RPM package management system is used. If a file, that is a part of a installed software package, has incorrect permissions, then result from the rule is fail and it is possible to see which files caused the failure. In this case, failure is caused by /var/log/gdm folder. The /var/log/gdm folder access and ownership permissions on running system are different that permissions that are expected from the RPM package manager. The fact can be found with following command: [root@localhost ~]# rpm -Va gdm .M....G.. /var/log/gdm [root@localhost ~]# M stands for Mode differs (includes permissions and file type) G stands for Group ownership differs The command above shows divergences. The permissions can be reset to the permissions expected from the RPM package manager, see following commands: [root@localhost ~]# ls -la /var/log/gdm total 4 drwx--x--x. 2 root gdm 6 Sep 1 22:57 . drwxr-xr-x. 18 root root 4096 Sep 10 17:48 .. [root@localhost ~]# rpm --setugids gdm [root@localhost ~]# rpm --setperms gdm [root@localhost ~]# ls -la /var/log/gdm total 4 drwxr-xr-x. 2 root root 6 Sep 1 22:57 . drwxr-xr-x. 18 root root 4096 Sep 10 17:48 .. [root@localhost ~]# There are two fact you can observe: 1) The /var/log/gdm group ownership was gdm but rpm resets it to root group. 2) The /var/log/gdm access permissions were drwx--x--x. but rpm resets them to drwxr-xr-x. After restart, the permissions are set back to permissions that are considered as incorrect by rpm: [root@localhost ~]# ls -la /var/log/gdm total 4 drwx--x--x. 2 root gdm 6 Sep 1 22:57 . drwxr-xr-x. 18 root root 4096 Sep 10 17:48 .. I hope, it is more clear now. However, I would like to raise a few questions: 1) Should permissions of the /var/log folder be checker in scap-security-guide? The folder contains log files and their checksum/size can change. If the folder should not be checked, then the component of this bug is set correctly. 2) Should the /var/log/gdm folder be part of the gdm package? Are any of the permissions of /var/log/gdm mentioned above unexpected? If the folder should have different permissions or it should not be included in the package, then the bug can be moved to gdm. To answer Milan's questions, permssions of the /var/log/gdm folder are highly relevant from the security standpoint, and any discrepancy in this regard has to be investigated and potentially waived by people who do the security hardening. Therefore, that discrepancy should be removed, as it hinders security evaluations. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (gdm bug fix and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2022:1771 |
Created attachment 1714552 [details] E8 profile scan performed after installation Description of problem: The following rules fail to pass when doing fresh installation of RHEL8.3 using Server with GUI package group: 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.50-14.el8 How reproducible: In most cases (~80% probability) rpm_verify_permissions fails, rpm_verify_ownership occasionally fails, and sometimes both passes. Steps to Reproduce: 1. Start installation 2. Select Server with GUI package group 3. Select PCI DSS, E8, or HIPAA profile 4. After installation scan machine running (replace the E8 profile with the profile selected at the beginning of the installation): $ oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_e8 --report e8_report.html /usr/share/xml/scap/ssg/content/ssg-rhel8-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: The failures are caused by /var/log/gdm file from gdm package.