Инициализация поставщика

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

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

Механизм

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

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

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

Основной цикл обработки init содержит проверку того, что если команда аннотирована для запуска в подпроцессе поставщика и исходит из сценария поставщика, эта команда отправляется через межпроцессное взаимодействие (IPC) в подпроцесс инициализации поставщика, который запускает команду и отправляет результат обратно в 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

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

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

Для устройств, выпущенных до Android 9, правила neverallows можно обойти, добавив атрибут типа data_between_core_and_vendor_violators в специфичный для устройства файл vendor_init.te .

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

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

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

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