Le sandboxing applicatif d'Android

Le sandboxing applicatif d’Android
Adrien Grassein
Smile ECS
23 avril 2019
1 / 70

Plan I
1 Présentation
2 Introduction
3 Mécanisme Linux
Introduction
Processus
Droits d’accès
"Capabilities"
Security-Enhanced Linux (SELinux)
2 / 70

Plan II
4 La communication inter-processus
Introduction
Les permissions
5 Signature des applications
Principe
Danger des ROM customs
6 Questions
3 / 70

1 - Présentation
1 Présentation
4 / 70

1 - Présentation
Adrien Grassein
Expert
Technique
Smile ECS
8 ans d’expérience sur Android :
Parrot -> Automobile / Drone (Android 1.x 2.x 4.x et 5.x);
Redbend (Harman/Samsung) -> Virtualisation d’Android
(Android 5.x 6.x et 7.x);
Smile -> Automobile / Médical / Bancaire / Robotique (Android
6.x 7.x 8.x et 9.x).
5 / 70

1 - Présentation
ESN Spécialisée dans l’Open Source;
BU ECS : Issue du rachat d’OpenWide par Smile;
Spécialisée dans les systèmes embarqués;
Effectifs : 1800 au total (dont 100 dans la BU systèmes
embarqués);
Des agences en France et en Europe (4 agences en
France pour la BU);
Publication régulière de livres blancs;
Également organisme de formation.
6 / 70

2 - Introduction
2 Introduction
7 / 70

2 - Introduction
Qu’est-ce que le sandboxing?
Isolation des applications les unes des autres;
Notion de sécurité informatique;
Évite qu’un problème d’une application affecte les autres;
Évite qu’une application puisse "voir" ce que font les autres.
8 / 70

2 - Introduction
Pourquoi faire du sandboxing sur Android?
Android est un système ouvert;
Le but d’Android est d’installer des applications tierces;
De plus en plus d’applications sensibles disponibles (banques, transports,
médicales, etc).
9 / 70

2 - Introduction
Beaucoup de sources d’installation d’application :
Via des stores applicatifs;
Via mails / liens;
Via le debug (ADB).
10 / 70

2 - Introduction
De quoi cherche-t-on à se protéger?
Accès à des données par une application non autorisée;
Déni de service par une application.
11 / 70

3 - Mécanisme Linux
3 Mécanisme Linux
Introduction
Processus
Droits d’accès
"Capabilities"
12 / 70

3 - Mécanisme Linux - Introduction
3 Mécanisme Linux
Introduction
Processus
Droits d’accès
"Capabilities"
13 / 70

Android utilise beaucoup de mécanismes provenant de Linux pour se protéger :
Processus;
Droits d’accès;
"Capabilities";
SELinux.
14 / 70

Pourquoi les utiliser?
Android est (pour le moment) basé sur un kernel Linux;
Déjà implémentés;
Mécanismes éprouvés.
15 / 70

3 - Mécanisme Linux - Processus
3 Mécanisme Linux
Introduction
Processus
Droits d’accès
"Capabilities"
16 / 70

Quel est le problème à résoudre?
Du code a besoin de mémoire RAM pour s’exécuter (tas et pile);
Le contenu de cette mémoire peut être privé;
Le code peut arrêter de s’exécuter pour diverses raisons (mauvaise instruction, etc).
17 / 70

Si le code a accès à toute la mémoire :
Du code malicieux pourrait avoir accès à des informations privées;
ou altérer certaines informations.
18 / 70

Si tout le code s’exécute dans le même contexte :
Du code malicieux pourrait provoquer l’arrêt complet du code.
19 / 70

Solution :
Séparer chaque programme dans son propre contexte d’exécution;
Avec son propre espace mémoire (mémoire virtuelle);
Un mécanisme permet de vérifier qu’on ne sorte pas de son espace mémoire
(MPU);
Un mécanisme permet de traduire les adresses virtuelles en adresses physiques
(MMU).
20 / 70

