Implémenter SELinux

SELinux est configuré sur default-deny, ce qui signifie que chaque accès dont il a un hook dans le noyau doit être explicitement autorisé par la stratégie. Ce signifie qu'un fichier de règles contient une grande quantité d'informations règles, types, classes, autorisations, etc. Tout savoir sur SELinux n'entrent pas dans le cadre de ce document, mais la compréhension de la façon d'écrire les règles de sécurité sont désormais essentielles lors de l'utilisation de nouveaux appareils Android. Il y a un de nombreuses informations concernant SELinux sont déjà disponibles. Reportez-vous à la section Aide documentation pour obtenir des suggestions de ressources.

Fichiers de clé

Pour activer SELinux, intégrez le dernière version Noyau Android, puis incorporez les fichiers présents system/sepolicy . Une fois compilés, ces fichiers constituent le composant de sécurité et couvrent le système d'exploitation Android en amont.

En général, vous ne devez pas modifier les fichiers system/sepolicy directement. À la place, ajoutez ou modifiez vos propres fichiers de règles spécifiques à l'appareil dans le /device/manufacturer/device-name/sepolicy . Dans Android 8.0 et versions ultérieures, les modifications que vous apportez à ces fichiers doivent n'affectent que la stratégie dans votre répertoire de fournisseurs. Pour en savoir plus sur la séparation sepolicy publique sur Android 8.0 et versions ultérieures, voir Personnaliser SEPolicy sous Android 8.0 et versions ultérieures. Quelle que soit la version d'Android, vous êtes toujours en train de modifier les fichiers suivants:

Fichiers de règles

Les fichiers qui se terminent par *.te sont des fichiers sources de règles SELinux. définir les domaines et leurs libellés. Vous devrez peut-être créer de nouveaux fichiers de stratégie /device/manufacturer/device-name/sepolicy, mais vous devez essayer de mettre à jour les fichiers existants lorsque cela est possible.

Fichiers de contexte

Les fichiers de contexte vous permettent de spécifier des libellés pour vos objets.

  • file_contexts attribue des libellés aux fichiers et est utilisé par divers de l'espace utilisateur. Lorsque vous créez des règles, créez ou mettez à jour ce fichier pour attribuer de nouveaux libellés aux fichiers. Pour appliquer un nouveau file_contexts, recompilez l'image du système de fichiers ou exécutez restorecon sur le fichier pour à modifier leur libellé. Lors des mises à niveau, les modifications apportées à file_contexts sont automatiquement appliquée aux partitions système et userdata dans le cadre du mise à niveau. Les modifications peuvent aussi être appliquées automatiquement lors de la mise à niveau vers d'autres des partitions en ajoutant des appels restorecon_recursive à votre init.board.rc après l'installation de la partition en lecture/écriture.
  • genfs_contexts attribue des étiquettes aux systèmes de fichiers, comme proc ou vfat non compatibles avec les méthodes étendues . Cette configuration est chargée dans le cadre de la stratégie de noyau, mais les modifications peuvent ne pas prendre effet pour les nœuds de calcul intégrés, ce qui nécessite un redémarrage ou démonter et réinstaller le système de fichiers pour appliquer complètement la modification. Des étiquettes spécifiques peuvent également être attribuées à des installations spécifiques, telles que vfat avec l'option context=mount.
  • property_contexts attribue des libellés aux propriétés système Android pour contrôler quels processus peuvent les définir. Cette configuration est lue par init au démarrage.
  • service_contexts attribue des étiquettes aux services de liaison Android pour contrôler quels processus peuvent ajouter (enregistrer) et trouver (rechercher) un binder référence pour le service. Cette configuration est lue par servicemanager au démarrage.
  • seapp_contexts attribue des étiquettes aux processus de l'application et /data/data. Cette configuration est lue par zygote à chaque lancement d'appli et d'ici le installd au démarrage.
  • mac_permissions.xml attribue un tag seinfo aux applications en fonction de leur signature et éventuellement du nom de package. La Le tag seinfo peut ensuite être utilisé comme clé dans le Fichier seapp_contexts pour attribuer un libellé spécifique à toutes les applications avec cette balise seinfo. Cette configuration est lue par system_server au démarrage.
  • keystore2_key_contexts attribue des étiquettes aux espaces de noms Keystore 2.0. Ces espaces de noms sont appliqués par le daemon keystore2. Keystore a toujours des espaces de noms basés sur UID/AID. Keystore 2.0 applique également sepolicy et les espaces de noms définis. Une description détaillée du format et des conventions de ce est disponible ici.

BoardConfig.mk makefile

Après avoir modifié ou ajouté des fichiers de règles et de contexte, mettez à jour votre /device/manufacturer/device-name/BoardConfig.mk makefile pour référencer le sous-répertoire sepolicy et chaque nouveau fichier de stratégie. Pour en savoir plus sur les variables BOARD_SEPOLICY, consultez <ph type="x-smartling-placeholder"></ph> system/sepolicy/README.

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

BOARD_SEPOLICY_UNION += \
        genfs_contexts \
        file_contexts \
        sepolicy.te

Une fois recompilé, SELinux est activé sur votre appareil. Vous pouvez désormais effectuer l'une des deux opérations suivantes : personnaliser vos règles SELinux en fonction de vos propres ajouts au système d'exploitation Android, comme décrit dans Personnalisation ou validation de votre la configuration existante, comme expliqué dans Validation.

