Просмотр запретов SELinux Утилита semodule Утилита audit2why Анализ сообщений об отказе SELinux Утилита audit2allow Исправление проанализированных отказов SELinux Проблемы с маркировкой Неправильный контекст Утилита secon
Окружение
Если сценарий заблокирован SELinux, первым шагом для поиска дополнительной информации об отказе должно быть обращение к файлу /var/log/audit/audit.log. Для запроса журналов аудита используйте инструмент ausearch. Поскольку решения SELinux, такие как разрешение или запрет доступа, кэшируются (этот кэш называется "кэш векторов доступа" или AVC), используйте значения AVC и USER_AVC для параметра типа сообщения, например:
ausearch
AVC
USER_AVC
sudo ausearch -m AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR -ts recent
Если совпадений нет, проверьте, запущен ли демон аудита. Если нет, перезапустите его командой systemctl start auditd, затем повторите сценарий отказа и снова просмотрите журнал аудита.
systemctl start auditd
В случае если auditd запущен, но в выводе ausearch нет совпадений, проверьте сообщения, которые могут быть зарегистрированы в журнале systemd:
auditd
sudo journalctl -t setroubleshoot
Если SELinux активен и демон аудита не запущен в системе, найдите определенные сообщения SELinux в выводе команды dmesg:
dmesg
sudo dmesg | grep -i -e type=1300 -e type=1400
Даже если предыдущие три проверки не принесли результата, остается вероятность того, что отказы AVC были скрыты правилами dontaudit.
Для временного отключения правил dontaudit и разрешения регистрации всех отказов выполните команду:
sudo semodule -DB
Для включения правил dontaudit в политике выполните следующую команду:
sudo semodule -B
Если применены все четыре предыдущих шага, а проблема по-прежнему остается невыявленной, подумайте, действительно ли SELinux блокирует сценарий:
Переключиться в разрешительный режим:
sudo setenforce 0
Проверьте текущий режим работы SELinux:
getenforcePermissive
Повторите сценарий.
Если проблема все еще возникает, сценарий блокирует что-то другое, а не SELinux.
Утилита semodule используется в системе РЕД ОС для управления модулями политик безопасности, включая установку, обновление, вывод списка и удаление модулей.
Синтаксис:
semodule [опции]
semodule применяется к пакетам модулей, созданным с помощью semodule_package. По соглашению эти файлы имеют суффикс .pp (пакет политики).
semodule_package
Перед работой с модулями убедитесь, что SELinux активен:
sestatus
Для просмотра загруженных модулей политик SELinux используйте:
sudo semodule -l
Для загрузки или замены модуля политики из файла используйте параметр -i. Если модуль с таким именем уже загружен, он будет обновлен:
-i
sudo semodule -i module.pp
Здесь module.pp является файлом модуля политики, который требуется загрузить.
Если требуется удалить модуль политики, используйте параметр -r:
-r
sudo semodule -r module
Здесь в качестве параметра выступает имя модуля, который требуется стереть.
Для включения модуля используйте параметр -e:
-e
sudo semodule -e module
Для выключения модуля используйте параметр -d:
-d
sudo semodule -d module
Для получения информации о возможностях утилиты semodule выполните команду:
man semodule
Утилита audit2why — определит из сообщения аудита SELinux причину запрета доступа.
Эта утилита обрабатывает сообщения аудита SELinux, принятые со стандартного ввода, и сообщает, какой компонент политики вызвал каждый из запретов. Если задана опция -p, то используется указанная этой опцией политика, в противном случае используется активная политика. Есть три возможные причины запрета доступа:
В первом случае разрешительное правило может присутствовать в политике, но было отключено через булевы атрибуты. Если же разрешительного правила не было, то оно может быть создано при помощи утилиты audit2allow.
Во втором случае могло произойти нарушение ограничения. Просмотрите policy/constraints или policy/mls для того, чтобы определить ограничение. Обычно, проблема может быть решена добавлением атрибута типа к домену.
В третьем случае была произведена попытка сменить роль, при том что не существует разрешительного правила для участвующей при этом пары ролей. Проблема может быть решена добавлением в политику разрешительного правила для этой пары ролей.
audit2why [опции]
--help
-p <policyfile>
Пример:
audit2why < /var/log/audit/audit.logtype=KERNEL msg=audit(1115316408.926:336418): avc: denied { getattr } for path=/home/ sds dev=hda5 ino=1175041 scontext=root:secadm_r: secadm_t:s0-s9:c0.c127 tcontext=user_u:object_r:user_home_dir_t:s0 tclass=dir
Причина: Отсутствует или отключено разрешительное правило. Разрешительное правило может присутствовать в политике, но было отключено через булевы переключатели; проверьте булевы переключатели. Можно посмотреть необходимые разрешительные правила, запустив audit2allow и подав это сообщение аудита на ввод.
type=KERNEL msg=audit(1115320071.648:606858): avc: denied { append } for name=.bash_history dev=hda5 ino=1175047 scontext=user_u:user_r:user_t:s1-s9:c0.c127 tcontext=user_u:object_r:user_home_t:s0 tclass=file
Причина: Нарушение ограничения. Проверьте policy/constraints. Обычно, для разрешения ограничения необходимо добавить в домен атрибут типа.
После определения того, что SELinux блокирует сценарий, может потребоваться проанализировать основную причину, прежде чем выбирать способ исправления.
Выведите более подробную информацию о зарегистрированном отказе, используя команду sealert. Для этого установите пакет setroubleshoot:
sealert
sudo dnf install setroubleshoot
Выведите информацию:
sealert -l "*"SELinux запрещает gmain доступ watch к каталог /run/mount. ***** Модуль catchall предлагает (точность 100.) *************************** Если вы считаете, что gmain должно быть разрешено watch доступ к mount directory по умолчанию. То рекомендуется создать отчет об ошибке. Чтобы разрешить доступ, можно создать локальный модуль политики. Сделать разрешить этот доступ сейчас, выполнив: # ausearch -c 'gmain' --raw | audit2allow -M my-gmain # semodule -X 300 -i my-gmain.pp Дополнительные сведения: Исходный контекст system_u:system_r:xdm_t:s0-s0:c0.c1023 Целевой контекст system_u:object_r:mount_var_run_t:s0 Целевые объекты /run/mount [ dir ] Источник gmain Путь к источнику gmain Порт <Неизвестно> Узел localhost.localdomain Исходные пакеты RPM Целевые пакеты RPM SELinux Policy RPM selinux-policy-targeted-38.33-2.red80.noarch Local Policy RPM selinux-policy-targeted-38.33-2.red80.noarch SELinux активен True Тип регламента targeted Режим Enforcing Имя узла localhost.localdomain Платформа Linux localhost.localdomain 6.6.51-1.red80.x86_64 #1 SMP PREEMPT_DYNAMIC Sun Sep 15 22:29:03 MSK 2024 x86_64 x86_64 Счетчик уведомлений 1 Впервые обнаружено 2025-02-26 15:47:15 MSK В последний раз 2025-02-26 15:47:15 MSK Локальный ID ff01d332-18c4-4450-b0f5-97a69665b5db Построчный вывод сообщений аудита type=AVC msg=audit(1740574035.94:289): avc: denied { watch } for pid=1387 comm="gmain" path="/run/mount" dev="tmpfs" ino=154 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:mount_var_run_t:s0 tclass=dir permissive=0 Hash: gmain,xdm_t,mount_var_run_t,dir,watch
Утилита audit2allow создает разрешительные правила политики SELinux из файлов журналов, содержащих сообщения о запрете операций. Эта утилита сканирует журналы в поиске сообщений, появляющихся, когда система не дает разрешения на операцию. Далее утилита генерирует ряд правил, которые, будучи загруженными в политику, могли бы разрешить эти операции.
Однако, данная утилита генерирует только разрешительные правила. Некоторые отказы в использовании разрешений могут потребовать других изменений политики. Например, добавление атрибута в определение типа, для разрешения существующего ограничения, добавления разрешительного правила для роли или модификации ограничения. В случае сомнений для диагностики можно попробовать использовать утилиту audit2why.
Следует с осторожностью работать с выводом данной утилиты, убедившись, что разрешаемые операции не представляют угрозы безопасности. Обычно бывает лучше определить новый домен/тип или произвести другие структурные изменения. Лучше избирательно разрешить оптимальный набор операций вместо того, чтобы вслепую применить иногда слишком широкие разрешения, рекомендованные этой утилитой. Некоторые запреты на использование разрешений бывают не принципиальны для приложения. В таких случаях вместо использования разрешительного правила («allow» rule) лучше просто подавить журналирование этих запретов при помощи правила «dontaudit».
audit2allow [опции]
-a
--all
--dmesg
/bin/dmesg
ausearch -m avc | audit2allow
-f
--fcfile <File Context File>
-M
-h
-i <inputfile>
--input <inputfile>
-l
--lastreload
-m <modulename>
--module <modulename>
-M <modulename>
-o
-o <outputfile>
--output <outputfile>
--requires
-R
--reference
-t
--tefile
-v
--verbose
Следующий пример подходит для системы, использующей пакет audit. Если не используется пакет audit, сообщения AVC будут появляться в /var/log/messages. В этом случае замените /var/log/audit/audit.log, используемый в примере, на /var/log/messages. Использование audit2allow для генерации монолитной (не модульной) политики.
Для вывода типа политики выполните команду:
cat /etc/selinux/config | grep SELINUXTYPE# SELINUXTYPE= can take one of these three values: SELINUXTYPE=targeted
Создайте папку:
mkdir -p /etc/selinux/targeted/src/policy/domains/misc/
Перейти в директорию политики:
cd /etc/selinux/targeted/src/policy
Скопируйте правила из лога аудита и добавьте их в файл local.te:
cat /var/log/audit/audit.log | audit2allow >> domains/misc/local.te
Посмотрите domains/misc/local.te и измените его:
nano domains/misc/local.te
Пример содержимого файла:
policy_module(local, 1.0) require { type cupsd_config_t; type unconfined_t; attribute file_type; } type fifo_file; typeattribute fifo_file file_type; allow cupsd_config_t unconfined_t:fifo_file { getattr ioctl };
Создайте Makefile:
cd /etc/selinux/targeted/src/policy/domains/misc nano Makefile
NAME = local include /usr/share/selinux/devel/Makefile
Загрузите политику:
make load
Выполните проверку, что политика local отображается в списке загруженных:
semodule -l | grep -w local local
cat /var/log/audit/audit.log | audit2allow -m locals > locals.te
Посмотрите locals.te и измените его:
locals.te
module locals 1.0; require { role system_r; class fifo_file { getattr ioctl }; type cupsd_config_t; type unconfined_t;}; allow cupsd_config_t unconfined_t:fifo_file { getattr ioctl };
Скомпилируйте модуль:
checkmodule -M -m -o locals.mod locals.te
Создайте пакет:
semodule_package -o locals.pp -m locals.mod
Для загрузки пакета политики в ядро необходимо выполнить команду:
semodule -i locals.pp
Выполните проверку, что политика locals отображается в списке загруженных:
locals
semodule -l | grep -w locals locals
Создайте модуль политики:
cat /var/log/audit/audit.log | audit2allow -M testlocal
Ожидаемый вывод по команде:
********************* ВАЖНО ************************ Чтобы сделать этот пакет политики активным, выполните: semodule -i testlocal.pp
Загрузите созданный модуль:
semodule -i testlocal.pp
Проверьте, что модуль в списке загруженных:
semodule -l | grep -w testlocaltestlocal
В большинстве случаев рекомендации, предоставляемые инструментом sealert дают точные указания по исправлению проблем, связанных с политикой SELinux.
Будьте осторожны при использовании инструмента audit2allow, который предназначен для изменения конфигурации SELinux. Не следует использовать audit2allow для генерации модуля локальной политики в качестве первого варианта после обнаружения отказа SELinux. Устранение неполадок следует начинать с проверки, нет ли проблем с маркировкой файлов и процессов. Второй наиболее частый случай — вы изменили конфигурацию процесса и забыли сообщить об этом SELinux.
audit2allow
Выявить неправильную маркировку бывает сложно. Одно дело, когда процесс работает в корректном домене, но ему отказано в доступе к файлам с неправильным типом. Другое дело, когда сам процесс работает в неверном домене. Такое случается когда исполняемый файл имеет неправильную маркировку, и после запуска сервиса процесс получает контекст, унаследованный от процесса, который его запустил. Например, если systemd в домене init_t запускает исполняемый файл, перемещённый из домашней директории, с типом user_home_t, это приведет к неверной маркировке и проблемам с доступом.
init_t
user_home_t
Распространенной причиной проблем с маркировкой является использование нестандартных каталогов для службы. Например, вместо использования /var/www/html/ для веб-сайта администратор может выбрать /srv/myweb/. Каталог /srv помечается типом var_t. Все файлы и каталоги, созданные в /srv наследуют этот тип. Кроме того, вновь созданные объекты в каталогах верхнего уровня, таких как /myserver, могут быть помечены типом default_t. SELinux не позволяет Apache HTTP Server (httpd) получать доступ к этим типам, поскольку по умолчанию не разрешает доступ к каталогам с типами, отличными от ожидаемых. Чтобы разрешить доступ, необходимо настроить SELinux, указав, что файлы в /srv/myweb/ должны быть доступны для httpd:
var_t
default_t
sudo semanage fcontext -a -t httpd_sys_content_t "/srv/myweb(/.*)?"
Эта команда добавляет контекст для /srv/myweb/ каталога и всех файлов и каталогов в нем в конфигурацию файлового контекста SELinux. Утилита semanage не изменяет контекст. Для применения изменений используйте утилиту restorecon:
sudo restorecon -R -v /srv/myweb
Утилита matchpathcon проверяет контекст пути к файлу и сравнивает его с меткой по умолчанию для этого пути. Следующий пример демонстрирует использование matchpathcon в каталоге, содержащем неправильно помеченные файлы:
matchpathcon -V /var/www/html/* /var/www/html/index.html имеет контекст unconfined_u:object_r:user_home_t:s0, должен быть system_u:object_r:httpd_sys_content_t:s0 /var/www/html/page1.html имеет контекст unconfined_u:object_r:user_home_t:s0, должен быть system_u:object_r:httpd_sys_content_t:s0
В этом примере файлы index.html и page1.html помечены типом user_home_t, который используется для файлов в домашних каталогах пользователей. Использование команды mv для перемещения файлов из домашнего каталога может привести к тому, что файлы будут помечены типом user_home_t. Этот тип не должен существовать за пределами домашних каталогов. Используйте утилиту restorecon для восстановления таких файлов до их правильного типа:
mv
sudo restorecon -v /var/www/html/index.html restorecon reset /var/www/html/index.html контекст unconfined_u:object_r:user_home_t:s0->system_u:object_r:httpd_sys_content_t:s0
Чтобы восстановить контекст для всех файлов в каталоге, используйте опцию -R:
sudo restorecon -R -v /var/www/html/ restorecon reset /var/www/html/page1.html контекст unconfined_u:object_r:samba_share_t:s0->system_u:object_r:httpd_sys_content_t:s0 restorecon reset /var/www/html/index.html контекст unconfined_u:object_r:samba_share_t:s0->system_u:object_r:httpd_sys_content_t:s0
Утилита secon отображает контекст безопасности для указанного файла, процесса, пользовательского ввода или собственного контекста запуска.
secon [-hVurtscmPRfLp] [CONTEXT] [--file] FILE [--link] FILE [--pid] PID
Опции:
-V
--version
-P
--prompt
-u
--user
--role
--type
-s
--sensitivity
-c
--clearance
-m
--mls-range
--raw
--file
-L
--link
-p
--pid
--pid-exec
--pid-fs
--current
--self
--current-exec
--self-exec
--current-fs
--self-fs
--parent
--parent-exec
--parent-fs
Если не было задано опций, то для того, чтобы secon получил контекст из другого источника, может быть задан дополнительный аргумент CONTEXT. Если этим аргументом является знак дефиса (-), то контекст будет прочитан из стандартного ввода. Если аргументы не заданы, secon читает контекст из стандартного ввода, но только в том случае, если stdin не является терминалом. В этом случае secon будет вести себя как будто была передана опция --self .
CONTEXT
-
Если не задана ни одна из опций: --user, --role, --type, --level или --mls-range, то все они будут использованы.
--level
Дата последнего изменения: 21.10.2025
Если вы нашли ошибку, пожалуйста, выделите текст и нажмите Ctrl+Enter.
Нажимая «Отправить запрос», вы соглашаетесь с условиями обработки персональных данных.
Вы будете получать только актуальную информацию по обновлению безопасности
Подписываясь на уведомления, вы соглашаетесь с условиями обработки персональных данных.
На ваш почтовый адрес отправлено письмо с подтверждением подписки.