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.
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.
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?
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.
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