Bac à sable d'application

La plate-forme Android exploite la protection basée sur l'utilisateur Linux pour identifier et isoler les ressources des applications. Cela isole les applications les unes des autres et protège les applications et le système contre les applications malveillantes. Pour ce faire, Android attribue un ID 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 kernel. Le noyau applique la sécurité entre les applications et le système au niveau du processus via des services Linux standards tels que les ID utilisateur et de groupe attribués aux applications. Par défaut, les applications ne peuvent pas interagir entre elles et ont un accès limité à l'OS. Si l'application A tente d'effectuer une action malveillante, comme lire les données de l'application B ou composer un numéro de téléphone sans autorisation, elle ne peut pas le faire, car elle ne dispose pas des droits d'utilisateur par défaut appropriés. Le bac à sable est simple, auditable et basé sur une séparation des processus et des autorisations de fichiers de type UNIX vieille de plusieurs décennies.

Étant donné que le bac à sable d'application se trouve dans le noyau, ce modèle de sécurité s'applique à la fois au code natif et aux applications de l'OS. Tous les logiciels situés au-dessus du noyau, tels que les bibliothèques de l'OS, le framework d'application, l'environnement d'exécution de l'application et toutes les applications, s'exécutent dans le bac à sable d'application. Sur certaines plates-formes, les développeurs sont limités à un framework de développement, un ensemble d'API ou un langage spécifiques. Sur Android, aucune restriction n'est imposée pour la manière dont une application peut être écrite afin de renforcer la sécurité. À cet égard, le code natif est aussi mis en bac à sable que le code interprété.

Protections

En règle générale, pour sortir du bac à sable d'application sur un appareil correctement configuré, il faut compromettre la sécurité du noyau Linux. Cependant, comme pour les autres fonctionnalités de sécurité, les protections individuelles qui appliquent le bac à sable de l'application ne sont pas invulnérables. Il est donc important de mettre en place une défense en profondeur pour éviter que des failles uniques ne compromettent l'OS ou d'autres applications.

Android s'appuie sur un certain nombre de protections pour appliquer le bac à sable de l'application. Ces mesures d'application 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 d'origine. Les versions précédentes d'Android incluaient les protections suivantes:

• Sous Android 5.0, SELinux fournissait une séparation du contrôle des 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. L'isolation entre les applications était donc principalement appliquée par le DAC UID.
• Dans Android 6.0, le bac à sable SELinux a été étendu pour isoler les applications au-delà de la limite par utilisateur physique. De plus, Android a également défini des valeurs par défaut plus sûres pour les données d'application: pour les applications avec targetSdkVersion >= 24, les autorisations DAC par défaut sur le répertoire d'accueil d'une application sont passées de 751 à 700. Cela a fourni une valeur par défaut plus sûre pour les données d'application privées (bien que les applications puissent remplacer ces valeurs par défaut).
• Sous Android 8.0, toutes les applications étaient configurées pour s'exécuter avec un filtre seccomp-bpf qui limitait les appels système que les applications étaient autorisées à utiliser, renforçant ainsi la limite entre l'application et le noyau.
• Sous Android 9, toutes les applications non privilégiées avec targetSdkVersion >= 28 doivent s'exécuter dans des bacs à sable SELinux individuels, en fournissant un MAC par application. Cette protection améliore la séparation des applications, empêche le forçage des valeurs par défaut sécurisées et, surtout, empêche les applications de rendre leurs données accessibles au monde entier.
• Sous Android 10, les applications ont une vue brute limitée du système de fichiers, sans accès direct à des chemins tels que /sdcard/DCIM. Toutefois, les applications conservent un accès brut complet à leurs chemins spécifiques au package, tels que renvoyés par toutes les méthodes applicables, telles que Context.getExternalFilesDir().

Consignes concernant le partage de fichiers

Définir les données de l'application comme accessibles à tous est une mauvaise pratique de sécurité. L'accès est accordé à tous et il n'est pas possible de limiter l'accès aux seuls destinataires prévus. Cette pratique a entraîné des fuites d'informations et des failles de délégation confuses. Elle est une cible privilégiée des logiciels malveillants qui ciblent les applications contenant des données sensibles (telles que les clients de messagerie). Sous Android 9 et versions ultérieures, le partage de fichiers de cette manière est explicitement interdit pour les applications avec targetSdkVersion>=28.

Au lieu de rendre les données de l'application accessibles à tous, suivez les consignes suivantes lorsque vous partagez des fichiers:

• Si votre application doit partager des fichiers avec une autre application, utilisez un fournisseur de contenu. Les fournisseurs de contenu partagent les données avec la granularité appropriée et sans les nombreux inconvénients des autorisations UNIX accessibles à tous (pour en savoir plus, consultez la section Principes de base des fournisseurs de contenu).
• Si votre application contient des fichiers qui doivent être accessibles à tous (par exemple, des photos), ils doivent être spécifiques aux contenus multimédias (photos, vidéos et fichiers audio uniquement) et stockés à l'aide de la classe MediaStore. (Pour savoir comment ajouter un élément multimédia, consultez la section Accéder aux fichiers multimédias de l'espace de stockage partagé.)

L'autorisation d'exécution Storage contrôle l'accès aux collections fortement typées via MediaStore. Pour accéder aux fichiers à faible typage tels que les PDF et la classe MediaStore.Downloads, les applications doivent utiliser des intents tels que l'intent ACTION_OPEN_DOCUMENT.

Pour activer le comportement d'Android 10, utilisez l'attribut de fichier manifeste requestLegacyExternalStorage et suivez les bonnes pratiques concernant les autorisations des applications.

• La valeur par défaut de l'indicateur de fichier manifeste est true pour les applications ciblant Android 9 (et versions antérieures).
• La valeur par défaut est "false" pour les applications ciblant Android 10. Pour désactiver temporairement la vue de stockage filtrée dans les applications ciblant Android 10, définissez la valeur de l'indicateur de fichier manifeste sur true.
• À l'aide d'autorisations limitées, le programme d'installation ajoute à la liste d'autorisation les applications autorisées pour le stockage hors bac à sable. Les applications non figurant sur la liste d'autorisation sont placées dans un bac à sable.