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 Wots 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).
Virtualisation
La virtualisation consiste à faire exécuter un système prévu pour une architecture donnée sur une autre architecture ; ce système est dit virtualisé. On distingue la couche applicative virtualisante comme hôte du système virtualisé comme invité.
Hyperviseurs : Un Virtual Machine Monitor (VMM) ou hyperviseur est une couche logicielle qui permet l’exécution concurrente de plusieurs OS sur une même machine physique [Gol74]. Elle fourni en particulier une abstraction de la machine physique sous la forme d’une Machine Virtuelle (Virtual Machine) (VM) ; une isolation entre les VMs.
Un VMM aura pour tâche au minimum de gérer le démarrage des VMs et le partage des ressources du système. En particulier, la configuration de la Memory Management Unit (MMU) permet la séparation des espaces mémoires des OSes; La répartition des interruptions est aussi nécessaire en particulier pour le partage du temps.
Enfin, l’ensemble réalise aussi la répartition des resources physiques du système, en particulier les périphériques d’entrée-sortie.
On distingue deux type de virtualisations avec hyperviseur ; la paravirtualisation, dans laquelle l’invité est modifié pour dialoguer avec son hôte par le biais d’hypercalls;
la virtualisation complète ou hardware-assisted virtualization, qui requiert des mécanismes de protection matériels entre les VMs.
Les deux méthodes nécessitent un matériel spéciVque avec un mode d’exécution privilégié pour le VMM ainsi que des instructions privilégiées associées.
Noyau en espace utilisateur : Un noyau en espace utilisateur ou user-space kernel est un noyau modifié pour être exécuté dans l’espace utilisateur d’un autre OS. Du fait de sa présence en espace utilisateur, le noyau invité abandonne tout contrôle de l’espace noyau à son hôte et fourni en échange des interfaces avec le noyau hôte. Ainsi, une application du système invité devient à l’exécution un processus du système hôte ; la communication entre l’application et le système invité est émulée à l’aide d’Inter Process Communication (IPC) du système hôte.
Un exemple de noyau en espace utilisateur est L4Linux , un noyau Linux modifié s’exécutant au dessus d’un micro-noyau L4 . Un des principaux avantages d’une telle technique étant de réduire à son strict minimum le code devant être vérifié [KEH+09].
On peut citer comme autre exemple User-Mode Linux (UML) qui permet d’exécuter Linux dans un Linux.
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 (2.4) qui la décrit. On y retrouve la liste des activities et providers, mais aussi les droits que l’application requiert 21 ainsi qu’une liste d’intents, des services que l’application est prête à satisfaire dans le cadre des communications inter-processus.
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
