I'm running the latest rkhunter-1.4.2-3.el6.noarch from Fedora EPEL.
Before this release using wildcards in ALLOWPROCDELFILE worked fine, but since this update it fails again.
An example from my config file:
ALLOWPROCDELFILE="/opt/zimbra/mysql-5.5.35/bin/mysqld:/opt/zimbra/data/tmp/ib"
This line will return issues with mysqld having an open fd against an ib file.
ALLOWPROCDELFILE="/opt/zimbra/mysql-5.5.35/bin/mysqld"
This line will again work, but it also accepts any file name.
This used to work fine in rkhunter-1.4.0-2.el6.noarch. The issue arrived when upgrading to rkhunter-1.4.0-1.el6.noarch.
(I guess you don't have anything to do with the Fedora EPEL packaging, I just added those version strings to be even more accurate. But it's based upon the upstream versions 1.4.0 and 1.4.2)
Already fixed in CVS.
This actually isn't fixed in the latest build. Anything with wildcards is failing, even the MySQL example that is included in the comments. If you replace the wildcard with the temporary file name, it properly filters it out, put the wildcard back and it doesn't work.
Example run with the following settings:
ALLOWPROCDELFILE=/usr/sbin/mysqld:/tmp/ib
ALLOWPROCDELFILE=/sbin/init:/var/log/upstart/systemd-logind.log
ALLOWPROCDELFILE=/opt/sp/php5.5/sbin/php-fpm:/tmp/.ZendSem.
ALLOWPROCDELFILE=/opt/sp/php5.6/sbin/php-fpm:/tmp/.ZendSem.
Warning: The following processes are using deleted files:
Process: /sbin/init PID: 1 File: /var/log/upstart/systemd-logind.log.1
Process: /usr/sbin/mysqld PID: 3981 File: /tmp/ibA9FZnr
Process: /opt/sp/php5.5/sbin/php-fpm PID: 5862 File: /tmp/.ZendSem.WsvJLh
Process: /opt/sp/php5.6/sbin/php-fpm PID: 31645 File: /tmp/.ZendSem.ROwvWC
Process: /opt/sp/php5.6/sbin/php-fpm PID: 31646 File: /tmp/.ZendSem.ROwvWC
Process: /opt/sp/php5.6/sbin/php-fpm PID: 31938 File: /tmp/.ZendSem.ROwvWC
Changed the settings to the following (note the change to mysql line):
ALLOWPROCDELFILE=/usr/sbin/mysqld:/tmp/ibA9FZnr
ALLOWPROCDELFILE=/sbin/init:/var/log/upstart/systemd-logind.log
ALLOWPROCDELFILE=/opt/sp/php5.5/sbin/php-fpm:/tmp/.ZendSem.
ALLOWPROCDELFILE=/opt/sp/php5.6/sbin/php-fpm:/tmp/.ZendSem.*
Warning: The following processes are using deleted files:
Process: /sbin/init PID: 1 File: /var/log/upstart/systemd-logind.log.1
Process: /opt/sp/php5.5/sbin/php-fpm PID: 5862 File: /tmp/.ZendSem.WsvJLh
Process: /opt/sp/php5.6/sbin/php-fpm PID: 31645 File: /tmp/.ZendSem.ROwvWC
Process: /opt/sp/php5.6/sbin/php-fpm PID: 31646 File: /tmp/.ZendSem.ROwvWC
Process: /opt/sp/php5.6/sbin/php-fpm PID: 31938 File: /tmp/.ZendSem.ROwvWC
md5 matches the latest version (1.4.2): 85ad366b7f3999eb2a9371e39a1a4df7
Relevant server info:
Distributor ID: Ubuntu
Description: Ubuntu 14.04.1 LTS
Release: 14.04
Codename: trusty
Can you run RKH with the '--debug' option please. Then email me the debug file in /tmp. A copy of the log file at the time might help too please.
thanks,
John.
I sent the logs through SourceForge messaging, but I couldn't attach them. Please confirm you received. For now I am running the command with the flag --disable deleted_files.
Your debug output failed:
================
+ echo You must enter an option for the program to perform.
You must enter an option for the program to perform.
+ echo Type in 'rkhunter --help' to see the available options,
Type in 'rkhunter --help' to see the available options,
+ echo or read the rkhunter man page.
or read the rkhunter man page.
================
It looks like, as it says, you didn't include any options telling RKH what to do. Try running something like: rkhunter --debug --enable deleted_files
Then email the debug file to 'jhorne@plymouth.ac.uk'.
@David, @JohnM: Just found this open bug report. Could you check the patch against CVS 1.526 supplied in another ticket? Maybe it fixes your problem.
@JohnH: I think [#129] and [#114] are addressing the same problem.
Related
Bugs:
#114Bugs:
#129I'll take a look at this and bug 129 as well. I agree that the new code (using expand_paths) does not seem right given that in this case the pathname has been deleted. Doh! I suspect that the EXISTWHITELIST option may fall under the same problem. I'll check to see if any other options could be affected too.
Okay, hopefully the current CVS version now has this fixed. Whatever pathnames are specified for the option are not expanded at all but are converted to regular expressions. This is then matched (by grep) to the deleted pathnames found by lsof.
Thanks for fixing John.