Compatibilité avec les règles

Cette page explique comment Android gère les problèmes de compatibilité des règles avec les mises à jour de la plate-forme en direct (OTA), où les nouveaux paramètres SELinux de la plate-forme peuvent différer des anciens paramètres SELinux du fournisseur.

Propriété et étiquetage des objets

La propriété doit être clairement définie pour chaque objet afin de séparer les règles de la plate-forme et du fournisseur. Par exemple, si les libellés de règles du fournisseur sont /dev/foo et que les libellés de règles de la plate-forme sont /dev/foo dans une OTA ultérieure, le comportement est indéfini (par exemple, un refus inattendu ou, plus grave, un échec du démarrage). Pour SELinux, cela se manifeste par une collision d'étiquettes. Le nœud de l'appareil ne peut comporter qu'un seul libellé, qui correspond à celui appliqué en dernier. Par conséquent :

  • Les processus qui ont besoin d'accéder au libellé qui n'a pas été appliqué perdent l'accès à la ressource.
  • Les processus qui accèdent au fichier peuvent échouer, car le mauvais nœud de périphérique a été créé.

Des collisions entre les libellés de plate-forme et de fournisseur peuvent se produire pour tout objet comportant un libellé SELinux, y compris les propriétés, les services, les processus, les fichiers et les sockets. Pour éviter ces problèmes, définissez clairement la propriété de ces objets.

Espace de noms de type/attribut

En plus des conflits d'étiquettes, les noms de types et d'attributs SELinux peuvent également entrer en conflit. SELinux n'autorise pas les déclarations multiples des mêmes types et attributs. Une règle comportant des déclarations en double ne peut pas être compilée. Pour éviter les conflits de noms de types et d'attributs, il est fortement recommandé que toutes les déclarations de fournisseur commencent par le préfixe vendor_. Par exemple, les fournisseurs doivent utiliser type vendor_foo, domain; au lieu de type foo, domain;.

Propriété des fichiers

Il est difficile d'éviter les collisions pour les fichiers, car les règles de la plate-forme et du fournisseur fournissent généralement des libellés pour tous les systèmes de fichiers. Contrairement à la dénomination des types, l'utilisation d'espaces de noms pour les fichiers n'est pas pratique, car beaucoup d'entre eux sont créés par le noyau. Pour éviter ces collisions, suivez les consignes d'attribution de noms pour les systèmes de fichiers dans cette section. Pour Android 8.0, il s'agit de recommandations sans application technique. À l'avenir, ces recommandations seront appliquées par la Vendor Test Suite (VTS).

Système (/system)

Seule l'image système doit fournir des libellés pour les composants /system à file_contexts, service_contexts, etc. Si des libellés pour les composants /system sont ajoutés dans la règle du fournisseur, une mise à jour OTA réservée au framework peut ne pas être possible.

Fournisseur (/vendor)

La règle SELinux de l'AOSP étiquette déjà les parties de la partition vendor avec lesquelles la plate-forme interagit, ce qui permet d'écrire des règles SELinux pour que les processus de la plate-forme puissent communiquer avec certaines parties de la partition vendor ou y accéder. Exemples :

/vendor path Libellé fourni par la plate-forme Processus de la plate-forme en fonction du libellé
/vendor(/.*)? vendor_file Tous les clients HAL du framework, ueventd, etc.
/vendor/framework(/.*)? vendor_framework_file dex2oat, appdomain, etc.
/vendor/app(/.*)? vendor_app_file dex2oat, installd, idmap, etc.
/vendor/overlay(/.*) vendor_overlay_file system_server, zygote, idmap, etc.

