Centos – rkhunter warns of inode change but no file modification date changes

centosrkhunteryum

I have several systems running Centos 6 with rkhunter installed. I have a daily cron running rkhunter and reporting back via email.

I very often get reports like:

---------------------- Start Rootkit Hunter Scan ----------------------
Warning: The file properties have changed:
        File: /sbin/fsck
        Current inode: 6029384    Stored inode: 6029326
Warning: The file properties have changed:
        File: /sbin/ip
        Current inode: 6029506    Stored inode: 6029343
Warning: The file properties have changed:
        File: /sbin/nologin
        Current inode: 6029443    Stored inode: 6029531
Warning: The file properties have changed:
        File: /bin/dmesg
        Current inode: 13369362    Stored inode: 13369366

From what I understand, rkhunter will usually report a changed hash and/or modification date on the scanned files to, so this leads me to think that there is no real change.

My question: is there some other activity on the machine that could make the inode change (running ext4) or is this really yum making regular (~ once a week) changes to these files as part of normal security updates?

Best Answer

Updating files is often done by writing a new file in the same directory followed by renaming the file on top of the old file. This method is usually applied to everything installed through a package manager, but also to any update performed to executables and libraries even if updated for other reasons.

This way of updating files ensure that any process opening the file will get either the old or the new, and not see anything changing in the file, which they have opened. It does mean that each time it is updated, you will actually have a new file with the same name, hence the inode number has changed.

I guess this is the reason for those files having a new inode number.

A security update could be one reason. But there is another possibility, which I first observed on Fedora Core 1, and that could very well have made it into Centos at some point.

Executables and libraries are being prelinked such that they can start faster and use less memory. During this process the load address is randomized to make exploiting security vulnerabilities a little bit harder. A cron job would periodically repeat the process with new randomized addresses causing all the prelinked executables and libraries to get updated.

Related Topic