The check actually doesn't check RPM database, there is a hardcoded whitelist of all expected SUID binaries. The whitelist needs to be updated or replaced by something which involves RPM database check.

*** Bug 1624302 has been marked as a duplicate of this bug. ***

The current approach both in upstream and in RHEL is that the OVAL check contains a hard-coded whitelist of authorized SUID binary paths. This whitelist can be found eg. in https://github.com/ComplianceAsCode/content/blob/55bb9e6b38aed1e845ca73f431b6c0c193e128d0/linux_os/guide/system/permissions/files/file_permissions_unauthorized_sgid/oval/shared.xml#L37 The OVAL check finds all files with SUID bit in whole "/" filesystem and filters the paths from the whitelist out. The remaining files are reported as findings.

The current approach involves multiple problems. For example: The whitelist doesn't contain all SUID binaries in the RPM packages provided in the distribution. This list is hard to obtain. We don't keep the list updated with every RHEL update. The list probably doesn't involve all Red Hat provided repositories. RPMs from custom repositories should be also considered authorized, and we can't watch all the repositories on the planet. The whitelist isn't customizable.

With the aforementioned problems in mind, I have created an alternative solution. It works this way: The check finds all SUID files on the "/" filesystem and checks RPM database if the found files are owned by any RPM package. The SUID files that aren't owned by any RPM package are reported as findings. This solution addresses many problems. We don't have to maintain the whitelist. It should work universally on any RPM based distribution. It implicitly allows all SUID binaries that come from any RPM including from custom or private yum repositories. In theory, the solution should prevent any similar bugs in future. The solution has been proposed to upstream as a pull request in https://github.com/ComplianceAsCode/content/pull/4648.

However, I have discovered that the aforementioned PR works only partially. The OVAL check still reports some SUID binaries that are owned by RPMs. Specifically, on my test machine, /usr/sbin/mount.nfs is reported as SUID binary that is not owned by any RPM, but rpm -qf /usr/sbin/mount.nfs returns that this file is owned by nfs-utils machine. In other words, this binary is reported as a false positive by the OVAL proposed in the PR even if it shouldn't be reported as a finding. Probably there can be multiple files like this in other machines.

The background of this problem is the fact that on modern Linux systems /sbin is a symlink to /usr/sbin and /bin is a symlink to /usr/bin. For example, the offending file /sbin/mount.nfs is actually located in /usr/sbin, which can be demonstrated by running "realpath /sbin/mount.nfs" which returns /usr/sbin/mount.nfs. However, the check proposed in PR https://github.com/ComplianceAsCode/content/pull/4648 doesn't handle this situation. That is because the solution uses rpmverifyfile probe which doesn't normalize paths or doesn't resolve symlinks. In our example, the nfs-utils RPM package declares that it provides /sbin/mount.nfs, it isn't expanded to real path and when compared using strcmp() with /usr/sbin/mount.nfs it doesn't match. Therefore this file isn't identified as a file owned by RPM.

I think that the behavior of the rpmverifyfile probe can bee seen as a bug. I think that the probe behavior isn't consistent with the behavior of "rpm -V" in this case, but according to the OVAL specification for rpmverifyfile_test located in https://oval.mitre.org/language/version5.11/ovaldefinition/documentation/linux-definitions-schema.html#rpmverifyfile_test the rpmverifyfile probe should align with the rpm -V command for verifying RPMs". For more details about this potential probe bug and also to read about options that haven't worked please see the discussion in https://github.com/ComplianceAsCode/content/pull/4648.




Based on this situation, I propose multiple proposals:

Proposal 1:
Discard patch from https://github.com/ComplianceAsCode/content/pull/4648. Instead, simply add /usr/libexec/dbus-1/dbus-daemon-launch-helper and /usr/libexec/flatpak-bwrap to the hard-coded whitelist in the currently present OVAL check. This is a very easy solution which fixes the reported problem in this bugzilla. However, we can get similar bugs in future, and we might need to update the whitelist repeatedly.

Proposal 2:
Use patch  https://github.com/ComplianceAsCode/content/pull/4648 and document there that it produces false positives. It will fix the reported bug. The drawback is that it’s triggered by nfs-utils package which is frequently installed, so the rule will evaluate as fail for a lot of users.

Proposal 3:
Use patch https://github.com/ComplianceAsCode/content/pull/4648 and fix OpenSCAP rpmverifyfile probe in a way that it can resolve symlinks. I have checked the rpmverifyfile probe code and it seems feasible to be achieved. As I previously mentioned it might be a bug fix actually, but it will require deeper investigation, maybe also a question on OVAL devel will be needed. Also, it will require users to update OpenSCAP, if they use version without this fix, then it’s same experience for them as in Proposal 2.

Proposal 4:
Amend patch https://github.com/ComplianceAsCode/content/pull/4648  in a way that it will contain whitelist that will whitelist the offending file /usr/sbin/mount.nfs, and optionally other files that can’t be discover using the OVAL check mechanism. It is a workaround, and pulls in the problem with maintaining hard-coded whitelists.

Should you have any other proposal please submit it.




Another problem that I discovered when testing  https://github.com/ComplianceAsCode/content/pull/4648 is that it reports SUID binaries within the Podman containers stored in local storage (tried on Fedora).

We have decided to follow proposal 3 and I have a patch for OpenSCAP that https://github.com/OpenSCAP/openscap/pull/1412 that implements it.

The fix on the content side has been merged upstream. https://github.com/ComplianceAsCode/content/pull/4648

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, 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-2020:1019