Linux sécurisé dans Android

Dans le cadre du modèle de sécurité Android, Android utilise Security-Enhanced Linux (SELinux) pour appliquer le contrôle d'accès obligatoire (MAC) sur tous les processus, même les processus exécutés avec des privilèges root/superuser (fonctionnalités Linux). De nombreuses entreprises et organisations ont contribué à l' implémentation SELinux d'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 déni 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 consigné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 violation sont consigné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 globale. 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 manière identique 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 du développement de politiques pour de nouveaux services (tout en gardant le reste du système en vigueur).

Fond

Le modèle de sécurité d'Android repose en partie sur le concept de sandbox 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 de l'application 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 d'un ensemble limité de domaines cruciaux ( installd , netd , vold et zygote ) à tout (plus de 60 domaines). Spécifiquement:

  • Tout est en mode application dans Android 5.x et supérieur.
  • 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 la permissivité de notre politique pour inclure une meilleure isolation entre les utilisateurs, un filtrage IOCTL, une menace réduite des services exposés, un resserrement 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 plus de détails, consultez Protéger Android avec plus de défenses du noyau 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 niveau inférieur du cadre du système Android. Cette version a mis à jour la politique SELinux pour permettre aux fabricants d'appareils et aux fournisseurs 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'avoir une version de plate-forme (framework) supérieure/plus récente en cours d'exécution sur l'appareil, le cas contraire 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 plate-forme ( system.img ). Ainsi, une version plus récente de la plate-forme 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és inutiles.

Ressources additionnelles

Pour obtenir de l'aide sur la construction de politiques SELinux utiles, reportez-vous aux ressources suivantes. Certains concepts SELinux ne sont pas utilisés par Android, consultez la section Spécificité lorsque vous envisagez une documentation externe.