La sécurité sous Android

La sécurité sous Android

Comme mentionné précédemment, le système Android est une plateforme open source où les applications sont publiées sur différents marchés sans être surveillées ou analysées pour conserver leur comportement. A ce titre, les mécanismes de protection de la plateforme Android sont utilisés au lieu de ceux du marché (Kim, Yoon, Yi, & Shin, 2012).

Protection par bacs à sable

Le modèle d’application Android garantit aux développeurs un ensemble complet de fonctionnalités et un environnement relativement sécurisé, particulièrement, pour les applications simples. Chaque application sous Android est  » bacs à sable  » dans son propre processus et l’espace du système de fichiers (Schiefer, 2014). Profitant des mécanismes de protection de l’espace de processus du noyau Linux, Android affecte à chaque application installée un ID utilisateur unique. A l’opposé des systèmes d’exploitation de bureau traditionnels (Linux, Windows, Mac, etc.), Android utilise généralement le concept de l’ID utilisateur pour représenter une application plutôt qu’un utilisateur humain. Cela permet au noyau de garder les applications confinées en mémoire, de restreindre d’une part l’accès au matériel ou aux services sous jacents et d’autre part l’accès au système de fichiers sur le périphérique. Par défaut, les données et ressources de chaque application sont hébergées dans un emplacement auquel seuls l’application et le Framework de base peuvent accéder : une conception essentielle pour le modèle de sécurité Android.

Les applications les plus avancées deviennent courantes, ces applications communiquent entre elles ou avec des appareils / serveurs via des réseaux.

Globalement, lors de l’installation des applications Android, chaque application recevra un identifiant utilisateur unique (UID). Le noyau Linux est responsable de l’application du contrôle d’accès aux ressources du système. Aucune application dès lors, ne pourra accéder aux fichiers d’autres applications. Par ailleurs, chaque application est exécutée dans des machines virtuelles distinctes. Ainsi, aucune application vulnérable n’affectera d’autres applications (Karmakar, 2012)

Le modèle des permissions 

Android protège les APIs sensibles en leur attribuant des autorisations afin d’amplifier les privilèges des applications sur l’appareil, y compris l’accès aux données et services stockés, tels que réseau, mémoire, etc. Toutes les autorisations requises pour accéder aux API sont protégées dans le fichier manifeste de chaque application (AndroidManifest.xml). Ils sont définies nécessairement par les développeurs d’application Android.

Les Permissions dans Android sont divisées en groupes d’autorisations organisées qui sont liées aux fonctionnalités d’un périphérique . Sous ce système, les demandes d’autorisation sont gérées au niveau du groupe et un seul groupe d’autorisations correspond à plusieurs déclarations d’autorisations dans le manifeste de l’application. Prenant à titre d’exemple, le groupe SMS qui inclut à la fois les déclarations READ_SMS et RECEIVE_SMS (Google , 2017).

Les permissions Android sont classées en quatre niveaux de protection :
• Permissions de protection normale : Les autorisations normales concernent les APIs dans lesquelles l’application doit accéder à des données ou des ressources en dehors du sandbox de l’application. Cependant, les risques pour la vie privée de l’utilisateur ou le fonctionnement des autres applications est très limité. Par exemple, l’autorisation de définir le fuseau horaire est une autorisation normale. Si une application déclare qu’elle a besoin de cette autorisation, le système accorde automatiquement l’autorisation à l’application.

• Permissions dangereuses : Les permissions dangereuses concernent des domaines dans lesquels l’application cherche à disposer des données ou des ressources qui impliquent des informations privées de l’utilisateur. Ils peuvent aussi affecter les données stockées de l’utilisateur ou le fonctionnement d’autres applications. La possibilité de déceler les contacts de l’utilisateur est par exemple une autorisation dangereuse. Si une application signale qu’elle a besoin d’une autorisation dangereuse, l’utilisateur doit accorder explicitement l’autorisation à l’application.