Implémentation de SELinux

SELinux est configuré pour refuser par défaut, ce qui signifie que chaque accès pour lequel il a un crochet dans le noyau doit être explicitement autorisé par la politique. Cela signifie qu'un fichier de stratégie est composé d'une grande quantité d'informations concernant les règles, les types, les classes, les autorisations, etc. Une prise en compte complète de SELinux sort du cadre de ce document, mais il est désormais essentiel de comprendre comment écrire des règles de politique lors de la mise en place de nouveaux appareils Android. De nombreuses informations sont déjà disponibles sur SELinux. Voir la documentation de support pour les ressources suggérées.

Fichiers clés

Pour activer SELinux, intégrez le dernier noyau Android puis incorporez les fichiers trouvés dans le répertoire system/sepolicy . Une fois compilés, ces fichiers comprennent la politique de sécurité du noyau SELinux et couvrent le système d'exploitation Android en amont.

En général, vous ne devez pas modifier directement les fichiers system/sepolicy . Au lieu de cela, ajoutez ou modifiez vos propres fichiers de stratégie spécifiques à l'appareil dans le répertoire /device/ manufacturer / device-name /sepolicy . Dans Android 8.0 et versions ultérieures, les modifications que vous apportez à ces fichiers ne doivent affecter que la politique de votre répertoire de fournisseur. Pour plus de détails sur la séparation de la sepolicy publique dans Android 8.0 et versions ultérieures, consultez Personnalisation de SEPolicy dans Android 8.0+ . Quelle que soit la version d'Android, vous modifiez toujours ces fichiers :

Fichiers de stratégie

Les fichiers qui se terminent par *.te sont des fichiers source de politique SELinux, qui définissent les domaines et leurs étiquettes. Vous devrez peut-être créer de nouveaux fichiers de stratégie dans /device/ manufacturer / device-name /sepolicy , mais vous devriez essayer de mettre à jour les fichiers existants dans la mesure du possible.

Fichiers de contexte

Les fichiers de contexte sont l'endroit où vous spécifiez des étiquettes pour vos objets.

  • file_contexts attribue des étiquettes aux fichiers et est utilisé par divers composants de l'espace utilisateur. Lorsque vous créez de nouvelles stratégies, créez ou mettez à jour ce fichier pour attribuer de nouvelles étiquettes aux fichiers. Pour appliquer de nouveaux file_contexts , reconstruisez l'image du système de fichiers ou exécutez restorecon sur le fichier à renommer. Lors des mises à niveau, les modifications apportées à file_contexts sont automatiquement appliquées aux partitions système et userdata dans le cadre de la mise à niveau. Les modifications peuvent également être automatiquement appliquées lors de la mise à niveau vers d'autres partitions en ajoutant des appels restorecon_recursive à votre init. board .rc après que la partition a été montée en lecture-écriture.
  • genfs_contexts attribue des étiquettes aux systèmes de fichiers, tels que proc ou vfat qui ne prennent pas en charge les attributs étendus. Cette configuration est chargée dans le cadre de la politique du noyau, mais les modifications peuvent ne pas prendre effet pour les inodes internes, nécessitant un redémarrage ou le démontage et le remontage du système de fichiers pour appliquer pleinement la modification. Des étiquettes spécifiques peuvent également être attribuées à des montages spécifiques, tels que vfat à l'aide de l'option context=mount .
  • property_contexts attribue des étiquettes aux propriétés du système Android pour contrôler les processus qui peuvent les définir. Cette configuration est lue par le processus init lors du démarrage.
  • service_contexts attribue des étiquettes aux services de classeur Android pour contrôler les processus qui peuvent ajouter (enregistrer) et trouver (rechercher) une référence de classeur pour le service. Cette configuration est lue par le processus servicemanager lors du démarrage.
  • seapp_contexts attribue des étiquettes aux processus d'application et aux répertoires /data/data . Cette configuration est lue par le processus zygote à chaque lancement d'application et par installd au démarrage.
  • mac_permissions.xml attribue une balise seinfo aux applications en fonction de leur signature et éventuellement de leur nom de package. La balise seinfo peut ensuite être utilisée comme clé dans le fichier seapp_contexts pour attribuer une étiquette spécifique à toutes les applications avec cette balise seinfo . Cette configuration est lue par system_server lors du démarrage.
  • keystore2_key_contexts attribue des étiquettes aux espaces de noms Keystore 2.0. Ces espaces de noms sont appliqués par le démon keystore2. Keystore a toujours fourni des espaces de noms basés sur UID/AID. Keystore 2.0 applique en outre les espaces de noms définis par sepolicy. Une description détaillée du format et des conventions de ce fichier peut être trouvée ici .

Makefile BoardConfig.mk

Après avoir modifié ou ajouté des fichiers de stratégie et de contexte, mettez à jour votre makefile /device/ manufacturer / device-name /BoardConfig.mk pour référencer le sous-répertoire sepolicy et chaque nouveau fichier de stratégie. Pour plus d'informations sur les variables BOARD_SEPOLICY , consultez le fichier system/sepolicy/README .

BOARD_SEPOLICY_DIRS += \
        <root>/device/manufacturer/device-name/sepolicy

BOARD_SEPOLICY_UNION += \
        genfs_contexts \
        file_contexts \
        sepolicy.te

Après la reconstruction, votre appareil est activé avec SELinux. Vous pouvez désormais personnaliser vos politiques SELinux pour prendre en charge vos propres ajouts au système d'exploitation Android comme décrit dans Personnalisation ou vérifier votre configuration existante comme indiqué dans Validation .

