On Tue, 16 Oct 2007, Julien Valroff wrote:
>
> Le mardi 16 octobre 2007 à 23:21 +1000, Tim Connors a écrit :
> > On Mon, 8 Oct 2007, Julien Valroff wrote:
> >
> > >
> > > Le lundi 08 octobre 2007 à 08:45 +1000, Tim Connors a écrit :
> > > [...]
> > > > Also, there is no documentation as to what a "suspicious file" in /dev
> > > > entails.
> > >
> > > The do_dev_whitelist_check() function seems quite clear on what a
> > > suspcious file is:
> > > FNAME=`${FILE_CMD} ${RKHTMPVAR} | cat -v | tr ' ' ' ' | tr -s ' ' | egrep
> > > -v ' (character special|block special|socket|fifo \(named pipe\)|symbolic
> > > link to|empty|directory|MAKEDEV)'`
> > >
> > > in clear: a suspicious file is everything that is not standard/common in
> > > /dev
> >
> > Hmmm, should still have the ability to whitelist entire directories in
> > that case (I suspect a /dev/shm/* wildcard already does this though),
> It does not work this way.
>
> I have tested with resolvconf which keeps some files
> under /dev/shm/resolvconf, and with the following line in rkhunter.conf,
> ALLOWDEVFILE=/dev/shm/resolvconf/*
>
> I had:
> [18:17:57] Info: Starting test name 'filesystem'
> [18:17:57] Info: SCAN_MODE_DEV set to 'THOROUGH'
> [18:17:58] Info: Found file '/dev/shm/resolvconf/resolv.conf': it is
> whitelisted.
> [18:18:15] Checking /dev for suspicious file types [ Warning ]
> [18:18:15] Warning: Suspicious files found in /dev:
> [18:18:15] /dev/shm/resolvconf/interface/eth1.inet: ASCII text
>
>
> > since /dev/shm is, as far as I am aware, a perfectly legal place to put
> > any old temporary files -
> It is indeed
>
> However, I am not sure /dev/shm should be whitelisted globally, nor that
> the user should have this possibility. Even /dev/shm can contain
> malicious file (as well as /tmp, cf suspscan test which is disabeld by
> default)
That's my feeling, and as it is identical to the /tmp and /var/tmp case,
it should be treated in the same way. Currently the config file options
and recomendation to not test /tmp and /var/tmp because it is just too
hard and slow (and false positives are just as bad as false negatives)
should get extended to /dev/shm, with appropriate logic in the rkhunter
script.
> Having the possibility to whitelist individual files is good from the
> user point of view, and better as far as security is concerned, what do
> you think?
It's perhaps adequate, but I do really fail to see how non-ordinary files
in a temporary files directory could ever signal something suspicious is
going on without giving an undue amount of false positives.
<snip>
> Clearly, you are right. Though rkhunter documentation is good, it is not
> very specific on what does each individual test. I will open a wishlist
> bug report on the upstream bug tracker.
Thanks.
--
TimC
Probably best see a real doctor and not take too much diagnostic advice
from a bunch of sysadmins who consider the body a meat computer that
needs debugging. -- Anthony de Boer on possible nerve damage in ASR