Par conséquent, des règles spécifiques doivent être respectées (appliquées via neverallows) lors de l'étiquetage de fichiers supplémentaires dans la partition vendor :

  • vendor_file doit être le libellé par défaut pour tous les fichiers de la partition vendor. La règle de la plate-forme exige cela pour accéder aux implémentations HAL de transmission.
  • Tous les nouveaux exec_types ajoutés dans la partition vendor via le règlement du fournisseur doivent comporter l'attribut vendor_file_type. Cela est appliqué par le biais de neverallows.
  • Pour éviter les conflits avec les futures mises à jour de la plate-forme/du framework, évitez de libeller les fichiers autres que exec_types dans la partition vendor.
  • Toutes les dépendances de bibliothèque pour les HAL de même processus identifiés par AOSP doivent être libellées same_process_hal_file..

Procfs (/proc)

Les fichiers dans /proc ne peuvent être libellés qu'avec le libellé genfscon. Dans Android 7.0, les règles platform et vendor utilisaient genfscon pour étiqueter les fichiers dans procfs.

Recommandation : Utilisez uniquement les libellés de règlement de la plate-forme /proc. Si les processus du fournisseur doivent accéder à des fichiers dans /proc qui sont actuellement associés au libellé par défaut (proc), le règlement du fournisseur ne doit pas les libeller explicitement. Il doit plutôt utiliser le type générique proc pour ajouter des règles pour les domaines des fournisseurs. Cela permet aux mises à jour de la plate-forme de s'adapter aux futures interfaces du noyau exposées via procfs et de les étiqueter explicitement si nécessaire.

Debugfs (/sys/kernel/debug)

Debugfs peut être libellé à la fois dans file_contexts et genfscon. Dans Android 7.0 à Android 10, le libellé de la plate-forme et celui du fournisseur sont debugfs.

Dans Android 11, debugfs ne peut pas être consulté ni monté sur les appareils de production. Les fabricants d'appareils doivent supprimer debugfs.

Tracefs (/sys/kernel/debug/tracing)

Tracefs peut être libellé à la fois dans file_contexts et genfscon. Dans Android 7.0, seuls les libellés de plate-forme tracefs.

Recommandation : Seule la plate-forme peut libeller tracefs.

Sysfs (/sys)

Les fichiers de /sys peuvent être libellés à l'aide de file_contexts et de genfscon. Dans Android 7.0, la plate-forme et le fournisseur utilisent genfscon pour libeller les fichiers dans sysfs.

Recommandation : La plate-forme peut identifier les nœuds sysfs qui ne sont pas spécifiques à un appareil. Sinon, seul le fournisseur peut libeller les fichiers.

tmpfs (/dev)

Les fichiers de /dev peuvent être libellés dans file_contexts. Dans Android 7.0, les fichiers de plate-forme et de libellé du fournisseur sont ici.

Recommandation : Le fournisseur peut n'étiqueter que les fichiers dans /dev/vendor (par exemple, /dev/vendor/foo, /dev/vendor/socket/bar).

Rootfs (/)

Les fichiers de / peuvent être libellés dans file_contexts. Dans Android 7.0, les fichiers de libellés de plate-forme et de fournisseur se trouvent ici.

Recommandation : Seul le système peut étiqueter les fichiers dans /.

Données (/data)

Les données sont libellées à l'aide d'une combinaison de file_contexts et de seapp_contexts.

Recommandation : Interdisez l'étiquetage des fournisseurs en dehors de /data/vendor. Seule la plate-forme peut libeller d'autres parties de /data.

Version des libellés Genfs

À partir du niveau d'API du fournisseur 202504, les nouveaux libellés SELinux attribués avec genfscon dans system/sepolicy/compat/plat_sepolicy_genfs_ver.cil sont facultatifs pour les anciennes partitions vendor. Cela permet aux anciennes partitions vendor de conserver leur implémentation SEPolicy existante. Cela est contrôlé par la variable Makefile BOARD_GENFS_LABELS_VERSION, qui est stockée dans /vendor/etc/selinux/genfs_labels_version.txt.

Exemple :

  • Dans le niveau d'API du fournisseur 202404, le nœud /sys/class/udc est libellé sysfs par défaut.
  • À partir du niveau d'API du fournisseur 202504, /sys/class/udc est libellé sysfs_udc.

