Compatibilité avec les règles

Cet article explique comment Android gère les problèmes de compatibilité avec les règles avec des OTA de plate-forme, où les paramètres SELinux de la nouvelle plate-forme peuvent différer de ceux de l'ancien fournisseur ; Paramètres SELinux.

La conception de règles SELinux basées sur des aigus tient compte d'une distinction binaire entre le règlement de la plate-forme et le règlement du fournisseur ; le schéma devient plus compliqué si les partitions de fournisseurs génèrent des dépendances, telles que platform < vendor < oem

Sur Android 8.0 et versions ultérieures, la règle globale de SELinux est divisée en règles privées des composants publics. Les composants publics sont la stratégie et les ressources infrastructure, dont la disponibilité est garantie pour une version de la plate-forme. Cette règle sera présentée aux rédacteurs des règles des fournisseurs pour leur permettre de créer un fichier de politique des fournisseurs qui, combiné au règlement fourni par la plate-forme, aboutit à une politique entièrement fonctionnelle pour un appareil.

• Pour la gestion des versions, la règle de plate-forme publique exportée sera écrite sous la forme suivante : attributs.
• Pour faciliter l'écriture des stratégies, les types exportés seront transformés en attributs avec gestion des versions dans le processus de création de la stratégie. Publique peuvent également être utilisés directement dans les décisions d'étiquetage prises par le fournisseur de contextes.

Android conserve le mappage entre les types concrets exportés sur la plate-forme. et les attributs avec gestion des versions correspondants à chaque plate-forme version. Ainsi, lorsque des objets sont étiquetés avec un type, n'enfreint pas le comportement garanti par la règle publique de la plate-forme dans une précédente version. Ce mappage est maintenu en maintenant un fichier de mappage à jour pour <ph type="x-smartling-placeholder"></ph> chaque version de la plate-forme, qui conserve les informations d'appartenance des attributs a été exporté dans les stratégies publiques.

Propriété et étiquetage des objets

Lors de la personnalisation des règles dans Android 8.0 ou version ultérieure, la propriété doit être clairement définie pour chaque objet afin de séparer les règles de plate-forme et de fournisseur. Par exemple, si le fournisseur étiquette /dev/foo et la plate-forme étiquette /dev/foo dans une OTA ultérieure, le comportement n'est pas défini. Pour Sous SELinux, cela se manifeste par une collision d’étiquettes. Le nœud d'appareil ne peut comporter qu'un une étiquette unique qui résout le libellé qui est appliqué en dernier. Par conséquent :

• Les processus qui ont besoin d'accéder à l'étiquette dont l'attribution a échoué de perdre l'accès à la ressource.
• Les processus qui accèdent au fichier peuvent être interrompus, car le mauvais Un nœud d'appareil a été créé.

Les propriétés système sont également susceptibles de créer des collisions de noms qui pourraient entraîner un comportement indéfini sur le système (ainsi que pour l'étiquetage SELinux). Collisions entre les étiquettes de plate-forme et de fournisseur peut survenir pour tout objet doté d'un libellé, y compris les propriétés, les services, les processus, les fichiers et les sockets. Pour éviter ces problèmes, définir clairement la propriété de ces objets.

Outre les collisions de libellés, les noms de type/d'attribut SELinux peuvent également entrer en conflit. Un conflit de noms d'attributs ou de types entraîne toujours une erreur du compilateur de stratégies.

Espace de noms des types/attributs

SELinux n'autorise pas les déclarations multiples du même type/attribut. Règles comportant des déclarations en double, la compilation échouera. Pour éviter de taper et collision de noms d'attributs, toutes les déclarations de fournisseur doivent être associées à un espace de noms commençant par vendor_.

type foo, domain; → type vendor_foo, domain;

Propriétés système et processus de propriété des libellés

Pour éviter les conflits d'étiquetage, la meilleure solution consiste à utiliser les espaces de noms de propriétés. À identifier facilement les propriétés de la plate-forme et éviter les conflits de noms lors du renommage ou en ajoutant des propriétés de plate-forme exportée, assurez-vous que toutes les propriétés du fournisseur ont préfixes:

Type de bien	Préfixes acceptés
propriétés du contrôle	ctl.vendor. ctl.start$vendor. ctl.stop$vendor. init.svc.vendor.
accessible en lecture	vendor.
lecture seule	ro.vendor. ro.boot. ro.hardware.
persistant	persist.vendor.

Les fournisseurs peuvent continuer à utiliser ro.boot.* (qui provient du noyau). cmdline) et ro.hardware.* (une propriété évidente liée au matériel).

