Les mécanismes de contrôle de flux

Contrôle d’accès

Les mécanismes de contrôle d’accès définissent en général deux types d’entités différentes. Les sujets sont les entités actives du système et peuvent représenter des utilisateurs ou des programmes.
Les objets par contre sont les entités passives du système et représentent l’ensemble des ressources accessibles d’un système, des fichiers par exemple. Il est intéressant de noter qu’un objet peut très bien être considéré comme un sujet, dès lors qu’un processus actif peut créer un nouveau processus fils, le terminer ou le suspendre selon les autorisations qu’il possède.

DAC

L’un des modèles classiques de contrôle d’accès est le contrôle d’accès discrétionnaire (DAC ). Ce modèle est largement implémenté dans les systèmes d’exploitation. Il définit pour les sujets un ensemble d’actions qu’ils peuvent réaliser sur des objets. La définition de cet ensemble de permissions sur un objet particulier est laissée à la discrétion du sujet auquel cet objet appartient. Dans [HRU76], les auteurs proposent de représenter l’ensemble des permissions par une matrice d’accès . Les lignes de cette matrice correspondent aux sujets et les colonnes correspondent aux objets (qui peuvent eux-mêmes être des sujets). L’objet O par exemple appartient au sujet S1 qui possède sur cet objet les droits de lecture, écriture et exécution. Le sujet S1 n’autorise par contre que la lecture et l’exécution de l’objet O pour le sujet S2.
Bien que ce modèle ait connu un grand succès, il est implémenté dans Unix, Linux et Windows, grâce à la flexibilité qu’il introduit, il souffre néanmoins d’un inconvénient majeur permettant de contourner la politique de sécurité.

MAC

Le contrôle d’accès obligatoire (MAC) impose que les droits d’accès aux objets ne soient pas seulement définis par les propriétaires des objets concernés. Bell et Lapadula [LB73] ont introduit un modèle de contrôle d’accès obligatoire qui associe à tous les sujets et objets un niveau de sécurité. Les sujets reçoivent un niveau d’habilitation ainsi qu’un ensemble de domaines auxquels ils sont confinés. Les objets reçoivent un niveau de classification et un ensemble de domaines. Ce modèle définit de nouvelles règles d’accès afin d’assurer le confinement de l’information en se basant sur les niveaux de sensibilité affectés aux sujets (habilitation) ou objets (classification) ainsi que sur les domaines auxquels ils appartiennent. Une relation d’ordre total ≤ est définie sur l’ensemble des niveaux de sensibilité, alors qu’une relation d’ordre partiel correspondant à la relation ⊆ de la théorie des ensembles est définie pour les domaines. Les règles du contrôle d’accès obligatoire dépendent de la propriété de sécurité à laquelle on s’intéresse, confidentialité ou intégrité.

Détection d’intrusion

Les systèmes de détection d’intrusions servent en théorie à détecter toutes violations de la politique de sécurité [And80]. Ces systèmes se composent classiquement de trois éléments distincts. Un capteur collecte des données qui peuvent être des paquets transitant sur le réseau ou des journaux d’audit système par exemple. Ces données sont ensuite fournies à l’analyseur qui détectera des intrusions éventuelles dans le système. Enfin, le manager collecte les alertes produites par l’analyseur, les corrèle puis réagit ou les présente à l’opérateur. Nous allons nous intéresser dans le cadre de nos travaux aux méthodes d’analyses utilisées par ces systèmes. Il existe deux écoles du point de vue des différentes méthodes d’analyse pour la détection. L’approche par scénarios définit un ensemble de comportements du système qui violent la politique de sécurité et cherche des motifs ou signatures correspondant à ces scénarios d’attaques pendant l’analyse des données collectées. L’approche comportementale par contre s’appuie sur la définition d’un ensemble de comportements de référence pour le système. Elle compare ensuite l’activité du système à ces profils  normaux  définis au préalable afin de détecter des déviations considérées comme étant des intrusions.

Approches par scénarios

Les approches par scénarios se basent sur une connaissance à priori des attaques contre les systèmes. La plupart des outils commerciaux tels que Snort 1 sont basés sur ces approches. Elles définissent des signatures correspondant à l’exploitation de vulnérabilités connues et remontent une alerte dès qu’une tentative d’intrusion est détectée. Faciles à configurer, les systèmes de détection d’intrusion basés sur ce type d’approche, permettent aussi de fournir des rapports très précis concernant l’intrusion détectée, puisque chaque signature est en général propre à une vulnérabilité particulière, présente sur une version particulière du programme attaqué. Cependant, ces systèmes ne détectent pas les intrusions effectives, mais les attaques contre le système. Ils sont aussi très limités par le fait qu’ils ne peuvent détecter des attaques résultant de l’exploitation de vulnérabilités non publiques (zero days vulnerabilities). De plus, garder une base de connaissance des signatures d’attaques à jour peut s’avérer être une tâche très laborieuse au vue du nombre de nouvelles vulnérabilités découvertes chaque jour.

Approches comportementales

