Dan начал публикацию очередной серии заметок о новых security фичах Fedora 20. В первом посте он рассказал об интеграции journald и setroubleshoot.

Как вы уже в курсе, Fedora Project в очередной раз сделал выбор, в т.ч. и за тех, кто выбор делать не в состоянии из-за паралича, разбившего их коммьюнити ("we are about choice" и прочее). В качестве стандартного интерфейса для ведения системного журнала был выбран journald, и система Lumberjack, частью которой он является. Ранее, в эпоху юниксвэя, единого системного журнала не было. Был syslog, были сообщения ядра, были отдельные логи в разных приложениях, пишущиеся в файлы, по-разному отформатированные. Чтоб связать сообщения какого-нибудь приложения, которые оно ведет в своих текстовичках, с сообщениями из syslog, или SELinux, надо было каждый раз писать небольшой скрипт на Perl и/или смеси из bash/grep/sed/awk, который затем будет периодически ломаться. Сисадмины просыпались по ночам из-за ложных срабатываний, иногда не просыпались из-за несрабатываний.Сейчас это начало исправляться в лучшую сторону.

Одна из проблемных областей, это работа с журналом SELinux. Ранее он велся в файле /var/log/audit/audit.log в виде довольно загадочных строк примерно такого вида:

type=SYSCALL msg=audit(1288657341.923:641): arch=14 syscall=196 success=no exit=-13 a0=104f1755 a1=bfacfb30 a2=bfacfb30 a3=2e items=0 ppid=21254 pid=21260 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=90 comm="updatedb" exe="/usr/bin/updatedb" subj=system_u:system_r:locate_t:s0-s0:c0.c1023 key=(null)





По каждому из таких сообщений создается соответствующее ему в /var/log/messages, где описывается, куда посмотреть дальше, где уже, в свою очередь, приводится команда, которую надо запустить, чтоб получить описание проблемы. Dan задумался, а почему б не автоматизировать этот процесс? Сказано - сделано (в отличие от отечественных анонимных аналитиков, максимум способных в очередной раз на форуме призвать "собирать на киллера", Dan умеет программировать).

Во-1 теперь системный журнал по умолчанию ведется в journald, а не в syslog, куда он перенаправляется с утерей части данных, для совместимости (к сожалению, в syslog смешаны концепции хранения и отображения данных, в то время, как в journald они отделены). В journald ведутся "бинарные логи" (повторимся, это только хранилище журнала, а не отображение его, которое можно получить, например, с помощью journalctl), поэтому способы анализа куда более богатые, чем простое грепанье по текстовому файлу. Во-2 начиная с Fedora 18 SELinux ведет свой журнал сразу в journald. После еще одного небольшого хака, доступного начиная с systemd 206, позволившего событиям SELinux появляться под категорией приложения, к которому они относятся, теперь есть возможность получать подробнейшую информацию об ситуации. Посмотрите в его блоге, как выглядело до, и как выглядит после. Dan искренне надеется, что настолько радикальное упрощение разбора журнала SELinux приведет к значительному уменьшению числа тех, кто первым делом отключает его при любой проблеме с проприетарным или плохо написанным ПО.

На этом Dan не остановился, и сейчас работает с мэйнтейнерами Glibc и ядра по реализации более подробных сообщений об ошибках EPERM и EACCESS. Будет, конечно, снова неюниксвэйно.