Записи вида avc: denied { read } в системном журнале означают, что SELinux заблокировал попытку процесса выполнить действие, не разрешённое текущей политикой безопасности. Совокупность таких записей и называют списком блокировки AVC (Access Vector Cache) — это не отдельный файл, а поток сообщений аудита, которые ядро генерирует при каждом отказе доступа. Понимание структуры этих сообщений — первый шаг к тому, чтобы устранить проблему, не ослабляя защиту системы.
Типичная ситуация: после установки собственного сервиса, переноса приложения или обновления системы программа перестаёт запускаться, хотя права на файлы выставлены корректно. Причина почти всегда видна именно в журнале AVC — там зафиксировано, какой процесс, к какому объекту и с каким действием был остановлен. В этой статье разберём, как читать такие записи, где их искать и как безопасно добавить разрешающее правило.
Что такое AVC и почему появляются отказы
Access Vector Cache — это кэш решений о доступе внутри механизма SELinux. Когда процесс запрашивает операцию над объектом (файлом, сокетом, другим процессом), подсистема безопасности проверяет политику и кэширует результат. Если доступ запрещён, в журнал аудита попадает сообщение avc: denied с подробным описанием инцидента.
Отказ не обязательно означает атаку. Частые легитимные причины:
- 🛠️ приложение обращается к файлу с неверным контекстом безопасности после копирования или распаковки;
- 📦 собственный сервис запускается в домене, которому политика не разрешает нужные операции;
- 🔄 обновление политики изменило правила, и ранее работавший сценарий стал блокироваться;
- 📁 файл создан в нестандартном расположении, для которого нет правила file_contexts.
Где искать список блокировок AVC
На системах с auditd отказы пишутся в /var/log/audit/audit.log. Если служба аудита не установлена, сообщения попадают в общий системный журнал — их можно посмотреть через journalctl или классический dmesg. На Android отказы SELinux видны в выводе logcat и буфере ядра.
Быстрый фильтр по отказам за текущую загрузку:
sudo ausearch -m avc -ts recentЕсли утилита ausearch отсутствует, установите пакет аудита вашего дистрибутива либо используйте sudo grep "avc" /var/log/audit/audit.log. Точные пути и названия пакетов зависят от дистрибутива — сверяйтесь с его документацией.
⚠️ Внимание: не переводите SELinux в режим permissive на постоянной основе ради «тихого» журнала. Это отключает принудительную защиту для всей системы, а не только для проблемного сервиса.
Как читать запись avc: denied
Каждая строка отказа содержит набор полей, которые раскрывают суть инцидента. Ключевые из них приведены в таблице.
| Поле | Значение | На что указывает |
|---|---|---|
| scontext | Контекст источника (процесса) | Домен, из которого выполнялось действие |
| tcontext | Контекст цели (объекта) | Тип файла, порта или ресурса |
| tclass | Класс объекта | file, dir, tcp_socket, process и т.д. |
| { action } | Запрошенное действие | read, write, execute, name_bind и др. |
| comm / exe | Имя исполняемого файла | Какая программа вызвала отказ |
Логика разбора проста: смотрите, кто (scontext) пытался что сделать (действие) с чем (tcontext + tclass). Например, если веб-сервер в домене httpd_t получил отказ { read } к файлу с типом user_home_t, это почти наверняка значит, что контент размещён в домашнем каталоге, куда политика веб-сервера доступа не даёт.
Диагностика: от симптома к причине
Прежде чем что-то менять, воспроизведите ошибку и сразу проверьте журнал — так вы увидите свежие отказы, относящиеся именно к вашему сценарию. Дальше действуйте по чек-листу.
☑️ Диагностика отказа AVC
Отдельно проверьте контексты файлов командой ls -Z на проблемном пути. Большинство «загадочных» отказов решается не новым модулем политики, а восстановлением правильного контекста — например, через restorecon -Rv /путь/к/каталогу, если расположение стандартное и для него есть правило разметки.
Безопасные способы устранения отказов
Порядок действий — от наименее инвазивного к более сложному:
- 🔧 Восстановление контекста —
restoreconна файлы, если они находятся в стандартном месте; - 🏷️ Назначение типа —
semanage fcontextплюсrestorecon, если приложение живёт в нестандартном каталоге; - 🎚️ Булевы переключатели —
setsebool, если нужная возможность уже предусмотрена политикой (список смотрите черезgetsebool -a); - 🧩 Локальный модуль политики — генерация через
audit2allow, когда ничего из перечисленного не подходит.
Типовой конвейер для создания минимального модуля выглядит так:
sudo ausearch -m avc -ts recent | audit2allow -M myservice
sudo semodule -i myservice.pp
⚠️ Внимание: никогда не применяйте audit2allow «в лоб» по всему журналу. Утилита превратит в разрешения вообще все найденные отказы, включая потенциально вредоносные. Фильтруйте вывод по конкретному сервису и вручную просматривайте сгенерированные правила перед установкой.
AVC на Android: особенности
На устройствах Android SELinux работает в enforcing-режиме, и отказы avc: denied видны в logcat и буфере dmesg. Чаще всего с ними сталкиваются разработчики прошивок и авторы модулей, когда системный компонент или модификация пытается обратиться к ресурсу вне разрешённой политики.
Здесь принцип тот же: найти запись, определить scontext, tcontext и действие, затем добавить правило в файлы политики (.te) при сборке. Однако на пользовательском устройстве без root и пересборки образа изменить политику нельзя — и это осознанное ограничение безопасности платформы. Если отказы вызывает стороннее приложение, правильный путь — сообщить разработчику, а не пытаться ослабить защиту устройства.
Что означает scontext=...
u:r:untrusted_app:s0:Это типичный домен обычного Android-приложения. Если отказ возникает у такого источника, приложение пытается выполнить действие, запрещённое платформой для обычных программ. Обойти это без изменения системы нельзя — и не нужно: ограничение защищает данные других приложений.
Типичные ошибки при работе с отказами
Первая и самая распространённая — глобальный перевод системы в permissive вместо точечного решения. Вторая — массовая генерация правил через audit2allow без анализа: так в политику попадают разрешения, фактически обнуляющие защиту для отдельных доменов.
Третья ошибка — игнорирование булевых переключателей. Нередко нужная возможность уже предусмотрена поставщиком политики, и вместо написания модуля достаточно одной команды setsebool -P с подходящим флагом. Перечень доступных переключателей и их назначение зависят от дистрибутива — описания смотрите в документации вашей системы.
Часто задаваемые вопросы
Опасны ли записи avc: denied сами по себе?
Нет, это лишь журнальные сообщения о заблокированных действиях. Они сигнализируют либо о неверной конфигурации, либо о реальной попытке несанкционированного доступа — в обоих случаях SELinux уже выполнил свою работу и остановил операцию.
Можно ли просто отключить SELinux?
Технически можно, но делать этого не следует: вы лишаетесь слоя принудительного контроля доступа, который сдерживает компрометацию сервисов. Правильный подход — разобрать конкретный отказ и добавить точечное разрешение.
Почему restorecon не помогает?
Возможные причины: файл находится в нестандартном расположении, для которого нет правила разметки, либо контекст зафиксирован вручную. Проверьте ожидаемый контекст через matchpathcon и при необходимости добавьте правило через semanage fcontext.
Чем permissive-домен отличается от permissive-режима всей системы?
Командой semanage permissive -a домен_t можно ослабить контроль только для одного домена: его отказы будут журналироваться, но не блокироваться, тогда как остальная система останется под защитой. Это приемлемый временный инструмент диагностики.
Как понять, что добавленное правило избыточно?
Сравните сгенерированные audit2allow разрешения с реальными действиями приложения. Если программе нужно только чтение конфигурации, а правило разрешает запись и исполнение — сократите его вручную до фактически необходимых операций.