Tous les services du fournisseur dans les fichiers init rc doivent comporter vendor. pour les services dans les fichiers init rc des partitions non-système. Des règles similaires sont appliqué aux libellés SELinux des propriétés du fournisseur (vendor_) pour les propriétés du fournisseur).

Propriété des fichiers

La prévention des conflits de fichiers est difficile, car la plateforme et le fournisseur et la règle de pare-feu fournissent tous deux généralement des étiquettes pour tous les systèmes de fichiers. Contrairement à la dénomination des types, l'espace de noms des fichiers n'est pas pratique puisque bon nombre d'entre eux sont créés par noyau. Pour éviter ces conflits, suivez les instructions de dénomination des systèmes de fichiers. dans cette section. Pour Android 8.0, il s'agit de recommandations sans informations techniques leur application. À l'avenir, ces recommandations seront appliquées Suite de test pour les fournisseurs (VTS).

Système (/system)

Seule l'image système doit fournir des étiquettes pour les composants /system via file_contexts, service_contexts, etc. Si les étiquettes pour les composants /system sont ajoutés à la règle /vendor, une La mise à jour OTA uniquement du framework peut ne pas être possible.

Fournisseur (/vendor)

La règle AOSP SELinux libelle déjà des parties de la partition vendor avec laquelle la plate-forme interagit, ce qui permet d'écrire des règles SELinux pour la plate-forme processus pour pouvoir parler et/ou accéder à certaines parties de vendor partition. Exemples :

chemin /vendor	Libellé fourni par la plate-forme	Processus de la plate-forme en fonction de l'étiquette
/vendor(/.*)?	vendor_file	Tous les clients HAL dans le 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.

<ph type="x-smartling-placeholder">

Par conséquent, des règles spécifiques doivent être suivies (appliquées via neverallows) lors de l'ajout de libellés à des fichiers supplémentaires dans vendor partition:

• vendor_file doit être le libellé par défaut de tous les fichiers dans la partition vendor. La règle de la plate-forme l'exige pour accéder implémentations HAL passthrough.
• Toutes les nouvelles exec_types ont été ajoutées à la partition vendor via le fournisseur SEPolicy doit comporter l'attribut vendor_file_type. Ce est appliquée via des blocages.
• Pour éviter les conflits avec les futures mises à jour de la plate-forme/du framework, évitez d'ajouter des libellés. des fichiers autres que exec_types dans la partition vendor.
• Toutes les dépendances de bibliothèque pour les HAL de processus identiques identifiées par AOSP doivent être libellé same_process_hal_file.

Procfs (/proc)

Les fichiers dans /proc peuvent être libellés uniquement à l'aide de l'élément genfscon libellé. Dans Android 7.0, les fonctionnalités plate-forme et fournisseur La règle a utilisé genfscon pour appliquer un libellé aux fichiers dans procfs.

Recommandation:N'utilisez que les libellés de règles relatives aux plates-formes /proc. Si les processus vendor ont besoin d'accéder aux fichiers de /proc qui sont actuellement associés au libellé par défaut (proc) et aux règles relatives aux fournisseurs ne les libellez pas explicitement Type proc afin d'ajouter des règles pour les domaines de fournisseurs. Cela permet à la plate-forme pour prendre en charge les futures interfaces de noyau exposées via procfs et attribuez-leur des libellés explicites si nécessaire.

Debugfs (/sys/kernel/debug)

Debugfs peut être étiqueté à la fois dans file_contexts et genfscon Sur Android 7.0 à Android 10, la plate-forme et le libellé du fournisseur debugfs

Dans Android 11, debugfs ne peut pas être accessibles ou installés sur des appareils de production. Les fabricants d'appareils doivent Supprimez debugfs.

Tracefs (/sys/kernel/debug/tracing)

Tracefs peut être étiqueté à 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 ajouter le libellé tracefs.

Sysfs (/sys)

Les fichiers dans /sys peuvent être libellés à la fois avec file_contexts et genfscon. Dans Android 7.0, la plate-forme et le fournisseur utilisent file_contexts et genfscon pour ajouter des libellés aux fichiers dans sysfs

Recommandation:La plate-forme peut libeller sysfs. qui ne sont pas spécifiques à chaque appareil. Sinon, seul le fournisseur peut ajouter des libellés aux fichiers.

tmpfs (/dev)

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

Recommandation:Le fournisseur ne peut ajouter des libellés qu'aux fichiers dans /dev/vendor (par exemple, /dev/vendor/foo, /dev/vendor/socket/bar).

Rootfs (/)

Les fichiers dans / peuvent être libellés dans file_contexts. Sur Android 7.0, la plateforme et les fichiers de libellés de fournisseur ici.

Recommandation:Seul le système peut ajouter des libellés aux fichiers dans /.

Données (/data)

