Daniel P. Berrange wrote:
On Tue, Sep 02, 2008 at 11:07:45AM -0200, Thomas M Steenholdt wrote:
Bill Crawford wrote:
Thomas M Steenholdt wrote:
I wasn't even aware that prelinking actually changed the files. Isn't
this kind of dangerous from a system-integrity point-of-view. How can we
ever validate binaries if they are modified on purpose?
With "prelink --verify" ?
I can't see how that would actually verify that the binary has not been
modified by a rootkit or whatever?
It is explained in the manpage for prelink
-y --verify
Verifies a prelinked binary or library. This
option can be used only on a single binary or
library. It first applies an --undo operation on
the file, then prelinks just that file again and
compares this with the original file. If both are
identical, it prints the file after --undo opera-
tion on standard output and exits with zero sta-
tus. Otherwise it exits with error status. Thus
if --verify operation returns zero exit status
and its standard output is equal to the content
of the binary or library before prelinking, you
can be sure that nobody modified the binaries or
libraries after prelinking. Similarly with mes-
sage digests and checksums (unless you trigger
the improbable case of modified file and original
file having the same digest or checksum).
rpm -V should be able to detect this,
on the other hand, but how it works in conjunction with prelinking I
don't know...
IIRC, rpm -V is prelink aware, and calls out to prelink --verify rather than
doing a blind checksum compare.
Daniel
Does rpm -V use this trick to return sane results?
/Thomas
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