Toutefois, /sys/class/udc peut être utilisé par des partitions vendor utilisant le niveau d'API 202404, soit avec le libellé sysfs par défaut, soit avec un libellé spécifique au fournisseur. Le libellé inconditionnel /sys/class/udc en tant que sysfs_udc peut casser la compatibilité avec ces partitions vendor. Si vous cochez BOARD_GENFS_LABELS_VERSION, la plate-forme continue d'utiliser les libellés et les autorisations précédents pour les anciennes partitions vendor.

BOARD_GENFS_LABELS_VERSION peut être supérieur ou égal au niveau d'API du fournisseur. Par exemple, les partitions vendor utilisant le niveau d'API 202404 peuvent définir BOARD_GENFS_LABELS_VERSION sur 202504 pour adopter les nouveaux libellés introduits dans la version 202504. Consultez la liste des libellés genfs spécifiques à 202504.

Lors de l'étiquetage des nœuds genfscon, la plate-forme doit tenir compte des anciennes partitions vendor et implémenter des mécanismes de secours pour la compatibilité si nécessaire. La plate-forme peut utiliser des bibliothèques réservées à la plate-forme pour interroger la version des libellés genfs.

Politique publique de la plate-forme

La plate-forme SELinux est divisée en deux parties : privée et publique. Le règlement public de la plate-forme se compose de types et d'attributs qui sont toujours disponibles pour un niveau d'API du fournisseur, et qui servent d'API entre la plate-forme et le fournisseur. Cette règle est exposée aux rédacteurs de règles des fournisseurs pour leur permettre de créer des fichiers de règles de fournisseur qui, combinés à la règle privée de la plate-forme, aboutissent à une règle entièrement fonctionnelle pour un appareil. La règle publique de la plate-forme est définie dans system/sepolicy/public.

Par exemple, un type vendor_init, représentant le processus d'initialisation dans le contexte du fournisseur, est défini sous system/sepolicy/public/vendor_init.te : 

type vendor_init, domain;

Les fournisseurs peuvent se référer au type vendor_init pour écrire des règles de conformité personnalisées : 

# Allow vendor_init to set vendor_audio_prop in vendor's init scripts
set_prop(vendor_init, vendor_audio_prop)

Attributs de compatibilité

La règle SELinux est une interaction entre les types source et cible pour des classes d'objets et des autorisations spécifiques. Chaque objet (processus, fichiers, par exemple) concerné par la règle SELinux ne peut avoir qu'un seul type, mais ce type peut avoir plusieurs attributs.

La stratégie est principalement rédigée en termes de types existants. Ici, vendor_init et debugfs sont des types : 

allow vendor_init debugfs:dir { mounton };

Cela fonctionne, car la règle a été écrite en tenant compte de tous les types. Toutefois, si les règles du fournisseur et de la plate-forme utilisent des types spécifiques, et que le libellé d'un objet spécifique change dans une seule de ces règles, l'autre peut contenir des règles qui s'appuyaient auparavant sur l'accès accordé ou perdu. Par exemple, supposons que la règle de plate-forme libelle les nœuds sysfs comme sysfs : 

/sys(/.*)? u:object_r:sysfs:s0

La règle relative aux fournisseurs accorde l'accès à /sys/usb, qui porte la mention sysfs : 

allow vendor_init sysfs:chr_file rw_file_perms;

Si la règle de la plate-forme est modifiée pour que /sys/usb soit associé à sysfs_usb, la règle du fournisseur reste la même, mais vendor_init perd l'accès à /sys/usb en raison de l'absence de règle pour le nouveau type sysfs_usb : 

/sys/usb u:object_r:sysfs_usb:s0

Pour résoudre ce problème, Android introduit le concept d'attributs versionnés. Au moment de la compilation, le système de compilation traduit automatiquement les types publics de plate-forme utilisés dans la règle du fournisseur en ces attributs versionnés. Cette traduction est possible grâce à des fichiers de mappage qui associent un attribut versionné à un ou plusieurs types publics de la plate-forme.

