Bac à sable d'application

La plate-forme Android tire parti de la protection Linux basée sur l'utilisateur pour identifier et isoler et isoler les ressources de l'application. Cela permet d'isoler 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 un 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 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. La simple, auditable et basé sur des systèmes d'exploitation UNIX vieux de plusieurs décennies la séparation des processus et des autorisations de fichiers.

Comme le bac à sable de l'application se trouve dans le noyau, ce modèle de sécurité s'étend à la fois au code natif et aux applications de l'OS. Tous les logiciels situés au-dessus comme les bibliothèques d'OS, le framework d'application, l'environnement d'exécution toutes les applications, s'exécutent dans le bac à sable des applications. Sur certaines plates-formes, les développeurs sont contraints à un framework de développement, à un ensemble d'API langue. Sur Android, il n'existe aucune restriction concernant la façon dont une application peut être qui sont nécessaires pour renforcer la sécurité ; à cet égard, le code natif en bac à sable, comme du code interprété.

Protections

En général, 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 a considérablement renforcé le contrôle d’accès discrétionnaire basé sur les UID d’origine (DAC) de bac à sable. Les versions précédentes d'Android incluaient les éléments suivants : protections:

• Dans Android 5.0, SELinux proposait une séparation obligatoire du contrôle des accès (MAC) entre le système et les applications. Cependant, toutes les applications tierces s'exécutaient Contexte SELinux de sorte que l'isolation inter-applications était principalement appliquée par UID DAC.
• Dans Android 6.0, le bac à sable SELinux a été étendu afin d'isoler les applications 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 pour le partage de fichiers

Définir les données de l'application comme accessibles à tous est une mauvaise pratique de sécurité. Accès est accordé à tout le monde. De plus, il est impossible de limiter l'accès aux seules ressources destinataire(s). Cette pratique a conduit à des fuites de divulgation d'informations et à la confusion et constitue une cible privilégiée des logiciels malveillants ciblant les applications contenant des données sensibles (telles que des 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 votre application accessibles à tous, suivez les consignes ci-dessous 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 le niveau de précision adéquat sans les nombreux inconvénients des autorisations UNIX accessibles plus de détails, reportez-vous à Principes de base des fournisseurs de contenu).
• Si votre application contient des fichiers qui devraient véritablement être accessibles à tous (photos, par exemple), elles doivent être spécifiques au support (photos, vidéos et fichiers audio, par exemple). uniquement) et stockées à l'aide de la fonction MediaStore. (Pour savoir comment ajouter un élément multimédia, consultez 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 les filtres de l'espace de stockage dans les applications ciblant Android 10, définissez la valeur de l'indicateur du 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.