Vijay Avarachen
Wed, 10 Feb 2010 12:23:25 -0800
John,
Thank you for your response. I stand corrected with regards
to the prelink cron job.
Maybe I am not using this prelink patch correctly, because although it does not report the binaries (following a prelink cron run), it does report the folders containing them (with inodes included in checks. see my original email for sample). I can get better results by using the stock aide version shipped with centos 5 and just not check for inodes. So essentially the same conclusion you have arrived at. Are there any security ramifications by not using inodes in the check? Since I am checking for permissions, various checksums, ownership, create time, mod time and size, I think I can still have a high degree of confidence in the files integrity. Any thoughts? Thanks, Vijay Once I remove the inode check On Mon, Feb 8, 2010 at 11:25 AM, John Horne <john.ho...@plymouth.ac.uk> wrote: > On Mon, 2010-02-08 at 08:45 -0600, Vijay Avarachen wrote: >> >> I compiled the latest snapshot with the prelink patch applied and >> installed it. Prior to initializing the aide db, I ran the prelink >> cronjob (CentOS 5). After initializing the aide db I ran a check >> (aide -C) expecting to see no fs changes. To my surprise, aide >> reported numerous changes, all of them directories and in each case >> the inode had changed. >> > The prelink cronjob does not force prelinking to run, but simply sees if > prelinking is required to be run (and does so if necessary). If you need > to force prelinking to run, then you can either run 'prelink -fa' from > the command line, or 'touch /var/lib/misc/prelink.force' and then run > the cronjob. > > Prelinking will, to some extent, 'recreate' the relevant file, so it is > normal for the files inode number, and date/time values to change. > Things such as the ownership, permissions and SELinux attributes will, > of course, remain the same. > > The prelink patch simply (sorry, no disrespect there!) provides the > original binary to aide, so that the checksum can be checked to see if > the file content has changed. But whenever prelinking has run on files, > then their inode numbers will change. The prelink patch has no control > over that. As such, I tend to monitor the checksum of prelinked files, > but not the inode numbers. I use: > > #L: p+i+l+n+u+g+acl+selinux+xattrs > PRELINK = L-i+sha256+tiger > > > > > John. > > -- > John Horne Tel: +44 (0)1752 587287 > University of Plymouth, UK Fax: +44 (0)1752 587001 > _______________________________________________ > Aide mailing list > Aide@cs.tut.fi > https://mailman.cs.tut.fi/mailman/listinfo/aide > -- "Knowledge is the only wealth that grows as you spend it, and diminishes as you save it." -- ancient Sanskrit saying _______________________________________________ Aide mailing list Aide@cs.tut.fi https://mailman.cs.tut.fi/mailman/listinfo/aide