SELinux + logrotate + предварительно вращаются = Отклоненное Разрешение
С производственной точки зрения это - плохое состояние, чтобы быть в. Во-первых производительность ухудшается, когда использование диска увеличивается. Когда диск приближается к полной мощности существуют менее последовательные области диска, чтобы хранить данные в. Это влияет на производительность из-за дополнительного поиска на диске и эффектов задержки, ожидающих свободного сектора для достижения головки диска.
Более важный потенциальный эффект на систему. Сервер предоставляет жизненную услугу? Какой длины это будет, прежде чем разработка и операционные команды узнают, что сервисы снижаются? Какой длины это будет, прежде чем пользователи становятся сердитыми, когда нет никакого доступного сервиса? Приложения будут часто замораживаться, когда не будет никакого устройства хранения данных для записи в. Могут быть цепные реакции, которые могут вызвать дальнейшие проблемы - добавляющий еще больше времени, прежде чем сервисы будут полностью восстановлены. И когда сервис был восстановлен, состояние системы может быть несбалансированным - например, огромное отставание входящих данных во время сервисных задержек причин времени простоя обработки.
Посмотрите в / var / log / messages и /var/log/audit/audit.log (если у вас есть auditd . Вы также можете использовать Audit2Lool для просмотра сообщений об ошибках SELinux и возможных решений.
Кроме того, попробуйте Semanage Permissive - LOGROTATE_T , чтобы разрешить Logrotate работать и не отказываться от SELinux.
Если вы не уверены, что это SELinux, сначала попробуйте временно отключить SELinux, принудительноsudo setenforce 0SELinux Ref , и запустите код, который дал сбой. Если это SELinux, читайте дальше..
Недавно я столкнулся с этой проблемой и был мало знаком с SELinux, поэтому для меня это было своего рода кривой обучения. В отличие от (DAC )разрешений стандартного режима posix, использующих chmodи chown, SELinux гораздо более детализирован с разрешениями. В некоторых случаях он будет запрещать определенные операции, такие как подключение к Интернету через TCP/443, или разрешать запись в /foo & /bar, но больше нигде и т. д. в зависимости от вызывающего (приложения ).
Для просмотра файлов (MAC )обязательного контроля доступа ls -Zили пользователей id -Zс выводом в формате user:role:type:level.
В моем случае на Centos7 у меня был сценарий, вызываемый в файле конфигурации logrotate.d со сценарием предварительной ротации, который загружал файл журнала до его ротации. У меня было несколько отказов (, зарегистрированных в/var/log/audit/audit.log). Я узнал, что вы можете использовать несколько инструментов для создания определенного пакета политики для установки. Я создаю пакеты.rpm для нашего кода, поэтому я добавил все описанные ниже шаги в файл.spec для создания и установки пакета политики во время установки.
Что вам понадобится:policycoreutils -python, checkpolicy (может быть уже установлен)
Насколько я понимаю, если вы планируете распространять эту политику безопасности, идея заключается в том, что вы хотите отправить только файл *.te и создать политику на месте, поэтому, если определения, на которые опирается политика, будут обновлены, они будут унаследованы. во время установки.
#поиск сообщений об отказе
watch "tail /var/log/audit/audit.log | grep 'denied'"
#создание файла te (принудительного )файла (удобочитаемой политики безопасности)
grep 1561055176.928:11371 /var/log/audit/audit.log|audit2allow -m myapp > myapp.te
#вы также можете найти несколько сбоев и передать их все в audit2allow
cat /var/log/audit/audit.log | grep logrotate | audit2allow -m myapp > myapp.te
#вы также можете использовать команду audit2why, чтобы получить небольшое объяснение того, почему иногда не удавалось выполнить действия по устранению неполадок
cat /var/log/audit/audit.log | grep logrotate | audit2why
ПРЕДУПРЕЖДЕНИЕ На этом шаге я обнаружил, что отчет audit2why о том, что мой сценарий будет работать, если я запущу setsebool -P nis_enabled 1. Хотя это звучит прекрасно и модно, вы должны всегда проверять, каковы последствия запуска этих команд для безопасности. Установка этого параметра может расширить поверхность атаки, поэтому будьте осторожны.
#построить модуль политики из файла принудительного применения типов
checkmodule -M -m -o myapp.mod myapp.te
#собрать пакет политики из модуля политики
semodule_package -o myapp.pp -m myapp.mod
#загрузить пакет политик с привилегиями root
semodule -i myapp.pp
Мне пришлось проделать эти шаги несколько раз, пока я не накопил все крошечные разрешения, необходимые для работы моего кода.
--обновление--
В итоге я запустил свой скрипт непосредственно перед задачей logrotate cron, чтобы мне не пришлось расширять разрешения logrotate _t. У меня было это в prerotate, потому что я хотел не вращать файл при сбоях, что все еще удовлетворяет этот синтаксис. Используя синтаксис '&&', если 1-я команда не удалась, она не выполнит 2-ю.
10 * * * * root /usr/bin/sudo -i -u otheruser /opt/send_logs.sh && /usr/sbin/logrotate -f /path/to/myapp_logrotate.conf > /tmp/myapp_rotate.log 2&1