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 1721439 - Rule xccdf_org.ssgproject.content_rule_file_permissions_ungroupowned returns false positives when system has remote groups
Summary: Rule xccdf_org.ssgproject.content_rule_file_permissions_ungroupowned returns ...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: scap-security-guide
Version: 7.6
Hardware: All
OS: Linux
high
high
Target Milestone: rc
: ---
Assignee: Watson Yuuma Sato
QA Contact: BaseOS QE Security Team
Mirek Jahoda
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-06-18 10:08 UTC by Renaud Métrich
Modified: 2023-10-06 18:22 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Known Issue
Doc Text:
.OpenSCAP file ownership-related rules do not work with remote user and group back ends The OVAL language used by the OpenSCAP suite to perform configuration checks has a limited set of capabilities. It lacks possibilities to obtain a complete list of system users, groups, and their IDs if some of them are remote. For example, if they are stored in an external database such as LDAP. As a consequence, rules that work with user IDs or group IDs do not have access to IDs of remote users. Therefore, such IDs are identified as foreign to the system. This might result in scans to fail on compliant systems. In the `scap-security-guide` packages, the following rules are affected: * `xccdf_org.ssgproject.content_rule_file_permissions_ungroupowned` * `xccdf_org.ssgproject.content_rule_no_files_unowned_by_user` To work around this problem, if a rule that deals with user or group IDs fails on a system that defines remote users, check the failed parts manually. The OpenSCAP scanner enables you to specify the `--oval-results` option together with the `--report` option. This option displays offending files and UIDs in the HTML report and makes the manual revision process straightforward. Additionally, in RHEL 8.3, the rules in the `scap-security-guide` packages contain a warning that only local-user back ends have been evaluated.
Clone Of:
Environment:
Last Closed: 2020-04-30 13:28:34 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Renaud Métrich 2019-06-18 10:08:31 UTC 
Description of problem:

Rule xccdf_org.ssgproject.content_rule_file_permissions_ungroupowned returns false positives when system has remote groups (for example in LDAP).
Indeed, processes running as the remote group will be listed, because the group doesn't exist in /etc/group.


Version-Release number of selected component (if applicable):

scap-security-guide-0.1.40-12.el7.noarch


How reproducible:

Always


Steps to Reproduce:
1. Create a local user

  # useradd myuser

2. Delete the user from /etc/group (mimicing it is a user with a remote group)

3. Start a process as the fakely remote user

  # su - myuser
  $ sleep 3600

3. Execute xccdf_org.ssgproject.content_rule_file_permissions_ungroupowned


Actual results:

/proc/<pid of sleep> shown in report


Expected results:

/proc omitted


Additional info:

I would expect "/proc" gets excluded from the file system scan since it doesn't contain real files.
With excluding "/proc", this should fix the issue except when the remote group is used as primary group for some local home directories, but this is likely an error in such case.

I understand checking also remote groups (using "getent group" or similar) may not be a viable solution.
Comment 2 Jan Černý 2019-10-02 09:40:07 UTC 
It isn't viable to implement a check that works correctly with LDAP groups using OpenSCAP. I suggest improving the rule description, describe that the check doesn't check LDAP and provide a bash oneliner to enable users to check and waive manually.
Comment 3 Marek Haicman 2020-04-14 12:30:39 UTC 
Jan, can you elaborate on this? I mean the whole train of thought that ended with "it isn't viable to implement"?

For example I understand we might need some additional knowledge, so what about this setup:
* current rule only local users
* new rule that checks LDAP via variable provided information
* if variable is empty (default), CPE of this rule will be false -> notapplicable

This way, we can have both rules in the profile, and if user provides data, will get better control?
Comment 4 Jan Černý 2020-04-15 09:22:44 UTC 
I don't remember the discussion so will try to summarize what I think now.

I think that the OVAL standard doesn't provide any specific way to assess users groups. But in this rule we need to obtain a list of groups so we use the ability to read data from text files and we read /etc/group. I think that there is no similar standard file that would contain the remote groups which we could read.

We can use OVAL ldap57_test to get data from LDAP. Unfortunately, the ldap57 probe isn't shipped in RHEL 8 and is disabled in RHEL 7. Also, I think that the LDAP query would be different for each customer depending on their layout.

Then there is SSSD, NSSswitch and others that are involved in managing groups.

In my opinion, we would need to provide a way to query groups using getent. In this situation it means developing and standardizing a new OVAL probe.

Another, but simple, solution would be that user would export the group list to an environment variable or a file and this rule would consume it.

Your setup sounds great, but we would have to (re)introduce the ldap57 probe to do that.
Comment 5 Marek Haicman 2020-04-30 13:28:34 UTC 
This bugzilla deals with the similar problem as Bug 1544765. Our investigation ( see Comment 4 ) showed it unfortunately cannot be fixed without implementation of additional openscap probe. Such an effort is outside the scope of the Maintenance Support 2 phase. And so, even though we fully understand the complications this means, we have no other option than to close it as WONTFIX. This will stay as a known issue in Red Hat Enterprise Linux 7, and we will at least update the rule description so it's not giving users false expectations. This description update is tracked in the Bug 1829743
Note You need to log in before you can comment on or make changes to this bug.