Par exemple, supposons que /sys/usb soit libellé sysfs dans la règle de plate-forme 202504 et que la règle du fournisseur 202504 accorde à vendor_init l'accès à /sys/usb. Dans ce cas :

  • La règle allow vendor_init sysfs:chr_file rw_file_perms; est écrite par la règle du fournisseur, car /sys/usb est libellé sysfs dans la règle de la plate-forme 202504. Lorsque le système de compilation compile la règle du fournisseur, il la traduit automatiquement en allow vendor_init_202504 sysfs_202504:chr_file rw_file_perms;. Les attributs vendor_init_202504 et sysfs_202504 correspondent aux types vendor_init et sysfs, qui sont les types définis par la plate-forme.
  • Le système de compilation génère un fichier de mappage d'identité /system/etc/selinux/mapping/202504.cil. Étant donné que les partitions system et vendor utilisent la même version 202504, le fichier de mappage contient des mappages d'identité de type_202504 à type. Par exemple, vendor_init_202504 est mappé sur vendor_init et sysfs_202504 sur sysfs : 
    (typeattributeset sysfs_202504 (sysfs))
(typeattributeset vendor_init_202504 (vendor_init))
...

Lorsque la version passe de 202504 à 202604, un nouveau fichier de mappage pour les partitions 202504 vendor est créé sous system/sepolicy/private/compat/202504/202504.cil, qui est installé sur /system/etc/selinux/mapping/202504.cil pour les partitions 202604 ou ultérieures system. Initialement, ce fichier de mappage contient des mappages d'identité, comme décrit précédemment. Si un nouveau libellé sysfs_usb pour /sys/usb est ajouté au règlement de la plate-forme 202604, le fichier de mapping est mis à jour pour mapper sysfs_202504 sur sysfs_usb : 

(typeattributeset sysfs_202504 (sysfs sysfs_usb))
(typeattributeset vendor_init_202504 (vendor_init))
...

Cette mise à jour permet à la règle allow vendor_init_202504 sysfs_202504:chr_file rw_file_perms; convertie pour les fournisseurs d'accorder automatiquement l'accès vendor_init au nouveau type sysfs_usb.

Pour maintenir la compatibilité avec les anciennes partitions vendor, chaque fois qu'un nouveau type public est ajouté, il doit être mappé à au moins un des attributs versionnés dans le fichier de mappage system/sepolicy/private/compat/ver/ver.cil ou être listé sous system/sepolicy/private/compat/ver/ver.ignore.cil pour indiquer qu'il n'existe aucun type correspondant dans les versions précédentes du fournisseur.

La combinaison du règlement de la plate-forme, du règlement du fournisseur et du fichier de mappage permet au système de se mettre à jour sans mettre à jour le règlement du fournisseur. De plus, la conversion en attributs versionnés s'effectue automatiquement. La règle du fournisseur n'a donc pas besoin de gérer le versionnage et peut continuer à utiliser les types publics tels quels.

Règles publiques et produit public system_ext

À partir d'Android 11, les partitions system_ext et product sont autorisées à exporter leurs types publics désignés vers la partition vendor. Comme le règlement public de la plate-forme, le règlement relatif aux fournisseurs utilise des types et des règles automatiquement traduits en attributs versionnés, par exemple de type à type_ver, où ver correspond au niveau d'API du fournisseur de la partition vendor.

Lorsque les partitions system_ext et product sont basées sur la même version de plate-forme ver, le système de compilation génère des fichiers de mappage de base vers system_ext/etc/selinux/mapping/ver.cil et product/etc/selinux/mapping/ver.cil, qui contiennent des mappages d'identité de type à type_ver. La règle du fournisseur peut accéder à type avec l'attribut versionné type_ver.

