Процесс инициализации имеет почти неограниченные права и использует входные сценарии как из системного, так и из вендорного разделов для инициализации системы в процессе загрузки. Этот доступ создает огромную дыру в разделении системы и поставщика 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.