Google is committed to advancing racial equity for Black communities. See how.
Эта страница была переведа с помощью Cloud Translation API.
Switch to English

Написание политики SELinux

Android Open Source Project (AOSP) предоставляет прочную базовую политику для приложений и сервисов, которые являются общими для всех устройств Android. Авторы AOSP регулярно уточняют эту политику. Ожидается, что основная политика будет составлять около 90–95% окончательной политики на устройстве, а настройки для конкретных устройств - оставшиеся 5–10%. В этой статье основное внимание уделяется настройкам для конкретных устройств, способам написания политики для конкретных устройств и некоторым подводным камням, которых следует избегать в процессе.

Запуск устройства

При написании политики для конкретного устройства выполните следующие действия.

Запустить в разрешающем режиме

Когда устройство находится в разрешающем режиме , отказы регистрируются, но не применяются. Разрешающий режим важен по двум причинам:

  • Разрешающий режим гарантирует, что активация политики не задерживает выполнение других задач раннего запуска устройства.
  • Принудительный отказ может скрыть другие отрицания. Например, доступ к файлу обычно влечет за собой поиск в каталоге, открытие файла, а затем чтение файла. В принудительном режиме произойдет только отказ в поиске в каталоге. Разрешающий режим гарантирует, что все отказы будут видны.

Самый простой способ перевести устройство в разрешающий режим - использовать командную строку ядра . Его можно добавить в файл BoardConfig.mk устройства: platform/device/<vendor>/<target>/BoardConfig.mk . После изменения командной строки выполните команду make clean , затем make bootimage и make bootimage новый загрузочный образ.

После этого подтвердите разрешающий режим с помощью:

adb shell getenforce

Две недели - разумное время, чтобы перейти в глобальный разрешительный режим. После устранения большинства отказов вернитесь в принудительный режим и устраняйте ошибки по мере их появления. Домены, все еще производящие отказы, или услуги, все еще находящиеся в стадии интенсивной разработки, могут быть временно переведены в разрешающий режим, но как можно скорее перевести их обратно в принудительный режим.

Применить рано

В принудительном режиме отказы регистрируются и принудительно. Лучше всего перевести устройство в принудительный режим как можно раньше. Ожидание создания и применения политики для конкретного устройства часто приводит к ошибкам в продукте и неудобствам для пользователей. Начните достаточно рано, чтобы принять участие в тестировании и обеспечить полное тестирование функциональности в реальных условиях. Ранний запуск гарантирует, что проблемы безопасности влияют на проектные решения. И наоборот, предоставление разрешений исключительно на основании наблюдаемых отказов - небезопасный подход. Используйте это время, чтобы выполнить аудит безопасности устройства и выявить ошибки, которые нельзя допускать.

Удалить или удалить существующую политику

Существует ряд веских причин для создания политики для конкретного устройства с нуля на новом устройстве, в том числе:

Решайте отказы в предоставлении основных услуг

Отказы, генерируемые базовыми службами, обычно решаются с помощью маркировки файлов. Например:

avc: denied { open } for pid=1003 comm=”mediaserver” path="/dev/kgsl-3d0”
dev="tmpfs" scontext=u:r:mediaserver:s0 tcontext=u:object_r:device:s0
tclass=chr_file permissive=1
avc: denied { read write } for pid=1003 name="kgsl-3d0" dev="tmpfs"
scontext=u:r:mediaserver:s0
tcontext=u:object_r:device:s0 tclass=chr_file permissive=1

полностью устраняется путем правильной маркировки /dev/kgsl-3d0 . В этом примере tcontext - это device . Это представляет собой контекст по умолчанию, где все в /dev получает метку « устройство », если не назначена более конкретная метка. Простое принятие вывода audit2allow здесь приведет к неправильному и чрезмерно разрешающему правилу.

Чтобы решить эту проблему, присвойте файлу более конкретную метку, в данном случае это gpu_device . Никаких дополнительных разрешений не требуется, так как mediaserver уже имеет необходимые разрешения в основной политике для доступа к gpu_device.

Другие файлы для конкретных устройств, которые должны быть помечены типами, предопределенными в основной политике:

В общем, предоставление разрешений ярлыкам по умолчанию неверно. Многие из этих разрешений запрещены непреодолимыми правилами, но даже если они не запрещены явно, лучше всего указать конкретную метку.

Обозначьте новые услуги и адреса отказов

Сервисы, запущенные Init, должны работать в собственных доменах SELinux. В следующем примере сервис «foo» помещается в собственный домен SELinux и предоставляет ему разрешения.

