How RPM verification deals with prelinking

Given the problems that prelinking adds to verifying that two systems are identical, you might sensibly ask how RPM verification deals with this problem. Unfortunately, the answer is not calculated to make security people happy.

RPM has no native knowledge of how to analyze prelinked things; instead it delegates this work to an external program. When RPM detects that it is trying to verify a prelinked file, it starts the program and expects it to produce the original, un-prelinked version of the file on standard output. RPM then verifies the checksum of this against what it should be.

(RPM detects prelinked files by looking for a couple of flags in the ELF headers. Things without valid ELF headers or without the flags are just verified as-is, which is the good news in all of this.)

What external program is used for this is not hard-coded into RPM but is instead specified by the __prelink_undo_cmd RPM macro (found in /etc/rpm/macros.prelink on Red Hat and Fedora machines). On a normal system this runs prelink with the -y flag, which verifies that the current version of the file is properly prelinked and then dumps out the un-prelinked version (you can read the details in the manpage).

(prelink itself needs to verify that the prelinking is correct, because nothing else will.)

I am not sure how all of this interacts with rpm's -R flag, which runs at least some scripts and the like chroot()'d. Ideally it would run your version of prelink instead of the version in the hierarchy you are pointing -R at, but I suspect that this won't work very well right now.

(To make this work, prelink would need to know that it should find all of the libraries for things that it is verifying in the 'alternate root', instead of in your regular system.)