Les données sont étiquetées grâce à une combinaison de file_contexts et seapp_contexts

Recommandation:Interdisez l'ajout de libellés de fournisseurs en dehors de /data/vendor Seule la plateforme peut étiqueter d'autres parties de /data

Attributs de compatibilité

La règle SELinux est une interaction entre les types source et cible pour des les classes d'objets et les autorisations. Tous les objets (processus, fichiers, etc.) concernés par les règles SELinux peuvent avoir un seul type, mais plusieurs .

Les règles sont rédigées principalement en fonction des types existants:

allow source_type target_type:target_class permission(s);

Cela fonctionne parce que la politique a été rédigée en tenant compte de tous les types. Toutefois, si les règles relatives aux fournisseurs et aux plates-formes utilisent des types spécifiques, et l'étiquette d'un des modifications d'objets spécifiques dans une seule de ces stratégies, l'autre peut contenir sur laquelle l'accès était accordé ou perdu. Exemple :

File_contexts:
/sys/A   u:object_r:sysfs:s0
Platform: allow p_domain sysfs:class perm;
Vendor: allow v_domain sysfs:class perm;

Peut être remplacé par:

File_contexts:
/sys/A   u:object_r:sysfs_A:s0

Même si la règle applicable aux fournisseurs reste la même, le v_domain perdrait l'accès en raison de l'absence de règles pour le nouveau sysfs_A de mots clés.

En définissant une stratégie en termes d'attributs, nous pouvons donner à l'objet sous-jacent type comportant un attribut correspondant à la règle pour la plate-forme et le code fournisseur. Cela peut être fait pour tous les types afin de créer efficacement attribute-policy, où des types concrets ne sont jamais utilisés. En pratique, Cette condition n'est requise que pour les parties de la règle qui chevauchent la plate-forme. et le fournisseur, qui sont définis et fournis en tant que règles publiques de plate-forme qui est construit dans le cadre de la politique des fournisseurs.

Définir une stratégie publique comme des attributs avec gestion des versions répond aux exigences de deux stratégies : objectifs de compatibilité:

• Assurez-vous que le code des fournisseurs continue de fonctionner après la mise à jour de la plate-forme. L'opération est effectuée en ajoutant des attributs aux types concrets pour les objets correspondant à ceux sur lesquels le code du fournisseur s'appuyait, ce qui préservait l'accès.
• Possibilité d'abandonner une règle. Atteint clairement délimitant les ensembles de règles en attributs pouvant être supprimés dès que la version à laquelle ils correspondent n'est plus prise en charge. Le développement peut sur la plate-forme, sachant que l'ancienne règle est toujours présente règles relatives aux fournisseurs et seront automatiquement supprimées en cas de mise à niveau.

Écriture des règles

Pour atteindre l'objectif de ne pas nécessiter la connaissance de modifications de version spécifiques pour développement de règles, Android 8.0 inclut un mappage entre "platform-public" les types de règles et leurs attributs. Le type foo est mappé pour l'attribut foo_vN, où N est le version ciblée. vN correspond aux la variable de compilation PLATFORM_SEPOLICY_VERSION et se présente au format MM.NN, où MM correspond au numéro du SDK de la plate-forme NN est une version spécifique à Sepolicy à la plate-forme.

Les attributs des stratégies publiques ne sont pas gérés par version, mais existent plutôt sous forme d'API sur quelle stratégie de plate-forme et de fournisseur peut créer pour maintenir l'interface entre les deux des partitions stables. Les rédacteurs des politiques de plateforme et de fournisseurs peuvent continuer à écrire telle qu'elle est rédigée aujourd'hui.

La règle publique de la plate-forme exportée en tant que allow source_foo target_bar:class perm; est incluse dans le règlement du fournisseur. Pendant compilation (qui inclut les version correspondante), celle-ci est transformée en stratégie, de la partie fournisseur de l'appareil (illustrée dans la section "Common Intermédiaire" Langue (CIL)):

 (allow source_foo_vN target_bar_vN (class (perm)))

Comme la politique des fournisseurs n'a jamais une longueur d'avance sur la plate-forme, elle ne doit pas se préoccuper de dans les versions précédentes. Cependant, les règles de la plate-forme doivent savoir jusqu'à quand remonte le fournisseur la règle est, d'inclure des attributs à ses types et de définir la règle correspondant à avec gestion des versions.

Différences entre les règles

Les attributs sont créés automatiquement en ajoutant _vN à la fin de chaque type n'a aucun effet si les attributs ne sont pas mappés aux types d'une version à l'autre diff. Android gère le mappage entre les versions pour les attributs et un la mise en correspondance des types avec ces attributs. Cette opération s'effectue dans le mappage contenant des instructions, tels que (CIL):

