Mettre en œuvre la sécurité

L'équipe de sécurité d'Android reçoit régulièrement des demandes d'informations sur la prévention des problèmes de sécurité potentiels sur les appareils Android. Nous effectuons également occasionnellement des contrôles ponctuels sur les appareils et informons les fabricants et les partenaires concernés des problèmes potentiels.

Cette page présente les bonnes pratiques de sécurité basées sur nos expériences, complétant la documentation Concevoir pour la sécurité que nous avons fournie aux développeurs. Elle inclut des détails propres à la création ou à l'installation de logiciels au niveau du système sur les appareils.

Pour faciliter l'adoption de ces bonnes pratiques, l'équipe de sécurité Android intègre, dans la mesure du possible, des tests dans la suite de tests de compatibilité Android (CTS) et dans Android Lint. Nous encourageons les implémentateurs d'appareils à contribuer à des tests qui peuvent aider d'autres utilisateurs d'Android (consultez les tests liés à la sécurité sur root/cts/tests/tests/security/src/android/security/cts).

Processus de développement

Appliquez les bonnes pratiques suivantes dans vos processus et environnements de développement.

Examiner le code source

L'examen du code source peut détecter un large éventail de problèmes de sécurité, y compris ceux identifiés dans ce document. Android encourage vivement l'examen manuel et automatisé du code source. Bonnes pratiques :

• Exécutez Android Lint sur tout le code de l'application à l'aide du SDK Android, puis corrigez les problèmes identifiés.
• Le code natif doit être analysé à l'aide d'un outil automatisé capable de détecter les problèmes de gestion de la mémoire, tels que les dépassements de mémoire tampon et les erreurs de décalage d'un bit.
• Le système de compilation Android est compatible avec de nombreux outils de nettoyage LLVM, tels que AddressSanitizer et UndefinedBehaviorSanitizer, qui peuvent être utilisés à cette fin.

Utiliser des tests automatisés

Les tests automatisés peuvent détecter un large éventail de problèmes de sécurité, y compris plusieurs problèmes abordés ci-dessous. Bonnes pratiques :

• Le CTS est régulièrement mis à jour avec des tests de sécurité. Exécutez la version la plus récente du CTS pour vérifier la compatibilité.
• Exécutez régulièrement CTS tout au long du processus de développement pour détecter les problèmes à un stade précoce et réduire le temps de correction. Android utilise CTS dans le cadre de l'intégration continue dans notre processus de compilation automatisé, qui effectue des compilations plusieurs fois par jour.
• Les fabricants d'appareils doivent automatiser les tests de sécurité des interfaces, y compris les tests avec des entrées mal formées (fuzz testing).

Images du système de signalisation

La signature de l'image système est essentielle pour déterminer l'intégrité de l'appareil. Bonnes pratiques :

• Les appareils ne doivent pas être signés avec une clé connue publiquement.
• Les clés utilisées pour signer des appareils doivent être gérées conformément aux pratiques standards du secteur pour la gestion des clés sensibles, y compris un module de sécurité matérielle (HSM) qui fournit un accès limité et auditable.

Signer des applications (APK)

Les signatures d'application jouent un rôle important dans la sécurité des appareils et sont utilisées pour les vérifications d'autorisations ainsi que pour les mises à jour logicielles. Lorsque vous sélectionnez une clé à utiliser pour signer des applications, il est important de déterminer si une application ne sera disponible que sur un seul appareil ou commune à plusieurs appareils. Bonnes pratiques :

• Les applications ne doivent pas être signées avec une clé connue publiquement.
• Les clés utilisées pour signer des applications doivent être gérées conformément aux pratiques standards du secteur pour la gestion des clés sensibles, y compris un HSM qui fournit un accès limité et auditable.
• Les applications ne doivent pas être signées avec la clé de la plate-forme.
• Les applications ayant le même nom de package ne doivent pas être signées avec des clés différentes. Cela se produit souvent lorsque vous créez une application pour différents appareils, en particulier lorsque vous utilisez la clé de plate-forme. Si l'application est indépendante de l'appareil, utilisez la même clé sur tous les appareils. Si l'application est spécifique à l'appareil, créez des noms de package uniques par appareil et par clé.

Publier des applications

Google Play permet aux fabricants d'appareils de mettre à jour des applications sans effectuer de mise à jour complète du système. Cela peut accélérer la réponse aux problèmes de sécurité et la diffusion de nouvelles fonctionnalités, et vous permet de vous assurer que votre application dispose d'un nom de package unique. Bonnes pratiques :

