Re: rkhunter warning after updating

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora Magazine]     [Fedora News]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux