Google стремится продвигать расовую справедливость для черных сообществ. Смотри как.
Эта страница была переведа с помощью Cloud Translation API.
Switch to English

Vendor Init

Процесс init имеет практически неограниченные права доступа и использует входные сценарии из системных разделов и разделов поставщика для инициализации системы во время процесса загрузки. Этот доступ создает огромную дыру в разделении системы / поставщика на тройную, поскольку сценарии вендора могут указывать init для доступа к файлам, свойствам и т. Д., Которые не являются частью стабильного двоичного интерфейса приложения-системы-вендора (ABI).

Vendor init предназначен для того, чтобы закрыть эту дыру, используя отдельный домен Linux (SELinux) с повышенной безопасностью vendor_init для запуска команд, найденных в /vendor с разрешениями конкретного поставщика.

Механизм

Поставщик init запускает подпроцесс init в начале процесса загрузки с контекстом SELinux u:r:vendor_init:s0 . Этот контекст SELinux имеет значительно меньше разрешений, чем контекст инициализации по умолчанию, и его доступ ограничен файлами, свойствами и т. Д., Которые либо зависят от поставщика, либо являются частью ABI стабильной системы-поставщика.

Init проверяет каждый загружаемый скрипт, чтобы увидеть, начинается ли его путь с /vendor и, если это так, помечает его с указанием того, что его команды должны выполняться в контексте init поставщика. Каждая встроенная инициализация аннотируется логическим значением, которое указывает, должна ли команда выполняться в подпроцессе инициализации поставщика:

  • Большинство команд, обращающихся к файловой системе, аннотированы для запуска в подпроцессе init поставщика и поэтому подчиняются init SEPolicy вендора.
  • Большинство команд, влияющих на внутреннее состояние инициализации (например, запуск и остановка служб), выполняются в рамках обычного процесса инициализации. Эти команды учитывают, что скрипт поставщика вызывает их для обработки своих собственных разрешений, отличных от SELinux.

Основной цикл обработки init содержит проверку того, что если команда аннотирована для выполнения в подпроцессе поставщика и происходит из сценария поставщика, эта команда отправляется через межпроцессное взаимодействие (IPC) в подпроцесс инициатора поставщика, который выполняет команду и отправляет результат обратно в init.

Использование Vendor Init

По умолчанию Vendor init включен, и его ограничения распространяются на все скрипты инициализации, представленные в разделе /vendor . Инициирование поставщика должно быть прозрачным для поставщиков, чьи сценарии уже не обращаются к системным файлам, свойствам и т. Д.

Однако, если команды в данном сценарии поставщика нарушают ограничения инициализации поставщика, команды завершатся неудачно. Неудачные команды имеют строку в журнале ядра (видимую с dmesg) от init, указывающую на сбой. Аудит SELinux сопровождает любую ошибочную команду, которая не удалась из-за политики SELinux. Пример сбоя, включая аудит SELinux:

type=1400 audit(1511821362.996:9): avc: denied { search } for pid=540 comm="init" name="nfc" dev="sda45" ino=1310721 scontext=u:r:vendor_init:s0 tcontext=u:object_r:nfc_data_file:s0 tclass=dir permissive=0
init: Command 'write /data/nfc/bad_file_access 1234' action=boot (/vendor/etc/init/hw/init.walleye.rc:422) took 2ms and failed: Unable to write to file '/data/nfc/bad_file_access': open() failed: Permission denied

Если команда не выполняется, есть два варианта:

  • Если команда не выполняется из-за предполагаемого ограничения (например, если команда обращается к системному файлу или свойству), команда должна быть повторно реализована дружественным способом, пропуская только стабильные интерфейсы. Правила Neverallow запрещают добавлять разрешения для доступа к системным файлам, которые не являются частью ABI стабильного системного поставщика.
  • Если метка SELinux является новой и ей еще не предоставлены разрешения в системе vendor_init.te а также не исключены разрешения с помощью правил neverallow, новой метке могут быть предоставлены разрешения в vendor_init.te от устройства vendor_init.te .

Для устройств, запускаемых до Android 9, правила обширных разрешений можно обойти, добавив data_between_core_and_vendor_violators data_between_core_and_vendor_violators в data_between_core_and_vendor_violators vendor_init.te для конкретного vendor_init.te .

Расположение кода

Основная часть логики IPC поставщика init находится в system / core / init / subcontext.cpp .

Таблица команд находится в классе BuiltinFunctionMap в system / core / init / builtins.cpp и содержит аннотации, указывающие, должна ли команда выполняться в подпроцессе init поставщика.

Инициирование SEPolicy for vendor разделяется на частные ( system / sepolicy / private / vendor_init.te ) и публичные ( system / sepolicy / public / vendor_init.te ) каталоги в system / sepolicy.