Bac à sable d'application

La plate-forme Android tire parti de la protection basée sur l'utilisateur Linux pour identifier et isoler les ressources de l'application. Cela isole les applications les unes des autres et protège les applications et le système des applications malveillantes. Pour ce faire, Android attribue un identifiant utilisateur unique (UID) à chaque application Android et l'exécute dans son propre processus.

Android utilise l'UID pour configurer une application Sandbox au niveau du noyau. Le noyau applique la sécurité entre les applications et le système au niveau du processus via des fonctionnalités Linux standard telles que les ID d'utilisateur et de groupe qui sont attribués aux applications. Par défaut, les applications ne peuvent pas interagir entre elles et ont un accès limité au système d'exploitation. Si l'application A essaie de faire quelque chose de malveillant, comme lire les données de l'application B ou appeler le téléphone sans autorisation, elle ne peut pas le faire car elle ne dispose pas des privilèges d'utilisateur par défaut appropriés. Le bac à sable est simple, vérifiable et basé sur une séparation des processus et des autorisations de fichiers de type UNIX, vieille de plusieurs décennies.

Étant donné que l'Application Sandbox est dans le noyau, ce modèle de sécurité s'étend à la fois au code natif et aux applications du système d'exploitation. Tous les logiciels situés au-dessus du noyau, tels que les bibliothèques du système d'exploitation, le cadre d'application, l'environnement d'exécution de l'application et toutes les applications, s'exécutent dans l'Application Sandbox. Sur certaines plates-formes, les développeurs sont contraints à un cadre de développement, un ensemble d'API ou un langage spécifique. Sur Android, il n'y a pas de restrictions sur la façon dont une application peut être écrite pour renforcer la sécurité ; à cet égard, le code natif est aussi sandboxé que le code interprété.

Protections

Généralement, pour sortir de l'Application Sandbox dans un appareil correctement configuré, il faut compromettre la sécurité du noyau Linux. Cependant, à l'instar d'autres fonctionnalités de sécurité, les protections individuelles appliquant le bac à sable de l'application ne sont pas invulnérables. La défense en profondeur est donc importante pour empêcher que des vulnérabilités uniques n'entraînent la compromission du système d'exploitation ou d'autres applications.

Android s'appuie sur un certain nombre de protections pour appliquer le sandbox de l'application. Ces applications ont été introduites au fil du temps et ont considérablement renforcé le bac à sable de contrôle d'accès discrétionnaire (DAC) basé sur l'UID. Les versions précédentes d'Android incluaient les protections suivantes :

  • Dans Android 5.0, SELinux a fourni une séparation de contrôle d'accès obligatoire (MAC) entre le système et les applications. Cependant, toutes les applications tierces s'exécutaient dans le même contexte SELinux, de sorte que l'isolement inter-applications était principalement appliqué par UID DAC.
  • Dans Android 6.0, le bac à sable SELinux a été étendu pour isoler les applications à travers la limite par utilisateur physique. De plus, Android a également mis en valeurs par défaut plus sûres pour les données d'application: Pour les applications avec targetSdkVersion >= 24 , les autorisations par défaut du CAD sur la maison dir d'une application passée de 751 à 700. Cette condition par défaut plus sûr pour les données d'applications privées (bien que les applications peuvent remplacer ces valeurs par défaut) .
  • Dans les applications 8,0, toutes les applications ont été mis à fonctionner avec un seccomp-bpf filtre qui limite les syscalls que les applications ont été autorisés à utiliser, renforçant ainsi la limite app / noyau.
  • Dans Android 9 toutes les applications non-privilégiés avec targetSdkVersion >= 28 doivent fonctionner dans des sandbox individuels SELinux, fournissant MAC sur une base par application. Cette protection améliore la séparation des applications, empêche le remplacement des valeurs par défaut sûres et (le plus important) empêche les applications de rendre leur monde de données accessible.
  • Dans Android 10, les applications ont une vue brute limitée du système de fichiers, sans accès direct aux chemins tels que /sdcard/DCIM. Cependant, les applications conservent un accès brut complet à leurs chemins spécifiques à l' emballage, retourné par les méthodes applicables, comme Context.getExternalFilesDir () .

Instructions pour le partage de fichiers

Définir les données de l'application comme étant accessibles dans le monde entier est une mauvaise pratique de sécurité. L'accès est accordé à tout le monde et il n'est pas possible de limiter l'accès au(x) seul(s) destinataire(s). Cette pratique a conduit à des fuites de divulgation d'informations et à des vulnérabilités confuses des adjoints, et est une cible de prédilection pour les logiciels malveillants qui ciblent les applications contenant des données sensibles (telles que les clients de messagerie). Dans Android 9 et plus, le partage de fichiers est ainsi explicitement refusé pour des applications avec targetSdkVersion>=28 .

Au lieu de rendre les données de l'application accessibles dans le monde entier, utilisez les directives suivantes lors du partage de fichiers :

  • Si vos besoins d'applications pour partager des fichiers avec une autre application, utilisez un fournisseur de contenu . Les fournisseurs de contenu partagent des données avec la granularité appropriée et sans les nombreux inconvénients des autorisations UNIX accessible du monde (pour plus de détails, reportez - vous à la base de fournisseur de contenu ).
  • Si votre application contient des fichiers qui devraient être véritablement accessibles au monde (photos), ils doivent être spécifiques aux médias (photos, vidéos et fichiers audio uniquement) et stockés en utilisant la MediaStore classe. (Pour plus de détails sur la façon d'ajouter un élément média, voir les fichiers multimédias d' accès de stockage partagé .)

Les contrôles d'autorisation d'exécution de stockage d' accès aux collections fortement typées par MediaStore. Pour accéder à des fichiers faiblement typés tels que les fichiers PDF et la MediaStore.Downloads classe, les applications doivent utiliser des intentions comme l' ACTION_OPEN_DOCUMENT intention.

Pour activer le comportement Android 10, utilisez le requestLegacyExternalStorage attribut manifeste, et suivez les meilleures pratiques Autorisations de l' application .

  • La valeur par défaut du pavillon manifeste est true pour les applications de ciblage applications 9 (et inférieure).
  • La valeur par défaut est false pour les applications ciblant Android 10. Pour désactiver temporairement la vue de stockage filtré dans des applications ciblant Android 10, définissez la valeur du drapeau manifeste true .
  • À l'aide d'autorisations restreintes, le programme d'installation met en liste blanche les applications autorisées pour le stockage sans bac à sable. Les applications qui ne sont pas sur liste blanche sont mises en bac à sable.