[PATCH]: hash whitelisting
Brought to you by:
dogsbody
Menu
▾
▴
#24 [PATCH]: hash whitelisting
This patch allows to "whitelist" the hash checksum for certain files (i.e.turn off the content verification, similar to what can be done for file attributes). Useful in case you'd like to use a package manager such as RPM for the hashes, but already know that the file content has been changed on disk.
Also covers the case where bi-arch RPMs have been installed that both claim the same file, some RPM versions (Centos4 etc al) will always report a verification error in this case.. this affects e.g. "curl".
In SF/Features/#1922881 "Speed up the properties db update?" John introduced the capability to supply --propupd with one a filename, a directory or a package name to update. That should make it easier to selectively update the hash database, so I'm wondering in which cases it would still be necessary to have RKH cater for whitelisting hash differences?
(mhm. looks like sf.net dropp[ed my last comment).
I agree that selectively updating the properties db would be useful. However, this does not cover all cases, such as a file being updated asynchronously with respect to rkhunter cron jobs. I also understand that once rkhunter uses the package manager checksums, it will still propagate an error from that even if the local properties db agrees with the current content on disk.
As such, I consider the "hash whitelisting" to be complimentary to the existing other whitelisting mechanisms, and would still hope that you eventually include it.
However, for the case at hand that I am trying to solve I've made the RPM package manager verification aware of bi-arch packages, and will open a new patch tracker..
Added in CVS for testing.
This has only been part applied to the current release (1.3.4). As such it does not work. As far as I can see (going back through the cvs versions) the whole patch was never applied, but part of it was as part of the bi-arch patch (which was applied in full).
The whitelisting of hashes used to be available, but was removed when the --propupd option was added (because users could then create a table of their own hashes rather than updating the os.dat file all the time). However, in cases where obtaining the hash causes persistent problems, and, as mentioned, if a package manager is used and the user has knowingly changed the file, causing the hash to fail, then whitelisting may be useful.
In the light of that it may be worth re-adding the original code again. I'm going to leave this at pending and if unspawn things it is okay to readd the code then I'll see about digging out the original stuff again (and checking what the patch does too).
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).
We need to apply this, although it goes a bit further than just hash whitelisting.
Users can now select which files they want to be checked, and this can include (typically) config files. Unless these are explicitly exempted from md5, date/time etc verification in the rpm spec file, then rpm will show these as having failed verification if they are changed. Whilst we could ask all maintainers to ensure that config files are exempt, it could be argued that some users would want to know if the file changed. So the only way around this is for us to whitelist files from failed rpm verification.
Fixed in CVS. It is not whitelisting as such. The PKGMGR_NO_VRFY config option is a list of files which will be skipped from the package manager check. However, they are checked as if they weren't part of a package. That way if the file is changed it will still be reported.