2009/12/2 Bill Davidsen <davidsen@xxxxxxx>: > Wow, a list of things I really don't want to change and an evil doer might > like to change. > > Whitelisting is kind of like taking the battery out of the smoke detector, > it stops the noise but loses the warning. Short term I'd rather manually > verify the checksums of the new packages, and long term, if Kevin doesn't > push a new list, you can build it yourself. I agree entirely. That's why I've got mine configured to ignore just the specific versions of the applications that I have currently installed that RKHunter complains about - if the version changes, RKHunter will complain and I'll know about it. Of course, to tamper with the RKHunter files as installed by the package an attacker would already need to be "root" so I'm not too concerned about that aspect, and I run "rpm --checksig" on all new or updated packages before installation anyway. However, Kevin made some valid points about managing the version number updates, even though we're only talking about nine applications here. I had a look into the mechanism used by RKHunter last night with a view to checking other applications, and it's something of a dog to say the least, so I can understand why Kevin didn't really want to touch it. Essentially there are two ASCII files in "/var/lib/rkhunter/db/", "programs_bad.dat" and "programs_good.dat", that contain lists of known bad and good application versions respectively for each application being checked and, as you might imagine, some of those lists are rather long... It was RKHunter's downloading of an updated version of "programs_bad.dat" during its initialisation update check that caused the warnings over the weekend, so simply amending the dat file isn't a solution unless you also ensure it that won't get overwritten by RKHunter's update mechanism. How to best prevent similar false alarms in future without requiring end-user involvement, I don't know. The only approaches I can think of are to disable the "apps" test, which Kevin suggested, or to watch "testing" for new updates to the checked applications then proactively update the whitelist in "rkhunter.conf" and push an updated RKHunter package. An easier option might be to update the remote version of "programs_bad.dat" file, but I'm assuming that is outside of Fedora's control since it wasn't the only distro to experience the problem. -- Andy The only person to have all his work done by Friday was Robinson Crusoe -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
