Description of problem: rkhunter generates spurious warninig message due to pulse audio device file Version-Release number of selected component (if applicable): rkhunter-1.3.2-1.fc8 pulseaudio-0.9.8-5.fc8 dbus-1.1.2-9.fc8 How reproducible: rkhunter --check Steps to Reproduce: 1. 2. 3. Actual results: [12:41:13] Checking /dev for suspicious file types [ Warning ] [12:41:13] Warning: Suspicious file types found in /dev: [12:41:13] /dev/shm/pulse-shm-894678170: data Expected results: pulse audion dev files should I think be whitelisted Additional info: This also leads to mails that system might be infected. In my opinion the mail should not be so generic, but should state in which section of the test the warning was generated or better should append the warning message from log file itself.
Thanks for the report... I thought I had whitelisted that file, but I guess I missed it. ;( Yeah, I agree the warning email is generic, I will see what I can do to make it more useful.
I have made this change in the rkhunter-1.3.2-2.fc9 version I just checked in. I'd like to wait a bit before pushing this back to fc8, as I am also re-arranging files to make a bit more sense and also make it so the selinux maintainer can write proper policy for it so it works under selinux. You should be able to add "ALLOWDEVFILE=/dev/shm/pulse-shm-*" to your /etc/rkhunter.conf for now. Also, I have adjusted the cron job so it will show you the warnings it got. I'll keep this bug open as a reminder to get the updated package in f8 soon.
Thanks Kevin, This will make rkhunter much more easier to use.
I hope so, feel free to provide further feedback if you can think of any. I hopefully will get the f8 package updated next week after the selinux stuff is more set.
If I run rkhunter after "yum update", I get a few warnings about some files. From the log: [02:05:38] /bin/pwd [ OK ] [02:05:39] /bin/rpm [ Warning ] [02:05:39] Warning: Package manager verification has failed: [02:05:39] File: /bin/rpm [02:05:39] Try running the command 'prelink /bin/rpm' to resolve dependency errors. [02:05:39] The file hash value has changed [02:05:39] The file size has changed [02:05:39] /bin/sed [ OK ] If I run /etc/cron.daily/prelink, rkhunter stops complaining. So my request would be to run rkhunter after prelink, i.e. to rename /etc/cron.daily/01-rkhunter to /etc/cron.daily/rkhunter.
Thanks for the comment. I agree, that seems like a good idea. I will add it into the package... Sorry for the delay here... will see about getting everything in place so there will be a post f9 update to fix these things. Thanks again for the feedback!
rkhunter-1.3.2-3.fc9 has been submitted as an update for Fedora 9
rkhunter-1.3.2-3.fc8 has been submitted as an update for Fedora 8
rkhunter-1.3.2-3.fc7 has been submitted as an update for Fedora 7
rkhunter-1.3.2-3.fc7 has been pushed to the Fedora 7 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update rkhunter'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F7/FEDORA-2008-4153
(BTW, rkhunter-1.3.2-3.fcX is still in updates/testing). I get similar email every night: --------------------- Start Rootkit Hunter Update --------------------- [ Rootkit Hunter version 1.3.2 ] [1;33mChecking rkhunter data files...[0;39m Checking file mirrors.dat[34C[ [1;32mNo update[0;39m ] Checking file programs_bad.dat[29C[ [1;32mNo update[0;39m ] Checking file backdoorports.dat[28C[ [1;32mNo update[0;39m ] Checking file suspscan.dat[33C[ [1;32mUpdated[0;39m ] Checking file i18n/cn[38C[ [1;32mUpdated[0;39m ] Checking file i18n/en[38C[ [1;32mNo update[0;39m ] Checking file i18n/zh[38C[ [1;32mUpdated[0;39m ] Checking file i18n/zh.utf8[33C[ [1;32mUpdated[0;39m ] ---------------------- Start Rootkit Hunter Scan ---------------------- ----------------------- End Rootkit Hunter Scan ----------------------- I think update output should not be shown. It is already available in /var/log/rkhunter/rkhunter.log.old and rkhunter.log, I think it's enough.
rkhunter-1.3.2-3.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.
rkhunter-1.3.2-3.fc7 has been pushed to the Fedora 7 stable repository. If problems still persist, please make note of it in this bug report.
rkhunter-1.3.2-3.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
>(BTW, rkhunter-1.3.2-3.fcX is still in updates/testing). Yeah, sorry about that... I requested stable, they should go out in the next push. >I get similar email every night: ...snipp... >I think update output should not be shown. It is already available in >/var/log/rkhunter/rkhunter.log.old and rkhunter.log, I think it's enough. Well, I think the idea is that if you send an email on each run it will go to a group of admins (likely stored on other machines), so it's not as easy to tamper with locally after the run. Ie, the email is generated and out of control of that box, but the local log files can easily be edited by an intruder and tampered with pretty undetectably.
(In reply to comment #15) > >I think update output should not be shown. It is already available in > >/var/log/rkhunter/rkhunter.log.old and rkhunter.log, I think it's enough. > > Well, I think the idea is that if you send an email on each run it will go to a > group of admins (likely stored on other machines), so it's not as easy to tamper > with locally after the run. > > Ie, the email is generated and out of control of that box, but the local log > files can easily be edited by an intruder and tampered with pretty undetectably. But it's update, not scan results! Either you trust update servers or not, but I really don't want to get the same email every night, I will go into habit to deleting them without reading, which is much worse. At least email could be sent when there was something updated, but I still think that sending scan results (when smth is wrong) is enough.
Now update and scan results are sent always: /bin/echo -e "\n--------------------- Start Rootkit Hunter Update ---------------------" \ > $TMPFILE1 /bin/nice -n 10 $RKHUNTER --update 2>&1 >> $TMPFILE1 /bin/echo -e "\n---------------------- Start Rootkit Hunter Scan ----------------------" \ >> $TMPFILE1 /bin/nice -n 10 $RKHUNTER $RKHUNTER_FLAGS 2>&1 >> $TMPFILE1 XITVAL=$? /bin/echo -e "\n----------------------- End Rootkit Hunter Scan -----------------------" \ >> $TMPFILE1 /bin/cat $TMPFILE1 | /bin/mail -s 'rkhunter Daily Run' $MAILTO I suggest to echo "Start Rootkit Hunter Update" only when there was smth updated (or only lines which don't have "No update"), and to print "Start/End Rootkit Hunter Scan" only when there was some output. Then there will be no email at all if there was nothing to update and nothing printed after scanning.
/etc/cron.daily/rkhunter differences between F7/8 and F9: -TMPFILE1=`/bin/mktemp -p /var/rkhunter/tmp rkhcronlog.XXXXXXXXXX` || exit 1 +TMPFILE1=`/bin/mktemp -p /var/run/rkhunter rkhcronlog.XXXXXXXXXX` || exit 1 - LOGFILE=/var/log/rkhunter.log + LOGFILE=/var/log/rkhunter/rkhunter.log Because of this F7/8 cron job cannot be run: mktemp: cannot create temp file /var/rkhunter/tmp/rkhcronlog.UeFlG18477: No such file or directory There are more differences between 7/8 and 9 (in RKHUNTER_FLAGS). I think F9 version is more correct.
ok, I have just build and requested updates to address these issues. The cron should be fixed to look in the right place(s) in all cases, and I also have it now only sending the email when there are warnings or errors in the run, not every night. Can you try the new build out and let me know what you think? F8: http://koji.fedoraproject.org/koji/taskinfo?taskID=666406 F9: http://koji.fedoraproject.org/koji/taskinfo?taskID=666360 rawhide: http://koji.fedoraproject.org/koji/taskinfo?taskID=666333
I think all the issues here are solved, so I am going to go ahead and close this now. Feel free to re-open it or file a new bug if you spot anything in need of further attention. Thanks for filing the bug!