(typeattributeset foo_vN (foo))

Mises à niveau de la plate-forme

La section suivante présente en détail les scénarios de mise à niveau de plate-forme.

Types identiques

Ce scénario se produit lorsqu'un objet ne modifie pas les libellés dans les versions de stratégies. Il en va de même pour les types de sources et de cibles. On peut le voir avec /dev/binder, qui porte le libellé binder_device dans l'ensemble versions. Dans la stratégie transformée, il est représenté comme suit:

binder_device_v1 … binder_device_vN

Lors de la mise à niveau depuis v1 → v2, la règle de plate-forme doit contiennent:

type binder_device; -> (type binder_device) (in CIL)

Dans le fichier de mappage v1 (CIL):

(typeattributeset binder_device_v1 (binder_device))

Dans le fichier de mappage v2 (CIL):

(typeattributeset binder_device_v2 (binder_device))

Dans la version 1 des règles relatives aux fournisseurs (CIL):

(typeattribute binder_device_v1)
(allow binder_device_v1 …)

Dans la version 2 des règles relatives aux fournisseurs (CIL):

(typeattribute binder_device_v2)
(allow binder_device_v2 …)

Nouveaux types

Ce scénario se produit lorsque la plate-forme a ajouté un nouveau type, ce qui peut se produire lors de l'ajout de nouvelles caractéristiques ou du renforcement des règles.

• Nouvelle fonctionnalité. Lorsque le type ajoute un libellé à un objet inexistants (par exemple, un nouveau processus de service), le code du fournisseur n'avait pas interagissent précédemment directement avec lui, donc il n'existe pas de stratégie correspondante. Les nouvelles correspondant au type ne comporte pas d'attribut dans et n'aurait donc pas besoin d'une entrée dans le ciblage du fichier de mappage qui version.
• Durcissement des règles. Lorsque le type représente une stratégie le nouvel attribut de type doit être associé à une chaîne d'attributs correspondant au précédent (comme dans l'exemple précédent, /sys/A de sysfs à sysfs_A). Fournisseur s'appuie sur une règle autorisant l'accès à sysfs et a besoin pour inclure cette règle en tant qu'attribut du nouveau type.

Lors de la mise à niveau depuis v1 → v2, la règle de plate-forme doit contiennent:

type sysfs_A; -> (type sysfs_A) (in CIL)
type sysfs; (type sysfs) (in CIL)

Dans le fichier de mappage v1 (CIL):

(typeattributeset sysfs_v1 (sysfs sysfs_A))

Dans le fichier de mappage v2 (CIL):

(typeattributeset sysfs_v2 (sysfs))
(typeattributeset sysfs_A_v2 (sysfs_A))

Dans la version 1 des règles relatives aux fournisseurs (CIL):

(typeattribute sysfs_v1)
(allow … sysfs_v1 …)

Dans la version 2 des règles relatives aux fournisseurs (CIL):

(typeattribute sysfs_A_v2)
(allow … sysfs_A_v2 …)
(typeattribute sysfs_v2)
(allow … sysfs_v2 …)

Types supprimés

Ce (rare) scénario se produit lorsqu'un type est supprimé, ce qui peut se produire lorsque sous-jacent:

• Reste, mais reçoit un libellé différent.
• Est supprimé par la plate-forme.

Lors de l'assouplissement des règles, un type est supprimé et l'objet associé à ce type est libellé reçoit un autre libellé existant. Cela représente la fusion de Mappages d'attributs: le code fournisseur doit pouvoir accéder à l'authentification par l'attribut qu'il possédait, mais le reste du système vous pourrez y accéder avec son nouvel attribut.

Si l'attribut auquel il a été basculé est nouveau, le ré-étiquetage est Idem pour le nouveau type, sauf que lorsqu'un libellé existant est utilisé, l'ajout de l'ancien attribut au nouveau type entraînerait l'apparition d'autres objets également étiquetés en les rendant accessibles de nouveau. C'est essentiellement ce que fait plate-forme et est considérée comme un compromis acceptable et la compatibilité avec d'autres appareils.

(typeattribute sysfs_v1)
(allow … sysfs_v1 …)

Exemple de version 1: Réduire les types (suppression de sysfs_A)

Lors de la mise à niveau depuis v1 → v2, la règle de plate-forme doit contiennent:

type sysfs; (type sysfs) (in CIL)

Dans le fichier de mappage v1 (CIL):

(typeattributeset sysfs_v1 (sysfs))
(type sysfs_A) # in case vendors used the sysfs_A label on objects
(typeattributeset sysfs_A_v1 (sysfs sysfs_A))

Dans le fichier de mappage v2 (CIL):