Lorsque les nouveaux fichiers de politique et les mises à jour de BoardConfig.mk sont en place, les nouveaux paramètres de politique sont automatiquement intégrés dans le fichier de politique final du noyau. Pour plus d'informations sur la manière dont sepolicy est créée sur l'appareil, consultez Création de sepolicy .

Mise en œuvre

Pour démarrer avec SELinux :

  1. Activez SELinux dans le noyau : CONFIG_SECURITY_SELINUX=y
  2. Modifiez le paramètre kernel_cmdline ou bootconfig de sorte que :
    BOARD_KERNEL_CMDLINE := androidboot.selinux=permissive
    ou
    BOARD_BOOTCONFIG := androidboot.selinux=permissive
    Ceci est uniquement pour le développement initial de la stratégie pour le périphérique. Une fois que vous avez une stratégie d'amorçage initiale, supprimez ce paramètre afin que votre appareil applique ou il échouera CTS.
  3. Démarrez le système en mode permissif et voyez quels refus sont rencontrés au démarrage :
    Sur Ubuntu 14.04 ou plus récent :
    adb shell su -c dmesg | grep denied | audit2allow -p out/target/product/BOARD/root/sepolicy
    
    Sur Ubuntu 12.04 :
    adb pull /sys/fs/selinux/policy
    adb logcat -b all | audit2allow -p policy
    
  4. Évaluez la sortie pour les avertissements qui ressemblent à init: Warning! Service name needs a SELinux domain defined; please fix! Voir Validation pour les instructions et les outils.
  5. Identifiez les périphériques et autres nouveaux fichiers nécessitant un étiquetage.
  6. Utilisez des étiquettes existantes ou nouvelles pour vos objets. Regardez les fichiers *_contexts pour voir comment les choses étaient précédemment étiquetées et utilisez la connaissance des significations des étiquettes pour en attribuer une nouvelle. Idéalement, il s'agira d'un label existant qui s'intégrera dans la politique, mais parfois un nouveau label sera nécessaire, et des règles d'accès à ce label seront nécessaires. Ajoutez vos étiquettes aux fichiers de contexte appropriés.
  7. Identifiez les domaines/processus qui doivent avoir leurs propres domaines de sécurité. Vous devrez probablement rédiger une toute nouvelle politique pour chacun. Tous les services créés à partir de init , par exemple, devraient avoir le leur. Les commandes suivantes aident à révéler celles qui restent en cours d'exécution (mais TOUS les services ont besoin d'un tel traitement) :
    adb shell su -c ps -Z | grep init
    
    adb shell su -c dmesg | grep 'avc: '
    
  8. Revoir init. device .rc pour identifier tous les domaines qui n'ont pas de type de domaine. Donnez-leur un domaine au début de votre processus de développement pour éviter d'ajouter des règles à init ou de confondre les accès init avec ceux qui sont dans leur propre stratégie.
  9. Configurez BOARD_CONFIG.mk pour utiliser les variables BOARD_SEPOLICY_* . Voir le README dans system/sepolicy pour plus de détails sur la configuration.
  10. Examinez le fichier init. device .rc et fstab. device et assurez-vous que chaque utilisation de mount correspond à un système de fichiers correctement étiqueté ou qu'une option context= mount est spécifiée.
  11. Passez en revue chaque refus et créez une politique SELinux pour gérer correctement chacun. Voir les exemples dans Personnalisation .

Vous devez commencer par les politiques de l'AOSP, puis les développer pour vos propres personnalisations. Pour plus d'informations sur la stratégie de politique et un examen plus approfondi de certaines de ces étapes, consultez Rédaction d'une politique SELinux .

Cas d'utilisation

Voici des exemples spécifiques d'exploits à prendre en compte lors de la création de votre propre logiciel et des politiques SELinux associées :

Liens symboliques - Parce que les liens symboliques apparaissent comme des fichiers, ils sont souvent lus comme des fichiers, ce qui peut conduire à des exploits. Par exemple, certains composants privilégiés, tels que init , modifient les autorisations de certains fichiers, parfois pour être excessivement ouverts.

Les attaquants pourraient alors remplacer ces fichiers par des liens symboliques vers le code qu'ils contrôlent, permettant à l'attaquant d'écraser des fichiers arbitraires. Mais si vous savez que votre application ne traversera jamais un lien symbolique, vous pouvez lui interdire de le faire avec SELinux.

Fichiers système - Tenez compte de la classe des fichiers système qui ne doivent être modifiés que par le serveur système. Néanmoins, puisque netd , init et vold s'exécutent en tant que root, ils peuvent accéder à ces fichiers système. Donc, si netd était compromis, il pourrait compromettre ces fichiers et potentiellement le serveur système lui-même.

Avec SELinux, vous pouvez identifier ces fichiers en tant que fichiers de données du serveur système. Par conséquent, le seul domaine disposant d'un accès en lecture/écriture est le serveur système. Même si netd était compromis, il ne pouvait pas basculer les domaines vers le domaine du serveur système et accéder à ces fichiers système bien qu'il s'exécute en tant que root.

Données d'application - Un autre exemple est la classe de fonctions qui doit s'exécuter en tant que root mais ne doit pas accéder aux données d'application. Ceci est extrêmement utile car des affirmations de grande envergure peuvent être faites, telles que certains domaines sans rapport avec les données d'application étant interdits d'accès à Internet.

setattr - Pour les commandes telles que chmod et chown , vous pouvez identifier l'ensemble de fichiers où le domaine associé peut effectuer setattr . Tout ce qui est en dehors de cela pourrait être interdit de ces changements, même par root. Ainsi, une application peut exécuter chmod et chown contre ceux étiquetés app_data_files mais pas shell_data_files ou system_data_files .