Linux à sécurité améliorée sous Android

Dans le cadre du modèle de sécurité Android, Android utilise Security-Enhanced Linux (SELinux) pour appliquer un contrôle d'accès obligatoire (MAC) sur tous les processus, même les processus exécutés avec les privilèges root/superutilisateur (capacités Linux). De nombreuses entreprises et organisations ont contribué à la mise en œuvre 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 des applications 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 selon deux modes globaux :

  • Mode permissif , dans lequel les refus d'autorisation sont enregistrés mais pas appliqués.
  • Mode d'application , dans lequel les refus d'autorisations sont à la fois enregistrés et appliqués.

Android inclut SELinux en mode d'application et une politique de sécurité correspondante qui fonctionne par défaut sur AOSP. En mode d'application, les actions non autorisées sont empêchées et toutes les tentatives de violations sont enregistrées par le noyau dans dmesg et logcat . Lors du développement, vous devez utiliser ces erreurs pour affiner vos politiques logicielles et SELinux avant de les appliquer. Pour plus de détails, consultez Implémentation de SELinux .

SELinux prend également en charge un mode permissif par domaine dans lequel des domaines spécifiques (processus) peuvent être rendus permissifs tout en plaçant le reste du système en mode d'application global. Un domaine est simplement une étiquette identifiant un processus ou un ensemble de processus dans la politique de sécurité, où tous les processus étiquetés avec le même domaine sont traités de la même manière par la politique de sécurité. Le mode permissif par domaine permet une application incrémentielle de SELinux à une partie toujours croissante du système et le développement de politiques pour de nouveaux services (tout en gardant le reste du système appliqué).

Arrière-plan

Le modèle de sécurité Android repose en partie sur le concept de sandbox d'applications . Chaque application s'exécute dans son propre bac à sable. Avant Android 4.3, ces sandbox é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 davantage les limites du bac à sable des applications Android.

Dans Android 5.0 et versions ultérieures, SELinux est entièrement appliqué, 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 sur un ensemble limité de domaines cruciaux ( installd , netd , vold et zygote ) à tout (plus de 60 domaines). Spécifiquement:

  • Tout est en mode d'application dans 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 , default_service ) indique que l'appareil a besoin d'un domaine spécial.

Android 6.0 a renforcé le système en réduisant le caractère permissif de notre politique pour inclure une meilleure isolation entre les utilisateurs, un 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 de 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 plus de détails, consultez Protéger Android avec davantage de défenses du noyau Linux et Renforcer la pile multimédia .

Android 8.0 a mis à jour SELinux pour fonctionner avec Treble , qui sépare le code du fournisseur de niveau inférieur du cadre du système Android. Cette version a mis à jour la politique SELinux pour permettre aux fabricants de périphériques et aux fournisseurs de SOC de mettre à jour leurs parties de la politique, de créer leurs images ( vendor.img , boot.img , etc.), puis de mettre à jour ces images indépendamment de la plate-forme ou vice versa.

Bien qu'il soit possible d'exécuter une version de plate-forme (framework) supérieure/plus récente sur l'appareil, le cas inverse n'est pas pris en charge ; les images du fournisseur ( vendor.img/odm.img ) ne peuvent pas avoir une version plus récente que la plateforme ( system.img ). Ainsi, une version de plate-forme plus récente peut introduire des problèmes de compatibilité SELinux, car la politique SELinux de la plate-forme est à une version plus récente que les parties SELinux du fournisseur de la politique. Le modèle Android 8.0 fournit une méthode pour conserver la compatibilité afin d'éviter les OTA simultanées inutiles.

Ressources additionnelles

Pour obtenir de l'aide pour créer des politiques SELinux utiles, reportez-vous aux ressources suivantes.