(typeattributeset sysfs_v2 (sysfs))

Dans la version 1 des règles relatives aux fournisseurs (CIL):

(typeattribute sysfs_A_v1)
(allow … sysfs_A_v1 …)
(typeattribute sysfs_v1)
(allow … sysfs_v1 …)

Dans la version 2 des règles relatives aux fournisseurs (CIL):

(typeattribute sysfs_v2)
(allow … sysfs_v2 …)

Exemple de version 2: suppression complète (type foo)

Lors de la mise à niveau depuis v1 → v2, la règle de plate-forme doit contiennent:

# nothing - we got rid of the type

Dans le fichier de mappage v1 (CIL):

(type foo) #needed in case vendors used the foo label on objects
(typeattributeset foo_v1 (foo))

Dans le fichier de mappage v2 (CIL):

# nothing - get rid of it

Dans la version 1 des règles relatives aux fournisseurs (CIL):

(typeattribute foo_v1)
(allow foo …)
(typeattribute sysfs_v1)
(allow sysfs_v1 …)

Dans la version 2 des règles relatives aux fournisseurs (CIL):

(typeattribute sysfs_v2)
(allow sysfs_v2 …)

Nouveau cours/Nouvelles autorisations

Ce scénario se produit lorsqu'une mise à niveau d'une plate-forme introduit de nouveaux composants de stratégie qui n'existent pas dans les versions précédentes. Par exemple, lorsqu'Android a ajouté la Gestionnaire d'objets servicemanager qui a créé les fonctionnalités d'ajout, de recherche et de liste les autorisations, les daemons de fournisseurs qui souhaitent s'enregistrer auprès servicemanager avait besoin d'autorisations qui n'étaient pas disponibles. Dans Android 8.0, seule la règle de plate-forme peut ajouter de nouvelles classes et autorisations.

À autoriser tous les domaines qui auraient pu être créés ou étendus conformément aux règles des fournisseurs pour que la nouvelle classe puisse être utilisée sans entrave, la règle de la plate-forme doit inclure une semblable à celle-ci:

allow {domain -coredomain} *:new_class perm;