Сервис запускается в init. device .rc нашего устройства init. device .rc файл init. device .rc как:

service foo /system/bin/foo
    class core
  1. Создайте новый домен "foo"

    Создайте файл device/ manufacturer / device-name /sepolicy/foo.te со следующим содержимым:

    # foo service
    type foo, domain;
    type foo_exec, exec_type, file_type;
    
    init_daemon_domain(foo)
    

    Это исходный шаблон для домена SELinux foo, в который вы можете добавлять правила на основе определенных операций, выполняемых этим исполняемым файлом.

  2. Этикетка /system/bin/foo

    Добавьте следующее в device/ manufacturer / device-name /sepolicy/file_contexts :

    /system/bin/foo   u:object_r:foo_exec:s0
    

    Это гарантирует, что исполняемый файл правильно помечен, чтобы SELinux запускал службу в правильном домене.

  3. Соберите и запрограммируйте загрузочный и системный образы.
  4. Уточните правила SELinux для домена.

    Используйте отказы для определения необходимых разрешений. Инструмент audit2allow предоставляет хорошие инструкции, но использует его только для информирования при написании политики. Не копируйте просто вывод.

Вернуться в принудительный режим

Устранение неполадок в разрешающем режиме - это нормально, но как можно раньше переключитесь обратно в принудительный режим и постарайтесь остаться там.

Распространенные ошибки

Вот несколько решений для типичных ошибок, возникающих при написании политик для конкретных устройств.

Чрезмерное использование отрицания

Следующий пример правила аналогичен запиранию входной двери, но оставлению окон открытыми:

allow { domain -untrusted_app } scary_debug_device:chr_file rw_file_perms

Цель ясна: все, кроме сторонних приложений, могут иметь доступ к устройству отладки.

В правиле есть несколько недостатков. Исключение untrusted_app легко обойти, потому что все приложения могут опционально запускать службы в домене isolated_app . Аналогичным образом, если в AOSP будут добавлены новые домены для сторонних приложений, у них также будет доступ к scary_debug_device . Правило слишком снисходительно. Большинство доменов не получат доступа к этому инструменту отладки. Правило должно было быть написано так, чтобы разрешать только те домены, которым требуется доступ.

Возможности отладки в производстве

Функции отладки не должны присутствовать в производственных сборках, равно как и их политика.

Самая простая альтернатива - разрешить функцию отладки только тогда, когда SELinux отключен в сборках eng / userdebug, таких как adb root и adb shell setenforce 0 .

Другой безопасный вариант - заключить разрешения отладки в оператор userdebug_or_eng .

Взрыв размера политики

Описание политик SEAndroid в дикой природе описывает тревожную тенденцию роста настроек политик устройств. Политика для конкретного устройства должна составлять 5–10% от общей политики, выполняемой на устройстве. Настройки в диапазоне 20% + почти наверняка содержат избыточные привилегии и мертвую политику.

Излишне большой полис:

  • Двойное воздействие на память, так как политика находится на виртуальном диске, а также загружается в память ядра.
  • Пустая трата дискового пространства из-за необходимости увеличивать загрузку.
  • Влияет на время поиска политики времени выполнения.

В следующем примере показаны два устройства, на которых политика производителя составляет 50% и 40% политики устройства. Переписывание политики привело к существенным улучшениям безопасности без потери функциональности, как показано ниже. (Устройства AOSP Shamu и Flounder включены для сравнения.)

Рисунок 1: Сравнение размера политики для конкретного устройства после аудита безопасности.

Рисунок 1 . Сравнение размера политики для конкретного устройства после аудита безопасности.

В обоих случаях политика была значительно уменьшена как по размеру, так и по количеству разрешений. Уменьшение размера политики почти полностью связано с удалением ненужных разрешений, многие из которых, вероятно, были правилами, созданными с помощью audit2allow которые были без разбора добавлены в политику. Мертвые домены также были проблемой для обоих устройств.

Предоставление возможности dac_override

Отказ dac_override означает, что нарушающий процесс пытается получить доступ к файлу с неправильными разрешениями пользователя / группы / мира unix. Правильное решение - почти никогда не предоставлять разрешение dac_override . Вместо этого измените разрешения unix для файла или процесса . Некоторым доменам, таким как init , vold и installd действительно нужна возможность переопределения разрешений файлов unix для доступа к файлам других процессов. См . Блог Дэна Уолша для более подробного объяснения.