Le processus d'initialisation a des autorisations presque illimitées et utilise des scripts d'entrée les partitions système et du fournisseur pour initialiser le système au démarrage processus. Cet accès provoque une énorme faille dans la répartition système/fournisseur Treble, car les scripts de fournisseur peuvent demander à init d'accéder aux fichiers, propriétés, etc. qui n'ont pas font partie de l'interface binaire d'application (ABI) stable du fournisseur et du système.
L'initialisation fournisseur est conçue pour fermer ce trou à l'aide d'un fichier
Le domaine Linux (SELinux) avec sécurité renforcée vendor_init doit s'exécuter
disponibles dans /vendor avec des autorisations spécifiques au fournisseur.
Mécanisme
L'initialisation du fournisseur duplique un sous-processus d'initialisation au début du processus de démarrage avec
Contexte SELinux u:r:vendor_init:s0. Ce contexte SELinux possède
beaucoup moins d'autorisations que le contexte init par défaut,
limités aux fichiers, propriétés, etc., qui sont spécifiques au fournisseur ou qui font partie
l'ABI stable système-fournisseur.
Init vérifie chaque script chargé pour voir si son chemin commence par
/vendor et, le cas échéant, lui ajoute un tag indiquant que ses commandes
doit être exécuté dans le contexte init du fournisseur. Chaque init intégré est annoté avec
Booléen spécifiant si la commande doit être exécutée dans l'initialisation du fournisseur
sous-processus:
- La plupart des commandes qui accèdent au système de fichiers sont annotées pour s'exécuter dans le fournisseur init et sont donc soumis à la règle SEPolicy "provider init".
- La plupart des commandes ayant une incidence sur l'état d'initialisation interne (par exemple, le démarrage et l'arrêt services) sont exécutés dans le cadre du processus init normal. Ces commandes sont créées qu'un script de fournisseur les appelle pour effectuer leurs propres opérations gestion des autorisations.
La boucle de traitement principale d'init vérifie que si une commande est annotée à s'exécuter dans le sous-processus du fournisseur et provient d'un script du fournisseur, qui est envoyée via la communication inter-processus (IPC) à la commande subprocess, qui exécute la commande et renvoie le résultat à init.
Utiliser l'Init fournisseur
L'initialisation du fournisseur est activée par défaut et ses restrictions s'appliquent à tous les scripts d'initialisation
présentes dans la partition /vendor. L'initialisation du fournisseur doit être transparente.
aux fournisseurs dont les scripts n'accèdent
déjà pas aux fichiers uniquement système,
propriétés, etc.
Toutefois, si les commandes d'un script de fournisseur donné enfreignent la commande init du fournisseur restrictions, les commandes échoueront. Les commandes ayant échoué ont une ligne dans le noyau log (visible avec dmesg) depuis init, indiquant un échec. Un audit SELinux accompagne toute commande défaillante qui a échoué en raison de la règle SELinux. Exemple d'une défaillance, y compris un audit 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
Si une commande échoue, deux options s'offrent à vous:
- Si la commande échoue en raison d'une restriction prévue (par exemple, si le accède à un fichier système ou à une propriété), elle doit être ré-implémentée de manière à être adaptée aux aigus, en passant par des interfaces uniquement stables. Les règles "Jamais autoriser" empêchent l'ajout d'autorisations permettant d'accéder aux fichiers système qui ne sont pas de l'ABI stable système-fournisseur.
- Si l'étiquette SELinux est nouvelle et qu'aucune autorisation ne lui a été accordée dans
le
vendor_init.tesystème ni les autorisations exclues via la des autorisations, le nouveau libellé peut se voir accorder des autorisations dans la sectionvendor_init.te
Pour les appareils dont le lancement est antérieur à Android 9, il est possible de contourner ces règles
en ajoutant le typeattribute data_between_core_and_vendor_violators à
le fichier vendor_init.te spécifique à l'appareil.
Emplacements du code
L'essentiel de la logique de l'IPC d'initialisation du fournisseur se trouve dans system/core/init/subcontext.cpp.
Le tableau des commandes se trouve dans la classe BuiltinFunctionMap du répertoire system/core/init/builtins.cpp.
et inclut des annotations indiquant si la commande doit être exécutée dans le répertoire
init.
Le SEPolicy de l'initialisation du fournisseur est réparti entre le serveur privé (system/sepolicy/private/vendor_init.te). et public (system/sepolicy/public/vendor_init.te) dans le répertoire system/sepolicy.