Solution :
21 / 70

Android est multi-process :
Chaque application (au sens AndroidManifest) s’exécute (par défaut) dans un
processus dédié;
Chaque élément d’une application peut s’exécuter dans un processus différent;
Plusieurs applications peuvent fonctionner en même temps.
22 / 70

Lancement d’une application sous Android :
23 / 70

3 - Mécanisme Linux - Droits d’accès
3 Mécanisme Linux
Introduction
Processus
Droits d’accès
"Capabilities"
24 / 70

Comment gérer l’accès aux ressources du File System?
Certaines doivent être partagées;
D’autres doivent rester privées.
25 / 70

Solution :
Identifier chaque accesseur aux ressources;
Donner un propriétaire aux ressources;
Définir une politique d’accès.
26 / 70

Création d’utilisateur (UID) et de groupes (GID) :
Chaque accesseur est identifié par un UID;
Chaque accesseur peut faire parti de un ou plusieurs groupes;
Les ressources ont un propriétaire et un groupe.
27 / 70

Création d’une politique d’accès :
Chaque ressource possède une politique d’accès;
Des droits en lecture, écriture et exécution sont définis;
Pour le propriétaire, le groupe et les autres;
La politique d’accès est vérifiée par le kernel au moment de l’accès.
28 / 70

Exemple : Dossier /data/data d’Android
29 / 70

Cas d’une distribution Linux :
Chaque compte utilisateur possède son UID;
Chaque utilisateur appartient à des groupes;
(Presque) toutes les applications héritent de l’UID et des GID de l’utilisateur.
30 / 70

Exemple : Spotify
31 / 70

Cas d’Android :
Un UID est créé pour chaque application;
Chaque UID appartient à des groupes;
Les applications n’appartiennent qu’à un nombre restreint de groupes.
32 / 70

Exemple : Application "Hello World" :
33 / 70

Des utilisateurs spéciaux :
Le framework créé des utilisateurs spéciaux au démarrage (+ de 60);
L’utilisateur "root" n’est (presque) pas utilisé dans le monde Java;
L’utilisateur "system" est le plus important, il possède la plupart des droits du
système.
34 / 70

3 - Mécanisme Linux - "Capabilities"
3 Mécanisme Linux
Introduction
Processus
Droits d’accès
"Capabilities"
35 / 70

Comment contrôler l’accès à des ressources qui ne sont pas sur le FS;
Par exemple, "nicer" un processus, changer les droits d’un fichier, etc.
36 / 70

Solution : Création des "capabilities" :
Il existe 38 "capablities" sous Android;
Chaque processus peut posséder une ou plusieurs de celles-ci;
Le kernel vérifie que le processus possède bien la "capability" associée à l’action;
Par défaut les applications n’ont aucune "capability" sous Android.
37 / 70

3 - Mécanisme Linux - Security-Enhanced Linux (SELinux)
3 Mécanisme Linux
Introduction
Processus
Droits d’accès
"Capabilities"
38 / 70

Comment contrôler plus finement l’accès aux ressources?
Par exemple, empêcher de faire des ioctl.
39 / 70

Solution : Créer une politique de sécurité précise :
Des domaines SELinux sont définis à la compilation;
Chaque processus appartient à un domaine;
Il existe trois domaines pour les applications Android;
Le domaine le plus restreint est pour les applications tierces.
40 / 70

4 - La communication inter-processus
Introduction
Les permissions
41 / 70

4 - La communication inter-processus - Introduction
Introduction
Les permissions
42 / 70

Toutes les fonctions sont découpées dans des processus;
Les processus ont besoin de communiquer entre eux.
43 / 70

Création d’une IPC : Binder
Mécanisme permettant une communication simplifiée entre les process;
Communication point à point;
Des générateurs de code pour le Java et le C++;
Driver dans le kernel Linux (/dev/binder, /dev/hwbinder, /dev/vndbinder).
44 / 70

