Hi!

Unfortunately the fix for bug #931396 fixes machines which have run
usrmerge.  But for those which have not, rkhunter now fails fatally:

erdos:~ # /usr/share/rkhunter/scripts/rkhupd.sh
Invalid SCRIPTWHITELIST configuration option: Non-existent pathname: /usr/bin/egrep
Invalid SCRIPTWHITELIST configuration option: Non-existent pathname: /usr/bin/fgrep
erdos:~ #

I don't know whether there is a way of saying "whitelist this script
if it is found, otherwise ignore it".  If there is, then this should
be applied to both /usr/bin/egrep and /bin/egrep, and likewise for
fgrep and any other /bin/... scripts.  If not, then I don't know what
to suggest.

Best wishes,

   Julian

I unfortunately don't know of a way to do that either.

As far as I can see, it will either work out-of-the-box for a usrmerged
system or for a classic system, but not both.

Francois

/usr/bin/egrep
/usr/bin/fgrep
Take a look at the EXISTWHITELIST config option - it may do what you want.


John.

Hey,

I have just spent a little bit of time digging into this, as I want
rkhunter to work (almost) turnkey, without needing users to have to
customise any configuration files.

In answer to John, sadly EXISTWHITELIST doesn't handle this situation,
it says that the the listed files/directories don't need to exist.
However we need to tell rkhunter that egrep and fgrep are allowed to be
scripts.

My approach has been two fold so far, and this feels really really
ugly, but, oh well.

If we modify /etc/default/rkhunter then it can modify
/etc/rkhunter.conf before we run rkhunter via either cron or apt. So
even if there is a transient change, it'll get picked up and corrected
eventually. I added this to /etc/default/rkhunter.conf (I also made it
handle lwp-request being present, since I hit that as well):

I'm just a fellow user here - when i started using this package a some
years ago i thought a turnkey approach would be good, but over time i
have come to take a different view.

Scanning packages like rkhunter (and chkrootkit, checksecurity, tiger,
etc, etc) cant realistically cope with every possible debian system,
and i dont think they should try.

I think there is more benefit from being told that things have changed
from some baseline (expected position), even if the baseline itself
needs adjusting. And that  it should not be debian's goal, in my
opinion, to eliminate warnings caused by debian packages (other than
those from essential:yes packages) as long as the warnings can be
silenced - rkhunter does pretty well here.

if grep moves from /usr/bin to /bin or the other way, i want to be
told, not have the scanner adjust itself.  If a new lwp-release script
appears i want to be told - even if the explanation is "because that
package got installed" (this does assume there is a reason to check if
lwp-release is a script - im not actually sure this is true given the
automatic updates are now disabled, but that's another story)

(i appreciate that it is entirely reasonable to disagree with this, I
just wanted to share my view)

(personally, i would leave usrmerge the default and close this bug as
you can already edit the rkhunter.conf to say where grep is located)