Assaf

Master Recherche en Informatique - Rennes 1 Encadrant : Guillaume Hiet (quipe SSIR, Suplec)
dumas-00636135, version 1 - 26 Oct 2011
Utilisation de m thodes hybrides pour la d tection e e dintrusion param tr e par la politique de s curit e e e e reposant sur le suivi des ux dinformation
Mounir ASSAF
Rennes, Juin 2011
Table des matires

1 Introduction 2 tat de l'art
4
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6 7 8 8 9 10 10 11 12 12 13 15 16
2.1 Contrle d'accs . . . . . . . . . . . . . . . 2.1.1 DAC . . . . . . . . . . . . . . . . . . 2.1.2 MAC . . . . . . . . . . . . . . . . . . 2.2 Dtection d'intrusion . . . . . . . . . . . . . 2.2.1 Approches par scnarios . . . . . . . 2.2.2 Approches comportementales . . . . 2.3 Contrle de ux d'information . . . . . . . . 2.3.1 Politique de ux en treillis . . . . . . 2.3.2 La proprit de non-interfrence . . . 2.3.3 Politique de ux en termes de CCAL 2.4 Les mcanismes de contrle de ux . . . . . 2.4.1 L'analyse statique . . . . . . . . . . 2.4.2 L'analyse dynamique . . . . . . . . . 2.4.3 L'analyse hybride . . . . . . . . . . . 3.1 3.2 3.3 3.4
3 Contexte
Objectifs . . . . . . . . . . . . . . . . . . . . . . . Soot : analyse statique de Bytecode . . . . . . . . Jimple : reprsentation intermdiaire de Bytecode Analyse statique de ot de donnes . . . . . . . . 3.4.1 Analyse de vivacit des variables . . . . . 3.4.2 Post-dominateur dans un CFG . . . . . .
21
21 22 22 25 25 26
4 Travaux raliss
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Suivi des ux explicites . . . . . . . . . . . . . . . . . . . . 4.2.1 Description . . . . . . . . . . . . . . . . . . . . . . . 4.2.2 Prsentation de l'analyse statique des ux explicites 4.2.3 Les rfrences . . . . . . . . . . . . . . . . . . . . . . 4.2.4 Les appels de mthodes . . . . . . . . . . . . . . . . 4.3 Suivi des ux implicites . . . . . . . . . . . . . . . . . . . . 4.3.1 Description . . . . . . . . . . . . . . . . . . . . . . . 2
28
28 28 28 29 34 35 37 37
4.3.2 Prsentation de l'analyse statique des ux implicites directs . 4.3.3 Les appels de mthode . . . . . . . . . . . . . . . . . . . . . . 4.3.4 Prsentation de l'analyse statique des ux implicites indirects 4.3.5 Les exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4 Rsum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
38 39 39 42 44
5 Travaux futurs et conclusion
45
Chapitre 1
Introduction
Les systmes d'information sont de nos jours de plus en plus confronts de nombreux risques menaant leur scurit. La protection de ces systmes suppose dans un premier temps de dnir une politique de scurit exprimant les besoins en terme de condentialit, intgrit et disponibilit des biens et services, puis dans un second temps de mettre en uvre cette politique. Gnralement, des mcanismes d'authentication et de contrles d'accs sont dploys pour la mise en uvre de la politique de scurit. Ils vrient d'abord l'identit des utilisateurs, puis s'assurent que ces derniers ont bien les autorisations ncessaires pour accder aux ressources du systme. Cependant, il est important de noter que ces approches prventives ne sont pas toujours susantes pour garantir les proprits de scurit. Elles ncessitent la vrication et le contrle des actions des utilisateurs an de s'assurer postriori que la politique est bien respecte. Intervient alors la dtection d'intrusion qui n'est autre que la dtection des violations de la politique de scurit [And80]. Plusieurs modles de systmes de dtection d'intrusion (IDS) ont t proposs depuis les travaux sminaux d'Anderson [FHS97, SCS98, KR02, ZMB03, HMZ+ 07]. Certaines approches, dites par scnarios, se basent sur une connaissance priori des attaques contre le systme. D'autres, dites comportementales, dnissent plutt le comportement de rfrence du systme. Ces approches comportementales ont l'avantage de pouvoir dtecter mme des attaques nouvelles contrairement aux approches par scnarios. Dans le cadre de ce stage, nous nous intressons en particulier un modle comportemental de dtection d'intrusion, paramtr par la politique de scurit et reposant sur le suivi du ux d'information. Ce modle propos par le laboratoire SSIR, a t implment au niveau du systme d'exploitation Linux. Une deuxime implmentation a ensuite t ralise au niveau de la machine virtuelle Java (JVM). Cette seconde implmentation (JBlare) s'intgre avec la premire (Blare) et permet d'assurer un suivi dynamique du ux d'information dirents niveaux selon les applications. L'objectif de ce stage est d'tudier les techniques d'analyse statique qui pourraient tre mises en oeuvre pour le suivi des ux d'information au niveau des programmes Java an de diminuer l'impact de l'analyse dynamique et amliorer la prcision du suivi. Ce rapport est organis comme suit : Nous dresserons dans la premire partie 2 un tat de l'art de la dtection d'intrusion et du contrle de ux d'information. Nous montrerons les limites du contrle d'accs, puis nous prsenterons les dirents modles de dtection d'intrusion, dont un modle paramtr par la politique de scurit et reposant sur le suivi des ux d'information. Nous exposerons ensuite deux modle de politique de ux et les direntes approches pour le contrle de 4
ux d'information. Nous introduisons ensuite dans la partie 3 le contexte de ce stage. Nous xerons nos objectifs, puis nous prsenterons les outils sur lesquels nous fondons notre approche. La partie 4 prsentera ensuite en dtail la dmarche que nous proposons. Enn, nous concluerons et discuterons des travaux futurs envisags dans la dernire partie 5.
Chapitre 2
tat de l'art
Nous prsentons dans cette partie deux modles de contrle d'accs et leurs limites. Nous montrons que ces mcanismes sont soit trs restrictifs, soit insusants pour garantir l'application de la politique de scurit. Ensuite, dirents modles de dtection d'intrusion sont exposs, dont un modle paramtr par la politique de scurit et reposant sur le suivi du ux d'information. Nous prsontons aussi dans cette partie deux modles de politiques de ux ainsi que les proprits qu'ils cherchent garantir, puis nous faisons un tat de l'art concernant les mcanismes de contrle de ux.
2.1 Contrle d'accs

Les mcanismes de contrle d'accs dnissent en gnral deux types d'entits direntes. Les sujets sont les entits actives du systme et peuvent reprsenter des utilisateurs ou des programmes. Les objets par contre sont les entits passives du systme et reprsentent l'ensemble des ressources accessibles d'un systme, des chiers par exemple. Il est intressant de noter qu'un objet peut trs bien tre considr comme un sujet, ds lors qu'un processus actif peut crer un nouveau processus ls, le terminer ou le suspendre selon les autorisations qu'il possde.
2.1.1 DAC
L'un des modles classiques de contrle d'accs est le contrle d'accs discrtionnaire (DAC ). Ce modle est largement implment dans les systmes d'exploitation. Il dnit pour les sujets un ensemble d'actions qu'ils peuvent raliser sur des objets. La dnition de cet ensemble de permissions sur un objet particulier est laisse la discrtion du sujet auquel cet objet appartient. Dans [HRU76], les auteurs proposent de reprsenter l'ensemble des permissions par une matrice d'accs telle que l'illustre la gure 2.1. Les lignes de cette matrice correspondent aux sujets et les colonnes correspondent aux objets (qui peuvent eux-mmes tre des sujets). L'objet O par exemple appartient au sujet S1 qui possde sur cet objet les droits de lecture, criture et excution. Le sujet S1 n'autorise par contre que la lecture et l'excution de l'objet O pour le sujet S2. Bien que ce modle ait connu un grand succs, il est implment dans Unix, Linux et Windows, grce la exibilit qu'il introduit, il soure nanmoins d'un inconvnient majeur permettant de contourner la politique de scurit. Prenons l'exemple du sujet S3 dans la gure 2.1. N'ayant pas t autoris lire le contenu de l'objet O par le sujet S1, S3 ne devrait pas pouvoir y accder. S2 qui a 6
Objets Sujets O Lobjet O appartient au sujet S1 S1 Sujets own RWX Permissions du sujet S2 sur lobjet O : lecture, excution
S2 S3
R-X
--X
Figure 2.1 Matrice de contrle d'accs

les droits de lecture sur O, pourrait toutefois copier ce contenu dans un second objet qu'il mettrait la disposition de S3. Ce problme est inhrent au fait que ce modle ne tient pas compte des ux d'informations engendrs par la suite d'accs auxquels a t autoris le sujet S2. En eet, une fois l'accs l'information autoris, ce modle n'impose pas de contraintes quant la dissmination de l'information contrairement au modle introduit par Bell et Lapadula [LB73], prsent par la suite.
2.1.2 MAC
Le contrle d'accs obligatoire (MAC) impose que les droits d'accs aux objets ne soient pas seulement dnis par les propritaires des objets concerns. Bell et Lapadula [LB73] ont introduit un modle de contrle d'accs obligatoire qui associe tous les sujets et objets un niveau de scurit. Les sujets reoivent un niveau d'habilitation ainsi qu'un ensemble de domaines auxquels ils sont conns. Les objets reoivent un niveau de classication et un ensemble de domaines. Ce modle dnit de nouvelles rgles d'accs an d'assurer le connement de l'information en se basant sur les niveaux de sensibilit aects aux sujets (habilitation) ou objets (classication) ainsi que sur les domaines auxquels ils appartiennent. Une relation d'ordre total est dnie sur l'ensemble des niveaux de sensibilit, alors qu'une relation d'ordre partiel correspondant la relation de la thorie des ensembles est dnie pour les domaines. Les rgles du contrle d'accs obligatoire dpendent de la proprit de scurit laquelle on s'intresse, condentialit ou intgrit. En eet, le modle propos par Bell et Lapadula [LB73] assure la condentialit alors que celui propos par Biba [Bib77] assure l'intgrit. Comme l'illustre la gure 2.2, le modle mettant en uvre la condentialit assure qu'un sujet S ne pourra lire l'information contenue dans un objet O que dans le cas o le niveau de classication de O est infrieur ou gal au niveau d'habilitation de S pour la relation , et que le domaine de S domine le domaine de O pour la relation . Ce modle conne aussi le ux d'information puisque le sujet S ne peut dclassier l'information. Pour que S puisse modier un objet O, il faut que le niveau d'habilitation de S soit infrieur au niveau de classication de O et que le domaine de S domine le domaine de O. Ce modle impose donc bien de ce fait la condentialit de l'information pouvant tre lue. De la mme manire, dans le cas du modle mettant en uvre l'intgrit, un sujet ne peut modier un objet s'il n'a pas un niveau d'habilitation suprieur au niveau de classication de l'objet et si son domaine ne domine pas le domaine de l'objet pour la relation . 7
Types d'accs
Type de politique
Condentialit
no read up
Hsujet Cobjet Dobjet Dsujet
Intgrit
no read down
Accs en lecture Accs en criture
no write down
no write up
Figure 2.2 Rgles d'autorisation d'accs des modles de contrle d'accs obligatoire
Cette approche permet un certain contrle du ux d'information, mais elle est trs restrictive. Elle pose le problme de la contamination de labels (label creep ) puisque le modle de Bell et Lapadula impose qu' chaque fois qu'un sujet habilit modie un objet, le niveau de classication de l'information contenue dans cet objet augmente. Les mcanismes classiques de mise en uvre des politiques de scurit, dits prventifs, s'avrent souvent insusants ou trop restrictif. Le contrle d'accs discrtionnaire n'est pas adapt pour suivre de manire able et prcise, le ot d'information an de garantir les proprits d'intgrit et de condentialit. Le contrle d'accs obligatoire par contre est trop restrictif pour tre utilis dans des systmes grand public ou professionnels. Il est donc ncessaire de s'en remettre des mcanismes d'audit et de contrle postriori automatiss.
2.2 Dtection d'intrusion

Les systmes de dtection d'intrusions servent en thorie dtecter toutes violations de la politique de scurit [And80]. Ces systmes se composent classiquement de trois lments distincts. Un capteur collecte des donnes qui peuvent tre des paquets transitant sur le rseau ou des journaux d'audit systme par exemple. Ces donnes sont ensuite fournies l'analyseur qui dtectera des intrusions ventuelles dans le systme. Enn, le manager collecte les alertes produites par l'analyseur, les corrle puis ragit ou les prsente l'oprateur. Nous allons nous intresser dans le cadre de nos travaux aux mthodes d'analyses utilises par ces systmes. Il existe deux coles du point de vue des direntes mthodes d'analyse pour la dtection. L'approche par scnarios dnit un ensemble de comportements du systme qui violent la politique de scurit et cherche des motifs ou signatures correspondant ces scnarios d'attaques pendant l'analyse des donnes collectes. L'approche comportementale par contre s'appuie sur la dnition d'un ensemble de comportements de rfrence pour le systme. Elle compare ensuite l'activit du systme ces prols normaux dnis au pralable an de dtecter des dviations considres comme tant des intrusions. Nous allons prsenter succinctement ces direntes approches en exposant leurs limites.
2.2.1 Approches par scnarios

Les approches par scnarios se basent sur une connaissance priori des attaques contre les systmes. La plupart des outils commerciaux tels que Snort 1 sont bass sur ces approches. Elles
1. http ://www.snort.org
dnissent des signatures correspondant l'exploitation de vulnrabilits connues et remontent une alerte ds qu'une tentative d'intrusion est dtecte. Faciles congurer, les systmes de dtection d'intrusion bass sur ce type d'approche, permettent aussi de fournir des rapports trs prcis concernant l'intrusion dtecte, puisque chaque signature est en gnral propre une vulnrabilit particulire, prsente sur une version particulire du programme attaqu. Cependant, ces systmes ne dtectent pas les intrusions eectives, mais les attaques contre le systme. Ils sont aussi trs limits par le fait qu'ils ne peuvent dtecter des attaques rsultant de l'exploitation de vulnrabilits non publiques (zero days vulnerabilities ). De plus, garder une base de connaissance des signatures d'attaques jour peut s'avrer tre une tche trs laborieuse au vue du nombre de nouvelles vulnrabilits dcouvertes chaque jour.
2.2.2 Approches comportementales

