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

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

Чтобы убедиться, что демон syslog на вашей машине специально вызывается 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 не тестирует демон syslog, вы можете запустить chkrootkit с -d флаг (для режима отладки) и отправить копию вывода в файл:

sudo chkrootkit -d |& tee ~/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 скажет, что это "Сбор проблемной информации". Когда это будет сделано, нажмите "Отправить". Это откроет новую вкладку браузера, где вы можете сообщить об ошибке.
4. Включите информацию, документирующую результаты chkrootkit когда проблема возникает. Я рекомендую прикрепить журнал, показывающий его вывод, предпочтительно с выводом отладки. Вы можете прикрепить файл журнала, созданный, если / когда вы запустили sudo chkrootkit -d |& tee ~/chkrootkit.log (см. выше). Вы также можете воспроизвести небольшую, самую важную часть в тексте отчета об ошибке.
5. Отправить отчет об ошибке.
6. По желанию, если вы прокомментируете этот ответ, я перейду к отчету об ошибке и укажу, что на меня это тоже влияет - поскольку я смог воспроизвести ошибку в моей системе. Я также могу предоставить дополнительную информацию - например, я могу подтвердить, что это происходит в бета-версии 15.04, и если у вас нет времени на создание и прикрепление журнала, я мог бы сделать это. (Но я бы посоветовал вам предоставить как можно больше соответствующей информации в исходном отчете.)