SELinux/AppArmor решают, что процессу можно, а что нельзя — auditd ничего не запрещает, он только записывает: кто, когда и какой файл открыл, какой syscall вызвал. Для разбора инцидента постфактум это то, чего не даст ни один MAC-модуль.
Демон auditd читает события из ядра (подсистема Linux Audit Framework) и пишет в /var/log/audit/audit.log. Правила задаются через auditctl (временные, до перезагрузки) или файлами в /etc/audit/rules.d/*.rules (постоянные, загружаются при старте).
Следить за изменением конкретного файла:
auditctl -w /etc/passwd -p wa -k passwd_changes
-w — путь, -p wa — какие типы доступа логировать (w — запись, a — изменение атрибутов; есть ещё r/x для чтения и выполнения), -k — метка (ключ), по которой потом искать именно эти события.
Следить за конкретным системным вызовом по всей системе:
auditctl -a always,exit -F arch=b64 -S execve -k exec_log
-a always,exit — писать событие на выходе из syscall, -F arch=b64 — только для 64-битных процессов (у 32-битных syscall-таблица другая, правило нужно дублировать под arch=b32, если это релевантно), -S execve — конкретно запуски новых процессов.
Читать по метке, а не грепать сырой лог руками:
ausearch -k passwd_changes
Сводный отчёт по категориям событий (авторизации, изменения файлов, использование команд) — aureport без дополнительных ключей.
Главное отличие от SELinux/AppArmor: правило -p wa не остановит запись в /etc/passwd, оно только положит событие в лог. Enforcement — отдельный вопрос, auditd — это видимость, а не барьер.
#linux #security #auditd