Здесь немного вводной информации об инструментарии аудита в Linux.

ЛИЦЕНЗИЯ
========
Демон аудита выпущен под GPL лицензией. Библиотека демона аудита - под
LGPL лицензией, т.е. она может быть слинкована с другим программным
обеспечением.

СБОРКА
======
Смотри README-install файл.

ИСПОЛЬЗОВАНИЕ
=============
Примеры использования:

  Наиболее частое использование:

    В первом окне:
        ./auditd
    Во втором окне (чтобы попробовать это, демон аудита не должен быть
    запущен как фоновая задача, достаточно лишь запустить его в
    отдельном окне):
        ./auditctl -s
        ./auditctl -a entry,always -S open
        ls
        ./auditctl -d entry,always -S open


  Слежение за определенным пользователем:
	./auditctl -a exit,always -S all -F loginuid=2000
	./auditctl -L 2000,"test uid" 

ПРИМЕРЫ КОНФИГУРАЦИОННЫХ ФАЙЛОВ
===============================
2 файла sample.config показывают примеры использования различных опций.
Файл contrib/capp.rules может быть основой для /etc/audit.rules - он
показывает как выглядит окружение для аудита в CAPP стиле.

ОБСУЖДЕНИЕ
==========
Ветки обсуждений в lkml: 
     http://marc.theaimsgroup.com/?t=107815888100001&r=1&w=2
     http://marc.theaimsgroup.com/?t=107901570800002&r=1&w=2


ИНФОРМАЦИЯ ДЛЯ РАЗРАБОТЧИКОВ
============================

Основные целями при разработке системных вызовов для подсистемы аудита
были: 1) максимально низкая нагрузка на производительность и 2)
отсутствие подобной функциональности в SELinux (и/или в любой другой
подсистеме безопасности). Инструментарий аудита будет работать без
внедренных компонент безопасности, но он не может быть использован
вместо них, т.е., например, он не будет предоставлять функциональные
возможности CAPP без действующих подсистем безопасности.

Есть две основные части: одна работает всегда (базовое журналирование в
audit.c), а другой вы можете управлять во время загрузки или работы
сервера (аудит системных вызовов в auditsc.c). Патч включает в
себя изменения в security/selinux/avc.c в качестве примера, как
системные вызовы аудита могут быть использованы совместно с другим
кодом, определяющим события для аудита.

Журналирование:
  1) использует сетевой сокет для связи с пользовательским
     пространством. Если демон запущен - все сообщения журналируются
     через этот сетевой сокет. Иначе, сообщения журналируются  через
     printk посредством демона syslog (по умолчанию).
  2) сообщения могут не журналироваться (настраивается отдельно) в
     зависимости от скорости появления сообщений или загруженности
     памяти (это частично реализовано в selinux/avc.c - код в avc.c,
     который делает это, необходимо удалить).
  3) Когда какая-то часть ядра генерирует часть сообщения аудита, эта
     часть будет немедленно послана в пользовательское пространство, _И_
     автоматически выставится флаг, указывающий, что этот системный
     вызов находится под аудитом. Таким образом, при выходе из
     системного вызова будет сформирована дополнительная информация
     (если включен аудит системных вызовов).

Аудит системных вызовов:
  1) Во время создания процесса, формируется контекст аудита и
     привязывается к структуре, описывающей процесс.
  2) Во время входа в системный вызов, заполняется следующая информация
     в контексте аудита, если он есть: номер системного вызова, дата и
     время, но не аргументы.
  3) В ходе работы системного вызова перехватываются обращения к
     getname() и path_lookup(). Эти процедуры вызываются, когда ядро
     действительно собирается искать информацию, для принятия решения,
     будет ли системный вызов успешно выполнен или нет. Перехватывать
     вызовы нужно для того, чтобы не допустить копирование информации,
     которую генерирует getname, поскольку getname уже сделал приватную
     (для ядра) копию этой информации. [Следует заметить, что сохранение
     копий всех аргументов системного вызова усложняет реализацию и
     требует увеличения расхода ресурсов, что, наиболее вероятно, не
     нужно. С этим патчем, к примеру, если вы непривилегированный
     пользователь, то chroot("foo") будет завершен с ошибкой - "foo" не
     будет отражено в записи аудита, потому что ядро определяет еще
     перед поиском "foo", что работа системного вызова не может быть
     продолжена. Этот подход предотвращает сохранение пользовательской
     информации, которая может быть обманчивой или ненадежной (например,
     из-за атаки на совместно используемую память) в отличие от
     рапортуемой информации, фактически используемой ядром.]
  4) Во время выхода их системного вызова генерируется та часть
     сообщения аудита, которая ответственна за информацию о системном
     вызове, включая имена файлов и номера inode (если доступны).
     Сообщение о системном вызове генерируется только если выставлен
     флаг, указывающий, что системный вызов находится под аудитом (он
     выставляется, например, когда SELinux генерирует avc сообщение или
     когда другая часть ядра определяет, что должно формироваться
     сообщение для аудита). Некоторая часть информации для сообщения
     аудита теперь дополнена той информацией, которую генерирует
     selinux/avc.c (имена фалов и некоторые номера inode), но некоторая -
     менее полная (например, getname не возвращает полный путь, а этот
     патч намеренно не определяет его по причине увеличения накладных
     расходов на это). [Следует заметить, что полное сообщение аудита
     приходит в пользовательское пространство по частям, это позволяет
     не хранить сообщения неопределенный срок внутри ядра.]
  5) Во время завершения процесса контекст аудита уничтожается.

  Во время шагов 1,2 и 4 может быть выполнена простая фильтрация
  (например, для увеличения производительности - отключение аудита
  системных вызовов выполняемых от имени пользователя, работающего с
  базой данных). Фильтрация может быть как простой, так и сложной. Тем не
  менее, я пытался реализовать фильтрацию на столько полно на сколько
  возможно без существенного увеличения потребления ресурсов (например,
  d_path()). В основном, инструментарий аудита должен полагаться на
  другие компоненты ядра (например, SELinux), чтобы принимать решение о
  том, что необходимо подвергать аудиту, а что нет.