• Importez vos applications sur Google Play pour permettre les mises à jour automatiques sans nécessiter de mise à jour Over The Air (OTA) complète. Les applications importées mais non publiées ne sont pas directement téléchargeables par les utilisateurs, mais elles sont tout de même mises à jour. Les utilisateurs qui ont déjà installé l'application peuvent la réinstaller et/ou l'installer sur d'autres appareils.
• Créez un nom de package d'application clairement associé à votre entreprise, par exemple en utilisant une marque de l'entreprise.
• Les applications publiées par les fabricants d'appareils doivent être importées sur le Google Play Store pour éviter l'usurpation d'identité du nom de package par des utilisateurs tiers. Si un fabricant d'appareils installe une application sur un appareil sans la publier sur le Play Store, un autre développeur peut importer la même application, utiliser le même nom de package et modifier les métadonnées de l'application. Lorsque l'application est présentée à l'utilisateur, ces métadonnées sans rapport peuvent prêter à confusion.

Réagir aux incidents

Les parties externes doivent pouvoir contacter les fabricants d'appareils au sujet des problèmes de sécurité spécifiques à l'appareil. Nous vous recommandons de créer une adresse e-mail publiquement accessible pour gérer les incidents de sécurité. Bonnes pratiques :

• Créez une adresse security@votre-entreprise.com ou similaire et faites-en la promotion.
• Si vous constatez un problème de sécurité affectant le système d'exploitation Android ou des appareils Android de plusieurs fabricants, vous devez contacter l'équipe de sécurité Android en envoyant un signalement de bug de sécurité.

Implémenter des produits

Suivez les bonnes pratiques ci-dessous lorsque vous implémentez un produit.

Isolez les processus racine.

Les processus racine sont la cible la plus fréquente des attaques d'escalade des privilèges. Par conséquent, réduire le nombre de processus racine réduit le risque d'escalade des privilèges. CTS inclut un test d'information qui liste les processus racine. Bonnes pratiques :

• Les appareils doivent exécuter le code minimal nécessaire en tant qu'utilisateur racine. Dans la mesure du possible, utilisez un processus Android standard plutôt qu'un processus racine. Le Galaxy Nexus ICS ne compte que six processus racine: vold, inetd, zygote, tf_daemon, ueventd et init. Si un processus doit s'exécuter en tant que root sur un appareil, documentez-le dans une demande de fonctionnalité AOSP afin qu'il puisse être examiné publiquement.
• Dans la mesure du possible, le code racine doit être isolé des données non fiables et accessible via l'IPC. Par exemple, réduisez la fonctionnalité racine à un petit service accessible via Binder et exposez le service avec l'autorisation de signature à une application disposant de privilèges faibles ou nuls pour gérer le trafic réseau.
• Les processus racine ne doivent pas écouter sur un socket réseau.
• Les processus racine ne doivent pas fournir d'environnement d'exécution à usage général pour les applications (par exemple, une VM Java).

Isoler les applications système

En règle générale, les applications préinstallées ne doivent pas s'exécuter avec l'UID système partagé. Toutefois, si une application doit utiliser l'UID partagé du système ou d'un autre service privilégié, elle ne doit pas exporter de services, de broadcast receivers ni de fournisseurs de contenu auxquels les applications tierces installées par les utilisateurs peuvent accéder. Bonnes pratiques :

• Les appareils doivent exécuter le code minimal nécessaire en tant que système. Dans la mesure du possible, utilisez un processus Android avec son propre UID plutôt que de réutiliser l'UID du système.
• Dans la mesure du possible, le code système doit être isolé des données non approuvées et ne doit exposer l'IPC qu'à d'autres processus approuvés.
• Les processus système ne doivent pas écouter sur un socket réseau.

Isoler les processus

Le bac à sable d'application Android offre aux applications une attente d'isolation par rapport aux autres processus du système, y compris les processus racine et les débogueurs. Sauf si le débogage est spécifiquement activé par l'application et l'utilisateur, aucune application ne doit enfreindre cette attente. Bonnes pratiques :

• Les processus racine ne doivent pas accéder aux données des dossiers de données d'application individuels, sauf s'ils utilisent une méthode de débogage Android documentée.
• Les processus racine ne doivent pas accéder à la mémoire des applications, sauf s'ils utilisent une méthode de débogage Android documentée.
• Les appareils ne doivent pas inclure d'application qui accède aux données ou à la mémoire d'autres applications ou processus.

Fichiers SUID sécurisés

Les nouveaux programmes setuid ne doivent pas être accessibles par des programmes non approuvés. Les programmes setuid ont souvent été le lieu de vulnérabilités pouvant être utilisées pour obtenir un accès racine. Par conséquent, essayez de réduire au maximum la disponibilité du programme setuid pour les applications non approuvées. Bonnes pratiques :

