Soutenance mémoire
SELinux
SELinux permet la mise en place de plusieurs types de politiques de sécurité, parmis lesquelles la plus classique est Domain Type Enforcement (DTE). Dans ce modèle, les éléments du système reçoivent un identifiant supplémentaire orthogonal à la politique DAC déjà présente ; on appelle domaine un identifiant qui porte sur un sujet (processus) et type un identifiant qui porte sur un objet (fichier). La façon dont les identifiants sont données est donnée à l’aide des fichiers de configuration de SELinux. Par défaut, toute tentative de la part d’une entité d’accéder à un objet est bloquée.Celle-ci doit être explicitement autorisée par la politique. Néanmoins, pour ajouter de la souplesse au système, il est possible d’effectuer une transition d’un domaine à un autre. Celle-ci peut se faire soit implicitement, dans ce cas elle est prévue dans la politique, soit explicitement. Par exemple, lors du démarrage d’un serveur HTTP, une transition se fait implicitement vers le domaine http_d sous lequel s’exécute alors le serveur. La configuration de SELinux donne le type http_conf_t aux fichiers de configurations du serveur présents dans /etc/httpd/ et le type http_t aux fichiers présents dans /srv/http/. Pour finir, le domaine http_d a les droits en lecture sur les types http_conf_t et http_t pour pouvoir lire sa configuration et le contenu des sites qu’il met à disposition. SELinux présente cependant le désavantage d’avoir été conçu pour des plateformes PC ; son overhead et son exhaustivité sont peu adaptés à des équipements mobiles sous Linux. Plusieurs projets, comme Tomoyo 4 ou Smack 5 , se reposent sur le framework LSM introduit par SELinux pour proposer une alternative légère pour ces environnements.
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 resources 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.
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.
Conteneurs Linux
Linux dispose à partir des versions 2.6.15 et ultérieures d’un mécanisme de virtualisation légère appelé « conteneurs Linux » avec les outils en espace utilisateurs lxc . Il s’agit d’un projet à long terme qui est à ce jour toujours en cours d’implémentation et d’inclusion dans la branche principale de Linux . Les conteneurs reposent sur les sous-systèmes du noyau et les groupes de contrôle qui sont deux mécanismes de labélisation pour les tâches et les ressources du système respectivement. Un groupe de contrôle, ou cgroup, est un ensembles de tâches du système d’exploitation. Chacun de ces ensembles de tâches peut être lié à un ou plusieurs soussystèmes assurant la configuration de l’accès aux ressources fournies par le noyau aux tâches de cet ensemble. Les groupes de contrôle sont par ailleurs organisés de manière hiérarchique sous la forme d’un arbre. Enfin, comme toute tâche fait partie d’un unique groupe de contrôle, celles-ci sont liées par défaut à la racine de cet arbre 5 ou au groupe de contrôle du processus parent si celui-ci en dispose d’un.
Performances des appels systèmes
Nous mesurons ici dans un premier temps les performances des appels systèmes ;Les mécanismes ajoutés, en particulier LSM, y étant directement liés, on obtient ainsi une vue très Vne de l’impact sur le système. Les mesures ont été réalisées à l’aide de l’outil lmbench fourni par le projet Debian. Plusieurs cas ont été considérés :
-vanilla : système Android original sur le noyau modiVé, politique de sécurité DAC ;
-TOMOYO (empty) : système Android original sur le noyau modiVé, politique de sécurité MAC vide ;
-TOMOYO : système Android original sur le noyau modiVé, politique de sécurité MAC en cours d’apprentissage (~300 domaines) ;
-TOMOYO+lxc (empty) : système Debian dans un conteneur Linux, politique de sécurité MAC vide ;
-TOMOYO+lxc : système Debian dans un conteneur Linux, politique de sécurité MAC en cours d’apprentissage (idem).
Un ensemble de 20 jeux ont été lancé pour chaque cas sur le système Android modiVé et au repos et tournant sur un processeur Snapdragon QSD8250 .
Performance des connexions réseau
Nous nous intéressons ici dans un deuxième temps aux performances des communications inter-processus. Plus particulièrement, nous allons observer l’impact sur la bande passante maximale sur des sockets lors d’une communication sur un réseau virtuel qui relie l’hôte aux conteneurs. De même, plusieurs cas pouvant correspondre à des cas pratiques ont été évoqués :
· hors-conteneur : communication entre deux applications en dehors de tout conteneur ;
· intra-conteneur : communication entre deux applications situées dans le même conteneur ;
· inter-conteneur : communication entre deux applications situées dans deux conteneurs séparés ;
· conteneur-hôte : communication entre une application située dans un conteneur et une application hors-conteneur ;
Pour se faire, nous réalisons un réseau virtuel interne au système. Celui-ci se compose :
· d’une interface pont virtuel sur la machine hôte ;
· d’une paire d’interfaces réseau virtuel, une extrémité étant liée à l’interface pont virtuel de l’hôte. Les mesures ont été réalisées à l’aide de l’outil iperf sur un système au repos.
|
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 conVance
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 ConVdentialité 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
