OpenSCAP
User and group ownership check does not respect LDAP
Description of Problem: When scanning a CentOS 7 system the findings to ensure all files are user owned and group owned returns false positives on user home directories. After investigating the issue I have determined that it looks like the scanner is not correctly mapping the uid/gid of the files to the appropriate user since we use LDAP. I was able to confirm this by manually entering user information into the group and passwd files and the scan no longer reports this as a finding.
OpenSCAP Version: openscap-1.2.17-4.el7.x86_64 openscap-scanner-1.2.17-4.el7.x86_64 scap-security-guide-0.1.43-13.el7.centos.noarch
Operating System & Version: CentOS Linux release 7.7.1908
Steps to Reproduce:
- Have a system using LDAP for user authentication with sssd as the client side application and slapd on the server side.
- Ensure the /etc/passwd, /etc/group, and /etc/shadow files have no references to users on the system.
- Ensure LDAP is configured properly by performing and id on a user uid or username and it should return the valid user information.
- Perform a scan.
Actual Results: All files in the /home/[username] are shown to not be owned by a user or group even though the uid/gid is correct for the user in question. Running an id or getent on the system returns the username correctly.
Expected Results: User files that have the correct uid/gid assigned based on what LDAP is configured for should not return as a finding, but legitimate files with no user or group should.
Additional Information / Debugging Steps: If the user information is entered into the account files on the system the scan shows the correct results, however this defeats the purpose of using LDAP for central account management so should not be considered as a solution.
What are the rule IDs of the problematic rules?
Unfortunately, the rule file_permissions_ungroupowned simply parses /etc/group as text file, which means LDAP is not consulted at all. Rewrting the rule to use OVAL password_object could help.
There is also rule no_files_unowned_by_user which uses OVAL password_object to get list of UIDs. The password probe uses getpwent(3) to get the data, and according to the man page it should work with LDAP. If this rule is affected by the problem as well, it needs deeper investigation.
The rule IDs affected by this are both xccdf_org.ssgproject.content_rule_file_permissions_ungroupowned and xccdf_org.ssgproject.content_rule_no_files_unowned_by_user. Knowing that the check uses getpwent got me looking into that and I found a thread on stackexchange where someone was having issues with LDAP and getent (https://serverfault.com/questions/673522/getent-passwd-dosent-show-users-of-ldap-server). The solution was to add "enumerate = true" in the sssd.conf under the [domain] section. This solution did resolve the no_files_unowned_by_user rule but as expected I am still seeing the false finding for file_permissions_ungroupowned. So re-writing that to use OVAL password_object might fix this.
What are the rule IDs of the problematic rules?
Unfortunately, the rule
file_permissions_ungroupownedsimply parses/etc/groupas text file, which means LDAP is not consulted at all. Rewrting the rule to use OVAL password_object could help.
OVAL password_object is representing 'getent passwd' AFAIK, and not 'getent group', am I right?
The only way to fix this issue is to enable enumeration in SSSD. According to Red Hat, they discourage the use of enumeration and that feature will be disabled in future versions of AD and IPA providers.
Are there plans to rewrite the rule in the near future?
Thanks.
That would require changes in password_object spec (similar to process58_test) and we currently don't have any plans for doing that. The test (and the rule) will officially drop support for remote users.