• Les processus SUID ne doivent pas fournir de shell ni de backdoor pouvant être utilisés pour contourner le modèle de sécurité Android.
• Les programmes SUID ne doivent pas être accessibles en écriture par un utilisateur.
• Les programmes SUID ne doivent pas être lisibles ni exécutables par tous les utilisateurs. Créez un groupe, limitez l'accès au binaire SUID aux membres de ce groupe et placez toutes les applications qui doivent pouvoir exécuter le programme SUID dans ce groupe.
• Les programmes SUID sont une source courante de rootage d'appareils par les utilisateurs. Pour réduire ce risque, les programmes SUID ne doivent pas être exécutables par l'utilisateur du shell.

Le vérificateur CTS inclut un test informatif qui liste les fichiers SUID. Certains fichiers setuid ne sont pas autorisés par les tests CTS.

Socettes d'écoute sécurisées

Les tests CTS échouent lorsqu'un appareil écoute sur n'importe quel port, sur n'importe quelle interface. En cas de défaillance, Android vérifie que les bonnes pratiques suivantes sont appliquées:

• Aucun port d'écoute ne doit être présent sur l'appareil.
• Les ports d'écoute doivent pouvoir être désactivés sans mise à jour OTA. Il peut s'agir d'une modification de la configuration du serveur ou de l'appareil utilisateur.
• Les processus racine ne doivent pas écouter sur un port.
• Les processus appartenant à l'UID système ne doivent pas écouter sur un port.
• Pour l'IPC local à l'aide de sockets, les applications doivent utiliser un socket de domaine UNIX dont l'accès est limité à un groupe. Créez un descripteur de fichier pour l'IPC et définissez-le sur +RW pour un groupe UNIX spécifique. Toutes les applications clientes doivent appartenir à ce groupe UNIX.
• Certains appareils dotés de plusieurs processeurs (par exemple, un radio/modem distinct du processeur de l'application) utilisent des sockets réseau pour communiquer entre les processeurs. Dans ce cas, le socket réseau utilisé pour la communication entre processeurs doit utiliser une interface réseau isolée pour empêcher l'accès des applications non autorisées sur l'appareil (c'est-à-dire utiliser iptables pour empêcher l'accès des autres applications sur l'appareil).
• Les daemons qui gèrent les ports d'écoute doivent être résistants aux données mal formées. Google peut effectuer des tests de fuzz sur le port à l'aide d'un client non autorisé et, dans la mesure du possible, d'un client autorisé. Tout plantage est enregistré en tant que bug avec un niveau de gravité approprié.

Données des journaux

La journalisation des données augmente le risque d'exposition de ces données et réduit les performances du système. Plusieurs incidents de sécurité publics ont eu lieu en raison de l'enregistrement de données utilisateur sensibles par des applications installées par défaut sur les appareils Android. Bonnes pratiques :

• Les applications ou les services système ne doivent pas consigner les données fournies par des applications tierces susceptibles de contenir des informations sensibles.
• Les applications ne doivent pas consigner d'informations permettant d'identifier personnellement l'utilisateur dans le cadre de leur fonctionnement normal.

Le CTS inclut des tests qui vérifient la présence d'informations potentiellement sensibles dans les journaux système.

Limiter l'accès à l'annuaire