Cela peut même nécessiter une règle autorisant l'accès à toute l'interface (politique publique). pour s'assurer que l'image du fournisseur a accès. Si cela se traduit par stratégie de sécurité (comme elle peut l'être lorsque le gestionnaire de service change), un fournisseur la mise à niveau peut être forcée.

Classe/Autorisations supprimées

Ce scénario se produit lorsqu'un gestionnaire d'objets est supprimé (par exemple, ZygoteConnection) et ne devrait pas causer de problèmes. La la classe et les autorisations du gestionnaire d'objets peuvent rester définies dans la règle jusqu'à ce que la version du fournisseur ne l'utilise plus. Cela se fait en ajoutant les définitions au fichier de mappage correspondant.

Personnalisation du fournisseur pour types nouveaux/renommés

Les nouveaux types de fournisseurs sont au cœur du développement de la politique des fournisseurs, car ils sont nécessaires pour décrire les nouveaux processus, binaires, périphériques, sous-systèmes et données stockées. En tant que il est impératif de permettre la création de types définis par le fournisseur.

Comme les règles relatives aux fournisseurs sont toujours les plus anciennes sur l'appareil, il n'est pas nécessaire convertir automatiquement tous les types de fournisseurs en attributs dans la règle. La plate-forme ne s'appuie pas sur un élément du règlement applicable aux fournisseurs, car la plate-forme que vous n'en avez pas connaissance ; Toutefois, la plate-forme fournit les attributs qu'il utilise pour interagir avec des objets étiquetés avec ces types (tels que domain, sysfs_type, etc.). Pour que la plate-forme continuent d'interagir correctement avec ces objets, les attributs et les types doivent être correctement appliquées, et des règles spécifiques peuvent être ajoutées les domaines personnalisables (tels que init).

Modifications des attributs pour Android 9

Les appareils passant à Android 9 peuvent utiliser les attributs suivants, mais les appareils avec Android 9.

Attributs de l'auteur de la violation

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'obligation de ne pas partager de fichiers en chemin entre vendor et coredomains. Plate-forme et Les processus des fournisseurs ne doivent pas utiliser de fichiers sur disque pour communiquer (ABI instable). Recommandation: <ph type="x-smartling-placeholder">
  </ph>
  • Le code fournisseur doit utiliser /data/vendor.
  • Le système ne doit pas utiliser /data/vendor.
• system_executes_vendor_violators Attribut pour tous les domaines système (sauf init et shell domains) qui ne respectent pas l'exigence de ne pas exécuter les binaires du fournisseur. Exécution de Les binaires des fournisseurs ont une API instable. La plate-forme ne doit pas exécuter les binaires du fournisseur directement. Recommandation: <ph type="x-smartling-placeholder">
  </ph>
  • Ces dépendances de plate-forme sur les binaires des fournisseurs doivent se trouver derrière des HAL HIDL.

    OU

  • Les coredomains qui ont besoin d'accéder aux binaires du fournisseur doivent être déplacées vers la partition des fournisseurs et ne sont donc plus coredomain.

Attributs non approuvés

Les applications non approuvées qui hébergent du code arbitraire ne devraient pas avoir accès à HwBinder services, à l'exception de ceux considérés comme suffisamment sûrs pour y accéder depuis de telles applications (voir les services sécurisés ci-dessous). Voici les deux principales raisons à cela:

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

Services sécurisés

Les services sécurisés incluent:

• same_process_hwservice Ces services (par définition) s'exécutent processus du client et ont donc le même accès que le domaine du client dans que le processus exécute.
• coredomain_hwservice Ces services ne présentent aucun risque associée à la raison 2.
• hal_configstore_ISurfaceFlingerConfigs Ce service est spécialement conçu pour être utilisé par n'importe quel domaine.
• hal_graphics_allocator_hwservice Ces opérations sont également proposés par le service de liaison surfaceflinger, quelles applications sont autorisées pour y accéder.
• hal_omx_hwservice Il s'agit d'une version HwBinder mediacodec Service de liaison 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 éléments hwservices non considérés comme sûrs possèdent l'attribut untrusted_app_visible_hwservice Les serveurs HAL correspondants ont l'attribut untrusted_app_visible_halserver. Lancement des appareils avec Android 9 NE DOIT PAS utiliser untrusted.

Recommandation :

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

  OU

• Les applications nécessitant un accès direct aux HAL vendor doivent disposer de leur propre domaine sepolicy défini par le fournisseur.

Tests d'attributs de fichier

Android 9 inclut des tests de durée de compilation qui garantissent que tous les fichiers d'un d'adresses possède les attributs appropriés (par exemple, tous les fichiers du sysfs comportent l'attribut sysfs_type obligatoire).

Politique publique de la plate-forme

La politique de plate-forme publique est essentielle pour se conformer à la norme Android 8.0 modèle d'architecture sans simplement maintenir l'union des règles de la plate-forme des versions 1 et 2. Les fournisseurs sont exposés à un sous-ensemble des règles de la plate-forme qui contient des types et attributs utilisables, ainsi que des règles sur ces types et attributs qui est ensuite intégré à la politique des fournisseurs (c'est-à-dire vendor_sepolicy.cil).

Les types et les règles sont automatiquement traduits dans la stratégie générée par le fournisseur dans attribute_vN, de sorte que tous les types fournis par la plate-forme sont des attributs avec gestion des versions (les attributs ne le sont toutefois pas). La plate-forme est et de cartographier les types concrets qu'il fournit dans les pour garantir que la politique du fournisseur continue de fonctionner et que les règles fournies pour une version particulière sont incluses. La combinaison de la politique publique de plateforme et la politique des fournisseurs satisfont à l’architecture d’Android 8.0 l'objectif du modèle, à savoir autoriser les compilations indépendantes de plates-formes et de fournisseurs.

Mappage sur des chaînes d'attributs

Lors de l'utilisation d'attributs à mapper à des versions de stratégie, un type correspond à un attribut ou de multiples attributs, ce qui garantit que les objets étiquetés avec le type sont accessibles via correspondant à leurs types précédents.

Si vous avez pour objectif de masquer les informations de version pour le rédacteur générer automatiquement les attributs avec gestion des versions et les attribuer au les types appropriés. Dans le cas courant des types statiques, c'est simple: type_foo correspond à type_foo_v1.

Pour un changement de libellé d'objet, comme sysfs → sysfs_A, ou mediaserver → audioserver, la création de ce mappage est non trivial (et décrit dans les exemples ci-dessus). Gestionnaires de règles de plate-forme doit déterminer comment créer le mappage aux points de transition des objets, ce qui nécessite de comprendre la relation entre les objets et leurs les étiquettes et déterminer quand cela se produit. Pour assurer la rétrocompatibilité, cette la complexité doit être gérée du côté de la plate-forme, qui est la seule partition ce qui peut augmenter les revenus.

Amélioration de la version

Pour plus de simplicité, la plate-forme Android publie une version de sepolicy lorsqu'une nouvelle la branche de release est coupée. Comme décrit ci-dessus, le numéro de version est contenu dans PLATFORM_SEPOLICY_VERSION et se présente sous la forme MM.nn, où MM correspond à la valeur du SDK et nn est un valeur privée gérée dans /platform/system/sepolicy. Pour Par exemple, 19.0 pour Kitkat, 21.0 pour Lollipop, 22.0 pour Lollipop-MR1 23.0 pour Marshmallow, 24.0 pour Nougat, 25.0 pour Nougat-MR1, 26.0 pour Oreo, 27.0 pour Oreo-MR1 et 28.0 pour Android 9. Les hausses ne sont pas toujours des nombres entiers. Pour par exemple, si un coup de MR à une version nécessite une modification incompatible system/sepolicy/public, mais pas de bouton d'API, la règle sepolicy la version pourrait être: vN.1. Version présente dans un environnement de développement La branche est un 10000.0 qui ne pourra jamais être utilisé dans le cadre de la livraison des appareils.

Android risque d'abandonner la version la plus ancienne lors de la mise à jour. Pour indiquer quand arrêt d'une version, Android peut collecter le nombre d'appareils règles exécutant cette version d'Android tout en recevant toujours la principale plate-forme mises à jour. Si le nombre est inférieur à un certain seuil, cette version est obsolète.

Impact sur les performances de plusieurs attributs

Comme décrit sur la page https://github.com/SELinuxProject/cil/issues/9, un grand nombre d'attributs affectés à un type entraîne des problèmes de performances en cas de défaut de cache de règles.

Il s'agissait d'un problème dans Android. Les modifications ont été ajoutés à Android 8.0 pour supprimer les attributs ajoutés à la règle par le compilateur de stratégies et supprimer les attributs inutilisés. Ces modifications ont été résolues des régressions de performances.

Ext. système : règles publiques et règles publiques pour les produits

À partir d'Android 11, les partitions "system_ext" et "product" sont autorisées à : exporter leurs types publics désignés vers la partition des fournisseurs. Aimer la plate-forme politique publique, le fournisseur utilise des types et des règles automatiquement traduits en les attributs avec gestion des versions, par exemple de type à type_N, où N est la version. de la plateforme sur laquelle la partition du fournisseur est construite.

Lorsque les partitions "system_ext" et "product" sont basées sur la même version de la plate-forme N, le système de compilation génère des fichiers de mappage de base pour system_ext/etc/selinux/mapping/N.cil et product/etc/selinux/mapping/N.cil, qui contiennent l'identité les mappages de type à type_N. Le fournisseur peut accédez à type avec l'attribut versionné type_N.

Si seules les partitions "system_ext" et "product" sont mises à jour, N à N+1 (ou ultérieure), tandis que l'attribut le fournisseur reste à N, il risque de ne plus pouvoir accéder à types de system_ext et de partitions de produits. Pour éviter tout dysfonctionnement, system_ext et les partitions de produits doivent fournir des fichiers de mappage à partir de en attributs type_N. Chaque partenaire est de la maintenance des fichiers de mappage, s'ils doivent prendre en charge N fournisseur avec N+1 (ou version ultérieure) system_ext et les partitions de produits.

Pour ce faire, les partenaires doivent:

1. Copier les fichiers de mappage de base générés à partir de N system_ext et partitions de produits à leur arborescence source.
2. Modifiez les fichiers de mappage si nécessaire.
3. Installez le de mappage des fichiers avec N+1 (ou une version ultérieure) system_ext et des partitions de produits.

Par exemple, supposons que N system_ext ait un élément public nommé foo_type. Puis system_ext/etc/selinux/mapping/N.cil dans la partition system_ext N, se présente comme suit:

(typeattributeset foo_type_N (foo_type))
(expandtypeattribute foo_type_N true)
(typeattribute foo_type_N)

Si bar_type est ajouté à N+1 system_ext, et si bar_type doit être mappé à foo_type pour N fournisseur, N.cil peut être mis à jour à partir de

(typeattributeset foo_type_N (foo_type))

des

(typeattributeset foo_type_N (foo_type bar_type))

puis installé dans la partition de système N+1. N fournisseur peut continuer à accéder à N+1 foo_type et bar_type de system_ext.

Libellé des contextes SELinux

Pour établir la distinction entre la plate-forme et la sécurité du fournisseur, le système construit les fichiers de contexte SELinux différemment pour les garder séparés.

Contextes de fichier

Android 8.0 a apporté les modifications suivantes pour file_contexts:

• Pour éviter une surcharge de compilation supplémentaire sur l'appareil au démarrage, Les file_contexts cessent d'exister sous forme binaire. Au lieu de cela, ils sont des fichiers texte d'expression régulière lisibles tels que {property, service}_contexts (antérieur à la version 7.0).
• Les file_contexts sont divisés entre deux fichiers: <ph type="x-smartling-placeholder">
  </ph>
  • plat_file_contexts
    • plate-forme Android file_context sans étiquettes spécifiques à l'appareil, sauf pour étiqueter certaines parties Partition /vendor qui doit être étiquetée précisément pour garantir le bon fonctionnement des fichiers sepolicy.
    • Doit se trouver dans la partition system à /system/etc/selinux/plat_file_contexts sur l'appareil et sera chargé par init au début, en même temps que le fournisseur file_context.
  • vendor_file_contexts
    • file_context spécifique à l'appareil, créé en combinant la file_contexts trouvé dans les répertoires indiqués par BOARD_SEPOLICY_DIRS dans Boardconfig.mk fichiers.
    • Doit être installé : /vendor/etc/selinux/vendor_file_contexts po vendor et être chargé par init à au début avec la plate-forme file_context.

Contextes de propriété

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

• plat_property_contexts
  • plate-forme Android property_context sans étiquettes spécifiques à chaque appareil.
  • Doit se trouver dans la partition system à /system/etc/selinux/plat_property_contexts et être chargées par init, de même que le fournisseur property_contexts
• vendor_property_contexts
  • property_context spécifique à l'appareil, créé en combinant la property_contexts trouvé dans les répertoires indiqués par BOARD_SEPOLICY_DIRS sur l'appareil Boardconfig.mk fichiers.
  • Doit se trouver dans la partition vendor à /vendor/etc/selinux/vendor_property_contexts et être chargé par init au début avec la plate-forme property_context

Contextes de service

Dans Android 8.0, service_contexts est réparti entre les :

• plat_service_contexts
  • service_context spécifique à la plate-forme Android pour servicemanager service_context n'a pas étiquettes spécifiques à chaque appareil.
  • Doit se trouver dans la partition system à /system/etc/selinux/plat_service_contexts et être chargé par servicemanager au début avec le fournisseur. service_contexts
• vendor_service_contexts
  • service_context spécifique à l'appareil, créé en combinant la service_contexts trouvé dans les répertoires indiqués par BOARD_SEPOLICY_DIRS dans Boardconfig.mk fichiers.
  • Doit se trouver dans la partition vendor à /vendor/etc/selinux/vendor_service_contexts et être chargées par servicemanager au début, ainsi que la plate-forme service_contexts
  • Bien que servicemanager recherche ce fichier au démarrage, pour un appareil TREBLE entièrement conforme, le vendor_service_contexts NE DOIT PAS exister. En effet, toutes les interactions entre 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 se trouver dans la partition system à /system/etc/selinux/plat_hwservice_contexts et être chargé par hwservicemanager au début avec les vendor_hwservice_contexts
• vendor_hwservice_contexts
  • hwservice_context spécifique à l'appareil, créé en combinant la hwservice_contexts trouvé dans les répertoires indiqués par BOARD_SEPOLICY_DIRS dans Boardconfig.mk fichiers.
  • Doit se trouver dans la partition vendor à /vendor/etc/selinux/vendor_hwservice_contexts et être chargé par hwservicemanager au début, en même temps que plat_service_contexts
• vndservice_contexts
  • service_context spécifique à l'appareil pour vndservicemanager créée en combinant vndservice_contexts trouvé dans les répertoires indiqués par BOARD_SEPOLICY_DIRS dans Boardconfig.mk
  • Ce fichier doit se trouver dans la partition vendor, à l'adresse /vendor/etc/selinux/vndservice_contexts et être chargé par vndservicemanager au début.

Contextes Seapp

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

• plat_seapp_contexts
  • Plate-forme Android seapp_context non spécifique à l'appareil des modifications.
  • Doit se trouver dans la partition system à /system/etc/selinux/plat_seapp_contexts.
• vendor_seapp_contexts
  • Extension spécifique à l'appareil créée pour la plate-forme seapp_context en combinant les seapp_contexts trouvés dans les répertoires indiqué par BOARD_SEPOLICY_DIRS dans le Boardconfig.mk fichiers.
  • Doit se trouver dans la partition vendor à /vendor/etc/selinux/vendor_seapp_contexts

Autorisations MAC

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

• Voie mac_permissions.xml <ph type="x-smartling-placeholder">
  </ph>
  • plate-forme Android mac_permissions.xml sans les modifications spécifiques à chaque appareil.
  • Doit se trouver dans la partition system à /system/etc/selinux/.
• Hors plate-forme mac_permissions.xml <ph type="x-smartling-placeholder">
  </ph>
  • Extension de plate-forme spécifique à chaque appareil mac_permissions.xml créé à partir de mac_permissions.xml trouvé dans les répertoires indiqués par BOARD_SEPOLICY_DIRS dans le Boardconfig.mk fichiers.
  • Doit se trouver dans la partition vendor à /vendor/etc/selinux/.