Les approches comportementales ou approches par détection d’anomalies s’attachent à définir un comportement  normal  du système. Toute déviation par rapport à ce comportement de référence est considérée comme étant une intrusion. Ces approches permettent en théorie de détecter les attaques inconnues, contrairement aux approches par scénarios. Mais elles posent alors le problème de la définition de ces comportements de référence.
Forrest [FHS97] propose notamment une approche qui s’inspire du système immunitaire du corps humain. Elle fait l’analogie entre la détection d’intrusion et la détection de corps étrangers par les cellules immunitaires et les anticorps. Cette approche construit dans une première phase une base de données des séquences d’appels systèmes observés durant une exécution normale d’un programme donné. Durant la seconde phase qui correspond à la phase d’analyse, la trace de l’exécution de ce programme est comparée aux séquences d’appels système de référence définis précédemment.
À chaque fois que la trace d’exécution diverge suffisamment des séquences de référence, l’analyse lève une alerte d’intrusion. Les limites de cette approche dite par apprentissage sont intrinsèques à son mode de fonctionnement. En effet, cette approche suppose qu’un comportement anormal implique une intrusion. Cette hypothèse n’est pas nécessairement vraie, et peut induire la détection de plusieurs faux-positifs. Il se peut aussi que la phase d’apprentissage intègre dans le comportement de référence une intrusion. Ceci est d’autant plus probable s’il est possible de réapprendre et de compléter la trace de référence afin de tenir compte des évolutions possibles du système et du comportement des utilisateurs.
Une seconde approche proposée par Sekar [SCS98] consiste à utiliser une spécification explicite du comportement. Cette approche, contrairement à la précédente, spécifie le comportement normal au lieu de l’apprendre. L’auteur a donc été amené à définir un langage formel de haut niveau, ASL (Auditing Specification Language), afin de définir les comportements possibles d’un programme. Ces comportements sont spécifiés en terme de séquences d’évènements possibles et de conditions que ces événements doivent vérifier.

Les mécanismes de contrôle de flux

Les mécanismes de contrôle de flux s’intéressent aux flux d’information engendrés par un programme informatique afin de garantir les propriétés de confidentialité et d’intégrité. Certains reposent sur une analyse statique afin de certifier toutes les exécutions possibles d’un programme, alors que d’autres dits dynamiques ou hybrides ne s’intéressent qu’à l’exécution courante d’un programme afin de s’assurer que cette exécution ne viole pas les propriétés de sécurité.
Deux types de flux d’information peuvent être distingués. Le premier est dit explicite, lorsque la valeur d’une variable x dépend explicitement de la valeur d’une variable y. Dans le cas de l’affectation x := y par exemple, il y a un flux explicite de y vers x. Le second type de flux est dit implicite lorsque la valeur d’une variable dépend d’un branchement conditionnel. Dans l’exemple if (secret) then public := 1 else public := 0, il y a un flux d’information implicite de la variable secret contrôlant le branchement vers la variable public.

Jimple : représentation intermédiaire de Bytecode

L’analyse statique de Bytecode et plus généralement des langages de pile s’avérant très complexe, Vallée-Rai et Hendren [VRH98] ont eu recours au développement d’une représentation intermédiaire de Bytecode faciliant cette tâche. Cette forme intermédiaire, appelée Jimple, a les caractéristiques suivantes : elle est sous la forme d’un code 3 adresses ;  elle n’utilise pas de pile ; ses variables sont explicitement déclarées et typées.
L’exemple suivant  tiré de [VRH98], est une séquence d’instructions Bytecode stockant dans la variable locale l0 la valeur de l’expression l1/(5∗(l2+l3)). Cette exemple illustre la difficulté de l’analyse statique de Bytecode. En effet, avant de pouvoir déterminer quelle expression est utilisée à la ligne 10 par exemple, il faut d’abord examiner toutes les instructions précédentes en simulant leur effet sur la pile. Ceci peut s’avérer très coûteux, d’autant plus qu’il peut y avoir un très grand nombre d’instructions entre l’empilement d’un opérande sur la pile et son dépilement, c’est-à-dire son utilisation. Or en Jimple, il suffit de localiser les instructions qui manipulent la variable correspondante. De plus, le nombre très restreint d’instructions Jimple, comparé à la multitude d’instructions Bytecode, facilite grandement l’implémentation d’une analyse statique.
La génération de code Jimple à partir de Bytecode dans le framework Soot passe par 5 étapes : génération de code Jimple simple non typé ; une première phase d’optimisation ; séparation des différentes variables pour préparer le typage ; typage du code Jimple ; une dernière phase d’optimisation.

Table des matières

1 Introduction 
2 État de l’art 
2.1 Contrôle d’accès
2.1.1 DAC
2.1.2 MAC
2.2 Détection d’intrusion
2.2.1 Approches par scénarios
2.2.2 Approches comportementales
2.3 Contrôle de flux d’information
2.3.1 Politique de flux en treillis
2.3.2 La propriété de non-interférence
2.3.3 Politique de flux en termes de CCAL
2.4 Les mécanismes de contrôle de flux
2.4.1 L’analyse statique
2.4.2 L’analyse dynamique
2.4.3 L’analyse hybride
3 Contexte 
3.1 Objectifs
3.2 Soot : analyse statique de Bytecode
3.3 Jimple : représentation intermédiaire de Bytecode
3.4 Analyse statique de flot de données
3.4.1 Analyse de vivacité des variables
3.4.2 Post-dominateur dans un CFG
4 Travaux réalisés 
4.1 Introduction
4.2 Suivi des flux explicites
4.2.1 Description
4.2.2 Présentation de l’analyse statique des flux explicites
4.2.3 Les références
4.2.4 Les appels de méthodes
4.3 Suivi des flux implicites
4.3.1 Description
4.3.2 Présentation de l’analyse statique des flux implicites directs
4.3.3 Les appels de méthode
4.3.4 Présentation de l’analyse statique des flux implicites indirects
4.3.5 Les exceptions
4.4 Résumé
5 Travaux futurs et conclusion

Télécharger le rapport complet