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

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

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

Механизм

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

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

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

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

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

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

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

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