Ce document explique comment les développeurs d'applications peuvent définir leurs propres autorisations à l'aide des fonctionnalités de sécurité fournies par Android. Si elle dispose d'autorisations personnalisées, une application peut partager ses ressources et ses fonctionnalités avec d'autres applications. Pour en savoir plus sur les autorisations, consultez la section Présentation des autorisations.
Arrière-plan
Android est un système d'exploitation à séparation de privilèges, dans lequel chaque application s'exécute avec une identité système distincte (identifiant de groupe et identifiant utilisateur Linux). Certaines parties du système sont également séparées en identités distinctes. Linux isole donc les applications les unes des autres ainsi que du système.
Les applications peuvent exposer leurs fonctionnalités à d'autres applications en définissant des autorisations que d'autres applications peuvent demander. Elles peuvent également définir des autorisations qui sont automatiquement accessibles pour toutes les autres applications signées avec le même certificat.
Signature d'application
Tous les APK doivent être signés avec un certificat dont la clé privée est détenue par leur développeur. Le certificat n'a pas besoin d'être signé par une autorité de certification. Il est normal et permis pour les applications Android d'utiliser des certificats autosignés. L'objectif des certificats sur Android est de distinguer les auteurs d'applications. Cela permet au système d'accorder ou de refuser aux applications l'accès aux autorisations au niveau de la signature et d'accorder ou de refuser la demande d'obtention, par une application, de la même identité Linux qu'une autre application.
Accorder des autorisations de signature après la fabrication de l'appareil
À partir d'Android 12 (niveau d'API 31), l'attribut knownCerts pour les autorisations au niveau de la signature vous permet de faire référence aux condensés des certificats de signature connus au moment de la déclaration.
Vous pouvez déclarer l'attribut knownCerts et utiliser l'option knownSigner dans l'attribut protectionLevel de votre application pour une autorisation au niveau de la signature spécifique. Ensuite, le système accorde cette autorisation à l'application à l'origine de la demande si l'un des signataires de la chaîne de signature de cette application, y compris le signataire actuel, correspond à l'un des condensés déclarés avec l'autorisation dans l'attribut knownCerts.
L'option knownSigner permet aux appareils et aux applications d'accorder des autorisations de signature à d'autres applications sans avoir à signer les applications lors de la fabrication et de l'expédition de l'appareil.
ID utilisateur et accès aux fichiers
Au moment de l'installation, Android attribue à chaque package un ID utilisateur Linux distinct. L'identité reste constante pendant toute la durée de vie du package sur cet appareil. Sur un appareil différent, le même package peut avoir un UID différent. L'important est que chaque package possède un UID distinct sur un appareil donné.
Étant donné que l'application des mesures de sécurité s'effectue au niveau du processus, le code de deux packages ne peut normalement pas s'exécuter dans le même processus, car ils doivent s'exécuter sous des utilisateurs Linux différents.
Toutes les données stockées par une application se voient attribuer l'ID utilisateur de cette application et ne sont généralement pas accessibles à d'autres packages.
Pour en savoir plus sur le modèle de sécurité d'Android, consultez la page Vue d'ensemble de la sécurité Android
Définir et appliquer des autorisations
Pour appliquer vos propres autorisations, vous devez d'abord les déclarer dans votre AndroidManifest.xml à l'aide d'un ou de plusieurs éléments <permission>.
Convention d'attribution de noms
Le système empêche plusieurs packages de déclarer une autorisation portant le même nom, sauf si tous les packages sont signés avec le même certificat. Si un package déclare une autorisation, le système ne permet pas non plus à l'utilisateur d'installer d'autres packages avec le même nom d'autorisation, sauf si ces packages sont signés avec le même certificat que le premier.
Nous vous recommandons de préfixer les noms d'autorisations avec le nom du package de l'application concernée, selon la méthode du nom de domaine inversé, suivi de .permission., puis d'une description de la fonctionnalité représentée par l'autorisation, en majuscules SNAKE_CASE. Par exemple, com.example.myapp.permission.ENGAGE_HYPERSPACE.
Suivez cette recommandation pour éviter les conflits dans les noms et pour identifier clairement le propriétaire et le rôle d'une autorisation personnalisée.
Exemple
Par exemple, une application qui doit contrôler quelles autres applications peuvent démarrer l'une de ses activités peut déclarer une autorisation pour cette opération comme suit :
<manifest
xmlns:android="http://schemas.android.com/apk/res/android"
package="com.example.myapp" >
<permission
android:name="com.example.myapp.permission.DEADLY_ACTIVITY"
android:label="@string/permlab_deadlyActivity"
android:description="@string/permdesc_deadlyActivity"
android:permissionGroup="android.permission-group.COST_MONEY"
android:protectionLevel="dangerous" />
...
</manifest>
L'attribut
protectionLevel est obligatoire et indique au système comment informer les utilisateurs des applications nécessitant l'autorisation ou quelles applications peuvent détenir cette autorisation, comme décrit dans la documentation associée.
L'attribut android:permissionGroup est facultatif et n'est utilisé que pour aider le système à afficher les autorisations auprès de l'utilisateur. Dans la plupart des cas, vous allez définir un groupe système standard (répertorié dans android.Manifest.permission_group), bien que vous puissiez définir un groupe vous-même, comme décrit dans la section suivante.
Nous vous recommandons d'utiliser un groupe existant, car cela simplifie l'affichage des autorisations aux utilisateurs.
Vous devez fournir à la fois un libellé et une description pour l'autorisation. Il s'agit de ressources de chaîne que l'utilisateur peut voir lorsqu'il consulte une liste d'autorisations (android:label) ou des détails sur une seule autorisation (android:description).
Le libellé doit être court et se composer de quelques mots décrivant la fonctionnalité clé protégée par l'autorisation. La description doit contenir quelques phrases décrivant l'action accordée au titulaire par l'autorisation. Notre convention se compose de deux phrases : la première décrit l'autorisation, et la seconde avertit l'utilisateur des problèmes qui peuvent se produire si une application dispose de cette autorisation.
Voici un exemple de libellé et de description pour l'autorisation CALL_PHONE :
<string name="permlab_callPhone">directly call phone numbers</string> <string name="permdesc_callPhone">Allows the app to call non-emergency phone numbers without your intervention. Malicious apps may cause unexpected calls on your phone bill.</string>
Créer un groupe d'autorisations
Comme indiqué dans la section précédente, vous pouvez utiliser l'attribut android:permissionGroup pour aider le système à décrire les autorisations accordées à l'utilisateur. Dans la plupart des cas, vous le définirez sur un groupe système standard (répertorié dans android.Manifest.permission_group), mais vous pouvez également définir votre propre groupe avec <permission-group>.
L'élément <permission-group> définit un libellé pour un ensemble d'autorisations : celles déclarées dans le fichier manifeste avec les éléments <permission> et celles déclarées ailleurs. Cela n'affecte que la façon dont les autorisations sont regroupées lorsqu'elles sont présentées à l'utilisateur. L'élément <permission-group> ne spécifie pas les autorisations qui appartiennent au groupe, mais il attribue un nom au groupe.
Vous pouvez placer une autorisation dans le groupe en attribuant le nom du groupe à l'attribut permissionGroup de l'élément <permission>.
L'élément <permission-tree> déclare un espace de noms pour un groupe d'autorisations définies dans le code.
Recommandations d'autorisations personnalisées
Vous pouvez définir des autorisations personnalisées pour vos applications et demander des autorisations personnalisées à d'autres applications en définissant des éléments <uses-permission>.
Toutefois, réfléchissez bien pour décider si cela est nécessaire.
- Si vous concevez une suite d'applications qui se partagent ainsi une fonctionnalité, essayez de concevoir les applications de sorte que chaque autorisation ne soit définie qu'une seule fois. Vous devez effectuer cette opération si les applications ne sont pas toutes signées avec le même certificat. Même si les applications sont toutes signées avec le même certificat, il est recommandé de ne définir chaque autorisation qu'une seule fois.
- Si cette fonctionnalité n'est disponible que pour les applications signées avec la même signature que celle qui la fournit, vous pourrez peut-être éviter de définir des autorisations personnalisées à l'aide de vérifications de signature. Lorsque l'une de vos applications envoie une requête à l'une de vos autres applications, celle-ci peut vérifier que les deux applications sont signées avec le même certificat avant de se conformer à la requête.
Si une autorisation personnalisée est nécessaire, déterminez si seules les applications signées par le même développeur que l'application effectuant la vérification des autorisations ont besoin d'y accéder, par exemple lors de la mise en œuvre de communications inter-processus sécurisées entre deux applications du même développeur. Si tel est le cas, nous vous recommandons d'utiliser les autorisations de signature. Les autorisations de signature sont transparentes pour l'utilisateur et évitent à celui-ci d'avoir à confirmer des autorisations, ce qui peut le dérouter.
Poursuivez votre lecture :
<uses-permission>- Documentation de référence de l'API pour la balise du fichier manifeste qui déclare les autorisations système requises par votre application.
Les sujets suivants peuvent aussi vous intéresser :
- Vue d'ensemble de la sécurité Android
- Discussion détaillée sur le modèle de sécurité de la plate-forme Android.