Ygtjki

I am told I should do rpm -Va because:

operating system must be configured so that the cryptographic hash of system files and commands matches vendor values... Without cryptographic integrity protections, system command and files can be altered by unauthorized users without detection

So a rpm -Va | grep '^..5' is done and if anything comes back that is supposed to be a problem.

From a clean install from DVD I can successfully meet that criteria.

However, I am also told to configure files such as /etc/ssh/sshd_config and /etc/audit/audit.rules not to mention some obvious other ones to make a system functional, and changing these of course results in these files not matching vendor values, thus the rpm -Va comes back with mainly S.5....T

Can someone explain the purpose or rationale of this? As well as how grep '^..5' is supposed to work? Is there a way to make this work such that -- yeah, I changed a .conf file, but have rpm be updated to not flag specified packages as having been altered?

To take the easy part first, the grep '^..5 portion investigates the output for lines that start with any two characters followed by a 5. That 5 represents (from man rpm):

5 digest (formerly MD5 sum) differs

as a fairly good indicator that the corresponding file has changed.

Next, I would encourage any rpm -Va | grep ... investigation to ignore config files. These are files, like you point out, that are intended to be changed by the system administrator. Luckily, they are indicated in the rpm -Va output with a c marker:

The format of the output is a string of 9 characters, a possible attribute marker:

c %config configuration file.
d %doc documentation file.
g %ghost file (i.e. the file contents are not included in the package payload).
l %license license file.
r %readme readme file.

from the package header, followed by the file name.

... so I would consider something along the lines of:

sudo rpm -Va | awk '/^..5/ && $2 != "c"'

... which ties together the grep ^..5 idea along with ignoring files that are classified as configuration files. Alternatively, you could capture every flagged line of output and then "whitelist" config files where you've accepted the risk of change -- then, you're alerted when a presumed-static config file changes.

Without repackaging the RPM's, I do not know of a way to update the digest in the RPM database to indicate that you've changed a config file, which is why I suggest the above workarounds.