[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Another rkhunter question

On Sun, 2009-05-17 at 13:41 -0400, Gene Heskett wrote:
> On Sunday 17 May 2009, John Horne wrote:
> >On Sun, 2009-05-17 at 09:35 -0400, Gene Heskett wrote:

> >>
> >> I've given up on rkhunter ever shutting up about the group and passwd
> >> files,
> >
> >What is it saying about the files? If necessary disable the relevant
> >passwd/group tests (use 'rkhunter --list test' to see the test names).
> I would rather not, I would rather rkhunter's bug was fixed.  I have also 
> copied those files manually into rkhunters db, but that made no diff.
> >From an email from rkhunter:
> Warning: Unable to check for passwd file differences: no copy of the passwd 
> file exists.
> Warning: Unable to check for group file differences: no copy of the group file 
> exists.
Okay, can you run:

    rkhunter --debug --enable "passwd_changes group_changes"

This will create a file in the /tmp directory named something like
'rkhunter_debug'. Can you email that to me please (it will be big, so do
not email to this list).

Secondly, did you install rkhunter from source or via an RPM from a

> I'd druther rkhunter was fixed.  --propupd, which is supposed to record the 
> systems 'clean' state if I understand it correctly, doesn't fix this.
No, the propupd option has nothing to do with passwd/group files. It
records file properties (mode, permissions, hash values etc). running
rkhunter with --propupd will make no difference in that respect.

> >> but fussing about this is new.
> >> ---------------------- Start Rootkit Hunter Scan ----------------------
> >> Warning: Suspicious file types found in /dev:
> >>          /dev/shm/sem.ADBE_REL_root: data
> >>          /dev/shm/sem.ADBE_WritePrefs_root: data
> >>          /dev/shm/sem.ADBE_ReadPrefs_root: data
> >
> >Items in /dev/shm that are genuine can be whitelisted in rkhunter.conf.
> >There is an example of the pulse file whitelisted in the supplied
> >rkhunter.conf file. It is easy enough to do the same for the ADBE files.
> >No need to remove any packages.
> I realize that John & thank you for the reply, but that doesn't tell me IF 
> they are _genuine_ or what the heck they are doing.
Ah, yes. Whether they are genuine or not is, I'm afraid, for you to
decide. I too have just upgraded acrobat to version 9, and have seen
these files created. I suspect a lot of people running rkhunter will get
caught out by them.

> I did find out who owns /dev/shm though, its kded4, and even with x stopped, 
> or a fresh reboot to runlevel 3, /dev/shm can be emptied, but cannot be 
> deleted as its 'busy'.  So I suppose the other files will reappear at some 
> point in the course of my daily activities.
I think if you run 'mount' you will see that /dev/shm is mounted as a
tmpfs. Basically it resides in memory (AFAIK), so the files will be
recreated when necessary after each reboot.


John Horne, University of Plymouth, UK  Tel: +44 (0)1752 587287
E-mail: John Horne plymouth ac uk       Fax: +44 (0)1752 587001

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]