On Tue, 2008-11-04 at 22:03 +0000, Dick Gevers wrote:
> On Tue, 04 Nov 2008 12:33:05 +0000, John Horne wrote about Re:
> [Rkhunter-users] False warning about /usr/sbin/vipw:
>
> >On Fri, 2008-10-31 at 18:14 +0000, Dick Gevers wrote:
> >> Using rkhunter 1.3.3. cvs of 6th October 2008 I have to report that once
> >> only I get a warning for this file in today's 16.50 h cronjob. Not before
> >> and not after:
> >>
> >>
> >> [16:52:35] //usr/sbin/vipw [ Warning ]
> >> [16:52:35] Warning: The file properties have changed:
> >> [16:52:35] File: //usr/sbin/vipw
> >> [16:52:35] Current hash:
> >> 37f1adce84d73bb92921c3bbdc074e919ce01d3d [16:52:35] Stored
> >> hash : 575d90229ec34de850e99c08c6eb4bec
> >>
> >Looks like the hash function has changed - possibly from MD5 to SHA1.
>
> I don't think so:
>
> # sha1sum /usr/sbin/vipw
> 37f1adce84d73bb92921c3bbdc074e919ce01d3d /usr/sbin/vipw
>
Yes, so what does 'md5sum /usr/sbin/vipw' show?
Can you also run:
rpm -qf '[%{FILEINODES}:%{FILEMODES:octal}:%{FILEUSERNAME}:
%{FILEGROUPNAME}:%{FILESIZES}:%{FILEMTIMES}:%{FILEMD5S}:
%{FILENAMES}\n]' /usr/sbin/vipw
and let me know what it shows (the above command should all be on one
line).
> Besides:
>
> # stat /usr/local/etcrkhunter.conf
> File: `rkhunter.conf'
> Size: 21977 Blocks: 48 IO Block: 4096 regular file
> Device: 816h/2070d Inode: 347561 Links: 1
> Access: (0600/-rw-------) Uid: ( 0/ root) Gid: ( 0/ root)
> Access: 2008-11-04 21:46:04.000000000 +0000
> Modify: 2008-10-06 17:25:34.000000000 +0000
> Change: 2008-10-06 17:25:34.000000000 +0000
>
>
> So somehow the stored hash is (and was before) wrong, but almost all the
> time rkh ignores that, except once last Friday.
>
> And it *is* from the one and only set of db/rkhunter.dat and *old being
> looked at:
>
> # tail -5 rkhunter.conf
>
> INSTALLDIR=/usr/local
> DBDIR=/var/lib/rkhunter/db
> SCRIPTDIR=/usr/local/lib/rkhunter/scripts
> TMPDIR=/var/lib/rkhunter/tmp
>
> It's beyond me how this can be.
>
I'm tending to think that it was some interaction between the file
concerned and your package manager. If the check with the package
manager fails (albeit it depends where it fails), then RKH assumes the
file is not part of a package and so treats it like an ordinary file. In
that respect the hash check would fail, the inode would also fail if
prelinking is used. However, I would also then perhaps have expected
things like the DTM to have failed too.
Obviously, next time around if the package manager command works, then
RKH sees no error.
Part of the problem is that we deliberately do not record package
manager failures for the simple reason that they are not failures for
non-packaged files. I'll have a think about this, and perhaps see if we
can see if a bit more info can be stored/logged if a package manager
command fails.
John.
--
---------------------------------------------------------------
John Horne, University of Plymouth, UK Tel: +44 (0)1752 587287
E-mail: [EMAIL PROTECTED] Fax: +44 (0)1752 587001
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Rkhunter-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/rkhunter-users