Si seules les partitions system_ext et product sont mises à jour, par exemple de ver à ver+1 (ou ultérieurement), tandis que la partition vendor reste à ver, il est possible que la règle du fournisseur perde l'accès aux types des partitions system_ext et product. Pour éviter toute rupture, les partitions system_ext et product doivent fournir des fichiers de mappage des types concrets vers les attributs type_ver. Chaque partenaire est responsable de la maintenance des fichiers de mappage s'il prend en charge la partition ver vendor avec ver+1 (ou version ultérieure) system_ext et les partitions product.

Pour installer des fichiers de mappage dans les partitions system_ext et product, les intégrateurs ou fournisseurs d'appareils doivent :

  1. Copiez les fichiers de mappage de base générés à partir des partitions ver, system_ext et product dans leur arborescence source.
  2. Modifiez les fichiers de mappage si nécessaire.
  3. Installez les fichiers de mappage sur les partitions ver+1 (ou version ultérieure) system_ext et product.

Par exemple, supposons que la partition 202504 system_ext comporte un type public nommé foo_type. Ensuite, system_ext/etc/selinux/mapping/202504.cil dans la partition 202504 system_ext se présente comme suit : 

(typeattributeset foo_type_202504 (foo_type))
(expandtypeattribute foo_type_202504 true)
(typeattribute foo_type_202504)

Si bar_type est ajouté à la partition 202604 system_ext et que bar_type doit être mappé sur foo_type pour la partition 202504 vendor, 202504.cil peut être mis à jour de (typeattributeset foo_type_202504 (foo_type)) à (typeattributeset foo_type_202504 (foo_type bar_type)), puis installé sur la partition 202604 system_ext. La partition 202504 vendor peut continuer à accéder aux foo_type et bar_type de la partition 202604 system_ext.

Modifications d'attributs pour Android 9

Les appareils qui passent à Android 9 peuvent utiliser les attributs suivants, mais les appareils lancés avec Android 9 ne le doivent pas.

Attributs du contrevenant

Android 9 inclut les attributs liés au domaine suivants :

  • data_between_core_and_vendor_violators. Attribut pour tous les domaines qui ne respectent pas l'exigence de ne pas partager de fichiers par chemin d'accès entre vendor et coredomains. Les processus de plate-forme et de fournisseur ne doivent pas utiliser de fichiers sur disque pour communiquer (ABI instable). Recommandation :
    • Le code fournisseur doit utiliser /data/vendor.
    • Le système ne doit pas utiliser /data/vendor.
  • Attribut system_executes_vendor_violators. pour tous les domaines système (sauf init et shell domains) qui ne respectent pas l'exigence de ne pas exécuter de binaires de fournisseurs. L'exécution des binaires du fournisseur présente une API instable. La plate-forme ne doit pas exécuter directement les binaires du fournisseur. Recommandation :
    • Ces dépendances de plate-forme sur les binaires du fournisseur doivent se trouver derrière les HAL HIDL.

      OU

    • Les coredomains qui ont besoin d'accéder aux binaires du fournisseur doivent être déplacés vers la partition vendor et ne plus être coredomain.

Attributs non approuvés

Les applications non approuvées qui hébergent du code arbitraire ne doivent pas avoir accès aux services HwBinder, à l'exception de ceux considérés comme suffisamment sûrs pour être accessibles à partir de ces applications (voir les services sécurisés ci-dessous). Voici les deux principales raisons :

  1. Les serveurs HwBinder n'effectuent pas d'authentification du client, car HIDL n'expose actuellement pas les informations UID de l'appelant. Même si HIDL exposait de telles données, de nombreux services HwBinder fonctionnent à un niveau inférieur à celui des applications (comme les HAL) ou ne doivent pas s'appuyer sur l'identité de l'application pour l'autorisation. Par conséquent, pour plus de sécurité, l'hypothèse par défaut est que chaque service HwBinder traite tous ses clients comme étant également autorisés à effectuer les opérations proposées par le service.
  2. Les serveurs HAL (un sous-ensemble de services HwBinder) contiennent du code avec un taux d'incidence plus élevé de problèmes de sécurité que les composants system/core et ont accès aux couches inférieures de la pile (jusqu'au matériel), ce qui augmente les possibilités de contourner le modèle de sécurité Android.

