Вопрос или проблема
На некоторых системах Ubuntu 22 и 24 системный журнал засоряется сообщениями, подобными этому, которые совершенно неинтересны:
Feb 05 16:17:01 myhost.example.com audit[353829]: AVC apparmor="ALLOWED" operation="open" profile="/usr/sbin/sssd" name="/proc/420747/cmdline" pid=353829 comm="sssd_nss" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Я, конечно, хотел бы знать о событиях с DENIED, но как мне заставить apparmor/audit прекратить логирование событий с ALLOWED?
Ответ или решение
Для предотвращения засорения журналов системы уведомлениями об «РАЗРЕШЕННЫХ» (ALLOWED) событиях AppArmor на системах Ubuntu 22 и 24, необходимо предпринять ряд шагов, чтобы сконфигурировать AppArmor и систему аудита таким образом, чтобы они фильтровали подобные сообщения, сохраняя при этом возможность получать уведомления о «ЗАПРЕЩЕННЫХ» (DENIED) событиях.
Теория
AppArmor — это система мандатного контроля доступа, интегрированная в Linux, которая позволяет определять политики безопасности для процессов, ограничивая их действия. Эта система может генерировать журналы для аудита, включая как разрешенные, так и запрещенные операции. Журнализация разрешенных событий (events) может стать нежелательной в случаях, когда она вызывает перегрузку системных журналов, как это происходит в вашем случае.
Система аудита Linux, часто используемая совместно с AppArmor, управляет тем, какие события будут записаны в журнал. Конфигурация аудита/дизайна политики безопасности позволяет контролировать объем и тип записываемых данных.
Пример
Пример из вашего описания журнала:
Feb 05 16:17:01 myhost.example.com audit[353829]: AVC apparmor="ALLOWED" operation="open" profile="/usr/sbin/sssd" name="/proc/420747/cmdline" pid=353829 comm="sssd_nss" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Это событие указывает на разрешенный доступ, который в большинстве случаев может быть несущественным для администратора системы.
Применение
-
Настройка правил аудита:
- Вы можете изменить параметры системы аудита, чтобы игнорировать события с типом "ALLOWED", оставив только критические события "DENIED". Для этого в файле
/etc/audit/rules.d/
добавьте или откорректируйте файл правил, чтобы исключить такие события. Пример команды:echo '-a never,exit -F arch=b64 -S open,openat -F success=1' > /etc/audit/rules.d/disable-allowed-open.rules
- Перезапустите службу аудита для применения изменений:
sudo systemctl restart auditd
- Вы можете изменить параметры системы аудита, чтобы игнорировать события с типом "ALLOWED", оставив только критические события "DENIED". Для этого в файле
-
Использование утилит управления AppArmor:
- Чтобы уменьшить количество журналируемых "разрешенных" сообщений, вы можете изменить профиль AppArmor для конкретного приложения. Профайлы находятся в
/etc/apparmor.d/
. Найдите файл, связанный с/usr/sbin/sssd
и откройте его для редактирования:sudo nano /etc/apparmor.d/usr.sbin.sssd
- Убедитесь, что в разделе
audit
настроены только те события, которые действительно необходимо записывать. Например, вы можете удалить или закомментировать строки, связанные с разрешенными действиями, если они существуют.
- Чтобы уменьшить количество журналируемых "разрешенных" сообщений, вы можете изменить профиль AppArmor для конкретного приложения. Профайлы находятся в
-
Фильтрация сообщений на уровне системы логирования (журнализация):
- Вы можете настроить вашу систему журналирования, такую как
rsyslog
, чтобы она отфильтровывала нежелательные сообщения. Откройтеrsyslog
конфигурацию:sudo nano /etc/rsyslog.d/50-default.conf
- Добавьте фильтр для AppArmor, чтобы игнорировать ненужные сообщения:
if $msg contains 'apparmor="ALLOWED"' then ~
- Перезапустите
rsyslog
:sudo systemctl restart rsyslog
- Вы можете настроить вашу систему журналирования, такую как
Этот подход позволит вам избежать потери важной информации в случае запрещенных действий, в то время как нежелательные события, связанные с разрешенными действиями, будут игнорироваться, помогая поддерживать чистоту журналов системы. Внесение таких изменений также способствует повышению эффективности, так как важно постоянно контролировать критические события безопасности с минимальными отвлечениями.