Soutenance mémoire
Pour assurer la sécurité d’un système informatique, il convient en premier lieu de définir puis de mettre en œuvre une politique de sécurité. Celle-ci peut s’exprimer en termes d’exigences concernant la confidentialité (seules les personnes autorisées peuvent lire les données), l’intégrité (seules les personnes autorisées peuvent modifier les données) et la disponibilité (les personnes autorisées peuvent effectivement accéder aux données). La mise en œuvre de la politique passe par l’utilisation de méthodes préventives (par exemple, Linux implémente un contrôle d’accès DAC [Lam74]). Ces méthodes sont nécessaires mais souvent insuffisantes et il convient de s’assurer, a posteriori, du respect de la politique. La détection d’intrusion consiste à surveiller un système informatique dans le but de détecter les tentatives d’intrusion, c’est-à-dire un contournement de la politique de sécurité. Une attaque contre un système est la tentative par un acteur (logiciel ou humain) de réaliser une intrusion. Une intrusion repose sur l’exploitation de vulnérabilités du système, par exemple des bogues logiciels.
Il existe deux approches pour détecter les intrusions. Les IDS (Intrusion Detection System) signature-based [DDW99] s’attachent à repérer dans les données du système (par exemple, les journaux fournis par le système d’exploitation pour un host-based IDS ou les paquets réseaux pour un network-based IDS) qu’ils observent les « signatures » d’attaques ou d’intrusions connues. Le grand défaut de cette approche est de ne pouvoir détecter que les exploitations de vulnérabilités connues. L’autre approche utilisée dans la détection d’intrusion est l’approche comportementale [DDW99] : plutôt que de rechercher une attaque, on modélise le comportement normal du système et on vérifie que ce dernier ne s’en éloigne pas. La difficulté est justement dans la définition de ce comportement. Les IDS auxquels nous allons nous intéresser sont des IDS dits policy-based [KR02]. Dans cette approche, le comportement normal du système est modélisé par l’expression d’une politique de sécurité.
KBlare [VTTCM10] et jBlare [Ass11] sont deux IDS comportementaux policy-based et basés sur les flux d’information qui ont été développés par l’équipe CIDre. Ils implémentent le même modèle à deux niveaux différents : le premier au niveau du noyau Linux et le second au niveau de la JVM. L’équipe CIDre cherche à les faire coopérer. En effet, kBlare surveille tous les flux du système mais il est obligé de sur-approximer l’action des processus. Si un processus accède à deux fichiers, kBlare estime qu’il a mélangé leurs contenus même si ce n’est pas le cas. JBlare, quant à lui, surveille les flux au sein des applications Java mais son utilisation nécessite de spécifier explicitement les labels de sécurité. Une coopération entre kBlare et jBlare permettrait à kBlare de ne plus sur-approximer les flux d’information des applications Java et dispenserait le développeur de devoir spécifier les labels de son code Java, les niveaux de sécurité des variables étant hérités de kBlare.
Sécurité d’un système d’information
L’administrateur sécurité définit, pour un système d’information, une politique de sécurité qui fixe des objectifs en terme de confidentialité, d’intégrité et de disponibilité. Une fois cette politique définie, il convient d’implémenter des mécanismes permettant d’assurer son respect.
Contrôle d’accès
Le contrôle d’accès vise à assurer que chaque accès à une ressource se fait dans le respect de la politique de sécurité établie. Il existe plusieurs modèles proposés dans la littérature, nous n’en présenterons que deux : le DAC (implémenté par défaut dans Linux ou Windows) et le MAC [SS94] (implémenté dans les extensions de sécurité comme SELinux [SVS01] ou AppArmor [Bau06]).
DAC
Le DAC (pour Discretionary Access Control) est le modèle de contrôle d’accès utilisé par défaut dans la plupart des systèmes d’exploitation. Il garantit que tous les accès directs à une ressource sont explicitement autorisés par la politique de sécurité. Ainsi, les différents utilisateurs possèdent des permissions de réaliser des actions (typiquement lecture, écriture, exécution) sur des objets. Il est dit discrétionnaire car la délégation (le transfert de certaines permissions) est à la discrétion des propriétaires des objets, qui peuvent de ce fait donner leurs permissions à d’autres utilisateurs. Dans le DAC de Linux, cet aspect de délégation transparaît dans les commandes chown et chmod.
MAC
À l’inverse d’un DAC traditionnel, un modèle MAC (pour Mandatory Access Control) ne permet pas la délégation sans contrôle. Cela signifie que la politique de sécurité est entièrement définie par un administrateur et les utilisateurs doivent obtenir l’accord d’une autorité centrale administrative pour déléguer un droit.
Le modèle de Bell et LaPadula [BL73] est le premier modèle à considérer une approche dite « multi-niveaux, » communément appelé MLS pour multi-level security. Il vise à assurer des propriétés de confidentialité. Les modèles MLS sont une approche possible permettant de réaliser une politique d’accès MAC. Dans le modèle de Bell et LaPadula, on distingue deux types d’acteurs : les sujets (actifs) et les conteneurs (passifs). Le modèle définit aussi un ensemble de niveaux d’information (par exemple, P ublic, Secret, Conf identiel) et un ordre partiel de cet ensemble. À chaque conteneur, on associe un niveau en lien avec l’information qu’il contient. Ainsi, le fichier /etc/passwd pourra être de niveau confidentiel, du fait qu’on ne désire pas que son contenu puisse être lu par n’importe qui. Chaque sujet u reçoit un niveau d’habilitation su. Lorsqu’il décide d’accéder au système d’information, l’utilisateur ouvre une session avec un niveau d’habilitation sc, avec sc ≤ su. Par la suite, le système s’assure du respect de deux règles fondamentales: le no read up et le no write down. Ces règles ont été pensées pour que la session d’un utilisateur de confiance ne soit pas détournée par un programme malicieux.
No read up Si un sujet active une session de niveau sc, alors il ne peut lire des conteneurs que de niveaux sr, si sr ≤ sc. Cela signifie tout simplement qu’un sujet ne peut lire une information d’un niveau de confidentialité plus haut que le sien.
No write down Bell et LaPadula ont imaginé un modèle qui assure des propriétés de confidentialités sur un système d’information. La règle du no write down s’assure qu’une information d’un niveau s ne fuit pas dans un conteneur de niveau s’ si s’ ≤ s. Ainsi, un sujet ayant activé une session avec un niveau sc ne pourra écrire que dans des conteneurs de niveaux sw, avec sc ≤ sw. Cette propriété permet d’écraser des données de hauts niveaux de confidentialités avec des données de niveaux plus faibles, ce qui n’est pas un problème car le modèle ne se soucie pas de l’intégrité des données. Il existe un modèle analogue à Bell et LaPadula s’assurant quant à lui de l’intégrité des données : le modèle de Biba [Bib77] se place dans un contexte similaire et énonce des règles analogues : no write up (des données de basses intégrités ne peuvent être écrites dans des données de hauts intégrités) et no read down (un sujet ne peut récupérer des données de basses intégrités pour les écrire dans des fichiers de hautes intégrités).
|
Table des matières
I Introduction
II État de l’art
1 Sécurité d’un système d’information
1.1 Contrôle d’accès
1.2 Détection d’intrusion
2 Contrôle de flux
2.1 Au niveau OS
2.2 Au niveau langage
3 Coopération de moniteurs
3.1 Pourquoi coopérer ?
3.2 kBlare et jBlare
3.3 Laminar
III Formalisation
4 Modèles existants
4.1 Le modèle générique Blare
4.2 Politique de sécurité
4.3 Implémentation historique
5 Coopération
5.1 Notion d’applications tierces
5.2 Politique de coopération
5.3 Tag de coopération
6 Coopération avec jBlare
6.1 Fonctionnement des applications Java
6.2 Stratégie de coopération
6.3 Formalisation
IV Implémentation
7 kBlare
7.1 Implémentation de CIDre
7.2 Modification du suivi de flux
7.3 API pour dialogue avec l’espace utilisateur
8 jBlare
8.1 Analyse dynamique et analyse hybride
8.2 Modification de l’interpréteur
8.3 Modification de JNI
V Expérimentation
9 Discussion sur l’efficacité
9.1 Programme jouet
9.2 Avec l’API Java
9.3 Faiblesses
10 Performances
10.1 Overhead kBlare
10.2 Overhead jBlare
VI Conclusion