Services Safe

Voici quelques exemples de services sécurisés :

  • same_process_hwservice. Ces services (par définition) s'exécutent dans le processus du client et ont donc le même accès que le domaine client dans lequel le processus s'exécute.
  • coredomain_hwservice. Ces services ne présentent pas les risques associés à la raison n° 2.
  • hal_configstore_ISurfaceFlingerConfigs. Ce service est spécifiquement conçu pour être utilisé par n'importe quel domaine.
  • hal_graphics_allocator_hwservice. Ces opérations sont également proposées par le service Binder surfaceflinger, auquel les applications sont autorisées à accéder.
  • hal_omx_hwservice. Il s'agit d'une version HwBinder du service Binder mediacodec, auquel les applications sont autorisées à accéder.
  • hal_codec2_hwservice. Il s'agit d'une version plus récente de hal_omx_hwservice.

Attributs utilisables

Tous les hwservices considérés comme non sécurisés possèdent l'attribut untrusted_app_visible_hwservice. Les serveurs HAL correspondants possèdent l'attribut untrusted_app_visible_halserver. Les appareils lancés avec Android 9 NE DOIVENT PAS utiliser l'attribut untrusted.

Recommandation :

  • Les applications non fiables doivent plutôt communiquer avec un service système qui communique avec le HAL HIDL du fournisseur. Par exemple, les applications peuvent communiquer avec binderservicedomain, puis mediaserver (qui est un binderservicedomain) communique à son tour avec hal_graphics_allocator.

    OU

  • Les applications qui ont besoin d'un accès direct aux HAL vendor doivent avoir leur propre domaine sepolicy défini par le fournisseur.

Tests des attributs de fichier