Transaction Binder :
45 / 70

4 - La communication inter-processus - Les permissions
Introduction
Les permissions
46 / 70

Comment s’assurer des droits du processus client?
47 / 70

Solution : Création du système de permissions
La communication se fait via un drvier générique, donc une protection à ce niveau
serait inefficace;
Les "serveurs" doivent vérifier les droits des clients;
Chaque service peut requérir d’avoir une permission pour l’utiliser;
Chaque application peut demander une permission;
Le "PackageManager" accorde ou non chaque permission à l’application;
Le service vérifie, via le PM, que l’application possède bien les droits nécessaires.
48 / 70

Diagramme de séquence :
49 / 70

Niveaux de permissions :
Il existe plusieurs niveaux de permissions, en fonction de la criticité de la fonction;
"normal" : accordée automatiquement;
"dangerous" : accordée directement par l’utilisateur;
"preinstalled" : accordée aux applications préinstallées;
"priviliedge" : accordée en fonction de la où l’application est installée;
Il en existe actuellement 23, sachant que certaines peuvent se combiner.
50 / 70

Lien entre permission et UID/GID :
Certaines permissions donnent accès à un ou plusieurs groupes;
Certains UID donnent accès à des permissions;
Tout ça est défini à la compilation par la plateforme.
51 / 70

Exemple : Permission android.permission.INTERNET
52 / 70

Exemple : Permission android.permission.INTERNET
53 / 70

Lien entre permission et UID/GID :
Certaines permissions sont automatiquement données à certains utilisateurs;
Par exemple l’utilisateur "shell" a beaucoup de permissions.
54 / 70

5 - Signature des applications
Principe
55 / 70

5 - Signature des applications - Principe
Principe
56 / 70

Comment identifier les applications?
Comment s’assurer que deux composants appartiennent au même développeur?
57 / 70

Solution : Signer chaque application avec un certificat public et une clef privée.
Permet de reconnaître le développeur de l’application;
Permet une mise à jour sûre (même signature que la version précédente);
Permet de partager des choses.
58 / 70

Partage de processus :
Deux applications signées avec la même clef peuvent s’exécuter dans le même
processus;
Permet de gagner en performance (évite de faire des IPC couteûses).
59 / 70

Partage d’UID :
Deux applications signées avec la même clef peuvent partager le même UID;
Permet d’accéder, par exemple, aux mêmes dossiers.
60 / 70

Partage de permission :
Une application peut demander à n’accorder une de ses permissions qu’à une
application signée de la même façon;
Permet d’avoir des permissions privées.
61 / 70

Les applications de base d’Android sont également signées :
4 certificats signent tous les composants de base;
"platform" est le plus important, il permet de demander l’UID "system";
Il permet aussi d’obtenir des permissions très dangereuses;
Ces certificats sont censés être secrets.
62 / 70

Certificats internes d’Android :
63 / 70

5 - Signature des applications - Danger des ROM customs
Principe
64 / 70

Sont souvent des ROM "open sources" :
Tous les certificats régissants Android sont publics (même ceux censés être privés);
Il est possible d’exécuter une application avec l’UID "system";
Il est possible d’obtenir les permissions du système.
65 / 70

Démonstration : Déni de service :
Application rebootant aléatoirement au boot le device;
Requiert la permission "android.permission.REBOOT" protégée par signature;
Requiert le certificat "platform".
66 / 70

Démonstration : Déni de service : Sur Pixel2 (ROM commerciale)
67 / 70

Démonstration : Déni de service : Sur Nitrogen8m (ROM custom)
68 / 70

6 - Questions
6 Questions
69 / 70

Le sandboxing applicatif d'Android

Contenu connexe

Similaire à Le sandboxing applicatif d'Android

Le sandboxing applicatif d'Android