IBTS-77-RP-1000
Politiques de sécurité
Aujourd’hui, les Operating Systems (OSes) sur plate-formes PC, comme GNU/- Linux utilisent des politiques de sécurité de type Discretionary Access Control (DAC) [HRU76]. Dans ce modèle, un ensemble de sujets du système se voient fournir sur un ensemble d’objets du système des permissions sous la forme d’une matrice de contrôle d’accès A, où A(si,oj ) représente les droits que possède le sujet si sur l’objet oj . Le but de cette politique est de contrôler que les sujets effectuent sur les objets des actions qui sont spécifiquement autorisées.
Dans le cadre des systèmes Unix, les sujets sont des utilisateurs du système, les objets des fichiers présents dans le Virtual File System (VFS) et les droits se limitent à rwx .
Un autre type de politique de sécurité répandu est le modèle Mandatory Access Control (MAC). Celui-ci cherche à contrôler la façon dont circule l’information afin de détecter les flots suspects. Dans le cas de la confidentialité, c’est à dire de vérifier qu’une information confidentielle ne circule pas par un canal non-autorisé, le modèle utilisé est celui de Bell et LaPadula [LB96].
Ici, les sujets reçoivent des niveaux d’habilitation et les objets des niveaux de classification. La politique interdit ensuite la lecture si le niveau d’habilitation du sujet est inférieur au niveau de classification de l’objet ; similairement, l’écriture requiert un niveau d’habilitation inférieur au niveau de classification. Ainsi, l’information ne peut circuler que dans le sens du niveau de classification croissant. De la même façon, il est possible d’utiliser des modèles MAC pour assurer l’intégrité. Le modèle de Biba [BM77] permet de contrôler qu’aucune information de faible intégrité ne soit mélangée avec une information de forte intégrité. Pour cela, on inverse les contraintes du modèle de Bell et LaPadula ; l’écriture n’est autorisée que vers des objets d’intégrité moindres et la lecture seulement depuis les objets de plus forte intégrité.
À ce jour, plusieurs frameworks fournissant des politiques MAC sont disponibles sous Linux. On pourra citer à titre d’exemple SELinux, Tomoyo ou encore Smack, tous trois basés sur le framework Linux Security Modules (LSM).
Architectures de confiance
La sécurité informatique se base principalement sur trois concepts : la confidentialité, qui assure qu’une information ne soit connue que par des personnes légitimes ; l’authenticité, qui prouve un lien entre une information et une « personne » ; l’intégrité, qui montre la non-altération d’une information.
Ces concepts ont par exemple permis l’essors de méthodes formelles de vérifications de protocoles. Cependant, cette approche théorique oublie que la pratique pourrait se résumer à un utilisateur et à son ordinateur. L’ordinateur est toujours disponible pour rendre service à son propriétaire ; En revanche, son propriétaire n’est pas en mesure d’appréhender la complexité de l’ordinateur. Mon ordinateur fait-il réellement ce qu’il me dit faire ? Puis-je avoir confiance en ce qu’il fait ?
Ceci a conduit à l’apparition de l’informatique de confiance, ou trusted computing. Dans ce domaine, le concept central de confiance, que l’on peut résumer à « la machine fait ce qu’elle est censé faire, et uniquement cela », a été résolu à l’aide de l’intégrité. Il est impossible de montrer de façon raisonnable à un instant donné l’affirmation précédente ; On peut néanmoins considérer que c’est bien le cas dans un état initial.
Dans ce cas là, prouver qu’elle est de confiance revient alors à montrer son intégrité. En pratique, les approches se restreignent souvent à considérer que le matériel est de confiance ; Seul le logiciel peut avoir été modifié. Cela revient à considérer que le pouvoir de l’attaquant est dénué de toute présence physique. Ce type d’attaquant se manifeste par exemple sous la forme d’un cheval de Troie.
Créer un logiciel capable de prouver qu’il est de confiance est un casse tête insolvable. Si celui-ci est de confiance, il affirmera toujours qu’il l’est ; Si il ne l’est pas, il affirmera quand même qu’il l’est. Il est néanmoins possible de contourner cette difficulté en ayant recours à un élément matériel [PB03] sous la forme d’un tiers de confiance.
L’informatique de confiance fait usage du concept de Trusted Computing Base (TCB) et utilise le concept de trusted chain ainsi que le trusted boot. La TCB peut se résumer comme étant l’ensemble des parties qui composent un système et dont une modification met en danger la sécurité de l’ensemble du système. La trusted chain est une relation transitive de confiance entre les composants du système .
La TCB n’a pas besoin d’être la plus large possible ; Au contraire, il est intéressant de limiter la TCB au strict minimum, la trusted chain pouvant garantir l’intégrité du des autres composants.
Le trusted boot est quand à lui l’opération qui consiste à démarrer le système en partant de la TCB et en construisant une trusted chain. Celle-ci peut être obtenue de diverse manières, souvent en ayant recours à la cryptographie. Deux méthodes simples pour un élément de confiance consistent en vérifier un hash préalablement calculé ou vérifier une signature .
Android
Android 20 est un environnement de développement complet développé par l’Open Handset Alliance (OHA) et destiné en particulier à s’adresser au marché de la téléphonie mobile. Il se compose entre autres d’un système d’exploitation basé sur le noyau Linux et d’une machine virtuelle Java nommée Dalvik. Le noyau Linux fourni au système Android l’ensemble des primitives de base, tout particulièrement la gestion de la mémoire, la gestion des processus, un ensemble de pilotes ainsi que la gestion du réseau. Le noyau a par ailleurs reçu un certain nombre de patches afin d’améliorer le support des plate-formes mobiles. L’autre élément principal du système Android est Dalvik, la machine virtuelle Java qui permet l’exécution des application à l’intérieur de sandboxes.
Une application Android est sous la forme d’une archive au format .apk qui regroupe de façon assez similaire au format .jar ses constituants. L’exécutable est lui-même sous la forme d’un fichier au format .dex conçu avec un soucis de compacité. L’exécution est séparée en plusieurs classes, les activities qui correspondent à ce qui sera affiché à l’écran, et les providers qui fourniront des services aux autres applications.
Enfin, une application Android comprend aussi un fichier AndroidManifest.xml qui la décrit. On y retrouve la liste des activities et providers, mais aussi les droits que l’application requiert ainsi qu’une liste d’intents, des services que l’application est prête à satisfaire dans le cadre des communications inter-processus. Au dessus du noyau Linux, un certains nombre de bibliothèques natives, écrites en C ou C++, fournissent des services aux applications présentes dans le système Android. Celles-ci fournissent en particulier des interfaces natives Java pour être utilisables au sein de la machine virtuelle Java. À côté, les core libraries ainsi que le application framework layer, écrits tous les deux en Java, ajoutent respectivement un sous-ensembles des fonctionnalités de la Java 5 SE ainsi qu’un certains nombre d’extensions.
Mesure d’intégrité
Récement [NKZS10], des travaux ont démarrés afin d’adapter le système Android aux architectures de confiance. Ces travaux s’orientent spécifiquement autour de la capacité d’installer facilement des applications avec tous les risques que cela apporte.
En particulier, ils s’intéressent à la possibilité de prouver l’intégrité du système tout en permettant l’ajout de ces applications.
L’architecture du système se base sur les concepts du Trusted Computing Group – Mobile Workgroup (TCG-MW) [MPWb][MPWa], à savoir la mesure d’une empreinte cryptographique du système. Cependant, les MTM n’étant pas encore à l’heure actuelle disponibles sur les systèmes Android, la solution retenue consiste pour l’instant à utiliser un émulateur comme celui décrit dans [EB09].
La trusted chain permettant de prouver l’intégrité du système a ensuite été modifiée afin de s’adapter à la présence de la machine virtuelle Java. En plus du Stored Measurement Log (SML), qui contiendra ici par exemple une mesure de Dalvik ou de bibliothèques, un nouveau journal, appelé Android Measurement Log (AML), est chargé d’une façon similaire au SML de conserver les mesures des applications chargées dans les instances de la machine virtuelle Java. Ces mesures se font de deux manières. La première, au niveau de l’application, consiste à effectuer une mesure de Vchier .apk correspondant lors du démarrage de celle-ci. La seconde, plus fine, consiste quand à elle à installer un hook sur le chargeur de classes, assurant ainsi que la totalité des classes chargées dans la machine virtuelle Java aient bien été mesurées.
Confidentialité sous Android
Afin de répondre à une nécessité forte de confidentialité, nous souhaitons ajouter à Android le modèle de sécurité multi-niveau décrit par Bell et Lapadula [LB96].
Du fait que nous nous plaçons dans un système embarqué mono-utilisateur , nous ne cherchons pas à utiliser le modèle exhaustif ; nous réduisons donc le poset des habilitations à deux éléments qui seront nommés par la suite « haut » et « bas ».
Nous décrivons maintenant trois scenarii qui décrivent une action légitime selon les deux propriétés énoncées pour le modèle.
Remontée d’une donnée
« L’utilisateur veut transformer le niveau de classification d’une information de bas vers haut (write up). »
Déclassification d’une donnée
«L’utilisateur veut transformer le niveau de classification d’une information de haut vers bas (write-down).»
Cette action est en théorie illicite du point de vue du modèle ; Cependant si l’information est chiffrée et que les sujets de niveau de classification bas ne sont pas en mesure de la déchiffrer, alors le modèle est respecté.
|
Table des matières
1 Introduction
2 État de l’art
2.1 Politiques de sécurité
2.1.1 SELinux
2.1.2 MSSF
2.2 Virtualisation
2.2.1 Hyperviseurs
2.2.2 Noyau en espace utilisateur
2.2.3 Virtualisation par le système d’exploitation
2.3 Architectures de confiance
2.3.1 Trusted platform module
2.3.2 Mobile trusted module
2.3.3 ARM TrustZone
2.4 Android
2.4.1 SELinux
2.4.2 Mesure d’intégrité
3 Objectifs
4 Isolation sous Android
4.1 Confidentialité sous Android
4.2 Contexte technique
4.2.1 Conteneurs Linux
4.2.2 TOMOYO Linux
4.3 Modèle proposé
4.3.1 Organisation des conteneurs
4.3.2 Modèle retenu
5 Implémentation
5.1 Création des conteneurs
5.2 TOMOYO Linux
5.2.1 Introduction
5.2.2 Isolation d’Android
5.2.3 Implémentation de la diode
5.3 Évaluation des performances
5.3.1 Considérations
5.3.2 Performances des appels systèmes
5.3.3 Performance des connexions réseau
5.3.4 Conclusions
6 Conclusion
7 Travaux futurs
Télécharger le rapport complet