Android 9 inclut des tests au moment de la compilation qui garantissent que tous les fichiers situés à des emplacements spécifiques possèdent les attributs appropriés (par exemple, que tous les fichiers de sysfs possèdent l'attribut sysfs_type requis).

Libellés de contexte SELinux

Pour distinguer les règles sepolicy de la plate-forme de celles du fournisseur, le système crée les fichiers de contexte SELinux différemment pour les séparer.

Contextes de fichier

Android 8.0 a introduit les modifications suivantes pour file_contexts :

  • Pour éviter une surcharge de compilation supplémentaire sur l'appareil au démarrage, les file_contexts n'existent plus sous forme binaire. Ils sont plutôt lisibles et se présentent sous la forme de fichiers texte d'expressions régulières, comme {property, service}_contexts (comme avant la version 7.0).
  • Les file_contexts sont répartis dans deux fichiers :
    • plat_file_contexts
      • Plate-forme Android file_context sans libellés spécifiques à l'appareil, à l'exception du libellé des parties de la partition /vendor, qui doit être précis pour assurer le bon fonctionnement des fichiers sepolicy.
      • Doit résider dans la partition system à /system/etc/selinux/plat_file_contexts sur l'appareil et être chargé par init au début avec le file_context du fournisseur.
    • vendor_file_contexts
      • file_context spécifique à l'appareil, créé en combinant file_contexts trouvé dans les répertoires pointés par BOARD_SEPOLICY_DIRS dans les fichiers Boardconfig.mk de l'appareil.
      • Doit être installé à l'emplacement /vendor/etc/selinux/vendor_file_contexts dans la partition vendor et être chargé par init au démarrage avec la plate-forme file_context.

Contextes de propriété

Dans Android 8.0, property_contexts est divisé en deux fichiers :

  • plat_property_contexts
    • Plate-forme Android property_context sans libellés spécifiques à l'appareil.
    • Doit résider dans la partition system à /system/etc/selinux/plat_property_contexts et être chargé par init au début avec le fournisseur property_contexts.
  • vendor_property_contexts
    • property_context spécifique à l'appareil, créé en combinant property_contexts trouvé dans les répertoires pointés par BOARD_SEPOLICY_DIRS dans les fichiers Boardconfig.mk de l'appareil.
    • Doit résider dans la partition vendor à /vendor/etc/selinux/vendor_property_contexts et être chargé par init au démarrage avec le property_context de la plate-forme

Contextes de service

Dans Android 8.0, le fichier service_contexts est divisé entre les fichiers suivants :

  • plat_service_contexts
    • service_context spécifique à la plate-forme Android pour servicemanager. service_context ne comporte pas de libellés spécifiques à l'appareil.
    • Doit résider dans la partition system à /system/etc/selinux/plat_service_contexts et être chargé par servicemanager au début avec le service_contexts du fournisseur.
  • vendor_service_contexts
    • service_context spécifique à l'appareil, créé en combinant service_contexts trouvé dans les répertoires pointés par BOARD_SEPOLICY_DIRS dans les fichiers Boardconfig.mk de l'appareil.
    • Doit résider dans la partition vendor à l'adresse /vendor/etc/selinux/vendor_service_contexts et être chargé par servicemanager au démarrage avec le service_contexts de la plate-forme.
    • Bien que servicemanager recherche ce fichier au démarrage, pour un appareil TREBLE entièrement conforme, le fichier vendor_service_contexts NE DOIT PAS exister. En effet, toute interaction entre les processus vendor et system DOIT passer par hwservicemanager/hwbinder.
  • plat_hwservice_contexts
    • Plate-forme Android hwservice_context pour hwservicemanager sans libellé spécifique à l'appareil.
    • Doit résider dans la partition system à /system/etc/selinux/plat_hwservice_contexts et être chargé par hwservicemanager au début avec vendor_hwservice_contexts.
  • vendor_hwservice_contexts
    • hwservice_context spécifique à l'appareil, créé en combinant hwservice_contexts trouvé dans les répertoires pointés par BOARD_SEPOLICY_DIRS dans les fichiers Boardconfig.mk de l'appareil.
    • Doit résider dans la partition vendor à /vendor/etc/selinux/vendor_hwservice_contexts et être chargé par hwservicemanager au démarrage avec plat_service_contexts.
  • vndservice_contexts
    • service_context spécifique à l'appareil pour le vndservicemanager créé en combinant vndservice_contexts trouvé dans les répertoires pointés par BOARD_SEPOLICY_DIRS dans le Boardconfig.mk de l'appareil.
    • Ce fichier doit résider dans la partition vendor à l'adresse /vendor/etc/selinux/vndservice_contexts et être chargé par vndservicemanager au démarrage.

Contextes Seapp

Dans Android 8.0, seapp_contexts est divisé en deux fichiers :

  • plat_seapp_contexts
    • Plate-forme Android seapp_context sans modifications spécifiques à l'appareil.
    • Doit résider dans la partition system à l'adresse /system/etc/selinux/plat_seapp_contexts.
  • vendor_seapp_contexts
    • Extension spécifique à l'appareil de la plate-forme seapp_context créée en combinant seapp_contexts trouvés dans les répertoires pointés par BOARD_SEPOLICY_DIRS dans les fichiers Boardconfig.mk de l'appareil.
    • Doit résider dans la partition vendor à l'adresse /vendor/etc/selinux/vendor_seapp_contexts.

Autorisations MAC

Dans Android 8.0, mac_permissions.xml est divisé en deux fichiers :

  • Plate-forme mac_permissions.xml
    • Plate-forme Android mac_permissions.xml sans modifications spécifiques à l'appareil.
    • Doit résider dans la partition system à l'adresse /system/etc/selinux/.
  • Hors plate-forme mac_permissions.xml
    • Extension spécifique à l'appareil de la plate-forme mac_permissions.xml construite à partir de mac_permissions.xml trouvée dans les répertoires indiqués par BOARD_SEPOLICY_DIRS dans les fichiers Boardconfig.mk de l'appareil.
    • Doit résider dans la partition vendor à l'adresse /vendor/etc/selinux/.