La plate-forme Android profite de la protection basée sur les utilisateurs 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 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 un bac à sable d'application au niveau du noyau. Le noyau applique la sécurité entre les applications et le système au niveau des processus via des fonctionnalités Linux standard telles que les ID d'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é au système d'exploitation. Si l'application A tente de faire quelque chose de malveillant, 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 privilèges 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 se trouve 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, le runtime d'application et toutes les applications, s'exécutent dans l'Application Sandbox. Sur certaines plates-formes, les développeurs sont limités à un cadre de développement, un ensemble d'API ou un langage spécifique. Sur Android, il n'existe aucune restriction sur la façon dont une application peut être écrite, nécessaire pour renforcer la sécurité ; à cet égard, le code natif est aussi sandboxé que le code interprété.
Protections
Généralement, pour sortir du Application Sandbox sur un périphérique 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 sandbox de l’application ne sont pas invulnérables. Une défense en profondeur est donc importante pour empêcher qu’une seule vulnérabilité ne conduise à une compromission du système d’exploitation ou d’autres applications.
Android s'appuie sur un certain nombre de protections pour appliquer le bac à sable des applications. Ces mesures ont été introduites au fil du temps et ont considérablement renforcé le bac à sable original 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 fournissait une séparation obligatoire du contrôle d'accès (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'isolation inter-applications était principalement appliquée par l'UID DAC.
- Dans Android 6.0, le bac à sable SELinux a été étendu pour isoler les applications au-delà des limites de chaque 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 personnel 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). . - Dans 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 frontière application/noyau. - Dans Android 9, toutes les applications non privilégiées avec
targetSdkVersion >= 28
doivent s'exécuter dans des bacs à sable SELinux individuels, fournissant un MAC pour chaque application. Cette protection améliore la séparation des applications, empêche le remplacement des valeurs par défaut sécurisées et (plus important encore) 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 au package, tel que renvoyé par toutes les méthodes applicables, telles que Context.getExternalFilesDir() .
Lignes directrices pour le partage de fichiers
Définir les données de l'application comme étant accessibles au 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 uniquement au(x) destinataire(s) prévu(s). Cette pratique a conduit à des fuites d'informations et à des vulnérabilités confuses, et constitue une cible privilégiée pour les 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 des applications accessibles au monde entier, suivez les directives suivantes lors du partage de 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 plus de détails, reportez-vous aux principes de base des fournisseurs de contenu ).
- Si votre application contient des fichiers qui devraient véritablement être accessibles au monde entier (comme des photos), ils doivent être spécifiques au média (photos, vidéos et fichiers audio uniquement) et stockés à l'aide de la classe MediaStore . (Pour plus de détails sur la façon d'ajouter un élément multimédia, voir Accéder aux fichiers multimédias à partir du stockage partagé .)
L'autorisation d'exécution Storage contrôle l'accès aux collections fortement typées via MediaStore . Pour accéder à des fichiers faiblement typés tels que les PDF et la classe MediaStore.Downloads , les applications doivent utiliser des intentions telles que l'intention ACTION_OPEN_DOCUMENT .
Pour activer le comportement d'Android 10, utilisez l'attribut manifeste requestLegacyExternalStorage
et suivez les bonnes pratiques en matière d'autorisations d'application .
- La valeur par défaut de l’indicateur de 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 l'affichage du stockage filtré dans les applications ciblant Android 10, définissez la valeur de l'indicateur du manifeste sur
true
. - À l'aide d'autorisations restreintes, le programme d'installation met en liste blanche les applications autorisées pour le stockage hors bac à sable. Les applications qui ne figurent pas sur la liste blanche sont mises en bac à sable.