Red Hat Bugzilla – Bug 58910
[4.2]: feeding RPM update info to tripwire
Last modified: 2008-05-01 11:38:01 EDT
I use tripwire, but every time I install updates of packages with a large number
of files, such as glibc or the kernel, it becomes pretty much impossible to
verify that no files have been unintentionally (or maliciously) modified just as
I installed the updates. And, unfortunately, it's not that unlikely to have an
intruder get in just as you install the package that fixes that very security
problem (assuming you always install fixes as they are published, which I do).
It would be nice to have some integration between RPM and tripwire, such that I
could run soem RPM command that would run `tripwire -m c -I' with an editor that
will look at log of modified files, compare their md5sums and timestamps with
those in the RPM database and approve the changes, leaving any other modified
files alone. It would be nice if it would display the list of
installed/uninstalled packages before committing the changes. Extra points if
this could somehow be integrated into RHN, so that one didn't have to go into
every single machine of a workgroup after requesting a global update.
If the RFE gets into rpm, then python bindings are the only impediment
to using in up2date. Whether RHN chooses to do that is a different
Thanks for entering the bug report.
Re-implementing tripwire within rpm looks very doable,
will probably take a shot at an implementation this summer ...
FYI: rpm-4.1-0.53 and later now verifies
header/digests/signatures whenever a header
is read. AFAICT There are 3 things that remain to
duplicate tripwire functionality on top of
an rpm database:
a) (easy) sign all the database files in order
to detect any modification.
b) (moderate) steal a tripwire configuration
paradigm, remapping duplicated functionality
onto existing verify CLI bits.
c) (moderate) walk the file tree to find files
not under package management, and %ghost those
files into a separate, virtual package header.
This ain't gonna happen for rpm-4.1, will be addressed in rpm-4.2
*** This bug has been marked as a duplicate of 76877 ***