Additional file context enhancements to include ownership and mode

[scholarsmate]

On RHEL-based systems, rpm -Va can quickly tell the difference between file system objects in the rpm database and objects on the file system to include size and hash mismatches, as well as 6 other differences.

Code	Meaning
S	File size differs.
M	File mode differs.
5	The checksum differs.
D	The major and minor version numbers differ on a device file.
L	A mismatch occurs in a link.
U	The file ownership differs.
G	The file group owner differs.
T	The file time (mtime) differs.

Currently fapolicyd and the toolkit are chiefly concerned about the contents of a file, as measured by file size and hash metrics.

There are compelling reasons to consider file ownership (user and group) and file mode in addition to file content metrics. These checks are very cheap relative to the file hash given that they are in the trusted rpm database and in stat(2).

It wouldn’t be a heavy lift to show ownership and mode discrepancies in this toolkit, but without any support and enforcement in fapolicyd proper, they will only serve as informational only at this point (which could frustrate users).

[stevegrubb]

What are the compelling reasons to consider file ownership and mode? Fapolicyd is really only supposed to answer the question of if this software is known or not. There are other tools like aide and audit that can spot and alert changes to ownership and mode.

The trust db only allows 512 bytes per entry. We have to be very careful about what goes in there due to the inflexible size constraint. If the reason was compelling enough to make a change, then we'd need to make a new version number, migrate the contents, and make the max file name length even smaller.

[scholarsmate]

Hi @stevegrubb,

Suppose there is a security service like fapolicyd that needs to read a set of configuration files. With respect to file mode, if one or more of these configuration files is world writable (u+w), that would be a problem because anyone could change the security policies (or disable the service entirely), opening the system to attacks. With respect to ownership, if one or more of those configuration files were owned by a non-administrative user, that user could make undesirable changes, again opening the system to attacks.

I think a boolean toggle could be used to say the file does or does not match the RPM or ancillary database mode or ownership. Maybe that information could be encoded in a pair of bits.

There are indeed other products like Tripwire, Samhain, SELinux, etc., that could also address these items. There are cases where you'll want to run a few security services that do redundant things so that it'll take more than one failure to open the system to attacks.

[stevegrubb]

There is a PATH record as part of the event. It's already recorded. So, what else should be added?

[scholarsmate]

If the requested file matched the trust databases' ownership and mode.