Почему chkrootkit не тестирует syslogd?

Это происходит потому что chkrootkit ищет названный исполняемый файл syslogd в нескольких общих местоположениях, но так как Ubuntu использует rsyslog, его демона системного журнала вместо этого звонят rsyslogd.

Проверять, что демона системного журнала на Вашей машине конкретно звонят rsyslogd вместо syslogd, можно работать locate syslogd (хотя, конечно, если у Вас действительно был руткит, он мог бы заставить неправильные результаты сообщаться этой командой также):

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

Проверить, что это то, почему chkrootkit не тестирует демона системного журнала, можно работать chkrootkit с -d флаг (для режима отладки) и отправляет копию вывода в файл:

sudo chkrootkit -d |& мишень ~/chkrootkit.log

Затем откройте файл журнала в текстовом редакторе и исследуйте вывод отладки между Checking `syslogd'... и not tested сообщения. На моей машине это похоже на это (на Вашей, я ожидаю, что это будет подобно):

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

Начиная с названного файла syslogd не существует ни в одном из тех местоположений (или вообще), нет ничего, чтобы это протестировало.

Возможное частичное обходное решение должно было бы создать символьную ссылку в одном из тех местоположений к реальному ryslogd исполняемый файл. Я считаю это только частичным решением, потому что я не знаю детали какой chkrootkit проверки (или должен проверить), или если существует что-либо специальное, которое это должно делать для надлежащего осмотра rsyslogd, или если это действительно работает правильно при осмотре символьных ссылок и недавно созданных файлов. chkrootkit действительно сообщает успешно проверка syslogd когда я делаю это, хотя:

ek@Io:~$ sudo ln -s /usr/sbin/rsyslogd /usr/local/sbin/syslogd
ek@Io:~$ sudo chkrootkit | grep syslogd
Checking `syslogd'...                                       not infected

^{sbin подкаталог /usr/local не мог бы уже существовать, в этом случае можно создать его. Так или иначе я действительно предлагаю удалить syslogd символьная ссылка после использования его.}

В любом случае действительное решение - как bodhi.zazen говорит - об этом нужно сообщить как ошибка против chkrootkit пакет в Ubuntu. Путем я предлагаю, чтобы Вы сообщили об ошибке, к:

1. Прочитайте это руководство, если Вы уже не имеете. Это обеспечивает превосходное руководство при записи отчетов об ошибках. (Этим вопросом является другой хороший ресурс.)
2. Выполненный ubuntu-bug chkrootkit.
3. Apport заявит, что "Собирает проблемную информацию". Когда это будет сделано, нажмите "Send". Это откроет новую вкладку браузера, где можно сообщить об ошибке.
4. Включайте информацию, документирующую вывод chkrootkit когда проблема происходит. Я рекомендую присоединить журнал, показывающий его вывод, предпочтительно включая вывод отладки. Вы могли присоединить файл журнала, созданный, если бы/когда Вы работали sudo chkrootkit -d |& tee ~/chkrootkit.log (см. выше). Вы могли бы также воспроизвести маленькую, самую соответствующую часть в тексте самого отчета об ошибках.
5. Отправьте отчет об ошибках.
6. Дополнительно, если Вы прокомментируете этот ответ, то я перейду к отчету об ошибках и укажу, что также затронут - поскольку я смог воспроизвести ошибку в своей системе. Я могу также смочь предоставить дополнительную информацию - например, я могу подтвердить, что происходит на 15.04 Бетах, и если у Вас нет времени, чтобы произвести и присоединить журнал, я мог бы сделать так. (Но я поощрил бы Вас предоставлять столько релевантной информации, сколько Вы можете в первоначальном докладе.)