Une fois les nouveaux fichiers de stratégie et les mises à jour de BoardConfig.mk en place, le nouveau les paramètres des stratégies sont automatiquement intégrés dans le fichier final de stratégie du noyau. Pour en savoir plus sur la création de sepolicy sur l'appareil, consultez Création de la règle sepolicy.

Implémentation

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

Pour commencer à utiliser SELinux:

  1. Activez SELinux dans le kernel: CONFIG_SECURITY_SELINUX=y
  2. Modifiez le paramètre kernel_cmdline ou bootconfig comme suit: 
    BOARD_KERNEL_CMDLINE := androidboot.selinux=permissive
     ou 
    BOARD_BOOTCONFIG := androidboot.selinux=permissive
     Elle ne s'applique qu'au développement initial de la stratégie de l'appareil. Après avoir une règle d'amorçage initiale, supprimez ce paramètre pour que votre l'appareil ne l'applique pas, sinon l'outil CTS échouera.
  3. Démarrez le système en mode permissif et observez les refus rencontrés au démarrage:
    Sous Ubuntu 14.04 ou version ultérieure: 
    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. Recherchez des avertissements ressemblant à ceux de init: Warning! Service name needs a SELinux domain defined; please fix! dans le résultat. Validation pour les instructions et des outils.
  5. Identifiez les appareils et les autres nouveaux fichiers nécessitant un libellé.
  6. Utilisez des libellés existants ou nouveaux pour vos objets. Consultez le *_contexts fichiers pour afficher l'ancien libellé et utilisez la connaissance de la signification des étiquettes pour en attribuer une nouvelle. Dans l’idéal, il s'agit d'un libellé existant qui entre dans le cadre du règlement, mais il arrive un nouveau libellé sera nécessaire, et les règles d'accès à ce libellé nécessaires. Ajoutez vos libellés aux fichiers de contexte appropriés.
  7. Identifiez les domaines/processus qui devraient disposer de leurs propres domaines de sécurité. Vous devrez probablement rédiger une toute nouvelle règle pour chacune d'elles. Tout les services générés à partir de init, par exemple, doivent avoir leur vous-même. Les commandes suivantes permettent d'afficher celles qui sont toujours en cours d'exécution (mais TOUTES nécessitent un tel traitement):
    adb shell su -c ps -Z | grep init

    adb shell su -c dmesg | grep 'avc: '
  8. Examinez init.device.rc pour identifier les domaines qui : n'ont pas de type de domaine. Attribuez-leur un domaine en avance dans votre de développement pour éviter d'ajouter des règles à init ou peut prêter à confusion init avec ceux qui se trouvent dans ses propres règles.
  9. Configurez BOARD_CONFIG.mk pour utiliser BOARD_SEPOLICY_* variables. Consultez le README dans system/sepolicy pour en savoir plus sur la configuration.
  10. Examinez les fichiers init.device.rc et fstab.device, puis assurez-vous que chaque utilisation de mount correspond à une ou qu'une option context= mount est spécifié.
  11. Passez en revue chaque refus et créez des règles SELinux pour les gérer correctement. Voir les exemples de la section Personnalisation.

Vous devez commencer par les règles de l'AOSP, puis vous appuyer dessus pour vos propres personnalisations. Pour en savoir plus sur la stratégie de règlement plus en détail certaines de ces étapes, Écrire la règle SELinux

Cas d'utilisation

Voici des exemples spécifiques d'exploitation de failles à prendre en compte logiciels et les règles SELinux associées:

Liens symboliques : les liens symboliques se présentant sous forme de fichiers, ils sont souvent être lus comme des fichiers, ce qui peut entraîner des exploits. Par exemple, certains rôles privilégiés composants, tels que init, modifient les autorisations de certains fichiers, être parfois trop ouverte.

Les attaquants peuvent ensuite remplacer ces fichiers par des liens symboliques pour le code qu’ils contrôlent, permettant à l’attaquant d’écraser des fichiers arbitraires. Mais si vous connaissez votre l'application ne traverse jamais un lien symbolique, vous pouvez l'interdire avec SELinux.

Fichiers système : voyons la classe des fichiers système qui ne doivent être modifiés que par le serveur système. Malgré tout, depuis le netd, init et vold s'exécutent en mode root, ils peuvent y accéder ces fichiers système. Ainsi, si netd est 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 la sécurité du domaine netd était compromise, il ne pourrait pas basculer les domaines vers le domaine du serveur système et accéder à ces fichiers système même s’il s’exécute en tant que racine.

Données d'application : la classe des fonctions doit s'exécuter en tant que racine, mais ne doit pas accéder aux données de l'application. C'est incroyablement car il est possible d'effectuer des assertions étendues (par exemple, certains domaines sans rapport aux données d'applications qui ont l'interdiction d'accéder à Internet.

setattr : pour les commandes telles que chmod et chown, vous pourriez identifier l'ensemble de fichiers auquel domaine peut effectuer setattr. Tout ce qui dépasse de cela pourrait être interdit ces modifications, même par racine. Ainsi, une application peut s'exécuter chmod et chown par rapport à celles étiquetées app_data_files, mais pas shell_data_files ou system_data_files.