La mise en œuvre des m´ecanismes de contrˆoles du flot d’information peut s’appuyer sur le contrˆole d’acc`es. Par exemple, il se pourrait que certaines entr´ees du programme soient gard´ees dans des fichiers du syst`eme sur lesquels s’appliquent des contrˆoles d’acc`es. La mise en œuvre peut aussi s’appuyer sur des techniques autres que le contrˆole d’acc`es, notamment en consid´erant les effets de chaque instruction du programme. Ce sont des techniques qui s’appuient sur des notions propres aux langages de programmation. En particulier, elles se servent de la s´emantique et de l’analyse du programme pour sp´ecifier et appliquer les politiques de s´ecurit´e pour la confidentialit´e ou pour l’int´egrit´e des donn´ees. Nous faisons dans cette section, un survol de ces diff´erents m´ecanismes.
Les m´ecanismes de contrˆole de flot d’information par le langage peuvent partitionn´es en deux groupes, les m´ecanismes bas´es sur une analyse statique du programme d’une part, et les m´ecanismes bas´es sur une approche dynamique de l’autre. Cependant, certains m´ecanismes dynamiques utilisent les r´esultats de l’analyse statique lors de l’examen du code. Ces derniers sont souvent appel´es des m´ecanismes hybrides.
2.4.1 Contrˆole de flot d’information par l’analyse statique
Analyser statiquement un programme consiste `a extraire des informations relatives `a l’ex´e- cution du code sans l’ex´ecuter effectivement. Les informations sont valables pour toutes les ex´ecutions possibles. Une telle analyse permet d’´etablir un mod`ele du comportement du pro- gramme. Les informations peuvent ˆetre utilis´ees pour optimiser, mettre au point, comprendre, maintenir ou v´erifier le code. Dans le cas du contrˆole du flot d’information, les m´ethodes sta- tiques analysent le programme avant son ex´ecution, et d´eterminent si toutes les ex´ecutions possibles sont s´ecuritaires. Denning et Denning furent les premiers `a utiliser l’analyse statique pour s’attaquer au probl`eme de s´ecurisation du flot d’information dans un programme [10]. Ils proposent de mod´eliser toute politique de flot d’information par un mod`ele en treillis. Cela consiste `a attribuer dans un premier temps `a chaque variable une ´etiquette qui correspond `
a son niveau de s´ecurit´e. Ensuite on munit l’ensemble des classes de s´ecurit´e obtenu d’une relation d’ordre partiel (v), qui en fait une structure de treillis de classes de s´ecurit´e. Enfin, en se servant des propri´et´es du treillis, on peut incorporer le processus de certification du pro- gramme dans la phase d’analyse du compilateur. Par exemple, chaque affectation est v´erifi´ee pour la propri´et´e suivante : la variable affect´ee doit ˆetre de haut niveau si la variable `a droite de l’affectation est de haut niveau (d´etection des flots explicites) ou si l’affectation a lieu dans une instruction conditionnelle ou une boucle de haut niveau. Leur m´ecanisme garantit qu’au- cun traitement de bas niveau n’est effectu´e dans un contexte de haut niveau. `A la suite de Denning et Denning, plusieurs autres travaux ont suivi dans le mˆeme sens. Ces m´ecanismes
ont l’avantage de ne pas augmenter la charge du programme `a l’ex´ecution. On s´epare souvent les m´ecanismes statiques en deux groupes : les m´ecanismes bas´es sur le syst`eme de types d’une part et les m´ecanismes non bas´es sur le syst`eme de types d’autre part.
Analyse bas´ee sur un syst`eme de types
Volpano et al. [32] furent les premiers `a utiliser un syst`eme de types pour analyser la s´ecurit´e du flot d’information. Leur mod`ele s’applique `a un langage imp´eratif simple. Plusieurs ´etudes ont suivi dans le mˆeme sens avec pour certaines une extension au niveau du langage et pour d’autres, une extension au niveau de la propri´et´e de non-interf´erence. Certaines approches, notamment les plus anciennes comme celle de Volpano et al. [32] sont insensibles aux flots au sens de2.3.2. Plus r´ecemment, Hunt et Sands ont propos´e pour la premi`ere fois un syst`eme de types sensible aux flots. D’autres travaux ont suivi dans le mˆeme sens, parmi lesquels ceux de Desharnais et al. [12]. Nous reviendrons plus en d´etails sur ces deux derni`eres approches dans le prochain chapitre.
Dans l’analyse bas´ee sur un syst`eme de types, la s´emantique statique du programme est repr´esent´ee par un ensemble de r`egles de d´eduction appel´e syst`eme de types.
Les r`egles permettent de d´eduire le type d’une expression et se pr´esentent sous la forme suivante :
P 1...P n
Q .
Une telle r`egle stipule que si P1, ..., Pnsont tous vrais, alors Q l’est aussi. Le num´erateur est
constitu´e de pr´emisses (Pi) alors que le d´enominateur contient la conclusion Q. Une r`egle qui
ne poss`ede pas de pr´emisses est un axiome. Un axiome Q est g´en´eralement repr´esent´e par :
Q ou tout simplement
Q . Le symbole signifie qu’il n’y a pas de pr´emisses.
Chaque pr´emisse ou conclusion peut utiliser un jugement de la forme :
Γ ` e : τ
– Γ est une mappe qui associe `a chaque variable du programme un ´el´ement du treillis de s´ecurit´e L. Cette mappe sera souvent appel´ee environnement de d´efinition des types ou tout simplement environnement de typage.
– e est une expression
– τ est un ´el´ement du treillis de s´ecurit´e L.
Ce jugement signifie que, sous un environnement de typage Γ, l’expression e est de type τ . Un environnement de d´efinition des types pour les constantes sert souvent de point de d´epart pour l’application des r`egles d’inf´erence et un algorithme d’inf´erence de types sert `a calculer les informations utiles.
Analyse statique non bas´ee sur un syst`eme de types
Comme le fait remarquer Le Guernic [18], toutes les techniques d’analyse statique de la s´ecurit´e du flot d’information ne sont pas bas´ees sur un syst`eme de types. La technique utilis´ee par Denning [11] avant Volpano, est similaire au syst`eme de types, mais n’est pas d´efinie comme telle. Denning d´ecrit un syst`eme dans lequel les variables et les commandes ont un niveau de s´ecurit´e. Ces niveaux sont ordonn´es et forment une structure de treillis. Denning d´efinit un ensemble de r`egles qui font le lien entre les structures du programme et le niveau de s´ecurit´e appropri´e de l’entit´e du programme impliqu´e dans ces structures. Elle sugg`ere deux pistes. La premi`ere consiste `a attribuer le niveau de s´ecurit´e aux variables et instructions et utiliser les r`egles pour v´erifier si les niveaux sont appropri´es. La seconde consiste `a assigner des niveaux de s´ecurit´e seulement aux variables d’entr´ee et utiliser les r`egles pour calculer le niveau de s´ecurit´e des autres entit´es du programme.
D’autres m´ethodes d’analyse non bas´ees sur le syst`eme de types existent, parmi lesquelles l’analyse par interpr´etation abstraite et l’approche bas´ee sur les contraintes.
Analyse par utilisation de l’interpr´etation abstraite
L’interpr´etation abstraite est une technique permettant de d´eriver une analyse statique, `a partir d’une s´emantique instrument´ee du programme. L’id´ee de base de l’interpr´etation abs- traite est l’approximation de la s´emantique des programmes. Elle peut ˆetre d´efinie comme une ex´ecution partielle d’un programme pour obtenir des informations sur sa s´emantique (par exemple, sa structure de contrˆole, son flot de donn´ees) sans avoir `a en faire le traitement complet. Pour s´ecuriser le flot d’information, l’instrumentation de la s´emantique consiste ha- bituellement `a ajouter aux valeurs une ´etiquette qui doit refl´eter l’ensemble des entr´ees qui ont influenc´e la valeur ´etiquet´ee. Toutefois, comme le remarque Le Guernic [18], il reste que la coh´erence de l’analyse r´eside dans la coh´erence du choix de la s´emantique instrument´ee. Autrement dit, si le calcul des ´etiquettes de s´ecurit´e par la s´emantique instrument´ee n’est pas coh´erent, il n’y aura aucune garantie de fiabilit´e pour l’analyse d´eriv´ee.
Analyse bas´ee sur les contraintes
Les m´ethodes d’analyse bas´ee sur les contraintes sont aussi utilis´ees pour v´erifier statiquement la s´ecurit´e du flot d’information. Ces m´ecanismes se d´eroulent g´en´eralement en deux ´etapes : – La premi`ere ´etape consiste `a g´en´erer un ensemble de contraintes qui doivent ˆetre v´erifi´ees pour un programme qui respecte la propri´et´e de non-interf´erence. On peut aussi se limiter `a la production d’une liste de contraintes qui doivent ˆetre respect´ees par une ex´ecution s´ecuritaire du programme.
– La seconde ´etape consiste `a r´esoudre le probl`eme en utilisant par exemple un prouveur de th´eor`emes4 ou un v´erificateur de mod`ele.5 On peut aussi le transformer en une instance d’un probl`eme de satisfaction de contraintes6 et la soumettre `a un solveur de contraintes.7
Habituellement, pour l’analyse de la s´ecurit´e du flot d’information, le probl`eme de r´esolution de contraintes concerne l’affectation des ´etiquettes de s´ecurit´e aux variables, de sorte qu’`a chaque ´etape de l’ex´ecution, l’information circule vers des variables avec un niveau de s´ecurit´e plus ´elev´e ou ´egal `a celui de l’origine du flot. L’autre approche, qui n’utilise pas les ´etiquettes de s´ecurit´e, consiste `a d´emontrer directement que pour deux ex´ecutions quelconques, les valeurs des sorties publiques ne sont pas diff´erentes si celles des entr´ees publiques sont identiques.
2.4.2 Contrˆole de flot d’information par analyse dynamique
Le contrˆole du flot d’information peut se faire dynamiquement, c’est-`a-dire pendant l’ex´ecu- tion du programme. Par rapport `a l’analyse statique, les m´ethodes dynamiques sont souvent plus pr´ecises. Par contre, ce sont des m´ecanismes qui peuvent ajouter une grande surcharge de travail `a l’ex´ecution du programme. S´ecuriser le programme par analyse dynamique est une id´ee plutˆot ancienne, qui remonte aux ann´ees 1970, au travail de Fenton [14] tout au moins, mais qui est toujours d’actualit´e. D’ailleurs, plusieurs travaux r´ecents ont ´etudi´e la possibilit´e d’incorporer des m´ecanismes dynamiques de contrˆole du flot d’information dans les
4. La d´emonstration de th´eor`emes est une approche de v´erification des programmes, qui est de plus en plus automatis´ee et assist´ee par ordinateur. Elle consiste `a ´enoncer des propositions et `a les d´emontrer dans un syst`eme de d´eduction de la logique math´ematique, en particulier dans le calcul des pr´edicats. L’objectif est de raisonner rigoureusement sur des programmes informatiques afin de d´emontrer leur validit´e par rapport `a une certaine sp´ecification. Le prouveur de th´eor`eme est l’outil informatique utilis´e.
5. Un v´erificateur de mod`ele, « model checker » en anglais, analyse exhaustivement l’´evolution du syst`eme lors de ses ex´ecutions possibles. Par exemple, pour d´emontrer l’absence d’erreurs `a l’ex´ecution, on pourra tester l’absence d’´etats d’erreur dans l’ensemble des ´etats accessibles du syst`eme. En g´en´eral, il n’est pas possible d’analyser directement le syst`eme, mais on en analyse plutˆot un mod`ele, plus ou moins abstrait par rapport `a la r´ealit´e.
6. Les probl`emes de satisfaction de contraintes, ou CSP en anglais pour « Constraints Satisfaction Problems
», sont des probl`emes math´ematiques o`u l’on cherche des ´etats ou des objets satisfaisant un certain nombre de contraintes ou de crit`eres.
7. En g´en´eral, on s´epare la mod´elisation d’un probl`eme CSP de sa r´esolution. Le solveur de contraintes est l’outil informatique qui est utilis´e dans la phase de r´esolution du probl`eme.
navigateurs web avec le langage JavaScript [13]. On regroupe g´en´eralement les m´ecanismes dynamiques en trois groupes :
(a) Le monitorage, qui consiste `a faire surveiller l’ex´ecution du programme par un autre programme appel´e moniteur.
(b) L’instrumentation, qui consiste `a transformer le programme, en y ajoutant des com- mandes pour contrˆoler le flot d’information.
(c) Une nouvelle approche bas´ee sur l’ex´ecution multiple du programme.
Le monitorage de l’ex´ecution
Un moniteur est un programme qui observe, r´egule et contrˆole ou v´erifie les op´erations d’un syst`eme de traitement des donn´ees. Dans le cadre de la s´ecurisation du flot d’information, le moniteur a pour objectif de contrˆoler l’ex´ecution des autres programmes pour pr´evenir tout flot d’information illicite. Des caract´eristiques pr´ecises des politiques de s´ecurit´e applicables par monitorage des programmes ont ´et´e ´etudi´ees dans la litt´erature. La non-interf´erence a ´
et´e pr´esent´ee comme un exemple de politique qui ne peut ˆetre appliqu´ee avec pr´ecision par des m´ecanismes dynamiques. Cependant, des travaux comme celui de Russo et Sabelfeld [24] ont rigoureusement d´emontr´e qu’il est possible d’utiliser un moniteur pour appliquer une certaine politique de s´ecurit´e qui est une approximation de la non-interf´erence et qui garantit la non-interf´erence dans les programmes qu’ils acceptent.
Le monitorage d’un programme est potentiellement plus permissif qu’une simple v´erification de type (analyse purement statique). En fait, le monitorage peut autoriser les ex´ecutions s´ecuritaires mˆeme si le programme contient des fragments non s´ecuritaires, dans les branches non prises d’un bloc conditionnel par exemple. De plus, la d´etermination des instructions s´ecuritaires se fait sur la base des informations pr´ecises `a l’ex´ecution par opposition `a des approximations de l’analyse statique. Mais, en g´en´eral, le moniteur ne peut voir que la partie d´ej`a ex´ecut´ee de la trace d’ex´ecution, `a moins qu’il ne soit dot´e des moyens lui permettant d’utiliser d’autres informations provenant de l’analyse statique.
Des travaux r´ecents sur le monitorage du flot d’information portent sur des langages interpr´e- t´es comme JavaScript. Dans la pratique, le moniteur est souvent int´egr´e `a la machine virtuelle Java par une modification du code source de cette derni`ere. Cette possibilit´e est due au fait que cette machine virtuelle est impliqu´ee dans tous les ´ev`enements du flot de contrˆole et du flot des donn´ees `a l’ex´ecution des programmes. Nous appellerons dans la suite un tel moniteur « moniteur MV ». Un exemple de moniteur MV est celui de Russo et Sabelfeld [24] que nous d´ecrivons plus en d´etail au chapitre suivant.
L’instrumentation du code
Chudnov et Naumann affirment [8] qu’un moniteur MV est peu pratique dans certains cas. L’une des raisons ´evoqu´ees est l’utilisation de nouvelles techniques de compilation comme le JIT (Just In Time). Cette technique de plus en plus r´epandue associe la traduction en bytecode et la compilation dynamique. La machine virtuelle n’a plus tout le contrˆole sur les petites ´etapes des flots de contrˆole et de donn´ees, notamment pour la partie du code qui est d´ej`a traduite en langage natif. L’autre solution, qui aura `a quelque chose pr`es le mˆeme r´esultat que le moniteur est la transformation du code source du programme, c’est-`a-dire l’instrumentation. Dans le cas du contrˆole du flot d’information, elle consiste `a ajouter au programme des variables qui refl`etent le niveau de s´ecurit´e de ses variables originales. Des tests sur ces nouvelles variables sont aussi ins´er´es, dans le but d’appliquer dynamiquement la non-interf´erence. Il sera alors suffisant de montrer que chaque programme ainsi transform´e est non interf´erent. Plusieurs ´etudes proposent de telles transformations pour un langage proc´edural simple et d´eterministe. Nous pr´esentons en d´etail dans le prochain chapitre un de ces m´ecanismes assez r´ecent, ´elabor´e par Chudnov et Naumann [8], qui a la particularit´e d’ˆetre bas´e sur une analyse sensible aux flots telle que d´efinie dans la section 2.3.2.
L’ex´ecution multiple
L’id´ee principale derri`ere l’approche par ex´ecution multiple consiste `a ex´ecuter un programme `
a plusieurs reprises, une fois pour chaque niveau de s´ecurit´e, en utilisant des r`egles sp´eciales pour s´ecuriser le flot d’information au niveau des op´erations d’entr´ee/sortie. Contrairement aux autres approches dynamiques et `a l’analyse statique par typage, l’ex´ecution multiple ne requiert pas que l’ensemble du code de l’application soit inspect´e (seulement les instructions d’entr´ee/sortie). C’est une id´ee qui a ´et´e explor´ee plus r´ecemment, `a la fin des ann´ees 90. Des articles r´ecents [4,13] proposent des techniques d’analyse bas´ees sur cette approche. Les difficult´es inh´erentes `a cette approche r´esident, d’une part dans le choix des valeurs d’entr´ees de haut niveau `a tester et, d’autre part dans le partage de la charge de test `a travers les diff´erentes copies de l’ex´ecution de la fonction avec des entr´ees diff´erentes. De plus, si le programme fait des choix non d´eterministes, il devient particuli`erement difficile d’analyser les valeurs obtenues pour les sorties de bas niveau. Dans ce cas, il faut g´en´eraliser ou adapter la technique pour en tenir compte.
Chapitre 3
Contrˆole du flot d’information par
analyse sensible aux flots
3.1
Introduction
Nous examinons dans ce chapitre quelques m´ecanismes de contrˆole de flot d’information parmi les plus r´ecents, tous bas´es sur une analyse sensible aux flots des donn´ees.
Pour bien comprendre la diff´erence entre une analyse sensible aux flots et une qui ne l’est pas, consid´erons le programme suivant :
secret := 0; if secret then public := 1
Une analyse insensible aux flots rejette ce programme parce qu’il a un sous-programme non s´ecuris´e, en l’occurrence, l’affectation `a une variable publique dans un bloc conditionnel avec une garde impliquant une variable secr`ete. D’un autre cˆot´e, le programme est accept´e par une analyse sensible aux flots, parce que la variable secret en recevant par affectation la constante 0 se comporte dans la suite comme une variable publique. On note que les constantes sont consid´er´ees comme publiques puisqu’elles ne transmettent aucune information sur un autre objet [10]. La garde du bloc conditionnel ´etant devenue publique, la mise `a jour de la variable public ne repr´esente plus de danger. Comme nous allons le voir, les approches sensibles aux flots permettent d’accepter un plus grand nombre de programmes s´ecuritaires que celles qui ne le sont pas.
Dans tout ce chapitre, nous supposons que dans notre syst`eme, les secrets sont conserv´es dans les variables des programmes. Les niveaux de s´ecurit´e sont associ´es aux variables et d´ecrivent la s´ecurit´e voulue pour leur contenu. La plus simple instance d’un tel probl`eme implique deux niveaux de s´ecurit´e : H pour haut niveau de s´ecurit´e qui d´enote la partie secr`ete de l’information et L pour bas niveau qui d´enote la partie publique. Une relation d’ordre partiel
L v H indique que les seuls flots permis sont ceux de L vers H. Le probl`eme de s´ecurit´e est de v´erifier qu’il n’y a pas de d´ependance entre la valeur initiale d’une variable de niveau H (contenant le secret dont le programme a acc`es) et la valeur finale d’une variable de niveau L (la sortie qui est visible par le public).
Dans la suite du chapitre, nous pr´esentons dans la premi`ere partie deux m´ecanismes d’analyse statique bas´es sur le typage. Il s’agit du mod`ele de Hunt et Sands [16] compl´et´e par Russo et Sabelfeld [24] pour le premier, et du mod`ele de Desharnais et al. [12] pour le second. Dans la seconde partie, on examine deux m´ecanismes hybrides de contrˆole dynamique de