Les approches comportementales ou approches par dtection d'anomalies s'attachent dnir un comportement normal du systme. Toute dviation par rapport ce comportement de rfrence est considre comme tant une intrusion. Ces approches permettent en thorie de dtecter les attaques inconnues, contrairement aux approches par scnarios. Mais elles posent alors le problme de la dnition de ces comportements de rfrence. Forrest [FHS97] propose notamment une approche qui s'inspire du systme immunitaire du corps humain. Elle fait l'analogie entre la dtection d'intrusion et la dtection de corps trangers par les cellules immunitaires et les anticorps. Cette approche construit dans une premire phase une base de donnes des squences d'appels systmes observs durant une excution normale d'un programme donn. Durant la seconde phase qui correspond la phase d'analyse, la trace de l'excution de ce programme est compare aux squences d'appels systme de rfrence dnis prcdemment. chaque fois que la trace d'excution diverge susamment des squences de rfrence, l'analyse lve une alerte d'intrusion. Les limites de cette approche dite par apprentissage sont intrinsques son mode de fonctionnement. En eet, cette approche suppose qu'un comportement anormal implique une intrusion. Cette hypothse n'est pas ncessairement vraie, et peut induire la dtection de plusieurs faux-positifs. Il se peut aussi que la phase d'apprentissage intgre dans le comportement de rfrence une intrusion. Ceci est d'autant plus probable s'il est possible de rapprendre et de complter la trace de rfrence an de tenir compte des volutions possibles du systme et du comportement des utilisateurs. Une seconde approche propose par Sekar [SCS98] consiste utiliser une spcication explicite du comportement. Cette approche, contrairement la prcdente, spcie le comportement normal au lieu de l'apprendre. L'auteur a donc t amen dnir un langage formel de haut niveau, ASL (Auditing Specication Language ), an de dnir les comportements possibles d'un programme. Ces comportements sont spcis en terme de squences d'vnements possibles et de conditions que ces vnements doivent vrier. Chaque vnement dni dans le langage ASL correspond un ensemble d'appels systmes. Par exemple, la spcication de la gure 2.3 autorise le programme concern n'ouvrir que le chier /etc/passwd et seulement en lecture. Ce langage permet aussi de
open(f ile, mode)|(realpath(f ile) { /etc/passwd }) (mode = RDON LY ) f ail /
Figure 2.3 Exemple de spcication de comportement en ASL

dnir les mesures prendre dans le cas o la compromission d'un programme est identie. Ces mesures permettent ainsi d'isoler le programme compromis pour s'assurer qu'il ne pourra menacer 9
la scurit du systme. Ce modle a t valid par une implmentation propose par Sekar. Nanmoins, il soure d'un inconvnient majeur puisque la mise en place de spcications pour chaque programme du systme et chacune des mises jour de ces programmes s'avre laborieuse. Une troisime approche consiste s'aranchir de la spcication des comportements lgaux de tous les programmes et d'induire ce comportement partir de la politique de scurit. Cette approche dite paramtre par la politique de scurit a t initialement propose par Ko et Redmond [KR02] an de dtecter les violations d'intgrit par des programmes concurrents (des conditions de course). Les travaux du laboratoire SSIR proposent un modle plus gnral qui permet de prendre en compte la fois les problmatiques de condentialit et d'intgrit [ZMB03, HMMT07] et ne sont pas cantonns aux attaques dites de conditions de course. Ce modle infre l'ensemble des comportements sains des applications en termes de ux d'informations autoriss en se basant sur la politique de scurit dnie au niveau de l'OS, la politique DAC notamment. Notons que ce modle ne s'intresse qu' la dtection des violations de proprits de condentialit et d'intgrit. Un programme malveillant prsent sur le systme ne sera dtect qu'au moment o il violera l'une de ces proprits de scurit par exemple. Une implmentation de ce modle a t propose dans [ZMB03, HMMT07]. Elle permet le suivi et le contrle du ux d'informations au niveau OS (Blare) ainsi qu'au niveau de la JVM (JBlare). JBlare ralise un suivi dynamique de ux d'information en instrumentant le bytecode des programmes Java. Ce suivi surapproxime cependant les ux engendrs au sein des mthodes Java, considres comme des botes noires. Les parties suivantes s'intresseront au contrle de ux d'information et notamment aux mcanismes permettant d'amliorer les performances et la prcision du suivi ralis par JBlare.
2.3 Contrle de ux d'information

Le contrle de ux s'intresse au suivi des ux d'information an de s'assurer que ces ux sont lgaux vis--vis de la politique de scurit. Cette section prsente formellement deux modles de politique de ux. Le premier est classiquement utilis pour le contrle de ux, notamment en conjonction avec la proprit de non-interfrence pour certier la scurit des programmes, proprit que nous prsentons dans la deuxime sous-section. Le second modle est plus adapt au contrle dynamique. Il interprte la politique de scurit en termes de ux autoriss entre objets du systme.
2.3.1 Politique de ux en treillis