Les répertoires accessibles en écriture pour tous les utilisateurs peuvent présenter des failles de sécurité et permettre à une application de renommer des fichiers approuvés, de les remplacer ou de lancer des attaques basées sur des liens symboliques (les pirates informatiques peuvent utiliser un lien symbolique vers un fichier pour inciter un programme approuvé à effectuer des actions qu'il ne devrait pas effectuer). Les répertoires en écriture peuvent également empêcher la désinstallation d'une application de nettoyer correctement tous les fichiers qui lui sont associés.

Nous vous recommandons de ne pas autoriser l'écriture par tous les utilisateurs pour les répertoires créés par le système ou les utilisateurs racine. Les tests CTS aident à appliquer cette bonne pratique en testant les répertoires connus.

Fichiers de configuration sécurisés

De nombreux pilotes et services s'appuient sur des fichiers de configuration et de données stockés dans des répertoires tels que /system/etc et /data. Si ces fichiers sont traités par un processus privilégié et sont accessibles en écriture pour tous les utilisateurs, une application peut exploiter une faille dans le processus en créant des contenus malveillants dans le fichier accessible en écriture pour tous les utilisateurs. Bonnes pratiques :

• Les fichiers de configuration utilisés par les processus privilégiés ne doivent pas être lisibles par tous les utilisateurs.
• Les fichiers de configuration utilisés par les processus privilégiés ne doivent pas être accessibles en écriture pour tous les utilisateurs.

Stocker des bibliothèques de code natif

Tout code utilisé par les processus de fabricant d'appareils privilégiés doit se trouver dans /vendor ou /system. Ces systèmes de fichiers sont montés en lecture seule au démarrage. Nous vous recommandons de placer les bibliothèques utilisées par le système ou d'autres applications hautement privilégiées installées sur l'appareil dans ces systèmes de fichiers. Cela peut éviter une faille de sécurité qui pourrait permettre à un pirate informatique de contrôler le code exécuté par un processus privilégié.

Limiter l'accès des pilotes d'appareils

Seul le code approuvé doit avoir un accès direct aux pilotes. Dans la mesure du possible, l'architecture privilégiée consiste à fournir un daemon à usage unique qui met en proxy les appels au pilote et limite l'accès du pilote à ce daemon. Il est recommandé que les nœuds d'appareils de pilote ne soient pas lisibles ni accessibles en écriture par tous les utilisateurs. Les tests CTS aident à appliquer cette bonne pratique en recherchant des instances connues de pilotes exposés.

Désactiver ADB

Android Debug Bridge (adb) est un outil de développement et de débogage utile, mais il est conçu pour être utilisé dans des environnements sécurisés et contrôlés. Il ne doit pas être activé pour une utilisation générale. Bonnes pratiques :

• ADB doit être désactivé par défaut.
• ADB doit exiger de l'utilisateur qu'il l'active avant d'accepter les connexions.

Déverrouiller les bootloaders

De nombreux appareils Android sont compatibles avec le déverrouillage, ce qui permet au propriétaire de l'appareil de modifier la partition système et/ou d'installer un système d'exploitation personnalisé. Les cas d'utilisation courants incluent l'installation d'une ROM tierce et l'exécution de développement au niveau du système sur l'appareil. Par exemple, le propriétaire d'un appareil Google Nexus peut exécuter fastboot oem unlock pour démarrer le processus de déverrouillage, qui présente le message suivant à l'utilisateur:

Il est recommandé que les appareils Android déverrouillables effacent de manière sécurisée toutes les données utilisateur avant d'être déverrouillés. Si toutes les données ne sont pas correctement supprimées lors du déverrouillage, un pirate informatique à proximité peut obtenir un accès non autorisé aux données utilisateur Android confidentielles. Pour éviter la divulgation des données utilisateur, un appareil compatible avec le déverrouillage doit l'implémenter correctement (nous avons constaté de nombreux cas où les fabricants d'appareils ont mal implémenté le déverrouillage). Un processus de déverrouillage correctement implémenté présente les propriétés suivantes:

• Lorsque l'utilisateur confirme la commande de déverrouillage, l'appareil doit commencer immédiatement à effacer les données. L'indicateur unlocked ne doit pas être défini tant que la suppression sécurisée n'est pas terminée.
• Si une suppression sécurisée ne peut pas être effectuée, l'appareil doit rester verrouillé.
• Si l'appareil de bloc sous-jacent est compatible, ioctl(BLKSECDISCARD) ou un équivalent doit être utilisé. Pour les appareils eMMC, cela signifie utiliser une commande Secure Erase ou Secure Trim. Pour eMMC 4.5 et versions ultérieures, cela signifie utiliser une opération d'effacement ou de suppression normale suivie d'une opération de nettoyage.
• Si BLKSECDISCARD n'est pas compatible avec l'appareil de bloc sous-jacent, ioctl(BLKDISCARD) doit être utilisé à la place. Sur les appareils eMMC, il s'agit d'une opération de suppression normale.
• Si BLKDISCARD n'est pas compatible, l'écrasement des périphériques de bloc avec des zéros est acceptable.
• Un utilisateur final doit avoir la possibilité d'exiger que les données utilisateur soient effacées avant de flasher une partition. Par exemple, sur les appareils Nexus, cela se fait via la commande fastboot oem lock.
• Un appareil peut enregistrer, via des efuses ou un mécanisme similaire, si un appareil a été déverrouillé et/ou verrouillé à nouveau.

Ces exigences garantissent que toutes les données sont détruites à la fin d'une opération de déverrouillage. Le non-respect de ces protections est considéré comme une faille de sécurité de niveau modéré.

Un appareil déverrouillé peut être verrouillé à nouveau à l'aide de la commande fastboot oem lock. Le verrouillage du bootloader offre la même protection des données utilisateur avec le nouvel OS personnalisé que celle disponible avec l'OS d'origine du fabricant de l'appareil (par exemple, les données utilisateur seront effacées si l'appareil est à nouveau déverrouillé).