Security-Enhanced Linux dans Android

Dans le cadre du modèle de sécurité d'Android, Android utilise Security-Enhanced Linux (SELinux) pour appliquer le contrôle des accès obligatoire (MAC) à tous les processus, même ceux exécutés avec des droits d'utilisateur racine/super-utilisateur (fonctionnalités Linux). De nombreuses entreprises et organisations ont contribué à l'implémentation de SELinux sur Android. Avec SELinux, Android peut mieux protéger et confiner les services système, contrôler l'accès aux données d'application et aux journaux système, réduire les effets des logiciels malveillants et protéger les utilisateurs contre les failles potentielles du code sur les appareils mobiles.

SELinux fonctionne sur le principe du refus par défaut: tout ce qui n'est pas explicitement autorisé est refusé. SELinux peut fonctionner dans deux modes globaux:

  • Mode permissif, dans lequel les refus d'autorisation sont consignés, mais pas appliqués.
  • Mode Enforcing (Application), dans lequel les refus d'autorisations sont à la fois consignés et appliqués.

Android inclut SELinux en mode d'application et une règle de sécurité correspondante qui fonctionne par défaut dans AOSP. En mode d'application, les actions non autorisées sont empêchées et toutes les tentatives d'infractions sont consignées par le noyau dans dmesg et logcat. Lors du développement, vous devez utiliser ces erreurs pour affiner votre logiciel et vos règles SELinux avant de les appliquer. Pour en savoir plus, consultez Implémenter SELinux.

SELinux prend également en charge un mode permissif par domaine dans lequel des domaines (processus) spécifiques peuvent être rendus permissifs tout en plaçant le reste du système en mode d'application forcée global. Un domaine est simplement un libellé identifiant un processus ou un ensemble de processus dans la stratégie de sécurité, où tous les processus libellés du même domaine sont traités de la même manière par la stratégie de sécurité. Le mode permissif par domaine permet d'appliquer SELinux de manière incrémentielle à une partie toujours plus importante du système et du développement de règles pour les nouveaux services (tout en conservant l'application du reste du système).

Arrière-plan

Le modèle de sécurité Android repose en partie sur le concept de bacs à sable d'application. Chaque application s'exécute dans son propre bac à sable. Avant Android 4.3, ces bacs à sable étaient définis par la création d'un UID Linux unique pour chaque application au moment de l'installation. Android 4.3 et versions ultérieures utilisent SELinux pour définir plus précisément les limites du bac à sable d'application Android.

Dans Android 5.0 et versions ultérieures, SELinux est entièrement appliqué, en s'appuyant sur la version permissive d'Android 4.3 et l'application partielle d'Android 4.4. Avec ce changement, Android est passé de l'application d'une règle à un ensemble limité de domaines cruciaux (installd, netd, vold et zygote) à l'application de la règle à tous les domaines (plus de 60 domaines). Plus spécifiquement :

  • Tout est en mode d'application sous Android 5.x et versions ultérieures.
  • Aucun processus autre que init ne doit s'exécuter dans le domaine init.
  • Tout refus générique (pour un block_device, socket_device ou default_service) indique que l'appareil a besoin d'un domaine spécial.

Android 6.0 a renforcé le système en réduisant la permissivité de notre stratégie pour inclure une meilleure isolation entre les utilisateurs, le filtrage IOCTL, une menace réduite des services exposés, un renforcement supplémentaire des domaines SELinux et un accès /proc extrêmement limité.

Android 7.0 a mis à jour la configuration SELinux pour verrouiller davantage le bac à sable de l'application et réduire la surface d'attaque. Cette version a également divisé la pile monolithique du serveur multimédia en processus plus petits afin de réduire la portée de leurs autorisations. Pour en savoir plus, consultez Protéger Android avec plus de défenses du kernel Linux et Renforcer la pile multimédia.

Android 8.0 a mis à jour SELinux pour qu'il fonctionne avec Treble, qui sépare le code du fournisseur de bas niveau du framework système Android. Cette version a mis à jour la stratégie SELinux pour permettre aux fabricants d'appareils et aux fournisseurs de SOC de mettre à jour leurs parties de la stratégie, de créer leurs images (vendor.img, boot.img, etc.), puis de mettre à jour ces images indépendamment de la plate-forme ou inversement.

Bien qu'il soit possible d'exécuter une version plus récente de la plate-forme (framework) sur l'appareil, le cas inverse n'est pas pris en charge. Les images du fournisseur (vendor.img/odm.img) ne peuvent pas être plus récentes que la plate-forme (system.img). Par conséquent, une version plus récente de la plate-forme peut entraîner des problèmes de compatibilité SELinux, car la règle SELinux de la plate-forme est plus récente que les parties SELinux du fournisseur de la règle. Le modèle Android 8.0 fournit une méthode permettant de conserver la compatibilité afin d'éviter les mises à jour OTA simultanées inutiles.

Ressources supplémentaires

Pour obtenir de l'aide pour créer des règles SELinux utiles, consultez les ressources suivantes.