Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Originally posted by Capt_Caveman I'm getting the feeling this might have something to do with prelinking. It should be run about the same time as yum by cron. All of the target dirs seem to appear in /etc/prelink.conf. Prelinking binaries can add entries to the end of the .dynamic section for virtual mem addresses locations. It also may explain why some test are coming back clean(those that don't look at the elf header) while others are flagging them (those that do check). Try undoing the prelinking with prelink -au binary and rerun tripwire.
OK, this seems to have "undone" some of the changes. The addresses at the end of the dynamic section of objdump are gone on the affected binaries. I also noticed that the other systems I was checking the binaries against don't have prelink installed, so that would explain why those addresses weren't showing up on those systems.
I ran tripwire and started comparing that report against the previous alarm reports. I've found that some files (/usr/sbin/callback, /usr/sbin/diskdumpctl_proc,/usr/bin/a2p, /usr/bin/c++... ) are back to where they were, e.g. MD5s are now what they were previously, suggesting that prelink updated many of these files.
HOWEVER, not all of them are back to where they were. /usr/bin/aspell, /usr/lib/autofs/autofs-ldap-auto-master, /usr/sbin/iptstate still do not checkout against any previous tripwire reports.
Still looks like I'm going to have to reformat and reinstall...
Perhaps... perhaps not. prelink may well be a "plausible explanation" for what TripWire is saying. TripWire presumably would not know about prelinking. (And for what it's worth, I don't bother to use it here.) If you changed a library, then the consequence of prelink would indeed be a "changed binary," and TripWire would howl.
A quick search of Google for the two terms, tripwire prelink, seemed to hit pay dirt, including the note that in Fedora Core 4, prelinking occurs "every 14 days."
To me, it seems like a strange utility (not suspicious, just strange as in "of dubious value"), and the 14-day schedule makes it more-so. I junked the thing probably six months ago, along with other RH stuff that I couldn't readily explain/justify, and I certainly don't see "slugging performance" in its absence. As others have commented, it seems to me that this would be the kind of thing that one might run "after an RPM update," or "on request," but not "regularly." Yet obviously, RH does so. Again, I'm not saying that this is suspicious.
Originally posted by sundialsvcs A quick search of Google for the two terms, tripwire prelink, seemed to hit pay dirt, including the note that in Fedora Core 4, prelinking occurs "every 14 days."
I noticed that FC3 does the same thing while I was exploring the prelink idea. It seems that it will also update every 7 days even if no RPM has been updated. This might be useful information, except that I never experienced such massive changes before the last two weeks. If I could explain all of the changes with this, I would be satisfied that nothing has been compromised.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.