Un modle de politique de ux, initialement propos par [Den76] est classiquement utilis dans les mcanismes de contrle de ux. Ce modle dnit les ux possibles entre objets, en leur assignant chacun un niveau de scurit. Les ux d'information autoriss entre objets sont alors spcis en dnissant une relation sur l'ensemble des niveaux de scurit. Le ux d'information d'un objet A vers B est alors autoris si et seulement si leurs niveaux de scurit A et B respectifs vrient la relation : A B . Denning [Den76] propose de modliser toute politique de ux d'information par un modle en treillis. Une relation : SC SC SC est introduite, o SC reprsente l'ensemble des labels de scurite. Cette relation spcie par exemple le label de scurit de l'objet dni par l'application d'une opration binaire sur deux objets A et B : (A + B) = A B .
10
Dnition 1 (Modle de politique de ux d'information en treillis). Un modle de ux d'information < SC, , > forme un treillis si : 1. la relation dnit une relation d'ordre partielle sur l'ensemble SC ; 2. l'ensemble SC est ni ; 3. SC admet une borne infrieure L telle que A SC, L A ; 4. dnit une borne suprieure minimale sur SC SC .
L'hypothse 1 suppose que la relation dnisse une relation d'ordre partielle sur SC . Elle est donc rexive, antisymtrique et transitive. La rexivit et l'antisymtrie ne posent pas de problmes particuliers. En eet, il est cohrent que toute politique autorise les ux intra-classes , un exemple typique tant l'aectation d'une variable elle-mme. De plus, si l'antisymtrie n'est pas vrie alors (A, B) SC SC tels que A B et B A avec A = B . Dans ce cas, rien ne justie de direncier ces deux classes de scurit puisqu'un ux d'une classe vers l'autre est considr lgal. La condition de transitivit implique que si A B et B C alors A C , c'est dire que si le ux indirect entre A et C en passant par B est permis alors le ux entre A et C est permis. Cette condition est raisonnable, bien qu'il soit ncessaire parfois de dnir des politiques de ux intransitives ; dans le cas de la dclassication par exemple, secret dclassi et dclassi publique alors que secret publique. Les hypothses 2 et 3 considrent que l'ensemble SC est ni et qu'il admet une borne infrieure. En vue d'une implmentation sur un systme informatique, l'ensemble SC doit tre ni. L'hypothse de l'existence d'une borne infrieure ne pose pas de problmes particuliers non plus puisque dans tous systmes informatiques, il existe des informations publiques si ce n'est les constantes utilises dans les programmes informatiques. Pour l'hypothse 4, par dnition de , A A B et B A B . Or si C SC tel que C A B et C = A B , alors il sut de poser A B = C .
2.3.2 La proprit de non-interfrence

Goguen et Meseguer [GM82] ont t les premiers dnir le notion de non-interfrence. Cette proprit spcie qu'un ensemble d'instructions pouvant tre excut par un groupe d'utilisateurs est non-interfrent avec un second groupe d'utilisateurs, si ces instructions n'ont aucun eet sur ce que pourrait observer ce second groupe. Considrons par exemple le cas simple de deux utilisateurs dont l'un (not utilisateur S) est privilgi et peut avoir accs de l'information classe secrte, alors que le second (not utilisateur P) est non-privilgi et n'a accs qu' de l'information publique. Cet utilisateur S a le droit d'excuter des oprations O de modication, de cration et de suppression de chiers secrets F. Ces oprations sont alors non-interfrentes avec le second utilisateur P si elles ne modient nullement l'information publique concernant les chiers F et observable par P. Ceci veut dire que P n'a aucun moyen d'infrer quelles oprations ont t excutes en observant les chiers F par exemple. Pour dnir formellement la proprit de non-interfrence pour un programme p, un ensemble de labels de scurit SC associs aux variables de p est considr. Cet ensemble est muni d'une relation d'ordre partiel . Intuitivement, si les niveaux de scurit des variables x et y , nots respectivement x et y vrient la relation x y , alors le ux d'information de x vers y est autoris. Une relation d'quivalence l , o l SC , est aussi dnie pour deux mmoires et d'un programme, telle que l si et seulement si pour toute variable x du programme considr, x l = (x) = (x). La non-interfrence peut alors tre dni comme suit : 11
Dnition 2. (non-interfrence) Un programme p est non-interfrent si

l SC , l ( p, ) ( p, ) = l
Cette dnition inspire de [VSI96] et [RS10], spcie que les variables de niveau bas ne dpendent pas des variables de niveau haut. En eet, si les valeurs de toutes les variables de niveau suprieur l sont changes entre deux excutions successives du programme p, cel n'impactera pas du tout les valeurs des variables de niveau infrieur ou gale l. Cette dnition ne tient toutefois pas compte de la non-terminaison du programme qui pourrait causer une fuite d'information. Elle est dite insensible la terminaison du programme.
2.3.3 Politique de ux en termes de CCAL

L'approche prsente par les travaux de l'quipe SSIR [HMMT07] [ZMB03] introduit un autre modle de politique de ux. Ce modle s'appuie sur la notion de contenus et de conteneurs. Les conteneurs sont les objets du systme qui contiennent des contenus, c'est--dire l'information elle-mme. Pour un chier F , le modle distingue donc l'information f qu'il contient de l'objet F en tant que rceptacle d'information. Par la suite, l'ensemble des contenus du systme est not I = {I1 , . . . , In } et l'ensemble des conteneurs est not O = {O1 , . . . , On }. Le modle propos interprte la politique de scurit dnie sur le systme an d'en dduire les ux d'informations lgaux. Il repose ainsi sur le concept de CCAL (Contents - Container Authorized Link ) qui associe des contenus aux conteneurs vers lesquels ces contenus peuvent s'couler sans enfreindre la politique de scurit. La politique de ux est alors dnie comme tant l'ensemble de ces CCAL :
Dnition 3 (Politique de ux). Une politique de ux est un ensemble des paires (Ii , i )iI appeles
CCAL o : Ii P(I) est un ensemble de contenus i P(O) est un ensemble de conteneurs
Une violation de la politique de scurit est alors dnie par l'association d'un contenu I un conteneur O alors que cette association n'est autorise par aucun CCAL dnissant la politique de ux :
Dnition 4 (Violation de la politique de scurit). Une violation de la politique de scurit est

caractrise par une situation o :
O, I tels que O contient I et (I , ) tel que I I et O
2.4 Les mcanismes de contrle de ux

Les mcanismes de contrle de ux s'intressent aux ux d'information engendrs par un programme informatique an de garantir les proprits de condentialit et d'intgrit. Certains reposent sur une analyse statique an de certier toutes les excutions possibles d'un programme, alors que d'autres dits dynamiques ou hybrides ne s'intressent qu' l'excution courante d'un programme an de s'assurer que cette excution ne viole pas les proprits de scurit. Deux types de ux d'information peuvent tre distingus. Le premier est dit explicite, lorsque la valeur d'une variable x dpend explicitement de la valeur d'une variable y . Dans le cas de l'affectation x := y par exemple, il y a un ux explicite de y vers x. Le second type de ux est dit 12
implicite lorsque la valeur d'une variable dpend d'un branchement conditionnel. Dans l'exemple if (secret) then public := 1 else public := 0, il y a un ux d'information implicite de la variable secret contrlant le branchement vers la variable public.
2.4.1 L'analyse statique

Volpano et Smith [VSI96] ont t les premiers proposer un systme de type pour le contrle de ux d'information en analyse statique. Ce systme de type a t propos au pralable pour un langage impratif simple prsent gure 2.5. La abilit de l'approche propose a t prouve en montrant que tout programme typable respecte la proprit de non-interfrence insensible la terminaison du programme (dnition 2). Ce systme de type a ensuite t tendu un langage procdural simple [VS97]. Cette approche considre un modle de ux d'information en treillis < SC, , >. Un systme de type introduit un ensemble de rgles d'infrences et d'axiomes permettant la drivation de jugements de type. Le jugement de type x : par exemple associe le type SC la variable x, tant un environnement de typage faisant correspondre les variables x d'un programme leurs types respectifs . L'environnement est initialis en assignant chaque variable globale x d'un programme un label de scurit not x. Le langage impratif (gure 2.5) utilis par Volpano est constitu de phrases p, c'est--dire d'expressions e ou de commandes c. Les expressions x, l et n sont des mtavariables qui reprsentent respectivement des identiants de variables, des pointeurs et des entiers. La smantique grand pas de ce langage est prsente la gure 2.7. Cette smantique introduit une mmoire , dnie comme une fonction valuant la valeur des pointeurs du programme. Le domaine de dnition de cette fonction est not dom(). Aussi, le contenu d'un pointeur l est not (l), alors que l'aectation de la valeur entire n au pointeur l est not [l := n]. Cette mmoire permet de dnir des jugements d'valuation tels e n (l'valuation d'une expression e fournit une valeur entire) ou c (l'valuation d'une commande c fournit une nouvelle mmoire ). L'auteur introduit aussi deux niveaux de typage, le typage de donnes nots qui reprsentent les classes de scurit de l'ensemble SC , puis le typage des phrases not qui regroupent les types de donnes , les types d'expressions var et les types de commandes cmd. Si x : var, alors la variable x contient des donnes dont le niveau de scurit est infrieur ou gale selon la relation dnie sur SC. Si c : cmd, alors les variables aectes dans la commande c sont de niveau suprieur ou gale . Une relation de sous-typage sur les types est aussi dnie, et note ; Si o (, ) SC SC , alors et cmd cmd. Intuitivement, les variables de niveau de scurit "bas" peuvent tre forces vers un niveau de scurit "plus haut", alors que les commandes d'un niveau de scurit "haut" peuvent tre forces vers un niveau de scurit "plus bas". Les rgles de typages dnies par Volpano sont prsentes en gure 2.6. Ces rgles garantissent que les ux explicites et implicites d'un programme respectent bien la politique de ux dnie par < SC, , >. Les trois rgles (INT), (VAR), (VARLOC) dnissent les types de scurit associs aux expressions de base ; entiers, variables et pointeurs. La rgle (ARITH) stipule que la combinaison binaire des expressions e1 et e2 n'est possible que si ces expressions ont le mme niveau de scurit. Cette rgle combine une des rgles de sous-typage s'assure que le label de scurit associ l'expression e1 + e2 est au moins e1 e2 puisque si e1 = e2 , alors il est possible de forcer les deux labels vers un niveau commun "plus haut" tel que et . La rgle (RVAL) permet la conversion du type var en . La rgle (ASSIGN) garantit que les ux explicites 13
(types des donnes) (types des phrases) | var| cmd
Figure 2.4 Les dirents types

(INT) (VAR) (VARLOC) (ARITH) (R-VAL) (ASSIGN)
(phrases) p : := e | c (expressions) e : := x | l | n | e + e | e e | e = e | e e (commands) c : := e := e | c; c | if e then c else c | while e do c | letvar x := e in c
(COMPOSE)
(IF) (WHILE) (LETVAR) pano et Smith
n n (BASE) ; n : l (l) (CONTENTS) ; x : var if (x) = var e n, e n ; l : var if (l) = (ADD) ; e : , ; e : e+e n+n e n, l dom() ; e + e : (UPDATE) ; e : var l := e [l := n] c , c ; e : (SEQUENCE) ; e : c; c e 1, c ; e := e : cmd (BRANCH) ; c : cmd, ; c : cmd if e then c else c e 0, c ; c; c : cmd ; e : , if e then c else c ; c : cmd, e0 (LOOP) ; c : cmd while e do c e 1, c , e+e n+n ; e : , ; c : cmd while e do c ; while e do c : cmd while e do c ; e : , e n, l dom(), / ; [x : var] c : cmd [l := n] [l/x]c (BINDVAR) e+e n+n letvar x := e in c l
Figure 2.5 Langage impratif introduit par Volpano
Figure 2.6 Les rgles du systme de type de Vol- Figure 2.7 Smantique naturelle du language impratif respectent la politique de ux. Elle spcie que l'aectation de la valeur d'une variable e e n'est possible que si e = e , tout en permettant cette aectation dans le cas gnral o e e grce au sous-typage. La rgle (COMPOSE) combine au sous-typage de commandes, s'assure que le type associ la composition de deux commandes c et c est au plus gal c c . Les rgles (IF) et (WHILE) garantissent que les ux implicites respectent la politique de ux. Elles s'assurent que les aectations de variables globales l'intrieur de branchements ne concernent que des variables dont le niveau de scurit est plus haut que celui de la variable de contrle. Enn, la rgle (LETVAR) garantit que le ux d'information explicite d l'initialisation des variables locales ne viole pas la politique de ux. En eet, si une variable x est initialie avec la valeur de l'expression e, la mmoire est mise jour pour associer x le label de e. Jif [Mye99], une implmentation de ce systme de type a t ralise. Elle propose d'associer statiquement des labels de scurit aux variables, pour le contrle de ux au sein des programmes Java. Cependant, le caractre g des labels de scurit associs aux variables fait de ce systme de type une analyse trop restrictive. Le programme secret = public; public = secret n'est pas typable par exemple, car cette analyse considre qu'il y a une fuite d'information suite l'aectation de la variable secret public , alors mme que secret contient une valeur publique. Cette analyse est dite 14
insensible au ux car elle ne permet pas la propagation des labels de scurit. Une analyse statique plus permissive a t propose dans [HS06]. Cette analyse permet le typage du programme ci-dessus car un label de scurit bas est associ la variable secret suite l'aectation secret = public. Cette analyse est dite sensible au ux car elle permet la propagation des labels de scurit. Cependant, ces deux analyses statiques cherchent prouver que toutes les excutions possibles d'un programme sont compatibles avec la politique de scurit. Or il est parfois dsirable de s'intresser la scurit de l'excution courante d'un programme seulement, sans prendre en compte toutes les excutions possibles.
2.4.2 L'analyse dynamique

Une approche dynamique de suivi de ux d'information pour la dtection d'intrusion a t prsente dans [HMZ+ 07] et [ZMB03]. Cette approche initialise la politique de ux prsente dans la section 2.3.3, en interprtant la politique de scurit dnie au niveau du systme d'exploitation. Elle dnit ainsi un ensemble de CCAL (dnition 3) spciant les ux autoriss du systme. Cette approche se base sur la notion de contenu et conteneur telle qu'introduite dans la section 2.3.3. Chaque objet se voit alors associ un ensemble de TAG de scurit en lecture et en criture. Le TAG en lecture T R d'un objet O contenant initialement l'information o, est l'ensemble des CCAL o le contenu o apparait. Son TAG en criture T W est donc l'ensemble des CCAL o le conteneur O apparait. Un ux d'information d'un contenu source vers un conteneur cible est alors traduit par la propagation des restrictions du TAG en lecture du contenu vers les restrictions du TAG en lecture du conteneur. L'exemple de la gure 2.8b illustre l'ensemble de CCAL interprtant la matrice d'accs discrtionnaire de la gure 2.8a. Les conteneurs des chiers F1 et F2 sont nots C1 , C2 . Leurs contenus sont nots f1 , f2 . Il est noter que l'interface de chaque utilisateur a t modlise par un contenu (fA , fB ), reprsentant l'information gnre par un utilisateur et un conteneur (CA , CB ), reprsentant l'information lue. Chaque conteneur est associ ses TAG en lecture et criture. Alice lecture, criture lecture, criture Bob lecture, criture
(a) Exemple de matrice d'accs discrtionnaire
F1
F2
CCALA CCALB
({f1 , f2 , fA }, {C1 , C2 , CA }) ({f2 , fB }, {C2 , CB })

(b) Ensemble des CCAL
Figure 2.8
L'interprtation en termes de CCAL de la gure 2.8b interdit l'utilisateur B d'accder en lecture au contenu f1 . Les gures 2.9b et 2.9c illustrent l'volution des objets suite la copie du contenu du chier F1 dans F2 puis la lecture de F2 par l'utilisateur B. La copie du chier F1 vers F2 gnre un ux d'information du contenu f1 vers le conteneur F2 . Ce ux d'information se traduit R alors par la propagation des restrictions du TAG en lecture TF1 = {CCALA } du chier F1 vers les restrictions du TAG en lecture du chier F2 = {CCALA , CCALB }. Cette propagation est induite R R par l'intersection de ces deux tags : TF2 TF1 = {CCALA } (gure 2.9b). Ce ux d'information peut donc tre not :
R W R W R R W ((F1 , f1 , TF1 , TF1 ), (F2 , f2 , TF2 , TF2 )) (F2 , f2 f1 , TF2 TF1 , TF2 )
La pertinence et la abilit de ce modle ont t prouves grce au thorme de dtection : 15
Thorme 1. (Thorme de dtection) Une violation de la politique de scurit est caractrise

par : T R T W =
Ainsi lors de la lecture du chier F2 par l'utilisateur Bob, un ux est gnr du contenu f2 vers le conteneur Cb (2.9c). Il est donc possible de dtecter une violation de la politique de scurit suite la gnration de ce ux.
TR CCALA CCALA , CCALB CCALA CCALB TW CCALA CCALA , CCALB CCALA CCALB TR CCALA CCALA CCALA CCALB TW CCALA CCALA , CCALB CCALA CCALB
C1 C2 CA CB
C1 C2 CA CB
(a) Associations initiales
(b) L'volution de au ux f1 C2
C1 C2 CA CB
CL CCALA CCALA CCALA
CE CCALA CCALA , CCALB CCALA CCALB
(c) L'volution de au ux f2 CB
Figure 2.9 L'association conteneur, TAG en lecture et TAG en criture

Cette approche a fait l'objet d'une implmentation [ZMB03, HMZ+ 07] sous Linux pour valider un prototype (Blare 2 ) de systme de dtection d'intrusion reposant sur le suivi de ux d'information. L'inconvnient majeur de Blare est la sur-approximation des ux d'information gnrs par les applications, considres comme des botes noires. Un prototype (JBlare) a t alors propos [HMMT07] an d'assurer le suivi d'information au niveau des applications Java en instrumant le bytecode. JBlare est bas sur le mme concept de propagation des CCAL. Il coopre avec Blare an d'assurer un suivi de ux d'information plus prcis et limiter ainsi les faux-positifs.
2.4.3 L'analyse hybride

Russo et Sabelfeld [RS10] ont propos un contrleur sensible au ux d'information, combinant analyse statique et dynamique. Ce contrleur hybride assure le suivi de ux d'information pour un langage impratif simple, tendu avec une instruction grant des sorties au niveau de deux interfaces (achage sur un cran, criture sur le disque . . . ). La premire interface est associe un niveau de scurit secret (not H ) et correspond l'information pouvant tre lue par des utilisateurs privilgis, alors qu'un niveau de scurit publique (not L) est associ la seconde. En eet, la smantique du contrleur est exprime pour deux labels de scurit tels que L H (n'est autoris qu'un ux d'information de Low vers High) pour simplier. L'approche propose constitue cependant un framework hybride de contrle de ux, pouvant tre gnralis un modle de politique en treillis ni, de cardinalit suprieure deux. Par la suite, le modle < {L, H}, , > est considr. La smantique du contrleur de ux d'information 2.10 introduit deux environnements de typages et s . L'environnement associe chaque variable du programme un label de scurit.
2. http ://www.rennes.supelec.fr/blare/
16
L'analyse propose tant une analyse sensible au ux, la valeur qu'associe chaque variable peut varier au cours de l'excution. Le second environnement s est utilis pour tenir compte des ux implicites. Il est initialis [ ] au dbut de l'excution. chaque fois qu'un branchement sur une variable de contrle de niveau H est rencontr, les variables modies dans les branches non excute sont ajoutes s , en y associant le label H . La gnration de cet environnement empil dans s , repose en gnral sur des annotations adjointes au programme durant l'analyse statique. s est aussi souvent appel contexte d'excution. En eet si s = , alors l'excution courante du programme gnre des ux implicites qu'il faut prendre en compte. Il est not que si s = [ ], le niveau de scurit associ au contexte d'excution est L (s = L). Si s = [ ], alors s = H . La smantique du langage impratif utilis est prsente gure 2.11. Les instructions de ce langage dclenche des vnements internes nots . Le contrleur ragit alors via des vnements . Ces vnements synchronisent en fait le programme et le contrleur de ux. (STOP) (LEVEL)
, s , s , s [x lev(e, ) lev(s )], s lev(e, ) = L , , lev(e, ) = H s =
b(e,c) b(e,c) a(x,e) s
(B-LOW) (B-HIGH) (J-HIGH) (J-LOW)
, s , updateh (c) : f , : s , s , ,
f
Figure 2.10 Smantique du contrleur

La gure 2.12 reprsente un programme P divulgant la valeur des variables secret et secret . Ce programme est initialise avec les valeurs secret = 1 et secret = 1. Les variables secrtes reoivent le label de scurit H . Les variables x et y reoivent le niveau L. L'volution du contrleur est reprsente gure 2.13. L'excution du programme P suit le schma suivant : 0 : Initialiement, l'environnement associe chaque variable son niveau de scurit. s est initialise . 1 : l'instruction if dclenche l'vnement interne b(secret, skip). La variable secret tant une variable de niveau H , la rgle B -HIGH applique la fonction updateH (skip). s empile alors l'ensemble vide {} puisqu'aucune variable n'est modie par la branche non excute, c'est--dire skip. 2 : la seconde instruction if dclenche l'vnement b(secret , skip) puisque s = . Le contrleur excute alors la fonction updateH (y := 0) et donc s empile l'ensemble {y H}. Il est noter que mme si la variable de contrle de ce branchement est associe un niveau L, la rgle B -HIGH aurait forc l'excution de la fonction updateH puisque s associe au contexte d'excution un niveau H pour empcher tout ux implicite dcoulant du branchement de l'instruction 1. 3 : l'aectation de la variable x dclenche l'vnement a(x, 1). Le label (x) est alors mis jour avec la valeur lev(x, ) lev(s ) = H . 6 : l'vnement interne f est dclench puisque les deux branches de l'instruction 2 se rejoignent. 17
(SKIP) (ASSIGN) (COMP) (COM P ) (IF)
skip, m stop, m m(e) = v x := e, m stop, m[x v] c1 , m stop, m c1 ; c2 , m c2 , m c1 , m c1 , m , c1 = stop c1 ; c2 , m c1 ; c2 , m m(e) = 0 if e then c1 else c2 , m m(e) = 0
b(e,c2 ) a(x,e)
c1 ; end, m
(WHILE)
if e then c1 else c2 , m c2 ; end, m m(e) = 0 while e do c , m

b(e,skip)
b(e,c1 )
c; end; while e do c, m m(e) = 0 c; end; while e do c, m
(STOP) (OUTPUT)
while e do c , m f end, m stop, m m(e) = v outputl (e), m

ol (e,v)
b(e,skip)
stop, m
Figure 2.11 Smantique du langage impratif et vnements internes
1 2 3 4 5 6 7 8 9 10
if
secret
if
secret x=1 y=0
else else
endif endif skip
outputL (x)
Figure 2.12 Exemple de fuite d'information dans un programme
18
0 1 2 3 6 9
b(secret, skip) b(secret , y :=0) a(x, 0) f f
secret H, secret H, secret H, secret H, secret H, secret H,
secret secret secret secret secret secret
H, H, H, H, H, H,
x L, x L, x L, x H, x H, x H,
yL yL yL yL yH yH
s [ ] [{} : ] [{y H} : {} : ] [{y H} : {} : ] [{} : ] [ ]
Figure 2.13 volution de et s suite l'excution de P

L'ensemble {y H} est dpil, puis (y) est mise jour (J -HIGH ). 9 : l'vnement interne f dpile simplement l'ensemble vide. L'instruction 10 reprsente une violation de la condentiali puisque la valeur de x peut divulguer la valeur des variables secret et secret . En eet, le framework propos considre que seules les interfaces de sortie sont responsables de la fuite d'information. Russo et Sabelfeld ont dmontr que le framework d'analyse hybride propos garantissait la proprit de non-interfrence insensible la terminaison du programme 2. Cepedant, il s'avre que le suivi de ux d'information n'est pas une tche aise en pratique. Plusieurs dicults se posent, notamment pour le suivi des ux implicites et la gestion des programmes concurrents. Plusieurs travaux se sont intresss l'implmentation de mcanismes de contrles de ux hybrides pour les programmes Java [NSCT07, CF07]. Les attaques contre ce langage qui est trs souvent utilis dans les applications Web, ont connu une nette hausse rcemment. Elles reprsentaient 7% de l'ensemble des attaques en Septembre 2010 (contre 5% en Juillet 2010), ce qui en fait l'un des premiers vecteur d'attaques Web 3 . Ces mcanismes s'appuient sur une analyse statique du bytecode Java pour construire le graphe de ot de contrle du programme (GFC) contrl. Un GFC est un graphe orient, dont les noeuds reprsentent des blocs d'instructions et les arcs reprsentent les dirents chemins que l'excution peut suivre. Cette tape est ncessaire pour dnir les variables dont les labels de scurit doivent tre mis jour pour tenir compte des ux implicites. L'analyse statique est eectue pralablement l'excution pour des raisons de performance. L'analyse dynamique propage ensuite les labels de scurit des variables au cours de l'excution. L'une des dicults de cette approche est de construire le GFC pour suivre de manire prcise les ux implicites. Cependant, il ne sut pas de prendre en compte seulement les structures conditionnelles de Java telles les instructions if et les boucles while. En eet, le transfert de ot de contrle peut aussi tre induit par des exceptions. L'exemple suivant try {int z = 1/(x y); } catch (Exception e){print(secret is true); } illustre un exemple de programme pouvant divulguer de l'information par le biais d'une exception. Un attaquant peut dduire la valeur de la variable secret en ayant accs la variable public. Cette exception est gnre suite l'valuation d'une instruction faisant intervenir la variable y . Or le niveau de scurit de y est gal H puisqu'elle dpend de la variable secret. On peut donc considrer qu'il existe un ux implicite dont il faut tenir compte, d la gnration d'une exception suite l'valuation d'une expression faisant intervenir la variable y . Les exceptions doivent alors tre gres de la mme manire qu'une instruction conditionnelle.
3. http ://www.cisco.com/en/US/prod/collateral/vpndevc/3q10_cisco_threat.pdf
19
Cette exception tant dclare et gre explicitement par une instruction try{. . .} catch{. . .}, Il est possible de tenir compte d'une manire prcise du transfert de ot de contrle grce l'analyse statique du bytecode. Nair et al. [NSCT07] ainsi que Chandra et Franz [CF07] prconisent dans ce cas d'ajouter au GFC une arte reliant le dbut du bloc d'instructions try{. . .} au bloc d'instructions catch{. . .}. Les exceptions peuvent tre dclares mais non gres explicitement par la mthode qui les dclare. Il est alors beaucoup plus dicile, de dterminer quel bloc d'instructions est excut pour la gestion de l'erreur leve, au moment de l'analyse statique. Chandra et Franz ignorent ce type d'exceptions. Nair et al. adoptent par contre une approche dirente. L'analyse statique essaie de dterminer quel type d'exception est lev, pour tenter de trouver l'instruction qui place dans la pile la rfrence ce type d'exception. Cette rfrence correspond au bloc charg de grer cette exception. Une arte reliant l'instruction throw ce bloc est ajoute au GFC. En cas d'chec, une arte relie chaque instruction throw au bloc exit de la mthode dans laquelle elle se trouve. Il est noter que les deux approches ignorent les exceptions non dclares.
20
Chapitre 3
Contexte
Dans cette partie, nous allons tout d'abord rappeler les objectifs de ce stage. Nous prsenterons ensuite l'outil Soot d'analyse statique de Bytecode, la reprsentation intermdiaire Jimple sur laquelle nous fondons notre analyse statique, puis deux exemples d'analyse de ux de donnes statique.
3.1 Objectifs
L'objectif de ce stage est de proposer un mcanisme hybride de suivi de ux d'information au sein des programmes Java, pour la dtection d'intrusion paramtre par la politique de scurit. Ce mcanisme inclue une premire analyse, statique, qui opre sur le Bytecode, puis une seconde analyse, dynamique, qui dduit les ux d'information gnrs par une excution d'un programme grce aux rsultats de l'analyse statique. L'analyse statique doit raliser un prol pour chaque classe Java analyse puis le sauvegarder sous forme d'annotations dans le chier contenant la classe correspondante. Ceci permettra l'analyse dynamique de rutiliser ce prol lors de chaque excution, sans avoir relancer l'analyse statique pour le regnrer. Contrairement Nair et al. [NSCT07] ainsi que Chandra et Franz [CF07] qui s'appuient sur l'analyse statique pour tenir compte des ux implicites seulement, nous souhaitons que notre analyse puisse aussi tenir compte des ux explicites pour amliorer les performances du suivi de ux d'information lors de l'analyse dynamique. L'analyse dynamique doit s'appuyer sur les annotations gnres par l'analyse statique pour dduire les ux d'information gnrs par le programme contrl, puis mettre jour les labels de scurit associs aux variables manipules. Comme Nair et al [NSCT07], nous prenons le parti de modier une JVM plutt que d'instrumenter le Bytecode Java. Ceci permettra de limiter l'impact de l'analyse dynamique et faciliter son intgration avec le mcanisme Blare de suivi des ux d'information au niveau OS. La premire partie de ce stage, comptant pour le Master Recherche en Informatique de l'universit de Rennes 1, doit dboucher sur le dveloppement d'un modle d'analyse statique pour le suivi de ux d'information. La conception et l'implmentation de l'analyse dynamique seront ralises lors de la seconde partie de ce stage, comptant comme stage de n d'tude pour l'cole Suplec. Les travaux eectus concernant l'analyse statique sont prsents dans la partie 4. Les trois sections suivantes exposent les outils ainsi que le contexte de l'analyse statique dveloppe.
21
3.2 Soot : analyse statique de Bytecode

Soot est un framework d'optimisation et d'analyse statique de Bytecode. Il a t ralis an de simplier l'analyse et la transformation de Bytecode Java grce l'utilisation d'une reprsentation intermdiaire sous forme de code 3 adresses. Il a bnci d'un dveloppement intensif depuis une dizaine d'anne, ce qui a permis de l'enrichir de plusieurs analyses statiques intra-procdurales ou inter-procdurales, ainsi que direntes optimisations telles que l'limination de code inutile ou la compaction de variables. Il intgre aussi direntes reprsentations intermdiaires du Bytecode telles que Jimple que nous prsentons dans la section suivante. Enn, ce framework intgre un plugin eclipse permettant la visualisation pas pas de l'analyse statique implmente, ce qui s'est avre tre d'une grande utilit lors de la validation de l'analyse statique dveloppe et du dbogage.
3.3 Jimple : reprsentation intermdiaire de Bytecode

L'analyse statique de Bytecode et plus gnralement des langages de pile s'avrant trs complexe, Valle-Rai et Hendren [VRH98] ont eu recours au dveloppement d'une reprsentation intermdiaire de Bytecode faciliant cette tche. Cette forme intermdiaire, appele Jimple, a les caractristiques suivantes : elle est sous la forme d'un code 3 adresses ; elle n'utilise pas de pile ; ses variables sont explicitement dclares et types. L'exemple suivant de la gure 3.1, tir de [VRH98], est une squence d'instructions Bytecode stockant dans la variable locale l0 la valeur de l'expression l1/(5 (l2 + l3)). Cette exemple illustre la dicult de l'analyse statique de Bytecode. En eet, avant de pouvoir dterminer quelle expression est utilise la ligne 10 par exemple, il faut d'abord examiner toutes les instructions prcdentes en simulant leur eet sur la pile. Ceci peut s'avrer trs coteux, d'autant plus qu'il peut y avoir un trs grand nombre d'instructions entre l'empilement d'un oprande sur la pile et son dpilement, c'est-dire son utilisation. Or en Jimple, il sut de localiser les instructions qui manipulent la variable correspondante. De plus, le nombre trs restreint d'instructions Jimple, compar la multitude d'instructions Bytecode, facilite grandement l'implmentation d'une analyse statique. La gnration de code Jimple partir de Bytecode dans le framework Soot passe par 5 tapes : 1. 2. 3. 4. 5. gnration de code Jimple simple non typ ; une premire phase d'optimisation ; sparation des direntes variables pour prparer le typage ; typage du code Jimple ; une dernire phase d'optimisation.
Dans la suite de ce rapport, nous ne nous intresserons pas aux tapes d'optimisation 2 et 5 que nous avons dsactives lors de l'analyse, car nous souhaitons garder une forme intermdiaire la plus dle possible au Bytecode initial, pour permettre la transposition des rsultats de notre analyse statique. La premire tape de gnration du code Jimple consiste produire un code 3 adresses simple, non typ. Ceci est ralis en associant chaque oprande de pile une variable Jimple locale non type, puis en transformant les rfrences d'oprandes de piles implicites en rfrences explicites de variables locales. La gure 3.1 illustre ces transformations. 22
Instructions Bytecode
1 2 3 4 5 6 7 8 9 10
Simulation de pile [ l1 ] [ l1 , [ l1 , [ l1 , [ l1 , [ l1 , [ l1 / [ l1 / [ l1 / [] 5] 5 , l2 ] 5 , l2 , l 3 ] 5 , l 2+l 3 ] 5 * ( l 2+l 3 ) ] ( 5 * ( l 2+l 3 ) ) ] ( 5 * ( l 2+l 3 ) ) , . . . ] ( 5 * ( l 2+l 3 ) ) ]
Instructions Jimple $stack0 = l1 $stack1 = 5 $stack2 = l2 $stack3 = l3 $stack2 = $stack2 + $stack3 $stack1 = $stack1 * $stack2 $stack0 = $stack0 / $stack1 ... ... l0 = $stack0
iload 1 iconst 5 iload 2 iload 3 iadd imul idiv ... ... istore 0
Figure 3.1 Exemple de programme

Instructions Bytecode
1 2 3 4
Instructions Jimple
1 2 3 4
l d c #10 astore 1 bipush 10 istore 2
$stack0 = " analyse statique " l1 = $stack0 $ s t a c k 0 = 10 l2 = $stack0
Figure 3.2 Exemple de code Jimple simple non typ

Le code Jimple obtenu suite la premire tape ne peut pas tre typ. En eet, l'exemple de la gure 3.2 illustre le fait que la mme variable Jimple puisse tre utilise avec dirents types. En l'occurence, la variable $stack0 est tantt une chane de caractre, tantt un entier. Ceci est possible car les spcications de la JVM permettent l'aectation de types dirents aux variables locales ainsi qu'aux oprandes de pile, du moment qu'aucun conit n'existe. L'ide pour s'aranchir de ce problme est alors de renommer ces variables pour viter qu'elles soient rutilises. Pour cela, le framework Soot utilise le concept de webs [Muc97], qui capture les direntes dnitions possibles pour une variable ainsi que ses direntes utilisations possibles. Nous parlerons dans la suite de ce rapport d'une variable dnie ou une variable utilise par une instruction selon les dnitions 5 et 6. Le concept de webs est formellement dni en 7.
Dnition 5 (Une variable dnie par une instruction). Une instruction dnit une variable si elle
assigne une valeur cette variable. lit la valeur de cette variable.
Dnition 6 (Une variable utilise par une instruction). Une instruction utilise une variable si elle Dnition 7 (Un web). Un web est un ensemble S de rfrences, minimal et clos. Cet ensemble
est clos dans le sens o pour chaque dnition d S , toutes les utilisations possibles de d sont dans S . De mme, pour chaque utilisation u S , toutes les dnitions possibles de u sont dans S . Un algorithme de construction des webs d'un programme est fourni dans [Muc97]. Considrons l'exemple illustr par la gure 3.3. 23
If z > 1
If z#1 > 1
x=1
x=2
x#1 = 1
x#1 = 2
If z > 2
If z#1 > 2
y=x+1
z = x -3
y#1 = x#1 + 1
z#2 = x#1 -3
x=4
x#2 = 4
z=x+7
z#3 = x#2 + 7
exit
exit
Figure 3.3 Exemple de programme

x :2 x :4 x :7
Figure 3.4 Sparation des variables pour

l'exemple 3.3 x :5 x :6 x :8
Dnitions d Utilisations u
Figure 3.5 Les direntes dnitions et utilisations de la variable x

La variable x est dnie l'instruction 2, 4 et 7, alors qu'elle est utilise l'instruction 5, 6 et 8 comme l'illustre la gure 3.5. Nous notons x : l la dnition ou l'utilisation de la variable x l'instruction dont le label est l. Prenons la dnition x : 2 par exemple. Cette dnition a deux utilisations possibles, x : 5 et x : 6. Or l'utilisation x : 5 n'a qu'une seule dnition possible qui est x : 2, alors que l'utilisation x : 6 a deux dnitions possible ; x : 2 et x : 4. Aussi, la dnition x : 4 n'a qu'une seule utilisation possible qui est x : 6. Nous avons ainsi construit notre premier ensemble minimal et clos, et donc le premier web. Le deuxime web est compos des dnitions et utilisations restantes, c'est--dire x : 7 et x : 8. En eet, la dnition x : 7 n'est utilis qu'une seule fois par x : 8 et l'utilisation x : 8 n'est dni qu'une seule fois par x : 7. Donc cet ensemble est bien clos et minimal. Une fois l'ensemble des webs construit, il est alors possible de sparer les direntes variables locales en associant chaque web une seule et unique variable, ce qu'illustre la gure 3.4 pour le programme de la gure 3.3. Les variables locales ainsi obtenues peuvent donc tre types, condition que le programme soit typable, ce qui est le cas de tous les programmes gnrs correctement par un compilateur Java.
24
L'tape numro 4 de la production du code Jimple consiste aecter des types aux direntes variables. L'approche adopte dans Soot consiste construire un ensemble de restrictions de types pour chaque variable locale en parcourant le code. Ces restrictions sont ensuite utilises pour en dduire le type de la variable en question.
3.4 Analyse statique de ot de donnes

L'analyse statique de ot de donnes a pour objectif de dnir, pour chacune des instructions d'un programme, une approximation d'un ensemble de proprits concernant les donnes manipules. Elle est ralise en spciant un ensemble d'quations locales dcrivant les proprits des chaque instruction, puis en rsolvant des quations globales dcrivant la propagation de ces proprits au sein d'instructions successives. Elle ncessite la reprsentation du programme sous forme de graphe de ot de contrle (CFG). Nous prsentons dans la suite l'analyse de vivacit des variables, un exemple classique d'analyse statique de ot de donnes, ainsi que l'analyse des post-dominateurs d'un noeud du CFG. Ces deux analyses, implmentes dans le framework Soot, sont utilises lors de notre analyse statique de ux d'information.
3.4.1 Analyse de vivacit des variables

Cette analyse dtermine pour un point donn du programme analys, quelles variables sont dnies et potentiellement utilises plus tard. Les compilateurs s'en servent souvent lors de l'allocation de registres ou l'limination de code inutile. Une dnition de la proprit de vivacit d'une variable est donne en 8.
Dnition 8 (La vivacit d'une variable). Une variable x est vive dans une instruction i si l'une
des conditions suivantes est ralise : 1. x est utilise dans l'instruction i ; 2. x est vive aprs l'excution de i, sans tre rednie par i.
Dans l'exemple de la gure 3.6, la variable y est utilise la premire instruction, mais n'est plus utilise plus tard. Donc la variable y est vive la premire instruction seulement. Notons que cette variable doit tre dnie bien avant ce bloc d'instruction. La variable x, par contre, est dnie la premire instruction, puis est utilise la dernire instruction. Or il existe un chemin d'excution o x n'est pas rednie entre la premire et la dernire instruction, elle est donc vive pour tout ce bloc d'instructions. Quant la variable z , elle n'est jamais utilise, bien que dnie la deuxime et quatrime instruction. Elle n'est donc vive aucune instruction. L'analyse de vivacit peut tre formalise en analyse de ot de donnes en arrire (backward analysis ) : le parcours du CFG dbute par le point de sortie du programme et remonte dans le sens contraire au chemin d'excution. Cette analyse associe deux ensembles chaque instruction i du programme, genSet(i) et killSet(i), dnis par les quations locales 3.1. GenSet(i) est l'ensemble des variables utilises par i, alors que KillSet(i) est l'ensemble des variables dnies par i.
GenSet(i) = ensemble de variables utilises par i KillSet(i) = ensemble variables dnies par i
(3.1)
25
x = y +1
z=0
If x < 0
z=1
x = sqrt(x)
return x
Figure 3.6 Exemple de programme et le rsulat de l'analyse de vivacit de ses variables

L'analyse de vivacit rsout ensuite pour chaque instruction i, les quations globales 3.2 des ensemble inSet(i) et outSet(i).
OutSet(i) = s:succ(i) InSet(s) InSet(i) = GenSet(i) (OutSet(i) \ KillSet(i))
(3.2)
L'ensemble OutSet(i) reprsente les variables vives aprs l'excution de l'intruction i. On considre par dnition, qu'une variable est vive aprs l'instruction i si elle est vive dans au moins un des successeurs de i car on cherche dterminer toutes les variables potentiellement vives, d'o l'utilisation de l'union. Si l'on cherchait dterminer les variables srement vives aprs une instruction donne, on aurait plutt utilis l'intersection des ensembles InSet(s), o s est un successeur de l'instruction i. Ce choix est trs important et dpend fortement de l'utilisation que nous voulons faire des rsultats de cette analyse. Si cette analyse est utilise pour l'limination de code inutile, nous choisirons de faire une sur-approximation des variables vives car nous voudrons absolument viter de supprimer des dnitions de variables qui pourraient tre utilises plus tard. Nous opterons alors pour l'union -comme nous l'avons fait dans cet exemple- plutt que l'intersection. L'ensemble InSet(i) par contre reprsente les variables vives avant l'excution de l'instruction i. L'analyse de ux de donnes rsout ces quations grce au parcous du CFG et la propagation des ensembles inSet et outSet, jusqu' trouver un point xe et donc une solution ces quations globales. La gure 3.7 illustre le rsultat de cet analyse sur l'exemple de la gure 3.6 :
3.4.2 Post-dominateur dans un CFG

Dans un graphe de ot de contrle, un noeud m post-domine un noeud n si tous les chemins d'excution de n vers le point de sortie passe par le noeud m. Cette relation dnit un ordre partiel pour les noeud du CFG. Dans l'exemple de la gure 3.3, les noeuds 6, 7 et 8 post-dominent le noeud 4. Par contre seul le point de sortie exit post-domine les noeuds 1, 2 et 3.
26
On appelle aussi un post-dominateur immdiat du noeud n l'unique noeud qui est dirent de n, qui post-domine n et qui est post-domin par tous les autres post-dominateurs de n. Pour une instruction conditionnelle, le post-dominateur immdiat est le point de jonction de toutes les branches de cette instruction. Le noeud exit est par exemple le post-dominateur immdiat du noeud 1 dans la gure 3.3. Les post-dominateurs des noeuds d'un CFG peuvent tre dtermins grce une analyse de ot de donnes en arrire. Les quations de cette analyse sont fournies dans la gure 3.3. Un exemple de cette analyse est aussi droul gure 3.8.
OutSet(i) = s:succ(i) InSet(s) InSet(i) = outSet(i) {i}
(3.3)
inSet(1)={y} x = y +1 1 killSet(1)={x} genSet(1) = {y}
inSet(1)={1,2,3,6} x = y +1 1 killSet(1)={x} genSet(1) = {y}
outSet(1)= inSet(2) = {x}
outSet(1)= inSet(2) = {2,3,6}
z=0
z=0
outSet(2)= inSet(3) = {x}
outSet(2)= inSet(3) = {3,6}
If x < 0
in Se t(4
3
{x
in Se
If x < 0
t(4
3
{5 ,6
outSet(3) = {4,6}{5,6}
t(5 )=
in
z=1
inS )= (4 x } et = { S ut ( et 6)
x = sqrt(x)
o in utS Se e t t(6 (5) )= = {x }
genSet(5)={x}, killSet(5) = {x} killSet(4)={z}
z=1
e inS = 4) {6} t( Se = ut t( 6)
in
Se
)= {x }
,6
Se
t(5 )=
)= {4
x = sqrt(x)
o in utS Se e t t(6 (5) )= = {6 }
5 killSet(4)={z}
return x outSet(6)={}
genSet(6)={x}
return x outSet(6)={}
Figure
3.7 Analyse de vivacit sur Figure 3.8 Analyse des post-dominateur l'exemple gure 3.6 sur l'exemple de la gure 3.6
27
Chapitre 4
Travaux raliss
4.1 Introduction
L'analyse statique que nous souhaitons raliser est une analyse intra-mthode. En eet, pour un programme Java, il est souvent impossible de dterminer, avec prcision, quelle mthode est appele lors de l'excution grce une analyse statique. Une analyse inter-procdurale ncessiterait alors de faire de grossires approximations. Notre analyse construit construit donc un prol pour chacune des mthodes appartenant aux classes Java analyses. Ce prol est ensuite utilis pour annoter la mthode correspondante. Cette analyse statique est ralise sur la reprsentation intermdiaire Jimple des mthodes. Elle fait l'hypothse que la JVM modie, ralisant l'analyse dynamique, soit capable d'aecter des labels de scurit aux variables manipules, que ces variables soient des paramtres de mthodes, oprandes de pile, objets ou attributs d'objets. De plus, cette JVM est capable de charger les annotations d'une mthode avant son excution et de les interprter en termes de ux d'information et de points de contrle, qui pointent tous deux vers des instructions Bytecode de la mthode analyse. Ces points de contrle correspondent un ensemble de compteurs ordinaux d'instructions Bytecode pour lesquelles il est ncessaire que la JVM eectue certaines actions an de suivre les ux d'information, avant de pouvoir poursuivre l'excution l'instruction suivante. Ces actions sont explicites dans la suite de ce rapport. Notons que l'analyse que nous proposons n'est pas une analyse l scuris car nous raisonnons sur une excution squentielle des mthodes analyses.
4.2 Suivi des ux explicites

Un ux d'information explicite de y vers x est gnr chaque fois que le contenu d'une variable y ou une information drive de ce contenu est transfr explicitement dans la variable x. Dans le cas d'une aectation x = y + z par exemple, il y a un ux explicite des variables y et z vers la variable x. Nous disons dans la suite de ce rapport que x dpend de y et z . Aussi, l'ensemble {y, z} des variables dont x dpend est appel l'ensemble de dpendance de x.
4.2.1 Description
L'analyse propose pour permettre le suivi des ux explicites est une analyse de ux de donnes en avant (forward analysis ). Le parcours du CFG dbute par les points d'entre de la mthode, 28
puis continue dans le sens du chemin d'excution. Nous souhaitons tenir compte avec prcision des ux explicites grce cette analyse. Cependant, comme nous l'avons discut dans la section 3.4.1, la perte d'information est inhrente l'analyse statique puisque nous devons choisir entre une surapproximation ou une sous-approximation des ux gnrs par deux chemins d'excution dirents qui se rejoignent. Ceci est illustr par la gure 4.1.
If z > 1
x=1 x {y} : un flux dinformation de y vers x a=b a {b} x=y x {y} y=x+1
x=2
If z > 2
z = x -3
skip sous-approximation : sur-approximation : x {y}, a {b}
x=4
Figure 4.1 Approximation de l'analyse

statique
exit
z=x+7
Figure
4.2 Exemple de dcoupage d'une mthode en blocs de base Nous nous aranchissons de ce problme en dcoupant la mthode analyse en blocs de base et en restreignant l'analyse statique chacun de ces blocs. Un bloc de base est une squence d'instruction, ayant un seul point d'entre (la premire instruction) et un seul point de sortie (la dernire instruction) [All70]. Ceci veut dire qu' chaque fois que la premire instruction d'un bloc est excute, les instructions suivantes de ce bloc sont excutes dans l'ordre et une seule fois. Un bloc de base ne contient donc ni des boucles ni des branchements. Il peut biensr avoir plusieurs blocs successeurs ou prdcesseurs. Il peut aussi tre lui mme un bloc successeur dans le cas des boucles. La gure 4.2 illustre un exemple de dcoupage d'une mthode en blocs de base.
4.2.2 Prsentation de l'analyse statique des ux explicites

L'analyse statique de ot de donnes propose est ralise pour chacun des blocs de base de la mthode analyse. Ces analyses tant indpendantes les unes des autres, l'analyse dynamique se charge de mettre bout bout les rsultats obtenus pour chaque bloc de base. En eet, la dernire instruction de chaque bloc, l'analyse statique force la JVM modie mettre jour les labels de scurit associs aux variables manipules dans ce bloc, avant de poursuivre l'excution du bloc successeur. Nous appellerons l'action de ce point de contrle save_labels(). Dans la suite, nous formaliserons l'analyse statique des ux explicites pour un bloc de base donn. Nous ne considrons 29
dans cette sous-section que les ux gnrs par des types primitifs Java puisque nous discuterons les rfrences dans la sous-section 4.2.3. L'analyse propose associe deux ensembles d'associations chaque instruction i du bloc de base Jimple analys, inSet(i) et outSet(i). Ces ensembles associe une variable son ensemble de dpendance. L'ensemble associe une variable v (que nous noterons inSet(i)[v] ou outSet(i)[v]) est l'ensemble des variables dont v dpend explicitement. Cela signie qu'il y a un ux d'information explicite partir de toutes les variables appartenant l'ensemble inSet(i)[v] (respectivement outSet(i)[v]) vers la variable v . L'ensemble inSet(i)[v] est l'ensemble des ux d'information explicites gnrs avant l'excution de l'instruction i, alors que l'ensemble outSet(i)[v] reprsente les ux explicites gnrs aprs l'excution de l'instruction i. Les quations de cette analyse de ux de donnes en avant sont explicites en 4.1. L'ensemble d'associations inSet du point d'entre du bloc de base est initialis l'ensembles d'associations vide {}.
inSet(i) = outSet(pred(i))
outSet(i) = genSet(i) inSet(i) {v Dv } si i dnit une variable v . Dv est l'ensemble genSet(i) = des variables utilises pour dnir v {} sinon
(4.1)
La premire quation de 4.1 copie dans l'ensemble d'associations inSet de l'instruction i l'ensemble d'associations outSet de son prdcesseur. La seconde quation introduit un ensemble d'associations genSet(i) ainsi qu'un oprateur . L'ensemble d'associations genSet(i) correspond aux ux d'information explicites gnrs par l'instruction i. Il associe la variable ventuellement dnie par l'instruction i son ensemble de dpendances explicites, c'est--dire les variables utilises par l'instruction i. L'oprateur est dni pour deux ensembles d'associations et rend un ensemble d'associations. Cet oprateur n'est pas commutatif car il rsout les dpendances des variables utilises dans une instruction en fonction des ux gnrs par les instructions qui la prcdent. Il est dni formellement en 9. Soient R et S deux ensembles d'associations tels que : R = vV {v R[v]} et S = vW {v S[v]}. R[v] ou S[v] est l'ensemble de dpendances de la variable v . L'oprateur est alors dni comme suit :
R S = vV {v R[v]} vW {v S[v]} = vV {v fS (R[v])} vW {v S[v]}
Dnition 9 (L'oprateur ). Soient V et W deux ensembles de variables.
o fS est dni comme suit :

fS (R[v]) = (xR[v]W S[v]) (xR[v]\W {x})
L'exemple de la gure 4.3 illustre l'analyse de ux de donnes selon la formalisation que nous avons proposes prcdemment. Considrons l'instruction numro 3 de cet exemple. Cette instruction dnit la variable $stack0#2 en utilisant les variables $stack0 et $stack1. L'ensemble d'associations outSet(3) va donc prendre en compte ces ux d'information explicites, tout en resolvant les 30
inSet(1)={} 1 $stack0 = l0 genSet(1) = {$stack0 {l0}}
inSet(2)= outSet(1) = { $stack0 {l0} } genSet(2) = {$stack1 {l1}}
$stack1 = l1
inSet(3)= outSet(3) = {$stack0 {l0}, $stack1 {l1}} genSet(3) = {$stack0#2 {$stack0, $stack1} }
$stack0#2 = $stack0 + $stack1
inSet(4)=outSet(3) = {$stack0 {l0}, $stack1 {l1}, $stack0#2 {l0,l1}}
$stack1#2 = l2
inSet(5)= outSet(4) = {$stack0 {l0}, $stack1 {l1}, $stack0#2 {l0,l1}, $stack1#2 {l2}} 5 $stack0#3 = $stack0#2 + $stack1#2 {$stack0 {l0}, $stack1 {l1}, $stack0#2 {l0,l1}, $stack1#2 {l2}, $stack0#3 {l0, l1, l2}} genSet(5) = {$stack0#3 {$stack0#2, $stack1#2} }
Figure 4.3 Exemple de l'analyse de ux de donnes

dpendances prsentes dans inSet(3), des deux variables $stack0 et $stack1 :
genSet(3) = {$stack0#2 {$stack0, $stack1}} inSet(3) = $stack0 {l0}, $stack1 {l1} outSet(3) = $stack0 {l0}, $stack1 {l1}, $stack0#2 {l1, l2}
Nous pouvons aussi remarquer grce l'exemple de la gure 4.3, que les ensemble d'associations inSet et outSet vont trs vite exploser en taille. En eet, du fait de l'utilisation des webs pour typer le code Jimple, un trs grand nombre de variables est gnr, alors que ces variables peuvent correspondre en ralit une seule et mme position sur la pile. L'oprande de pile $stack0 par exemple, empil la position 0 suite l'excution de l'instruction numro 1, est dpil aprs l'excution de l'instruction numro 3. Il est alors remplac par $stack0#2, sa somme avec $stack1. Donc cette variable $stack0 ne sera vraisemblablement plus utilise aprs l'excution de l'instruction numro 3. Pourtant, nous propageons pour l'instant ses dpendances, jusqu' la n du bloc analys. Nous adressons ce problme grce l'analyse de vivacit des variables. En eet, si une variable n'est plus vive dans une instruction i, c'est--dire qu'elle n'est plus utilise dans la suite de la mthode et si cette variable est prsente dans l'ensemble inSet(i), alors nous la supprimons de l'en31
semble d'associations outSet car nous n'avons plus besoin de garder l'ensemble de ses dpendances. Ce raisonnement n'est valable que pour les variables locales et les oprandes de piles de type primitif car ils ont une porte limite la mthode. S'ils ne sont pas utilises partir d'une certaine instruction, on peut oublier leurs dpendances puisque nous n'en aurons plus besoin par la suite. Nous introduisons pour cela un ensemble de variables killSet(i) pour chaque instruction i, ainsi qu'un oprateur dni en 10. L'ensemble de variables killSet(i) permet de supprimer les dpendances des variables qui sont prsentes dans l'ensemble d'associations inSet(i) et qui ne sont pas vives dans l'instruction i. L'oprateur est donc dni pour un ensemble d'associations et un ensembles de variables.
Dnition 10 (L'oprateur ). Soient V et W des ensemble de variables.
Soit R un ensemble d'associations, tel que R = vV {v R[v]}. L'oprateur est alors dni comme suit : R W = vV \W {v R[v]} o V \ W est la dirence ensembliste de V et W .
Les quations de la nouvelle analyse propose sont explicites en 4.2. Ces quations introduisent l'oprateur i paramtr par l'instruction i et dni en 11. Le fonctionnement de cet oprateur est le mme que celui prsent en 9, sauf qu'il rsout les dpendances de associations de genSet(i) avant la suppression des variables qui ne sont plus vives. Il rsout donc ces dpendances par rapport l'ensemble inSet(i).
inSet(i) = outSet(pred(i)) outSet(i) = genSet(i)
i
(inSet(i) killSet(i))
{v Dv } si i dnit une variable v . Dv est l'ensemble genSet(i) = des variables utilises pour dnir v {} sinon killSet(i) = l'ensemble des variables prsentes dans inSet(i) et qui ne sont plus vives dans i
(4.2)
Dnition 11 (L'oprateur
i ). Soient V , W et Z trois ensembles de variables. Soient R et S deux ensembles d'associations tels que : R = vV {v R[v]} et S = vW {v S[v]}. Soit l'ensemble d'association inSet(i) = vZ {v inSet(i)[v]} associ l'instruction i. L'oprateur i est alors dni comme suit :
R
i
S = vV {v R[v]}
i
vW {v S[v]}
= vV {v finSet(i) (R[v])} vW {v S[v]}
o fS est dni comme suit : finSet(i) (R[v]) = (xR[v]Z inSet(i)[v]) (xR[v]\Z {x}) Le rsultat de cette nouvelle analyse sur l'exemple 4.3 est illustr par la gure 4.4. Les variables supprimes grce l'ensemble killSet sont barr d'un trait dans cet exemple. Ce raisonnement concernant la vivacit des variables n'est par contre pas valable pour les objets qui peuvent avoir 32
une porte globale. En eet, comme nous allons le voir dans la section 4.2.3, l'analyse propose prcdemment est modie pour prendre en compte la particularit des objets ou des rfrences en gnral. Notons que l'analyse de vivacit est ralise sur l'ensemble de la mthode et pas seulement sur le bloc de base, contrairement l'analyse statique des ux explicites.
inSet(1)={} 1 $stack0 = l0 liveVars(1) = {$stack0}
inSet(2)= outSet(1) = { $stack0 {l0} } liveVars(2) = {$stack0, $stack1}
$stack1 = l1
inSet(3)= outSet(3) = {$stack0 {l0}, $stack1 {l1}}
liveVars(3) = {$stack0#2} 3 $stack0#2 = $stack0 + $stack1 killSet(3) = {$stack0, $stack1}
inSet(4)=outSet(3) = {$stack0 {l0}, $stack1 {l1}, $stack0#2 {l0,l1}} 4 $stack1#2 = l2 liveVars(4) = {$stack0#2, $stack1#2}
inSet(5)= outSet(4) = { $stack0#2 {l0,l1}, $stack1#2 {l2}}
$stack0#3 = $stack0#2 + $stack1#2
liveVars(5) = {$stack0#3} killSet(5) = {$stack0#2, $stack1#2}
{$stack0#2 {l0,l1}, $stack1#2 {l2}, $stack0#3 {l0, l1, l2}}
Figure 4.4 Exemple de l'analyse de ux de donnes

Enn, la n de chaque bloc de base, l'analyse statique marque la dernire instruction avec un point de contrle save_labels() forant la JVM modie mettre jour les labels de scurit des variables prsentes dans l'ensemble d'associations outSet. Ces variables vives donc, peuvent tre des oprandes de piles ou des variables locales. Pour permettre la mise jour des labels de scurit, l'analyse dynamique doit dnir un ensemble de labels SC ainsi qu'une relation : SC SC SC . Cette relation dpend du modle de politique de ux choisi. Dans le cas d'une politique de ux en treillis (dnition 4) par exemple, l1 l2 sera la borne suprieur minimal des deux labels de scurit l1 et l2 . Les ux d'information a {x, y, z} dnira alors le label de scurit a pour la variable a, tel que a = x (y z) o x, y et z sont respectivement les labels de scurit associs aux variables x, y et z .
33
4.2.3 Les rfrences

La manipulation des rfrences peut poser problme lors de notre analyse statique. En eet, considrons l'exemple prsent gure 4.5. Cet exemple stocke l'attribut statique T est.n dans la variable locale la position numro 1. Il rinitialise ensuite cet attribut en lui aectant la valeur 0. Le rsultat de l'analyse statique propose en 4.1 pour cet exemple est illustr par la gure 4.6. Rappelons que la variable stack0 par exemple a t supprime de outSet(3) car cette variable n'est plus utilise par la suite. Nous considrons par contre dans cette exemple que les variables l1, et T EST.n sont toujours vives l'instruction 4. Instructions Bytecode
1 2 3 4
Instructions Jimple
g e t s t a t i c TEST. n : int $ s t a c k 0 = <TEST: int n> istore 1 l1 = $stack0 iconst 0 $ s t a c k 0#2 = 0 p u t s t a t i c TEST. n : int <TEST: int n> = $ s t a c k 0#2
Figure 4.5 Cas particulier de la manipulation des rfrences
outSet(1) = $stack0 {T EST.n} outSet(2) = $stack0 {T EST.n}, {l1 {T EST.n}} outSet(3) = {l1 {T EST.n}}, $stack0#2 {} outSet(4) = {l1 {T EST.n}}, T EST.n {}
Figure 4.6 Rsultat de l'analyse statique de l'exemple gure 4.5

Le problme soulev par cet exemple, est que la variable l1 dpend selon notre analyse statique de l'attribut statique T EST.n, alors que T EST.n n'a aucune dpendance car une valeur constante lui a t assigne. Nous pourrions penser alors que la variable locale l1 n'a aucune dpendance elle non plus, alors qu'il aurait fallu la mettre jour avec le label de scurit de T EST.n avant que ce dernier ne soit redni. Une solution nave consisterait ajouter un point de contrle avant la modication de l'attribut T EST.n, pour mettre jour les labels de scurit de toutes les variables qui en dpendent. Toutefois, nous allons voir grce l'exemple de la gure 4.7 que ce problme est plus compliqu que cela, notamment cause des alias. Cet exemple stocke dans la variable locale l2 une deuxime rfrence du tableau point par la variable locale l1. Il modie ensuite deux fois l'lment se trouvant l'index 1 de ce tableau. L'analyse statique de ux de donne, telle que nous l'avons propose est incapable de dtecter que le mme lment du tableau est modi l'instruction 10 et l'instruction 14. La solution nave qui consisterait mettre jour les labels de scurit des variables qui dpendent d'un attribut d'objet ou d'un lment de tableau, avant que ce dernier ne soit modi, ne pourrait marcher que dans le cas o une analyse d'alias serait eectue au pralable. De plus, cette analyse d'alias devrait tre inter-procdural puisque les paramtres d'une mthode peuvent trs bien tre des alias pointant vers le mme objet, chose qu'on ne pourrait dtecter en se restreignant une analyse intra-mthode. 34
1 2 3 4 5 6 7 8 9 10 11 12 13 14
byte $stack1 , $ s t a c k 1#2 int l3 , l4 , $stack2 , $ s t a c k 2#2 int [ ] l1 , l2 , $stack0 , $ s t a c k 0 #2, $ s t a c k 0#3
$stack0 = 11; l2 = $stack0 ; $ s t a c k 0#2 = l 1 ; $stack1 = 1; $stack2 = l3 ; $ s t a c k 0 #2[ $ s t a c k 1 ] = $ s t a c k 2 ; $ s t a c k 0#3 = l 2 ; $ s t a c k 1#2 = 1 ; $ s t a c k 2#2 = l 4 ; $ s t a c k 0 #3[ $ s t a c k 1 #2] = $ s t a c k 2 #2;
Figure 4.7 Cas particulier de la manipulation des rfrences

Nous avons dcid de faire une sur-approximation grossire, en considrant que toutes les rfrences d'objets sont des alias du mme objet. Nous considrons aussi que toutes les rfrences de tableaux sont des alias du mme tableau. Ainsi, chaque fois qu'un attribut d'objet ou qu'un lment d'un tableau est modi, l'analyse statique ajoute un point de contrle. Dans le cas de la modication d'un attribut d'objet, le point de contrle force la JVM mettre jour les labels de scurit de toutes les variables qui dpendent d'un attribut d'objet, avant de poursuivre l'excution. Dans le cas de la modication d'un tableau par contre, le point de contrle force la JVM mettre jour les labels de scurit de toutes les variables qui dpendent d'un lment de tableau. L'analyse statique joint alors ce point de contrle une action save_labels(R) comme l'illustre la gure 4.8, o R est un tableau associatif exprimant les dpendances des variables mettre jour. Ces variables sont ensuite ajoutes l'ensemble killSet pour rinitialiser les dpendances pris en compte par l'analyse dynamique. Cette approximation grossire pourrait forcer la JVM modie mettre jour assez souvent les labels de scurit des variables pour certains programmes. En eet, nous pouvons imaginer une mthode eectuant un calcul complexe qui ne fait intervenir que des attributs d'objets. Dans ce cas l, les performances auxquelles nous pouvons nous attendre en seront nettement dgrades. Cependant, nous pensons que les pratiques de programmation en Java privilgient au maximum l'usage de variables locales et surtout d'oprandes de pile pour des raisons d'optimisation et de performance, plutt que l'usage intensif des attributs d'objets.
4.2.4 Les appels de mthodes

D'aprs les spcications de la JVM 1 , lors de l'appel d'une mthode non statique sur une instance d'objet O, la mthode appelante empile la rfrence de l'instance O, puis les arguments de la mthode appele. Suite l'invocation de cette dernire, la JVM dpile la rfrence de l'instance O ainsi que les arguments de la mthode appele, puis cre une nouvelle frame pour cette dernire. La
1. http ://java.sun.com/docs/books/jls/second_edition/html/jTOC.doc.html
35
inSet(1)={} 1 $stack0 = l1 { $stack0 {l1} } liveVars(2) = {l4, l2, l3, l1, $stack0}
l2 = $stack0
liveVars(2) = {l4, l2, l3, l1}
{$stack0 {l1}, l2 {l1}}
$stack0#2 = l1 { l2 {l1}, $stack0#2 {l1}}
liveVars(3) = {l4, l2, l3, $stack0#2} killSet(3) = {$stack0, $stack1}
$stack1 = 1
liveVars(5) = {l4, l2, l3, $stack0#2, $stack1}
{ l2 {l1}, $stack0#2 {l1}, $stack1 {}} 5 $stack2 = l3 liveVars(5) = {l4, l2, $stack0#2, $stack1, $stack2} killSet(5) = {$stack0#2, $stack1#2}
{ l2 {l1}, $stack0#2 {l1}, $stack1 {}, $stack2 {l3}} 6 $stack0#2[$stack1] = $stack2 liveVars(6) = {l4, l2} save_labels($stack0#2[$stack1] {l3})
{ l2 {l1}, $stack0#2 {l1}, $stack1 {}, $stack2 {l3}} 7 $stack0#3 = l2 {l2 {l1}, $stack0#3 {l1}} 8 $stack1#2 = 1
liveVars(7) = {l4, l2, $stack0#3}
liveVars(8) = {l4, $stack0#3, $stack1#2}
{$stack0#3 {l1}, $stack1#2 {}}
$stack2#2 = l4
liveVars(9) = {$stack0#3, $stack1#2, $stack2#2}
{$stack0#3 {l1}, $stack1#2 {}, $stack2#2 {l4}} 10 $stack0#3[$stack1#2] = $stack2#2 outSet(10) = {} liveVars(10) = {} save_labels($stack0#3[$stack1#2] {l4})
Figure 4.8 Rsultat de l'analyse statique de l'exemple gure 4.5, prenant en compte l'analyse de
vivacit 36
rfrence de l'instance est alors stock dans la variable locale la position 0. Le premier argument est stock la position 1, le deuxime argument la position 2 et ainsi de suite. L'appel d'une mthode statique se fait de la mme manire, sauf que la mthode appelante n'empile pas de rfrence d'instance d'objet. Le premier argument de la mthode appele se trouve alors dans la variable locale la position 0 de la nouvelle frame, le deuxime la position 1 et ainsi de suite. L'analyse statique que nous proposons insre un point de contrle save_labels() chaque appel de mthode, pour forcer la JVM mettre jour tous les labels de scurit des variables manipules par la mthode appelante. En eet, si nous dcidons de retarder cette mise jour de label jusqu'au premier point de contrle rencontr dans l'une des mthodes appeles, il faudrait . La JVM calcule alors les labels de scurit des paramtres de la mthode appele et les associe aux positions correspondantes sur la nouvelle pile. Ces labels sont utiliss par la suite pour dduire les labels de scurit des variables manipules par la mthode appele. Lors du retour de la mthode appele, la valeur de retour ventuelle est empile sur sa pile. Suite l'excution de l'instruction de retour, la JVM empile cette valeur de retour sur la pile de la mthode appelante avant de librer compltement la pile de la mthode appele. Or, comme l'instruction de retour est un point de sortie d'un bloc de base, c'est donc un point de contrle save_labels(). La JVM calcule alors pralablement les labels de scurit des variables manipules par la mthode appele, et associe donc un label de scurit la valeur de retour aussi. Ce label de scurit est donc associ la valeur de retour empil sur la pile de la mthode appelante.
4.3 Suivi des ux implicites

4.3.1 Description
L'analyse statique propose pour le suivi des ux implicites permet la JVM modie de maintenir une pile de labels de scurit, associs aux variables gnrant des ux implicites. Cette pile est ensuite utilise pour propager ces labels de scurit aux variables modies au sein des branches. Dans la suite, nous parlerons de ux implicites directs pour les ux implicites concernant les variables modies au sein d'une branche excute. Nous parlerons aussi de ux implicites indirects concernant les variables modies au sein d'une branche non excute. La gure 4.9 illustre ces deux types de ux d'information que nous direncions prsent.
If $stack1 < 0
Chemin pris lors de lexcution
l3 = 1 Flux implicite indirect : l3 {$stack1}
l2 = 0 Flux implicite direct : l2 {$stack1}
Figure 4.9 Flux implicites directs et indirects

L'analyse statique que nous proposons prend en compte les ux implicites directs, ainsi que certains ux implicites indirects. 37
4.3.2 Prsentation de l'analyse statique des ux implicites directs

Notre analyse statique permet la prise en compte des ux implicites directs grce au parcours du CFG de la mthode analyse. Cette analyse insre un point de contrle chaque branchement conditionnel, ainsi qu'un second point de contrle l'instruction de jonction des deux branches, c'est--dire au post-dominateur immdiat du branchement conditionnel. Comme l'illustre la gure 4.10, le premier point de contrle force la JVM modie valuer puis empiler le label de scurit associ aux variables dont la condition de branchement dpend, grce l'action push(V), o V est un ensemble de variables. Le deuxime point de contrle force la JVM dpiler ce label de scurit avant l'excution de l'instruction au point de jonction des branches, grce l'action pop(i) o i est un entier prcisant le nombre d'lment dpiler. Le point de jonction ou post-dominateur immdiat du branchement conditionnel est calcul grce une analyse de ux de donnes en arrire que nous avons prsent dans la sous-section 3.4.2. L'analyse statique dtermine alors les prdcesseurs du post-dominateur immdiat, pour les marquer d'un point de contrle.
Pimp : pile des flux implicites maintenue par la JVM modifie v : label de scurit associ la variable v push($stack1) Pimp = [$stack1] l4 = erreur $stack1#2 = l1
Pimp = []
If $stack1 < 0
l2 = 0
If $stack1#2 < 0 push($stack1#2) P imp = [$stack1, $stack1#2] l2 = $stack0 pop(2) Pimp = []
l3 = 0 pop(1)
l3 = $stack0 pop(2)
Figure 4.10 Analyse statique des variables gnrant des ux implicites
Il est plus judicieux d'instrumenter ainsi la JVM modie pour construire, dynamiquement, la pile contenant les labels de scurit des variables gnrant des ux implicites. En eet, comme le label de scurit associ une condition de branchement peut changer au cours de l'excution d'une des branches (si les variables intervenant dans cette condition sont rednies), il faut valuer ce label de scurit au moment de l'excution de l'instruction conditionnelle, ce qui revient construire la pile dynamiquement. Grce la pile des ux implicites, la JVM modie peut tenir compte des ux implicites directs. En eet, chaque fois qu'elle prend en compte les ux explicites concernant une variable v et ses 38
dpendances explicites Dv , elle propage les labels de scurit des variables de Dv vers v . Il sut alors de propager aussi les labels de la pile des ux implicites vers v .
4.3.3 Les appels de mthode

Lorsque l'appel d'une mthode se trouve au sein d'une des branches dpendant d'un branchement conditionnel c, toutes les variables modies au sein de cette mthode dpendent de ce branchement conditionnel. Il y a donc un ux implicite partir de la condition prsente dans la mthode appelante, vers toutes les variables modies dans la mthode appele. La JVM modie doit alors transmettre l'tat de la pile des ux implicites la mthode appele pour tenir compte de ces ux implicites. Une fois l'un des points de sortie de la mthode appele atteint, la JVM reprend l'excution de la mthode appelante. Elle reprend alors la pile des ux implicites l'tat prcdant l'appel de mthode. En eet, nous considrons que l'excution des instructions suivant l'appel de mthode ne dpend pas des instructions de la mthode appele, sauf dans certains cas discuts ci-aprs. La porte des ux implicites gnrs au sein de la mthode appele est donc limite cette mthode et c'est pour cela que nous reprenons la pile des ux implicites l'tat prcdent l'excution de cette mthode. Cette hypothse est fausse dans trois cas : 1. la mthode appele contient une boucle innie. Les instructions suivant l'appel de mthode ne sont alors jamais excutes ; 2. la mthode appele quitte le programme excut. 3. la mthode appele gnre une exception. Cette exception peut causer l'arrt du programme ou peut tre gre par l'une des mthode appelantes. Les instructions suivant l'appel de mthode ne sont donc srement pas excutes. Notons que si l'exception est gre par la mthode appele, alors les instructions suivant l'appel de mthode sont bien excutes. Les cas numro 1 et 2 correspondent la (non) terminaison du programme contrl. Certes, la terminaison d'un programme peut causer une fuite d'information, juge trs souvent minime. Ce problme reste en tout cas l'un des challenges ouverts dans le domaine du contrle de ux d'information. Notre analyse ne tient pas compte de la terminaison du programme contrle. Elle est donc insensible la terminaison. Le dernier cas est plus problmatique, et concerne la gestion des ux implicites ds aux exceptions que nous discuterons dans sous-section 4.3.5.
4.3.4 Prsentation de l'analyse statique des ux implicites indirects

An de tenir compte des ux d'information implicites indirects, nous compltons l'analyse statique ralise pour les ux implicites directs par une analyse de ux de donnes en arrire. Cette analyse permet de dterminer quelles variables sont modies au sein des direntes branches, pour permettre la JVM modie de mettre jour leur label de scurit lors de l'excution, quelque soit la branche excute. Avant de prsenter cette analyse, nous exposons d'abord la proposition 1 concernant le code Jimple. Cette proposition arme que toute instruction du code Jimple a au plus deux successeurs si nous ignorons les exceptions lors de la construction du CFG de la mthode analyse. En eet, la seule instruction ralisant un branchement en Jimple est l'instruction if . Or comme le code Jimple est un code 3 adresse, une instruction if ne peut dnir que deux successeurs possibles 39
car le premier oprande du code Jimple est utilis pour l'instruction if , le deuxime oprande est utilis pour la condition du branchement et le troisime oprande est utilis pour l'instruction cible du branchement si la condition est vraie. Donc suite l'excution d'une instruction if , le ot de contrle peut soit passer l'instruction suivante si la condition du branchement est fausse ou passer l'instruction cible du branchement si la condition du branchement est vraie. Donc si nous ignorons le changement de ot de contrle d aux exceptions, toute instruction ayant deux successeurs est une instruction if .
a au plus deux successeurs. De plus, une instruction ayant deux successeurs est une instruction if .
L'analyse que nous proposons pour le suivi des ux implicites indirects prend en compte tous les attributs de classes qui pourraient tre modis lors de l'excution, puisqu'ils ont une porte globale. Par contre, elle prend en compte seulement les variables locales et les oprandes de pile qui sont vifs au point de jonction de chaque branche, c'est--dire au post-dominateur immdiat. En eet, les variables locales et oprandes de piles ayant une porte locale la mthode, il n'y a pas besoin de mettre jour leur label de scurit ds qu'elles ne sont plus utilises au sein de la mthode. Cette analyse associe chaque instruction i deux piles d'ensembles inSet(i) et outSet(i) contenant les variables modies au sein des deux branches d'une instruction conditionnelle. Les quations de cette analyse sont explicites gure 4.3.
inSet(succ(i)) si i a un seul successeur outSet(i) = inSet(s2 ) i inSet(s1 ) si i est une instruction if dont les deux successeurs sont s1 et s2 popM ergeLast(outSet(i)) si i est une instruction if pushN ewSet(outSet(i), n)si i est un prdcesseur d'un post-dominateur immdiat, marqu d'une action pop(n) addT oLastSet(outSet(i), v) si v est une variable dnie par l'instruction i inSet(i) = addT oLastSet(pushN ewSet(outSet(i), n), v) si v est dnie par l'instruction i et i est un prdcesseur d'un post-dominateur immdiat marqu d'une action pop(n) outSet(i) sinon
Proposition 1. Si l'on ignore les exceptions lors de la construction du CFG, alors toute instruction
(4.3) Ces quations font intervenir un oprateur paramtr par l'instruction i et dni pour deux piles d'ensembles ayant le mme nombre d'lments, ainsi que dirents autres oprateurs dnis pour une pile d'ensemble. Une dnition formelle de chacun de ces oprateurs est prsent en 12, 13 et 14. L'ensemble outSet du point de sortie de la mthode est initialis avec une pile contenant un seul ensemble vide. Cette analyse a t ralise de sorte que le nombre d'lments des piles outSet(i) et inSet(i) rete la profondeur de branchements conditionnels l'instruction i. L'oprateur popM ergeLast dpile le dernier ensemble et rajoute toutes les variables qu'il contient l'avant dernier ensemble, sauf les variables locales et oprandes de piles non vifs au post-dominateur immdiat. L'oprateur 40
augmente. Le nombre d'ensembles empiler est dtermin grce aux rsultats de l'analyse prcdentes des ux implicites directs, puisque comme l'illustre la gure 4.10, une instruction peut tre le post-dominateur immdiat de plusieurs branchements. L'oprateur addT oLastSet, par contre, ajoute la variable dnie par une instruction au dernier ensemble de la liste inSet.
pushN ewSet empile un ensemble vide chaque fois que la profondeur de branchements conditionnels
Dnition 12 (Les oprateur popM ergeLast et pushN ewSet). Soient L une pile d'ensembles n
lments. Alors la pile M n 1 lments telle que M = popM ergeLast(L) est dnie comme suit : L[k] si 1 k < n 1 M [k] = L[n 1] L[n] si k = n 1 o est l'oprateur d'union dni pour les ensembles. La pile N n + m lments telle que N = pushN ewSet(L, m) et m 1 est dnie comme suit : L[k] si 1 k n N [k] = {} si n + 1 k n + m
une variable. Alors la liste O = addT oLastSet(L, v) est dnie comme suit : L[k] si 1 k < n O[k] = L[n] {v} si k = n
addT oLastSet). Soient L une pile d'ensembles n lments. Soit v
paramtr par l'instruction conditionnelle i). Soient L1 et L2 deux piles d'ensembles n lments. Soit Vi l'ensemble des variables locales et piles d'oprandes vives au post-dominateur immdiat de l'instruction i. Nous notons Loc(L1 [k]) la projection des variables de l'ensemble L1 [k] sur les variables locales et oprandes de piles. Notons aussi Class(L1 [k]) la projection des variables de l'ensemble L1 [k] sur les variables de classes (attributs statiques). La pile d'ensembles L n lments telle que L = L1 i L2 est dnie comme suit : L1 [k] si 1 k n 1
L[k] = Class(L1 [k]) Class(L2 [k]) ( Loc(L1 [k]) Loc(L2 [k]) Vi
si k = n
L'oprateur i paramtr par l'instruction conditionnelle i ralise l'union des variables appartenant aux deux derniers lments des piles inSet(s1 ) et inSet(s2 ), o s1 et s2 sont les deux successeurs de i, tout en supprimant les variables locales et oprandes de piles qui ne sont plus vifs au post-dominateur immdiat de l'instruction i. Cet oprateur est dnie pour deux piles ayant le mme nombre d'lments car les ensembles inSet des deux successeurs de l'instruction i ont le mme nombre d'lments. De plus, comme l'arme la proposition 2, tous les lments de ces deux ensembles inSet sont gaux sauf leur dernier lment. Bien que nous ne dmontrons pas cette proposition, il est intuitif de se rendre compte grce notamment l'exemple de la gure 4.11, que le dernier lment de l'ensemble inSet d'un successeur s de i contient des variables modies dans les chemins d'excution reliant s au post-dominateur immdiat de i, alors que les autres lments de inSet contiennent les variables modies dans les chemin d'excution reliant le post-dominateur immdiat de i au point de sortie de la mthode analyse. 41
Proposition 2 (Les ensembles inSet(s) des successeurs s d'une instruction conditionnelle i). Soit
i une instruction conditionnelle et s1 , s2 ses deux successeurs. Alors card(inSet(s1 )) = card(inSet(s2 )) et k, tel que 1 k card(inSet(s1 )) 1, alors inSet(s1 )[k] = inSet(s2 )[k]
Un exemple de cette analyse est illustr par la gure 4.11. Le dernier ensemble de la pile outSet(i) de chaque instruction conditionnelle i correspond aux variables potentiellement modies au sein des deux branches dnis par i et qui sont vives au post-dominateur immdiat de i. En eet, si nous considrons l'instruction 1 de cet exemple, le dernier lment de outSet(1) est {l2, l3}. Or ces deux variables sont justement les seules variables qui sont vives au post-dominateur immdiat de l'instruction 1, c'est--dire l'instruction 9. An de permettre la prise en compte des ux implicites indirects lors de l'analyse dynamique, nous annotons le post-dominateur immdiat de chaque instruction conditionnelle i avec le dernier lment de la pile outSet(i). L'analyse dynamique value alors les nouveaux labels de scurit des variables modies au sein des branches excutes et non excutes en utilisant la pile des ux implicites. L'analyse que nous avons propos ne prend en compte que les ux implicites indirects concernant les variables locales et les oprandes de piles, ainsi que variables de classe. Elle ne peut pas prendre en compte les ux implicites indirects concernant les attributs d'objets car nous ne connaissons pas les rfrences des objets concerns par ce ux implicites indirects lors de l'excution. Ceci ncessiterait de raliser une analyse statique d'alias et suppose donc une analyse inter-procdural comme le propose Chandra et Franz [CF07]. Nair et al. [NSCT07] par contre, adopte une approche qui consiste ne pas dpiler la pile des ux implicites au post-dominateur immdiat d'une instruction conditionnelle si un attribut d'objet, dont la rfrence ne peut pas tre dtermin l'excution, est modi au sein d'une branche non excute. Ceci pourrait permettre de tenir compte des ux implicites indirects si cet attribut d'objet est utilis par la suite. Cette approche, que nous pensons trop conservatrice, ncessite alors le dpilement de la pile des ux implicites manuellement pour viter le problme de la contamination des labels de scurit. ne permet de prendre en compte que les ux implicites indirects concernant les objets dont la rfrence est connue, avant l'excution de l'instruction conditionnelle. Considrons l'exemple o une rfrence d'un objet ne peut tre connue qu'au moment de l'excution grce un appel de mthode. Si cet appel de mthode se trouve dans une branche non excute, l'analyse dynamique ne peut dterminer la rfrence de cet objet an de tenir compte des ux implicites indirects le concernant. Les analyses proposes pour le suivi des ux d'information implicites, directs ou indirects, ne prennent pas en compte les ux gnrs par les exceptions. Nous discutons ce dernier point dans la sous-section suivante.
4.3.5 Les exceptions

Les exceptions gnrent des ux d'informations implicites ds au changement de ot de contrle. Nous pouvons distinguer deux types d'exceptions : les exceptions non gres par le programme qui causent son arrt ; les exceptions gres par le programme, que ce soit par la mthode courante ou l'une des mthode appelantes. Notre analyse est une analyse insensible la terminaison du programme et ne prend donc pas en compte les exceptions non gres. Pour ce qui est des exceptions gres, elles peuvent l'tre par 42
If $stack1 < 0 push($stack1)
inSet(1)= [{$stack0#3,l3,l2}] outSet(1)= [{$stack0#3},{l3,l2}] inSet(2)= [{$stack0#3},{l3,l2,l4}] inSet(3)= [{$stack0#3},{l3,l2}] inSet(5)= [{$stack0#3},{l2,l3,$stack1#2}] outSet(6)=[{$stack0#3},{l2,l3}] outSet(6)=[{$stack0#3},{},{l2,l3}] inSet(8)=[{$stack0#3},{},{l2}] l2 = $stack0 pop(2) inSet(4)=[{$stack0#3},{l3}] outSet(4)=[{$stack0#3},{}] inSet(7)=[{$stack0#3},{},{l3}] outSet(7)=outSet(8)= [{$stack0#3}, {},{}]
l4 = erreur
$stack1#2 = l1
l2 = 0
If $stack1#2 < 0 push($stack1#2)
4 pop(1)
l3 = $stack0
7 pop(2)
8 l3 = $stack0
9 $stack0#2 = l2 Live(9) = {l2,l3,$stack0#2}
inSet(9)=[{$stack0#3,$stack0#2}] outSet(9)=[{$stack0#3}]
10
If $stack0#2 !=0 push($stack0#2) 12 $stack0#3 = l3 pop(1)
inSet(10)=[{$stack0#3}] outSet(10)=[{},{$stack0#3}] inSet(12)=[{},{$stack0#3}] inSet(11)=[{},{$stack0#3}]
11
$stack0#3 = l2
pop(1)
13
return $stack0#3
Live(13) = {$stack0#3}
inSet(13)=outSet(13) = [{}]
Figure 4.11 Exemple d'analyse statique des ux implicites indirects

l'une des mthodes appelantes ou par la mthode courante. Si l'exception est gre par l'une des mthodes appelantes, ceci cause le changement du ot de contrle vers une autre mthode. Or comme nous proposons une analyse intra-mthode, nous ne pouvons tenir compte dans l'analyse statique, des ux d'information engendrs par l'ventuelle leve de cette exception. Nous devrions considrer une analyse inter-procdural pour pouvoir tenir compte des ux gnrs par ces exceptions. En ce qui concerne les exceptions gres par la mthode courante, il est possible de tenir compte des ux d'informations qu'elles gnrent puisque le ot de contrle change au sein de la mme mthode. Pour l'instant, notre analyse des ux implicites ignore ce type d'exceptions car nous pensons que cela entrainerait une contamination excessive des labels de scurit (label creep ). En eet, toutes les variables utilises dans des instructions pouvant lever une exception gnrent des ux implicites. Or la prise en compte de ces ux implicites reviendraient considrer toutes ces instructions comme une suite d'instructions conditionnelles qui ncessiteraient la prise en compte des ux implicites directs et indirects. Cette approche nous semble trop conservatrice car la leve d'exceptions relve de cas particuliers anormals qui ne font pas partie de l'excution courante des programmes contrls. Nous pensons tout de mme dvelopper une analyse prenant en compte ces exceptions pour pouvoir comparer les rsultats une analyse qui les ignore an d'armer ou inrmer cette conviction.
43
4.4 Rsum
Nous avons prsent dans cette section l'analyse statique dveloppe pour le suivi des ux d'information. Cette analyse intra-mthode est ralise sur une reprsentation intermdiaire du Bytecode : Jimple. Elle est constitue de plusieurs tapes dont la premire est la construction du CFG de la mthode, ralise grce Soot. Ensuite, une analyse de vivacit des variables, implmente aussi par Soot, est eectue. Les rsultats de cette analyse sont utiliss tout au long des tapes suivantes. S'ensuit alors une analyse de ot de donnes pour chaque bloc de base de la mthode analyse. Cette analyse que nous avons implment, permet la prise en compte des ux explicites par l'analyse dynamique, grce notamment des points de contrles forant la JVM modie mettre jour les labels de scurit associs tout ou une partie des variables. Un parcours du CFG, que nous avons implment, est ensuite ralis pour insrer des points de contrles pour chaque instruction conditionnelle ainsi que les prdcesseurs de leur post-dominateur immdiat. Ces points de contrles permettent lors de l'analyse dynamique de construire une pile de labels de scurit, associs aux variables gnrant des ux implicites. Finalement, une dernire analyse de ot de donne est ralise, pour permettre l'analyse dynamique la prise en compte des ux implicites indirects. Cette dernire analyse ainsi que les annotations de mthodes avec les rsultats de notre analyse statique n'ont pas encore t implment. Cependant, nous avons dj pens la manire de transposer les rsultats de notre analyse statique eectue sur du code Jimple au Bytecode Java. En eet, nous disposons grce Soot de l'oset de l'instruction Bytecode correspondant chaque instruction Jimple. Donc nous pouvons associer chaque ensemble outSet son instruction Bytecode correspondante. De plus, nous avons utilis grce Soot un nommage particulier des variables en Jimple, qui nous permet d'associer avec prcision chaque variable Jimple soit une position prcise sur la pile, soit une variable locale prcise.
44
Chapitre 5
Travaux futurs et conclusion

Durant la premire partie de ce stage, nous avons travaill sur un modle d'analyse statique permettant le suivi hybride des ux d'information au sein des programmes Java, pour la dtection d'intrusion. Nous avons prsent notre approche dans ce mmoire, ainsi que les hypothses que nous avons fait concernant l'analyse dynamique. L'analyse statique que nous avons propose permet la construction d'un prol pour chaque mthode analyse. Ce prol contient des informations sur les ux gnrs par la mthode, qu'ils soient explicites ou implicites. Il inclue aussi des points de contrles instrumentant les actions ralises lors de l'analyse dynamique pour la mise jour des labels de scurit. Nous avons implment l'analyse de ot de donnes prenant en compte les ux explicites gnrs par la mthode analyse, ainsi que le parcours du CFG permettant la prise en compte des ux implicites directs. Nous allons implmenter dans la suite de ce stage l'analyse dynamique des ux implicites indirects prenant compte les variables locales, les oprandes de pile ainsi que les variables de classe. Nous allons aussi faire en sorte d'annoter les mthodes analyses avec les prols raliss grce notre analyse statique avant la n de la premire partie de ce stage. Durant la deuxime partie de ce stage, nous nous attacherons la conception et l'implmentation de l'analyse dynamique des ux d'information. Nous apporterons les modications ncessaires la JVM ralisant cette analyse, pour lui permettre de charger les prols des mthodes avant leur excution et d'interprter ces prols en termes de ux d'information et de points de contrle. Nous raliserons aussi le mcanisme de gestion des labels de scurit capable d'associer un label chacune des variables manipules lors de l'excution d'un programme. Ce mcanisme s'intgrera avec Blare, l'outil de dtection d'intrusion bas sur le suivi des ux d'information au niveau OS. De plus, Nous raliserons des tests sur des applications ralistes pour valuer les rsulats de notre analyse de suivi des ux d'information et les performances engendrs par l'approche hybride que nous proposons. La suite de ces travaux pourrait concerner l'amlioration de l'analyse statique que nous proposons. En eet, une analyse d'alias coupl une analyse intra-procdurale pourrait permettre d'amliorer la prcision du suivi des ux d'information implicites indirects. Elle pourrait aussi permettre l'optimisation de l'analyse dynamique en diminuant le nombre de points de contrles insrs lors de l'analyse statique.
45
Table des gures

2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 2.11 2.12 2.13 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 Matrice de contrle d'accs . . . . . . . . . . . . . . . . . . . . . . . . . Rgles d'autorisation d'accs des modles de contrle d'accs obligatoire Exemple de spcication de comportement en ASL . . . . . . . . . . . . Les dirents types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Langage impratif introduit par Volpano . . . . . . . . . . . . . . . . . . Les rgles du systme de type de Volpano et Smith . . . . . . . . . . . . Smantique naturelle du language impratif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . L'association conteneur, TAG en lecture et TAG en criture . . . . . . . Smantique du contrleur . . . . . . . . . . . . . . . . . . . . . . . . . . Smantique du langage impratif et vnements internes . . . . . . . . . Exemple de fuite d'information dans un programme . . . . . . . . . . . . volution de et s suite l'excution de P . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8 9 14 14 14 14 15 16 17 18 18 19 23 23 24 24 24 26 27 27 29 29 31 33 34 34 35 36 37 38 43
Exemple de programme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Exemple de code Jimple simple non typ . . . . . . . . . . . . . . . . . . . . Exemple de programme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sparation des variables pour l'exemple 3.3 . . . . . . . . . . . . . . . . . . Les direntes dnitions et utilisations de la variable x . . . . . . . . . . . Exemple de programme et le rsulat de l'analyse de vivacit de ses variables Analyse de vivacit sur l'exemple gure 3.6 . . . . . . . . . . . . . . . . . . Analyse des post-dominateur sur l'exemple de la gure 3.6 . . . . . . . . . .
Approximation de l'analyse statique . . . . . . . . . . . . . . . . . . . . . . . . . . Exemple de dcoupage d'une mthode en blocs de base . . . . . . . . . . . . . . . . . Exemple de l'analyse de ux de donnes . . . . . . . . . . . . . . . . . . . . . . . . . Exemple de l'analyse de ux de donnes . . . . . . . . . . . . . . . . . . . . . . . . . Cas particulier de la manipulation des rfrences . . . . . . . . . . . . . . . . . . . . Rsultat de l'analyse statique de l'exemple gure 4.5 . . . . . . . . . . . . . . . . . . Cas particulier de la manipulation des rfrences . . . . . . . . . . . . . . . . . . . . Rsultat de l'analyse statique de l'exemple gure 4.5, prenant en compte l'analyse de vivacit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.9 Flux implicites directs et indirects . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.10 Analyse statique des variables gnrant des ux implicites . . . . . . . . . . . . . . . 4.11 Exemple d'analyse statique des ux implicites indirects . . . . . . . . . . . . . . . . .
46
Bibliographie
Frances E. Allen. Control ow analysis. SIGPLAN Not., 5(7) :119, 1970. James P. Anderson. Computer Security Threat Monitoring and Surveillance. Technical report, James P. Anderson Company, Fort Washington, Pennsylvania, April 1980. [Bib77] K. Biba. Integrity considerations for secure computer systems. Technical Report NESD-TR 76-372, MITRE Co., April 1977. [CF07] Deepak Chandra and Michael Franz. Fine-grained information ow analysis and enforcement in a java virtual machine. In ACSAC, pages 463475, 2007. [Den76] Dorothy E. Denning. A lattice model of secure information ow. Commun. ACM, 19(5) :236243, 1976. [FHS97] S. Forrest, S.A. Hofmeyr, and A. Somayaji. Computer immunology. Communications of the ACM, 40(10) :8896, October 1997. [GM82] J. Goguen and J. Meseguer. Security policies and security models. In IEEE Symposium on Research in Security and Privacy, 1982. [HMMT07] G. Hiet, L. M, B. Morin, and V. Viet Triem Tong. Monitoring both os and program level information ows to detect intrusions against network servers. In IEEE Workshop on "Monitoring, Attack Detection and Mitigation", 2007. + 07] Guillaume Hiet, Ludovic M, Jacob Zimmermann, Christophe Bidan, Benjamin Morin, [HMZ and Valrie Viet Triem Tong. Dtection able et pertinente de ux d'informations illgaux. In Proc of the 2nd Conference on Security in Network Architectures and Information Systems (SARSSI), 2007. [HRU76] Michael A. Harrison, Walter L. Ruzzo, and Jerey D. Ullman. Protection in operating systems. Communication of the ACM, 19(8) :461471, 1976. [HS06] S. Hunt and D. Sands. On ow-sensitive security types. In Conference record of the 33rd ACM SIGPLAN-SIGACT symposium on Principles of programming languages, pages 7990. ACM, 2006. [KR02] Calvin Ko and Timotyy Redmond. Noninterference and intrusion detection. In Proceedings of the IEEE Symposium on Security and Privacy, 2002. [LB73] Leonard J. LaPadula and D. Elliott Bell. Secure computer systems : A mathematical model. MTR-2547 (ESD-TR-73-278-II) Vol. 2, MITRE Corp., Bedford, may 1973. [Muc97] S.S. Muchnick. Advanced compiler design and implementation. Morgan Kaufmann, 1997. [All70] [And80]
47
A.C. Myers. JFlow : Practical mostly-static information ow control. In Proceedings of the 26th ACM SIGPLAN-SIGACT symposium on Principles of programming languages, pages 228241. ACM, 1999. [NSCT07] Srijith K. Nair, Patrick N. D. Simpson, Bruno Crispo, and Andrew S. Tanenbaum. A virtual machine based information ow control system for policy enforcement. In First International Workshop on Run Time Enforcement for Mobile and Distributed Systems (REM 2007), pages 111, Dresden, Germany, 2007. [RS10] Alejandro Russo and Andrei Sabelfeld. Dynamic vs. static ow-sensitive security analysis. Computer Security Foundations Symposium, IEEE, 0 :186199, 2010. [SCS98] R. Sekar, Yong Cai, and Mark Segal. A specication-based approach for building survivable systems. In Proceedings of the 21st National Information Systems Security Conference (NISSC'98), pages 338347, Crystal City, VI, October 1998. [VRH98] R. Vallee-Rai and L.J. Hendren. Jimple : Simplifying java bytecode for analyses and transformations. 1998. [VS97] D. Volpano and G. Smith. A type-based approach to program security. In Theory and Practice of Software Development, 1997. [VSI96] Dennis Volpano, Georey Smith, and Cynthia Irvine. A sound type system for secure ow analysis. Journal in Computer Security, 4(2-3) :167187, 1996. [ZMB03] Jacob Zimmermann, Ludovic M, and Christophe Bidan. An improved reference ow control model for policy-based intrusion detection. In Proceedings of the 8th European Symposium on Research in Computer Security (ESORICS), October 2003. [Mye99]
48

Assaf

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Assaf

Transféré par

Droits d'auteur :

Formats disponibles

Master Recherche en Informatique - Rennes 1 Encadrant : Guillaume Hiet (quipe SSIR, Suplec)

dumas-00636135, version 1 - 26 Oct 2011

Rennes, Juin 2011

Table des matires

5 Travaux futurs et conclusion

dumas-00636135, version 1 - 26 Oct 2011

dumas-00636135, version 1 - 26 Oct 2011

2.1 Contrle d'accs

Figure 2.1  Matrice de contrle d'accs

Accs en lecture Accs en criture

Hsujet Cobjet Dobjet Dsujet

Hsujet Cobjet Dobjet Dsujet

dumas-00636135, version 1 - 26 Oct 2011

2.2 Dtection d'intrusion

2.2.1 Approches par scnarios

2.2.2 Approches comportementales

dumas-00636135, version 1 - 26 Oct 2011

Figure 2.3  Exemple de spcication de comportement en ASL

dumas-00636135, version 1 - 26 Oct 2011

2.3 Contrle de ux d'information

2.3.1 Politique de ux en treillis

dumas-00636135, version 1 - 26 Oct 2011

2.3.2 La proprit de non-interfrence

Dnition 2. (non-interfrence) Un programme p est non-interfrent si

2.3.3 Politique de ux en termes de CCAL

dumas-00636135, version 1 - 26 Oct 2011

Dnition 4 (Violation de la politique de scurit). Une violation de la politique de scurit est

2.4 Les mcanismes de contrle de ux

2.4.1 L'analyse statique

dumas-00636135, version 1 - 26 Oct 2011

(types des donnes) (types des phrases) | var| cmd

Figure 2.4  Les dirents types

(phrases) p : := e | c (expressions) e : := x | l | n | e + e | e e | e = e | e e (commands) c : := e := e | c; c | if e then c else c | while e do c | letvar x := e in c

(IF) (WHILE) (LETVAR) pano et Smith

Figure 2.5  Langage impratif introduit par Volpano

2.4.2 L'analyse dynamique

dumas-00636135, version 1 - 26 Oct 2011

({f1 , f2 , fA }, {C1 , C2 , CA }) ({f2 , fB }, {C2 , CB })

La pertinence et la abilit de ce modle ont t prouves grce au thorme de dtection : 15

Thorme 1. (Thorme de dtection) Une violation de la politique de scurit est caractrise

(a) Associations initiales

(b) L'volution de au ux f1 C2

dumas-00636135, version 1 - 26 Oct 2011

CL CCALA CCALA CCALA

CE CCALA CCALA , CCALB CCALA CCALB

(c) L'volution de au ux f2 CB

Figure 2.9  L'association conteneur, TAG en lecture et TAG en criture

2.4.3 L'analyse hybride

(B-LOW) (B-HIGH) (J-HIGH) (J-LOW)

Figure 2.10  Smantique du contrleur

(SKIP) (ASSIGN) (COMP) (COM P ) (IF)

dumas-00636135, version 1 - 26 Oct 2011

if e then c1 else c2 , m c2 ; end, m m(e) = 0 while e do c , m

c; end; while e do c, m m(e) = 0 c; end; while e do c, m

while e do c , m f end, m stop, m m(e) = v outputl (e), m

Figure 2.11  Smantique du langage impratif et vnements internes

secret x=1 y=0

Figure 2.12  Exemple de fuite d'information dans un programme

b(secret, skip) b(secret , y :=0) a(x, 0) f f

secret H, secret H, secret H, secret H, secret H, secret H,

secret secret secret secret secret secret

s [ ] [{} : ] [{y H} : {} : ] [{y H} : {} : ] [{} : ] [ ]

Figure 2.13  volution de et s suite l'excution de P

dumas-00636135, version 1 - 26 Oct 2011

Figure 2.1 Matrice de contrle d'accs

Figure 2.3 Exemple de spcication de comportement en ASL

2.3 Contrle de ux d'information

2.3.1 Politique de ux en treillis

Dnition 2. (non-interfrence) Un programme p est non-interfrent si

2.3.3 Politique de ux en termes de CCAL

Dnition 4 (Violation de la politique de scurit). Une violation de la politique de scurit est

2.4 Les mcanismes de contrle de ux

Figure 2.4 Les dirents types

Figure 2.5 Langage impratif introduit par Volpano

La pertinence et la abilit de ce modle ont t prouves grce au thorme de dtection : 15

(b) L'volution de au ux f1 C2

(c) L'volution de au ux f2 CB

Figure 2.9 L'association conteneur, TAG en lecture et TAG en criture

Figure 2.10 Smantique du contrleur

Figure 2.11 Smantique du langage impratif et vnements internes

Figure 2.12 Exemple de fuite d'information dans un programme

Figure 2.13 volution de et s suite l'excution de P

Figure 3.1 Exemple de programme

Figure 3.2 Exemple de code Jimple simple non typ

Figure 3.3 Exemple de programme

Figure 3.4 Sparation des variables pour

Figure 3.5 Les direntes dnitions et utilisations de la variable x

3.4 Analyse statique de ot de donnes

Figure 3.6 Exemple de programme et le rsulat de l'analyse de vivacit de ses variables

4.2 Suivi des ux explicites

Figure 4.1 Approximation de l'analyse

4.2.2 Prsentation de l'analyse statique des ux explicites

Dnition 9 (L'oprateur ). Soient V et W deux ensembles de variables.

o fS est dni comme suit :

Figure 4.3 Exemple de l'analyse de ux de donnes

Dnition 10 (L'oprateur ). Soient V et W des ensemble de variables.

Figure 4.4 Exemple de l'analyse de ux de donnes

Figure 4.5 Cas particulier de la manipulation des rfrences

Figure 4.6 Rsultat de l'analyse statique de l'exemple gure 4.5

Figure 4.7 Cas particulier de la manipulation des rfrences

4.3 Suivi des ux implicites