This happens because chkrootkit looks for an executable named syslogd in several common locations, but since Ubuntu uses rsyslog, its syslog daemon is instead called rsyslogd.
To check that the syslog daemon on your machine specifically is called rsyslogd rather than syslogd, you can run locate syslogd (though of course, if you did have a rootkit, it could cause wrong results to be reported by this command too):
ek@Io:~$ locate syslogd
/etc/apparmor.d/usr.sbin.rsyslogd
/etc/apparmor.d/disable/usr.sbin.rsyslogd
/etc/apparmor.d/local/usr.sbin.rsyslogd
/usr/sbin/rsyslogd
/usr/share/man/man8/rsyslogd.8.gz
To verify that this is why chkrootkit is not testing the syslog daemon, you can run chkrootkit with the -d flag (for debug mode) and send a copy of the output to a file:
sudo chkrootkit -d |& tee ~/chkrootkit.log
Then open the log file in a text editor and examine the debug output between the Checking `syslogd'... and not tested messages. On my machine it looks like this (on yours I expect it will be similar):
Checking `syslogd'... + chk_syslogd
+ STATUS=1
+ SYSLOG_I_L=/usr/lib/pt07|/dev/pty[pqrs]|/dev/hd[als][0-7]|/dev/ddtz1|/dev/ptyxx|/dev/tux|syslogs\.h
+ loc syslogd syslogd /usr/local/sbin /usr/local/bin /usr/sbin /usr/bin /sbin /bin /sbin /usr/sbin /lib /usr/lib /usr/libexec .
+ thing=syslogd
+ shift
+ dflt=syslogd
+ shift
+ :
+ test -f /usr/local/sbin/syslogd
+ :
+ test -f /usr/local/bin/syslogd
+ :
+ test -f /usr/sbin/syslogd
+ :
+ test -f /usr/bin/syslogd
+ :
+ test -f /sbin/syslogd
+ :
+ test -f /bin/syslogd
+ :
+ test -f /sbin/syslogd
+ :
+ test -f /usr/sbin/syslogd
+ :
+ test -f /lib/syslogd
+ :
+ test -f /usr/lib/syslogd
+ :
+ test -f /usr/libexec/syslogd
+ :
+ test -f ./syslogd
+ [ / = / ]
+ echo syslogd
+ exit 1
+ CMD=syslogd
+ [ ! -r syslogd ]
+ return 2
+ STATUS=2
+ [ = t ]
+ echo not tested
not tested
Since a file called syslogd does not exist in any of those locations (or at all), there is nothing for it to test.
A possible partial workaround would be to create a symbolic link at one of those locations to the real ryslogd executable. I consider this only a partial solution because I don't know the details of what chkrootkit checks (or should check), or if there's anything special that it should be doing to properly inspect rsyslogd, or if it really works properly when inspecting symlinks and recently created files. chkrootkit does report successfully checking syslogd when I do this, though:
ek@Io:~$ sudo ln -s /usr/sbin/rsyslogd /usr/local/sbin/syslogd
ek@Io:~$ sudo chkrootkit | grep syslogd
Checking `syslogd'... not infected
The sbin subdirectory of /usr/local might not already exist, in which case you can create it. Either way, I do suggest removing the syslogd symlink after using it.
In any case the real solution is as bodhi.zazen says--this should be reported as a bug against the chkrootkit package in Ubuntu. The way I suggest you report the bug is to:
- Read this guide, if you haven't already. It provides excellent guidance on writing bug reports. (This question is another good resource.)
- Run
ubuntu-bug chkrootkit.
- Apport will say it is "Collecting problem information." When it's done, click "Send." This will open a new browser tab where you can report the bug.
- Include information documenting the output of
chkrootkit when the problem occurs. I recommend attaching a log showing its output, preferably including debug output. You could attach the log file created if/when you ran sudo chkrootkit -d |& tee ~/chkrootkit.log (see above). You might also reproduce the small, most relevant part in the text of the bug report itself.
- Submit the bug report.
- Optionally, if you comment on this answer, I'll go to the bug report and indicate that I am also affected--as I have been able to reproduce the bug on my system. I may also be able to provide additional information--for example, I can confirm it occurs on the 15.04 Beta, and if you don't have time to produce and attach a log, I could do so. (But I'd encourage you to provide as much relevant information as you can in the original report.)
