Строка sepolicy extends в логе модуля Magisk или в файле sepolicy.rule означает, что модуль дополняет существующую политику SELinux новыми разрешениями, не перезаписывая базовые правила системы. Если вы увидели такое сообщение при установке модуля, при сборке кастомной прошивки или в выводе журнала загрузки — это не ошибка, а техническое описание механизма: правила добавляются «поверх» заводской политики, чтобы рут-приложения и модификации могли получить доступ к нужным ресурсам. Понимание этого механизма важно, потому что именно через расширение sepolicy работает большинство модулей Magisk, и именно здесь кроются риски ослабления защиты устройства.
В этой статье разберём, что такое sepolicy и SELinux в контексте Android, как устроен механизм расширения политик, где встречаются файлы правил, чем опасны неосторожные разрешения и как проверить, какие именно правила добавил тот или иной модуль.
Что такое SELinux и sepolicy в Android
SELinux (Security-Enhanced Linux) — это система принудительного контроля доступа, встроенная в ядро Linux и обязательная в Android начиная с ранних версий платформы. В отличие от привычных разрешений Unix (владелец, группа, права на чтение и запись), SELinux решает, какой процесс к какому объекту может обращаться, на основе меток безопасности и набора правил.
Этот набор правил и называется sepolicy — политика безопасности. Она описывает тысячи утверждений вида «процессу с меткой X разрешено читать файл с меткой Y». Политика компилируется в бинарный формат и загружается ядром при старте системы. Без корректной sepolicy Android просто не загрузится: системные службы не смогут получить доступ даже к собственным файлам.
SELinux в Android работает в двух режимах:
- 🔒 Enforcing — нарушения правил блокируются и записываются в лог (стандартный режим для релизных прошивок);
- ⚠️ Permissive — нарушения только фиксируются в журнале, но не блокируются (используется при отладке, снижает защиту);
- 🛠️ Промежуточные состояния вроде частично permissive-доменов встречаются на некоторых кастомных сборках, что тоже ослабляет безопасность.
Что означает «extends» применительно к sepolicy
Фраза sepolicy extends описывает принцип инкрементального дополнения политики. Вместо того чтобы пересобирать и заменять всю sepolicy целиком (что требовало бы перепаковки разделов и легко ломало бы систему), механизм расширения добавляет отдельные правила в уже загруженную политику.
Технически это реализовано через специальные команды языка политик, которые внедряются на раннем этапе загрузки. В экосистеме Magisk, например, правила из файла sepolicy.rule внутри модуля применяются до старта системных служб — так модификации успевают получить нужные доступы ещё до того, как SELinux начнёт их блокировать.
Важно понимать разницу двух подходов:
- ➕ Расширение (extends) — добавление отдельных allow-правил к работающей политике; обратимо, применяется на лету при загрузке;
- ♻️ Замена политики — полная пересборка и подмена файла sepolicy; рискованно, требует модификации разделов и может привести к bootloop;
- 🧩 Магические «живые» патчи — изменение политики в памяти без перезагрузки; используется редко и требует глубокого понимания формата.
Где встречаются расширения sepolicy на практике
Чаще всего с механизмом расширения sepolicy пользователь сталкивается в трёх сценариях. Первый — установка модулей Magisk: многие из них содержат файл sepolicy.rule, и строки из него добавляются в политику при каждой загрузке. Если модуль не работает, а в логах видны отказы доступа (denial), причина может быть именно в отсутствующем или некорректном правиле.
Второй сценарий — разработка кастомных прошивок и ядер. Сборщики ROM дополняют базовую политику AOSP правилами под конкретное железо и фирменные сервисы. Третий — отладка: разработчики анализируют сообщения avc: denied в журнале и добавляют недостающие разрешения.
Посмотреть отказы SELinux можно через журнал ядра или logcat. Типичная команда для поиска отказов выглядит так:
adb shell dmesg | grep avc
adb logcat -b events | grep avc
Каждая строка отказа содержит метку процесса (scontext), метку объекта (tcontext) и класс объекта с действием — именно из этих данных конструируется недостающее правило.
Как модуль добавляет правила: общий принцип
Рассмотрим типовую механику на примере модулей Magisk, поскольку это самый распространённый случай. Точное поведение зависит от версии Magisk и конкретного модуля, поэтому детали всегда стоит сверять с документацией используемой версии.
Модуль — это архив с файлами, среди которых может находиться sepolicy.rule. Каждая непустая строка этого файла — отдельное правило на языке политик. Во время загрузки менеджер рут-доступа читает эти файлы из всех активных модулей и внедряет правила в политику до запуска системы.
☑️ Проверка правил sepolicy модуля
Упрощённый пример правила, разрешающего процессу с меткой my_daemon чтение файлов с меткой system_file:
allow my_daemon system_file:file read;Обратите внимание: правило всегда конкретно. Оно указывает источник, цель, класс объекта и набор операций. Правила вида «разрешить всё всем» технически возможны, но являются признаком небрежной или вредоносной модификации.
Риски расширения sepolicy и безопасность
Каждое добавленное allow-правило — это сознательное ослабление модели безопасности. Заводская политика проходит аудит производителя и Google, а правила из стороннего модуля — нет. Поэтому к расширениям sepolicy стоит относиться так же внимательно, как к выдаче рут-доступа приложению.
⚠️ Внимание: модуль с чрезмерно широкими правилами sepolicy фактически открывает обходной путь вокруг всей защиты SELinux. Вредоносный модуль может разрешить себе чтение данных других приложений, и система не будет этому препятствовать — ведь правило явно это разрешает.
Основные риски, которые стоит учитывать:
- 🕳️ Широкие allow-правила — разрешения целым доменам вместо точечных доступов;
- 🐛 Синтаксические ошибки в правилах — в худшем случае могут привести к сбоям загрузки;
- 🔓 Перевод доменов в permissive — некоторые модули «решают» проблему отказов, отключая контроль для целых подсистем;
- 🎭 Скрытые правила в закрытых модулях, содержимое которых пользователь не проверяет.
⚠️ Внимание: не копируйте готовые наборы правил sepolicy с форумов, не понимая, что каждое из них делает. Правило, безобидное на одном устройстве и версии Android, на другой может открыть уязвимость или сломать загрузку.
Почему нельзя просто перевести SELinux в permissive
Режим permissive отключает блокировку нарушений для всей системы, а не для одного приложения. Это снимает защиту со всех процессов сразу, включая системные. Кроме того, на многих устройствах permissive-режим детектируется банковскими приложениями и сервисами проверки целостности. Точечное расширение sepolicy — более безопасная альтернатива, поскольку ослабляет защиту только в строго заданной точке.
Сравнение подходов к изменению политики
Чтобы выбрать осознанный подход, полезно видеть различия между способами модификации sepolicy. Таблица ниже обобщает их ключевые свойства.
| Подход | Обратимость | Риск bootloop | Типичное применение |
|---|---|---|---|
| Расширение через модуль (sepolicy.rule) | Высокая — удалением модуля | Низкий | Модули Magisk, твики |
| Пересборка и замена файла sepolicy | Низкая — нужен бэкап раздела | Высокий | Разработка кастомных прошивок |
| Перевод SELinux в permissive | Средняя — правкой параметров загрузки | Средний | Отладка, не рекомендуется для постоянного использования |
| Точечное правило по данным avc-лога | Высокая | Низкий | Исправление конкретного отказа доступа |
Из сравнения видно, почему механизм extends стал стандартом в экосистеме рут-модификаций: он сочетает гибкость с обратимостью. Удалил модуль — перезагрузился — и политика вернулась к заводскому состоянию.
Как проверить, какие правила добавлены на устройстве
Для аудита текущего состояния политики есть несколько проверяемых шагов. Сначала посмотрите содержимое файлов sepolicy.rule в каталогах установленных модулей — обычно они доступны через файловый менеджер с рут-доступом в папке модулей Magisk. Каждая строка там — правило, которое будет применено при следующей загрузке.
Далее проверьте текущий режим SELinux:
adb shell getenforceОтвет Enforcing означает штатную работу защиты. Ответ Permissive на релизной прошивке — повод выяснить, какой модуль или модификация его изменила.
Наконец, проанализируйте свежие отказы доступа после действий, которые не работают. Если проблемная функция модуля порождает строки avc: denied, значит, правило либо отсутствует, либо не применилось — например, из-за синтаксической ошибки в файле. В таком случае разумный путь — сообщить разработчику модуля с приложением фрагмента лога, а не добавлять широкие разрешения самостоятельно.
FAQ: частые вопросы о sepolicy extends
Что значит «sepolicy extends» в логе при загрузке?
Это техническое сообщение о том, что к базовой политике SELinux добавляются дополнительные правила — обычно из установленных модулей. Само по себе это не ошибка и не признак проблемы.
Опасно ли расширять sepolicy?
Риск зависит от содержимого правил. Точечные разрешения от проверенных модулей — обычная практика. Широкие правила, permissive-домены и правила из неизвестных источников ослабляют защиту устройства и могут открыть уязвимости.
Как отменить расширение sepolicy?
Если правила добавлены модулем Magisk, достаточно удалить или отключить модуль и перезагрузить устройство — политика вернётся к заводскому состоянию. Если политика была заменена перепаковкой раздела, потребуется восстановление из резервной копии или прошивка стокового образа.
Что делать, если модуль не работает и в логах avc: denied?
Зафиксируйте строки отказа через dmesg или logcat, проверьте наличие соответствующего правила в файле sepolicy.rule модуля и передайте лог разработчику модуля. Самостоятельно добавляйте только те правила, смысл которых полностью понимаете.
Чем extends отличается от permissive-режима?
Extends добавляет конкретное разрешение в конкретной точке, сохраняя контроль над всем остальным. Permissive отключает блокировку нарушений для системы целиком. Первый подход точечный и предпочтительный, второй — отладочный и небезопасный для постоянного использования.