Combinaison d'approche statique et dynamique pour l'application de politiques de sécurité

Combinaison d’approche statique et

dynamique pour l’application de politiques de

s´

ecurit´

e

M´

emoire

Th´

eophane Gloria Godonou

Maˆıtrise en informatique avec m´

emoire

Maˆıtre `

es sciences (M.Sc.)

Qu´

ebec, Canada

R´

esum´

e

Ce m´emoire pr´esente une approche d’application de politiques de s´ecurit´e qui utilise une analyse de types bas´ee sur un syst`eme de types multi-valeurs. Cette analyse est suivie d’une instrumentation lorsque n´ecessaire. Le langage cible est un langage imp´eratif. Notre approche vise `a r´eduire les faux-positifs g´en´er´es par une analyse statique, et `a r´eduire la surcharge d’ex´ecution en n’instrumentant que lorsque n´ecessaire. Les faux-positifs surviennent dans l’analyse de syst`emes informatiques lorsqu’une information est manquante durant la compilation, par exemple le nom d’un fichier, et par cons´equent, son niveau de s´ecurit´e. L’id´ee principale de notre approche est de distinguer les r´eponses n´egatives des r´eponses incertaines. Au lieu de rejeter les commandes potentiellement non s´ecuritaires, elles sont identifi´ees et ´etiquet´ees pour la seconde phase de l’analyse. Les r´eponses n´egatives et positives sont trait´ees comme cela se fait d’habitude. Ce travail est une approche hybride d’application de politique de s´ecurit´e : les points potentiellement s´ecuritaires du programme d´etect´es par notre analyse par typage sont instrument´es par la suite avec des tests dynamiques. Le syst`eme de typage sur lequel se base le nˆotre a ´

et´e pr´esent´e par Desharnais et al. [12]. Notre approche a ´et´e accept´ee pour publication [7]. Dans ce travail nous pr´esentons les modifications apport´ees au pr´ec´edent travail et la phase d’instrumentation qui la compl`ete. La nouveaut´e de notre approche est de rajouter un niveau de s´ecurit´e aux trois du travail pr´ec´edent. Nous traitons les canaux et les variables de fa¸con sp´eciale. Les programmes interagissent par le biais de canaux de communication. Des niveaux de confidentialit´e sont associ´es aux canaux plutˆot qu’aux variables dont le niveau de s´ecurit´e est fonction de l’information qu’elles stockent. Notre analyse est sensible au flot.

Abstract

In this Master thesis, we present an approach to enforce information flow policies using a multi-valued type-based analysis followed by an instrumentation when needed. The target is a core imperative language. Our approach aims at reducing false positives generated by static analysis, and at reducing execution overhead by instrumenting only when needed. False positives arise in the analysis of real computing systems when some information is missing at compile time, for example the name of a file, and consequently, its security level. The key idea of our approach is to distinguish between negative and may responses. Instead of rejecting the possibly faulty commands, they are identified and annotated for the second step of the analysis; the positive and negative responses are treated as is usually done. This work is a hybrid security enforcement mechanism: the maybe-secure points of the program detected by our type based analysis are in-strumented with dynamic tests. The basic type based analysis has been reported by Desharnais et al. [12], this work deals with the modification of the type system and the instrumentation step. It has been accepted for publication [7]. The novelty of our approach is the handling of four security types, but we also treat variables and chan-nels in a special way. Programs interact via communication chanchan-nels. Secrecy levels are associated to channels rather than to variables whose security levels change according to the information they store. Thus the analysis is flow-sensitive.

Table des mati`

eres

R´esum´e iii

Abstract v

Table des mati`eres vii

Liste des tableaux ix

Liste des figures xi

Remerciements xix

1 Introduction 1

1.1 Motivation . . . 1

1.2 Approche et r´esultats escompt´es . . . 2

1.3 Structure du m´emoire . . . 3

2 Etat de l’art 5 2.1 Introduction . . . 5

2.2 Politiques de s´ecurit´e . . . 5

2.3 Approches statiques pour l’application des politiques de s´ecurit´e . . . . 6

2.4 Approches dynamiques pour l’application des politiques de s´ecurit´e . . 39

2.5 Approches hybrides pour l’application des politiques de s´ecurit´e . . . . 51

2.6 Conclusion . . . 55

3 Approche hybride bas´ee sur une analyse trivalu´ee 57 3.1 Introduction . . . 57

3.2 Langage cible . . . 58

3.3 Syst`eme de types de s´ecurit´e . . . 61

3.4 Algorithme d’inf´erence . . . 72

3.5 Instrumentation . . . 82

3.6 Conclusion . . . 89

4 Conclusion 93 4.1 Contributions . . . 93

Liste des tableaux

2.1 R`egles de typage. . . 17

2.2 R`egles de sous-typage. . . 18

2.3 Programme multithread avec fuite d’information . . . 21

2.4 R`egles de typage. . . 32

2.5 S´emantique des commandes. . . 46

2.6 R`egles de transition du moniteur. . . 47

2.7 S´emantique et ´ev´enements internes. . . 54

2.8 Moniteur sensible au flot. . . 54

3.1 S´emantique op´erationnelle structurelle . . . 62

3.2 R`egles de typage. . . 67

3.3 Algorithme d’inf´erence . . . 74

Liste des figures

2.1 Exemple de construction de diagramme de flot de contrˆole. . . 9

2.2 Exemple de construction de diagramme de d´ependances donn´ees. . . 10

2.3 Exemple de d´ecoupage de programme. . . 11

2.4 Sch´ema illustratif de la certification de code. . . 36

2.5 Architecture TAL. . . 38

2.6 Architecture de Naccio.. . . 41

2.7 Exemple d’automate de s´ecurit´e et instrumentation associ´ee. . . 44

2.8 Architecture du syst`eme de r´e´ecriture de politiques d’acc`es.. . . 45

2.9 Relations entre programmes accept´es par les syst`emes de types et les moni-teurs. . . 51

3.1 Analyse d’un programme pr´esentant un flot d’information implicite non s´ e-curitaire.. . . 69

3.2 Programmes illustrant l’utilisation de la commande if . . . 71

3.3 Exemple d´emontrant la n´ecessit´e d’une analyse it´erative pour le bloc while 71 3.4 Un programme g´en´erant des valeurs de s´ecurit´e inconnues et n´ecessitant une instrumentation. . . 71

3.5 faux positifs : incertitude due `a if et assignation d’un canal de niveau bas dans un contexte de niveau ´elev´e. . . 72

3.6 Flot implicite . . . 75

3.7 L’envoi d’une valeur priv´ee sur un canal de niveau inconnu provoque une instrumentation . . . 76

3.8 L’envoi d’une valeur priv´ee sur un canal de niveau inconnu provoque une instrumentation . . . 77

3.9 Exemple inspir´e de Zdancewic et Myers [56] . . . 77

3.10 L’envoi d’une valeur priv´ee sur un canal de niveau inconnu provoque une instrumentation . . . 85

3.11 L’envoi d’une valeur priv´ee sur un canal de niveau inconnu provoque une instrumentation . . . 86

3.12 L’envoi d’une valeur inconnue sur un canal de niveau public provoque une instrumentation . . . 88

3.13 Exemple illustrant l’instrumentation d’un programme avec boucle while . 89 3.14 Exemple de programme rejet´e. . . 90

A toi ma tr`es ch`ere m`ere, pour avoir toujours cru en moi et m’avoir soutenu mˆeme lorsque je n’y croyais plus moi-mˆeme, je d´edie ce m´emoire.

Il n’y a pas de vent favorable pour celui qui ne sait o`u il va.

Remerciements

Le pr´esent m´emoire est le fruit des efforts consentis tout au long de ma formation au programme de maˆıtrise en informatique de l’Universit´e Laval. Je profite de cette opportunit´e pour remercier tous ceux qui de pr`es ou de loin, m’ont assist´e dans la r´ealisation de cette œuvre.

Mes sinc`eres et chaleureux remerciements `a la professeure Nadia Tawbi, qui a accept´e de diriger ce travail, ainsi qu’`a ma co-directrice, la professeure Jos´ee Desharnais. C’est grˆace `a leurs implication, suggestions et connaissances dont j’ai b´en´efici´ees que ce travail a pu se r´ealiser.

Mes remerciements vont aussi `a l’endroit de tous mes coll`egues du groupe de recherche Langages, S´emantiques et M´ethodes Formelles (LSFM). Leur amiti´e, leurs suggestions et collaboration pendant les activit´es de recherche sont des qualit´es dont j’ai eu le plaisir de b´en´eficier. Je remercie particuli`erement Jean-Claude Simo pour sa collaboration, ainsi que Gildas Kouko pour ses conseils. Je remercie aussi Andrew Bedford, qui grˆace aux travaux effectu´es dans le cadre de son stage a permis l’implantation des algorithmes sur lesquels porte notre travail.

Je remercie ceux qui ont su m’accueillir `a Qu´ebec pour att´enuer la douleur de la distance qui me s´eparait des miens. Je voudrais remercier particuli`erement le professeur Pierre Marchand et sa femme Denise, ainsi que Lucie Caron. Je remercie Emmanuelle Soud´e et Georges Batona pour leur amiti´e tr`es fraternelle.

Mes remerciements s’adressent `a ma tr`es ch`ere m`ere Clotilde Tom´ety pour les sacrifices qu’elle a consentis pour la r´ealisation de tous mes projets d’´etude, et plus globalement pour que je sois la personne que je suis aujourd’hui.

Mes sentiments de gratitude s’adressent enfin `a mon Dieu tout puissant qui a toujours su me guider et m’´eclairer depuis ma naissance. Il est mon refuge et ma forteresse, `a lui je me confie.

Chapitre 1

Introduction

1.1

Motivation

L’omnipr´esence des technologies de l’information et de la communication est ind´eniable dans notre monde contemporain. On veut pouvoir acc´eder `a l’information partout et tr`es rapidement. Quasiment toutes les informations sont disponibles en ligne grˆace `a l’Internet. On y acc`ede par un nombre presque illimit´e de moyens : ordinateurs por-tables, t´el´ephones intelligents, tablettes, etc. Tout en assurant une disponibilit´e et un acc`es rapide `a l’information, il est vital de se doter de moyens assurant que les infor-mations ne sont accessibles qu’aux entit´es autoris´ees.

Le travail que nous pr´esentons dans ce m´emoire s’int`egre `a l’ensemble des m´ecanismes d’application de politiques de s´ecurit´e. Plus pr´ecis´ement, il traite des politiques de contrˆole du flot d’information entre variables et entit´es dans un syst`eme informatique. Nous pouvons distinguer deux types d’approches qui ont servi `a appliquer les politiques de s´ecurit´e. Il s’agit des techniques statiques et des techniques dynamiques. Plus r´ ecem-ment, un nouveau type d’approche a vu le jour pour tirer profit des forces des deux types d’approches pr´ec´edents, il s’agit de l’approche hybride. L’analyse statique ´evalue le comportement d’un programme dans toutes ses ex´ecutions possibles, sans avoir `a l’ex´ecuter. Un programme valid´e par une analyse statique par rapport `a une politique de s´ecurit´e peut ˆetre ex´ecut´e par la suite sans risque d’enfreindre la politique de s´ e-curit´e. Ce type d’analyse pr´esente comme avantages principaux, une conclusion valide pour toutes les ex´ecutions, et un impact quasi nul sur le temps d’ex´ecution. En effet puisque ce type d’analyse est effectu´e sans ex´ecuter le programme, il ne rajoute pas une surcharge d’ex´ecution. Cependant certaines informations ´etant disponibles seulement

dynamiquement, ce type d’approche est souvent confront´e `a un probl`eme d’ind´ ecidabi-lit´e. Ceci am`ene souvent les analyses `a ˆetre tr`es conservatrices et `a g´en´erer beaucoup de faux positifs, des cas o`u un programme s´ecuritaire est rejet´e du fait d’une mauvaise approximation. L’analyse dynamique quant `a elle, s’effectue plutˆot lors de l’ex´ecution du programme. Elle tient compte de l’ex´ecution courante, et sa port´ee ne peut ais´ement s’´etendre `a toutes les autres. L’autre faiblesse de cette approche est due `a ce qu’elle s’ef-fectue dynamiquement. Elle rajoute donc une surcharge d’ex´ecution. N´eanmoins, elle pr´esente comme force principale de pouvoir disposer de toutes les informations pour conclure contrairement `a l’analyse statique. Elle n’est pas confront´ee `a l’ind´ecidabilit´e inh´erente `a l’analyse statique.

1.2

Approche et r´

esultats escompt´

es

Notre approche est plutˆot du type hybride. En effet, l’analyse statique que nous pr´ esen-tons est compl´et´ee par une analyse dynamique afin de pouvoir, lorsque c’est pertinent, aller rechercher dynamiquement les informations n´ecessaires qui seraient manquantes statiquement. Le but ultime de notre travail est de r´eduire le nombre de faux positifs inh´erents `a une analyse statique, tout en minimisant la surcharge d’ex´ecution li´ee `a une ´

eventuelle phase dynamique. Ce travail porte sur le contrˆole du flot d’information. Il traite de politiques de s´ecurit´e concernant des restrictions li´ees `a l’acc`es `a l’information par les entit´es. Par exemple, il ne faudrait pas qu’une application de traitement de texte envoie, `a l’insu de son utilisateur, ses informations confidentielles comme son num´ero de carte de cr´edit. Ou bien qu’un site d’achat en ligne transmette les informations de connexion d’un utilisateur aux autres utilisateurs du site. Nous avons choisi d’adopter une analyse par typage. En effet cette approche est ´el´egante car elle permet une s´ e-paration entre la sp´ecification, les r`egles de typage, et l’impl´ementation, l’algorithme d’inf´erence. Elle permet ´egalement de faire la preuve de correction puisque la sp´ ecifi-cation est rigoureusement d´efinie. Des r`egles sont d´efinies dans celle-ci pour sp´ecifier le comportement d´esir´e du programme. Cette approche se base sur la syntaxe du langage de programmation d´efini `a cet effet. La propri´et´e de s´ecurit´e sur laquelle porte notre travail est une variante de la non-interf´erence de Goguen et Meseguer [16] adapt´ee `a des canaux de communication. L’apport de ce travail consiste en deux axes. Le premier est de concevoir un syst`eme de types qui permet d’´ecarter les cas incertains, ceux pour lesquels l’analyse statique ne peut conclure. Le second est de concevoir une instrumen-tation pour traiter ces cas incertains laiss´es par l’analyse statique. Au terme des deux phases de l’analyse, nous sommes en mesure de r´eduire le nombre de faux positifs dus

`

a une analyse purement statique. Pour permettre `a l’instrumentation de compl´eter le travail effectu´e par l’analyse statique, nous avons introduit un troisi`eme type de s´ecurit´e inconnu par rapport aux deux classiques, public et priv´e. Ce troisi`eme type permet de marquer les informations dont le niveau de s´ecurit´e ne peut ˆetre connu statiquement afin que l’instrumentation d´etermine leur type. Notre approche permet de r´eduire les faux positifs, tout en minimisant la surcharge d’ex´ecution qui peut ˆetre li´ee `a la phase dynamique.

1.3

Structure du m´

emoire

Le travail effectu´e dans le cadre de cette maˆıtrise s’inscrit dans un projet plus global. Celui-ci vise `a mettre en place une approche d’application de politique de s´ecurit´e sur le flot d’information combinant analyse statique et dynamique pour la v´erification de programmes. Il est envisag´e d’´evaluer des programmes ´ecrits dans des langages de haut niveau et s’ex´ecutant dans un environnement concurrentiel. Notre travail se restreint `

a des programmes ´ecrits dans un langage imp´eratif simple et la concurrence n’est pas trait´ee. Nous fournissons une base pour les travaux futurs qui approfondiront ces points. Ce m´emoire est structur´e comme suit : au chapitre 2, nous pr´esentons les travaux exis-tants sur les m´ecanismes d’application de politiques de s´ecurit´e, les analyses statiques et les analyses dynamiques. Quelques analyses hybrides sont ´egalement abord´ees. Ce chapitre pr´esente quelques techniques de contrˆole du flot d’information. Le chapitre 3

pr´esente notre approche, l’analyse hybride qui se base sur un typage trivalu´e. Nous pr´esentons enfin une conclusion au chapitre 4.

Chapitre 2

Etat de l’art

2.1

Introduction

Le pr´esent chapitre introduit quelques travaux importants traitant de techniques uti-lis´ees pour l’application des politiques de s´ecurit´e. Ceux-ci repr´esentent le cadre dans lequel s’ins`ere notre approche hybride combinant analyse statique et dynamique pour l’application de la politique de non-interf´erence. Nous commen¸cons par d´efinir la notion de politique de s´ecurit´e, puis nous pr´esentons quelques approches statiques d’application de politiques de s´ecurit´e. Par la suite, nous nous int´eressons aux approches dynamiques et terminons par les approches hybrides dont fait partie notre travail.

2.2

Politiques de s´

ecurit´

e

Un syst`eme S peut ex´ecuter des actions prises `a partir d’un ensemble d´enombrable possiblement infini Σ. On peut d´efinir une ex´ecution comme une s´equence d’actions de Σ.

Selon Schneider [42], une politique de s´ecurit´e est un pr´edicat sur un ensemble d’ex´ ecu-tions effectu´ees. Un syst`eme S satisfait une politique de s´ecurit´e P si pour son ensemble d’ex´ecutions ΣS, P ( ΣS ) est vrai. Un pr´edicat concernant une ex´ecution pr´ecise σ du

syst`eme est appel´e propri´et´e de s´ecurit´e. Une politique de s´ecurit´e pourrait porter par exemple sur :

1. le contrˆole d’acc`es : c’est la restriction d’op´erations que des entit´es pourraient effectuer sur des objets.

par des objets, des entit´es en observant le comportement d’un syst`eme.

3. la disponibilit´e : c’est la restriction des possibilit´es dont disposent des entit´es `a empˆecher d’autres entit´es d’acc´eder `a une certaine ressource.

Une politique de s´ecurit´e sur laquelle portera notre travail est la politique de non-interf´erence. C’est une politique de flot d’information. Elle a ´et´e introduite pour la premi`ere fois par Goguen et Meseguer [16]. Volpano et al. [48] la d´efinissent comme suit :

D´efinition 1. (Non-interf´erence) : Un programme c satisfait la non-interf´erence si, pour toutes m´emoires µ et ν qui co¨ıncident sur les variables de niveau public L (Low), les m´emoires produites en ex´ecutant c sur µ et ν co¨ıncident ´egalement sur les variables de niveau L (pourvu que les deux ex´ecutions s’ach`event avec succ`es).

De fa¸con plus informelle, cette propri´et´e stipule que l’ex´ecution du programme c avec deux m´emoires qui sont ´equivalentes en ce qui concerne les donn´ees publiques (mˆemes variables avec les mˆemes valeurs), produira deux m´emoires qui sont ´egalement ´

equivalentes en terme de donn´ees publiques. Plus simplement, les donn´ees confidentielles n’interf´ereront pas (n’affecteront pas) les donn´ees publiques. Il faut cependant noter que cette d´efinition de la non-interf´erence n’est valable que dans le cas d’un programme d´eterministe.

2.3

Approches statiques pour l’application des

politiques de s´

ecurit´

e

L’objet de l’analyse statique est d’examiner le code des programmes pour d´eterminer des propri´et´es de l’ex´ecution dynamique sans mˆeme les ex´ecuter. Elle consiste `a extraire des informations valables pour toutes les ex´ecutions possibles du programme. C’est un mod`ele du comportement du programme. L’analyse statique est une technique souvent utilis´ee par les d´eveloppeurs de compilateur pour effectuer diverses analyses et transfor-mations sur le code afin de l’optimiser ou de v´erifier sa conformit´e `a certaines propri´et´es. En ce qui concerne les politiques de s´ecurit´e l’analyse statique permet de savoir si pour toutes les ex´ecutions possibles du programme la politique est respect´ee. Un programme qui est jug´e respectant la politique de s´ecurit´e apr`es l’analyse statique, la respectera forc´ement dans quelque ex´ecution effective que ce soit. Il est parfois vital de s’assurer

autant que possible de la fiabilit´e d’un logiciel avant mˆeme de l’ex´ecuter. On imagine ais´ement qu’un constructeur d’avion qui con¸coit un nouveau mod`ele d’avion pourrait souhaiter que l’application qu’il installe sur celui-ci pour g´erer le pilotage automatique ou des param`etres critiques comme l’altitude, satisfasse un ensemble de propri´et´es d´ esi-r´ees. Cela offrirait une s´ecurit´e plus accrue pour les passagers. Ainsi effectuer l’analyse statique qui permet de conclure sur la fiabilit´e de l’application par rapport `a toutes ses ex´ecutions, plutˆot qu’une seule ex´ecution comme l’analyse dynamique se justifie. Cependant l’analyse statique ne peut pas conclure dans tous les cas qu’un programme est s´ecuritaire ou pas. En effet pour d´eterminer qu’un programme s’ex´ecute de fa¸con s´ e-curitaire, il est parfois important de tenir compte des donn´ees en entr´ee du programme. Par exemple, si on analyse un programme qui envoie de l’information confidentielle sur un canal choisi durant l’ex´ecution, on ne peut savoir si celui-ci est s´ecuritaire ou pas. La difficult´e qu’a l’analyse statique pour conclure s’explique bien par le th´eor`eme de Rice [38] :

Th´eor`eme 2. Toute propri´et´e extensionnelle non triviale portant sur des programmes est ind´ecidable.

On entend par propri´et´e extensionnelle, une propri´et´e qui ne d´epend que de la s´ eman-tique du programme, pas de sa syntaxe. Une propri´et´e non triviale en est une qui n’est ni toujours vraie, ni toujours fausse pour tous les programmes. Et on entend par propri´et´e ind´ecidable, une propri´et´e pour laquelle tout algorithme qui d´ecide si cette propri´et´e est vraie ou fausse boucle ind´efiniment ou bien se trompe au moins pour une infinit´e de programmes.

Il existe plusieurs techniques d’analyse statique. Nous pouvons distinguer les techniques d’analyse de flot de donn´ees et de flot de contrˆole, celles bas´ees sur le typage, l’inter-pr´etation abstraite ainsi que les techniques employant un compilateur certifi´e.

2.3.1

Techniques d’analyse de flot de donn´

ees et de flot de

contrˆ

ole.

Deux groupes de techniques existent principalement qui se basent sur l’analyse de flot par le biais de graphes. Nous avons les techniques d’analyse de flot de donn´ees et les techniques d’analyse de flot de contrˆole. L’analyse de flot de contrˆole et celle de flot

de donn´ees ont pour but de mod´eliser le comportement du programme sous forme de mod`ele pour en extraire certaines informations.

Analyse de flot de contrˆole

L’analyse de flot de contrˆole mod´elise en g´en´eral le comportement du programme sous la forme d’un graphe de flot de contrˆole CFG (Control Flow Graph). Le flot de contrˆole d’un programme est l’ordre dans lequel les diff´erentes instructions et appels de fonctions individuels sont ex´ecut´es ou ´evalu´es dans le programme. Kildall pr´esente le graphe de flot de contrˆole dans [24], qu’il utilise pour permettre des optimisations de programme comme des suppressions de redondances. Un exemple de traduction de programme en CFG est repr´esent´e `a la figure 2.1.

Dans un CFG, chaque nœud du graphe repr´esente un bloc de base. Un bloc de base est un bout de code avec un seul point d’entr´ee et un seul point de sortie. On ne peut acc´eder `a une partie du bloc, autre que son point d’entr´ee, par une instruction de saut (un jump) et qu’on ne peut en sortir, pour ex´ecuter un autre bloc de base, que par son unique point de sortie. Des arˆetes orient´ees repr´esentent les sauts (jump) d’un bloc de base `a un autre. Deux blocs sp´eciaux sont utilis´es : le bloc d’entr´ee qui d´ebute le contrˆole dans le graphe de flot et le bloc de sortie par lequel tout le flot de contrˆole sort. Le CFG peut cependant ˆetre construit avec des instructions simples comme nœud. C’est le cas du graphe de la figure 2.11_{. Cette analyse peut servir `a des optimisations comme}

la suppression de code inutile, qui n’est jamais utilis´e. On peut se rendre ainsi compte par exemple si un nœud n’est pas atteignable `a partir du bloc d’entr´ee du graphe de flot de contrˆole que celui-ci repr´esente du code inutile et qu’il peut ˆetre supprim´e sans le moindre impact sur le programme. En ce qui concerne les politiques de s´ecurit´e, on peut se servir d’un CFG pour tracer l’utilisation de primitives critiques d’un point de vue de la s´ecurit´e dans un programme comme l’ouverture d’un port (socket) ou l’envoi d’information sur un r´eseau.

Analyse de flot de donn´ees.

L’analyse de flot de donn´ees permet de calculer, selon le probl`eme, les informations pertinentes `a un point donn´e du programme. Un exemple d’analyse de flot de donn´ees est l’analyse de d´ependances. Le programme de la figure 2.22 _{illustre ce type d’analyse.}

L’analyse de flot de d´ependances calcule `a un point donn´e d’un programme, les

infor-1. source : cours Certification de logiciels GLO-7003, Universit´e Laval 2. source : cours Certification de logiciels GLO-7003, Universit´e Laval

Figure 2.1 – Exemple de construction de diagramme de flot de contrˆole.

mations pertinentes qui lui parviennent. Un point de programme se situe entre deux instructions cons´ecutives s´equentiellement d’un programme ainsi qu’au d´ebut et `a la fin d’un bloc de base. L’analyse de flot de donn´ees se sert du CFG g´en´er´e par l’analyse de flot de contrˆole pour comprendre l’effet de chaque instruction et voir comment les informations sont transmises `a un point du programme. Deux formes d’analyse sont possibles. Une analyse locale qui s’effectue `a l’int´erieur d’un bloc de base, qui analyse l’effet de chaque instruction et la composition des effets depuis le d´ebut du bloc de base jusqu’au niveau de chaque instruction. Il y a aussi une analyse globale qui ´evalue l’effet de chaque bloc, la propagation des effets tout le long du graphe de contrˆole puis l’application du r´esultat aux blocs de base.

Le probl`eme de l’analyse de flot de donn´ees correspond `a ´elaborer et `a r´esoudre `a chaque point donn´e d’un programme des ´equations de flot de donn´ees. En g´en´eral, il faut calcu-ler de fa¸con it´erative la sortie g´en´er´ee `a partir des entr´ees jusqu’`a atteindre une valeur stable, le point fixe. Cette approche a ´et´e pr´esent´ee par Kildall [24]. L’analyse peut ˆetre faite de deux fa¸cons, soit vers l’avant soit vers l’arri`ere. Dans l’analyse vers l’avant, la sortie d’un bloc est fonction des donn´ees `a l’entr´ee du bloc. Les donn´ees `a l’entr´ee du bloc sont fonction des sorties des blocs pr´ec´edents le bloc courant. Dans l’analyse vers l’arri`ere, c’est plutˆot l’inverse. C’est plutˆot l’entr´ee du bloc qui est fonction des sorties de celui-ci. Et les donn´ees en sortie du bloc sont fonction des entr´ees de ses

succes-Figure 2.2 – Exemple de construction de diagramme de d´ependances donn´ees.

seurs. Il faut noter que l’analyse de flot de donn´ees fait une estimation conservatrice des informations.

D´ecoupage de programmes (Program slicing)

La technique de d´ecoupage de programmes tel que mentionn´e par Weiser [52], `a partir d’un sous-ensemble du comportement d’un programme, r´eduit le programme `a une forme minimale qui pr´esente encore le mˆeme comportement par rapport `a un crit`ere donn´e. Le d´ecoupage de programmes se sert d’une analyse de de flot de contrˆole et d’une analyse de flot de donn´ees. Le programme produit est un programme ind´ependant pour lequel on a la garantie qu’il repr´esente fid`element le programme original dans le domaine sp´ecifi´e du sous-ensemble propre `a ce comportement. Ici, un comportement pourrait ˆetre simplement l’affectation d’une valeur particuli`ere `a une variable. On irait rechercher par exemple toutes les informations susceptibles de transmettre cette information. C’est une technique similaire `a celle employ´ee par un programmeur qui fait du d´ebogage pour am´eliorer un programme. Il va juste s´electionner la ligne concern´ee et sauter les instructions jusqu’`a celles qui sont affect´ees par celle-ci tout en ignorant tout le reste. L’avantage de cette m´ethode c’est qu’on se concentre uniquement sur la portion du code qui a un impact sur le comportement qu’on veut observer en ignorant tout le reste. Le comportement qu’on veut observer est appel´e crit`ere de d´ecoupage (slicing criterion) . La portion (slice) de programme est l’ensemble form´e par les instructions qui affectent

Figure 2.3 – Exemple de d´ecoupage de programme.

ou qui sont affect´ees par le crit`ere de d´ecoupage.

Plusieurs formes de d´ecoupage de programmes existent : le d´ecoupage de programmes statique, le d´ecoupage de programmes dynamique, le d´ecoupage de programmes avant, le d´ecoupage de programmes arri`ere, le d´ecoupage de programmes conditionnel. En ce qui concerne le d´ecoupage de programmes statique en particulier, on d´eduit le crit`ere de d´ecoupage du code source pour toutes les valeurs d’entr´ee possibles du programme. On ne fait aucune hypoth`ese sur des valeurs possibles d’entr´ee. Il g´en`ere en g´en´eral une portion de taille importante et contient toutes les instructions qui peuvent affecter une variable pour chaque ex´ecution possible.

A partir de la d´efinition initiale de Weiser, pour un crit`ere de d´ecoupage C=(x,V) avec x, une instruction dans le programme P, et V un sous-ensemble des variables de P. Une portion statique comprend toutes les instructions qui affectent la variable v, pour un ensemble de toutes les valeurs entr´ees `a l’instruction x en question. Les portions statiques sont d´etermin´ees en cherchant les ensembles successifs d’instructions qui sont indirectement pertinents conform´ement aux d´ependances de donn´ees et de contrˆole. Un exemple de d´ecoupage de programme est illustr´e `a la figure 2.33_.

2.3.2

L’analyse par typage

Une forme d’analyse statique qui a int´eress´e plusieurs chercheurs est l’analyse par ty-page. L’id´ee de cette analyse est d’assurer le respect d’une politique de s´ecurit´e grˆace `a

un langage typ´e. L’analyse par typage se fonde sur la citation de Robert Milner selon laquelle les programmes bien typ´es ne peuvent se tromper : “Well typed programs cannot go wrong”. Les pr´ecurseurs de la s´ecurisation du flot d’information par l’analyse statique sont Denning et Denning [11]. Leur analyse s’appuie sur un treillis de classes de s´ecurit´e pour ´evaluer le flot d’information dans le programme. N´eanmoins cette analyse n’est pas une analyse par typage. A l’origine, l’analyse par typage servait `a inf´erer ou v´erifier les types, mais elle a depuis ´et´e utilis´ee pour inf´erer d’autres types d’informations comme les effets de lecture ou ´ecriture, le flot de contrˆole, etc. L’analyse par typage consiste `a donner des types `a des variables et expressions, et en inf´erant progressivement le type d’expressions compos´ees de celles dont on connaˆıt le type, d´eduire le comportement global de l’expression statiquement.

L’analyse par typage se d´ecompose en cinq grandes ´etapes :

• la d´efinition de la s´emantique dynamique (ou op´erationnelle), ce sont les r`egles de typage.

• la d´efinition de la s´emantique statique (syst`eme de types) qui sera utilis´ee pour ´evaluer le programme

• la d´efinition d’un algorithme d’inf´erence de types pour typer le programme cible. • la preuve de coh´erence entre s´emantique statique et s´emantique dynamique

• les preuves de coh´erence et de compl´etude entre syst`eme de types (s´emantique sta-tique) et algorithme d’inf´erence.

La s´emantique dynamique est utilis´ee pour associer aux expressions form´ees dans le langage, les valeurs pr´ecises concr`etes qui leur sont associ´ees. Elle sp´ecifie la fa¸con selon laquelle un programme est ex´ecut´e.

La s´emantique statique permet d’associer un type `a un programme. Elle permet de g´en´eraliser les diff´erentes valeurs que re¸coit le programme en param`etre, celles qu’il manipule, et celle de retour. La g´en´eralisation peut ˆetre vue comme une abstraction. Ainsi les r`egles de typage permettront de sp´ecifier qu’un branchement conditionnel teste une expression de type bool´een, avant d’effectuer le corps de celui-ci. La s´emantique statique permet d’inf´erer `a partir de blocs plus petits le type de blocs plus importants (de fa¸con compositionnelle).

L’algorithme d’inf´erence de types automatise le processus que suit l’analyse statique pour d´eduire les types d’expressions et des commandes. C’est en quelque sorte une tra-duction de l’analyse statique. Il peut ainsi ˆetre assez ais´ement implant´e et ˆetre ex´ecut´e

par un ordinateur.

Apr`es avoir parl´e de quelques principes de base de l’analyse par typage, passons en revue quelques-uns des travaux importants qui l’ont trait´ee. Volpano et al. [48] ont pr´esent´e une preuve de coh´erence pour le syst`eme de Denning. A cet effet ils ont formul´e l’approche de Denning sous forme de syst`eme de type pour un langage d´eterministe. La preuve pr´esent´ee est celle de la propri´et´e de non-interf´erence. La preuve de coh´erence faite peut se traduire par “Tout programme bien typ´e, poss`ede la propri´et´e de non-interf´erence”. Ce travail est majeur car il est le premier `a pr´esenter une bonne preuve de coh´erence. Nous pr´esentons dans le chapitre qui suit, le travail de Volpano et al. [48].

Exemple d’analyse par typage.

Un syst`eme de types est un syst`eme formel de r`egles d’inf´erence pour ´etablir des juge-ments sur des programmes. Ils servent `a ´etablir que le type d’un programme est correcte dans des langages fortement typ´es, comme par exemple le Standard ML . Mais les sys-t`emes de types ne servent pas qu’`a justifier le type de programmes. Ils peuvent ˆetre per¸cus plus globalement comme des syst`emes logiques permettant de raisonner sur un bon nombre de propri´et´es de programmes. Une des propri´et´es pouvant ainsi ˆetre ´evalu´ee est celle des flots d’information s´ecuritaires, plus pr´ecis´ement la non-interf´erence. De fa-¸con intuitive, la non-interf´erence pour les programmes, signifie qu’une modification des valeurs en entr´ee confidentielles (high) ne peut provoquer une modification des valeurs en sortie publiques (low).

Plusieurs avantages existent `a pr´esenter l’analyse sous la forme d’un syst`eme de types. Cela joue le rˆole de sp´ecification formelle qui s´epare de fa¸con assez nette les politiques de s´ecurit´e, des algorithmes. Cette s´eparation permet une forme de coh´erence de l’ana-lyse semblable `a la notion de non-interf´erence de Goguen et Meseguer [16]. De fa¸con intuitive, cette forme de coh´erence dit que les variables dans un programme bien typ´e “n’interf`erent” pas avec des variables de niveaux inf´erieurs. Cette notion a ´et´e formalis´ee

comme un th´eor`eme de coh´erence de types et d´emontr´ee.

Afin de mieux pr´esenter le syst`eme de type, nous devons d´efinir la notion de treillis de niveaux de s´ecurit´e. Cette d´efinition se base sur une classification des niveaux de s´ecurit´e possibles des variables d’un programme. Un niveau de s´ecurit´e est une valeur qui d´esigne si une variable de programme est accessible publiquement ou pas. Un ni-veau de s´ecurit´e est associ´e `a chaque variable de programme. Ainsi un niveau L (Low) d´esigne une variable publique et un niveau H (DeclareRobustCommand), une variable

priv´ee. Le treillis est d´efini par ces classes de s´ecurit´e, et un ordre partiel sur elles (≤). Volpano et al.[48] l’´etendent pour en faire une relation de sous-typage not´ee ⊆. En fait dans leur travail, ils distinguent deux niveaux dans leur syst`eme de types. Le premier niveau est celui des types de donn´ees, not´e τ qui correspond aux classes que nous avons pr´ec´edemment mentionn´ees (L et H en l’occurrence) qui sont utilis´ees pour les expressions. Le type d’une expression correspond au type le plus ´elev´e des variables qui apparaissent dans sa d´efinition. Lorsqu’une expression e peut ˆetre typ´ee τ dans le syst`eme de types, alors selon une propri´et´e dite de s´ecurit´e simple, seules les variables de type τ ou de types plus bas pourront ˆetre lues lors de l’´evaluation de e. Le second niveau est celui des types de phrases. Il est plus g´en´eral et inclut les types de donn´ees τ , les types de variables τ var et les types de commandes τ cmd. Une commande c a le type τ cmd si toutes les variables qu’elle modifie sont de niveau de s´ecurit´e τ ou plus ´

elev´e. Cette propri´et´e est dite de confinement et est n´ecessaire pour garantir que les flots d’information implicites sont s´ecuritaires. Notons que la relation ⊆ est antimono-tone ( contravariante) pour les types de commandes. Ainsi lorsque τ ⊆ τ0 alors on a τ0 cmd ⊆ τ cmd.

Le syst`eme de types garantit que les flots d’information implicites et explicites sont s´ecuritaires. Pour mieux comprendre la diff´erence entre les types de flots d’information servons nous d’exemples. Consid´erons un programme qui assigne une variable de niveau H `a une variable de niveau L. Dans ce cas, le flot d’information est dit explicite. Il existe ´

egalement des cas de flot d’information implicites. Consid´erons le programme suivant :

if((secret%2) == 0) leak = 0 ;

else

leak = 1 ;

Ce programme copie implicitement le dernier bit de secret dans leak. Implicitement, car la valeur finale de leak d´epend de celle de secret bien que ce ne soit pas par une affectation directe. Le langage dans lequel sont d´efinis les programmes ´evalu´es par le syst`eme de types de Volpano et al. [48] est un langage imp´eratif simple. Les phrases du langage sont soit des expressions soit des commandes.

(phrases) p ::= e | c

(commandes) c ::= e := e0| c ; c0 _{| if e then c else c}0 _{| while e do c | letvar x :=e in c}

La m´etavariable x d´esigne les identifiants de variables (valeurs enti`eres), l pour les locations (emplacements/adresses en m´emoire), et n les litt´eraux d’entiers (identifiants de valeurs constantes). Les entiers sont les seuls valeurs. La valeur 0 sert `a repr´esente le bool´een f aux et 1 vrai. Les locations sont suppos´ees bien ordonn´ees. Les types tels que mentionn´es pr´ealablement sont les suivants :

(types de donn´ees) τ ::= s | H

(types de phrases) ρ ::= τ | τ var | τ cmd

Comme on peut s’en douter, le type τ var correspond au type des variables et τ cmd `

a celui des commandes. Le typage se base sur des jugements de typage de la forme : λ; γ ` p : ρ.

λ est l’environnement de typage des locations et γ est celui des identifiants. Le jugement peut se traduire par la phrase p a le type ρ en se basant sur le fait que λ donne les types des locations apparaissant dans p et γ les types des identifiants libres de p. Un environnement de typage d’identifiants est une fonction finie qui associe les identifiants `

a des types ρ ; γ(x) = ρ est le type associ´e `a x par γ. De mˆeme, γ[x : ρ] est un environnement de typage modifi´e qui assigne le type ρ `a x et le type γ(x’) `a tout autre identifiant x’. Un environnement de typage de locations est une fonction finie qui associe `

a des locations (emplacements) `a des types τ .

Les r`egles de typage du langage sont celles de la figure 2.1. Ces r`egles sont compl´et´ees par celles de la figure 2.2 qui sont des r`egles de sous-typage. Celles-ci restreignent les g´en´eralisations de types pour respecter la s´ecurit´e. La nouveaut´e principale de leur tra-vail est la preuve de coh´erence qui est faite. Elle est ´etablie par rapport `a la s´emantique du langage choisi. La preuve est celle du th´eor`eme de coh´erence suivant :

Si λ(l) = τ , pour une certaine location l, alors l’on peut arbitrairement modifier la valeur initiale d’une quelconque location l0 telle que λ(l0) n’est pas un sous-type de τ , ex´ecuter le programme, et la valeur finale de l restera la mˆeme pourvu que le programme se termine correctement.

Pour faciliter la preuve, les auteurs introduisent de nouvelles r`egles de typage qui in-cluent en mˆeme temps les cas rendus possibles par les r`egles de sous-typage. Ils d´ e-montrent en un premier temps, l’´equivalence entre les nouvelles r`egles et les initiales.

Puis ils d´emontrent par induction structurelle sur l’expression e la propri´et´e de s´ecurit´e simple et par induction structurelle sur la commande c, la propri´et´e de confinement. Par la suite, ils pr´esentent de fa¸con plus formelle la preuve de coh´erence dans [48] comme suit.

Th´eor`eme 3. (Coh´erence de type) Supposons

(a) λ ` c : ρ, (b) µ ` c ⇒ µ0, (c) ν ` c ⇒ ν0,

(d) dom(µ) = dom(ν) = dom(λ), et

(e) ν(l) = µ(l) pour tout l tel que λ(l) ≤ τ . Alors ν0(l) = µ0(l) pour tout l tel que λ(l) ≤ τ .

Finalement la preuve est faite par induction structurelle sur la d´erivation de µ ` c ⇒ µ0. Evolution de l’analyse par typage.

L’analyse par typage est une analyse qui se base sur le langage. On peut noter quatre domaines importants de recherche li´es `a l’analyse de flot d’information :

– l’enrichissement de l’expressivit´e du langage,

– l’analyse de l’impact sur la s´ecurit´e de la concurrence, – l’analyse des canaux cach´es

– la sensibilit´e au flot d’information

Passons en revue quelques uns des travaux importants dans chacun de ces domaines. A - Expressivit´e du langage.

L’objectif de l’un de ses domaines importants est d’enrichir l’expressivit´e des lan-gages utilis´es par l’analyse par typage, afin d’atteindre le niveau d’expressivit´e des langages de programmation de haut niveau. Au nombre des types de programma-tion ´etudi´es, nous pouvons citer la programmation proc´edurale, la programmation fonctionnelle, la programmation avec les exceptions et la programmation orient´ee objet.

Programmation proc´edurale : Volpano et Smith [50] pr´esentent un syst`eme de types avec des proc´edures de premier-ordre. Ils d´emontrent par la suite que le syst`eme de types garantit la non-interf´erence. Leur syst`eme de types

(INT) λ, γ ` n : τ

(VAR) λ, γ ` x : τ var , if γ(x) = τ var (VARLOC) λ, γ ` l : τ var , if λ(l) = τ (ARITH) λ, γ ` e : τ λ, γ ` e 0 : τ λ, γ ` e + e0: τ (R-VAL) λ, γ ` e : τ var λ, γ ` e : τ (ASSIGN) λ, γ ` e : τ var λ, γ ` e 0 : τ λ, γ ` e := e0: τ cmd (COMPOSE) λ, γ ` c : τ cmd λ, γ ` c 0 : τ cmd λ, γ ` c; c0: τ cmd (IF) λ, γ ` e : τ λ, γ ` c : τ cmd λ, γ ` c 0 : τ cmd λ, γ ` if e then c else c0: τ cmd (WHILE) λ, γ ` e : τ λ, γ ` c : τ cmd λ, γ ` while e do c : τ cmd (LETVAR) λ, γ ` e : τ λ, γ[x : τ var] ` c : τ 0 cmd λ, γ ` letvar x :=e in c : τ0cmd

Table 2.1 – R`egles de typage.

se sert beaucoup de la notion de polymorphisme. Le polymorphisme permet d’avoir des commandes et expressions dont les types sont g´en´eriques, c’est-`

a-dire d´ependant du contexte. Par exemple, les proc´edures peuvent avoir des types de s´ecurit´e polymorphiques pour permettre d’ajuster leur invocation au contexte (high ou low).

Programmation fonctionnelle Heintze et Riecke [18] travaillent avec l’alg`ebre de processus SLam calcul qui est inspir´e du lambda calcul. Ce langage est fonc-tionnel et supporte les fonctions de premi`ere-classe (fonctions utilis´ees comme valeurs ordinaires). Ils proposent un syst`eme de types pour la confidentialit´e et l’int´egrit´e de SLam et d´emontrent un th´eor`eme de non-interf´erence en se servant des relations logiques. Ils ´etendent ´egalement SLam et le syst`eme de types avec les ´etats et la concurrence cependant, ils n’en d´emontrent pas la non-interf´erence.

(BASE) τ ≤ τ 0 τ ⊆ τ0 (REFLEX) ` ρ ⊆ ρ (TRANS) ` ρ ⊆ ρ 0 <sub>` ρ</sub>0<sub>⊆ ρ</sub>00 ` ρ ⊆ ρ00 (CMD−) ` τ ⊆ τ 0 ` τ0 cmd ⊆ τ cmd (SUBTYPE) λ, γ ` p : ρ ` ρ ⊆ ρ 0 λ, γ ` p : ρ0

Table 2.2 – R`egles de sous-typage.

Zdancewic et Myers dans [55] et [57] d´efinissent un langage s´ecuritaire qui poss`ede des continuations de premi`ere-classe, des ´etats et des r´ef´erences. Ils d´emontrent la non-interf´erence pour le syst`eme de types. Ils montrent ´ ega-lement qu’en rajoutant les ´etats et les r´ef´erences `a un fragment de SLam, celui-ci peut ˆetre traduit en leur langage sans perte de pr´ecision.

Pottier et Conchon [36] pr´esentent une m´ethode syst´ematique pour ´etendre les syst`emes de types conventionnels avec le contrˆole de flot d’information, dans le cas de langages fonctionnels. Leur approche simplifie la preuve de cor-rection. En effet, elle permet de d´eduire cette preuve de correction de celle du syst`eme de types initial.

Pottier et Simonet [37] ont travaill´e sur une extension de la partie purement fonctionnelle du SLam calcul. Leur extension rajoute au Slam calcul les r´ef´ e-rences, les exceptions et le polymorphisme de types. Ils pr´esentent ´egalement la preuve de non-interf´erence qui lui est associ´ee.

Exceptions Les exceptions sont des m´ecanismes pr´esents dans certains langages, qui peuvent ˆetre lanc´es par un programme lorsqu’une erreur est d´ecel´ee `a l’ex´ecution. C’est le cas par exemple d’une division par z´ero. Un program-meur peut aussi s’en servir pour signaler des conditions exceptionnels. Une exception peut ˆetre attrap´ee par une construction sp´eciale du langage, entraˆı-nant un transfert de contrˆole non local `a l’origine de l’exception. Ceci pouvant

potentiellement cr´eer des flots d’information implicites. Une exception non at-trap´ee peut aussi causer un flot d’information implicite.

Volpano et Smith [49] proposent un syst`eme de types simple qui permet de d´eceler la pr´esence de flots d’information implicites li´es `a la gestion des ex-ceptions. Leur syst`eme de types est n´eanmoins assez restrictif.

Myers [32] juge impr´ecise les gestions pr´ec´edentes faites des exceptions. En ef-fet il d´efend le fait que ces m´ethodes ne peuvent ˆetre convenablement utilis´ees dans des langages de programmation fr´equemment utilis´es. Ce travail porte sur une extension du langage orient´e objet Java, JFlow. Cette extension du langage Java, lui rajoute des annotations de s´ecurit´e de flot d’information qui sont ´evalu´ees statiquement. Contrairement aux m´ethodes ant´erieures de ges-tion de flot d’informages-tion, Myers propose l’utilisages-tion d’´etiquettes de chemin. Les ´etiquettes de chemin sont les ´etiquettes des informations transmises par de diff´erents chemins de terminaison possibles : terminaison normale, termi-naison avec lancement d’exceptions, etc. Cela permet un suivi plus pr´ecis des flots implicites caus´es par les exceptions. Cependant ils n’ont pas d´emontr´e la non-interf´erence de leur syst`eme.

Pottier et Simonet [37] et Simonet[43] se sont int´eress´es `a la programmation fonctionnelle avec une version de lambda calcul enrichie entre autres du poly-morphisme, des r´ef´erences et des exceptions. Ils proposent pour la gestion des exceptions une version plus flexible, avec une analyse polymorphe des effets, que celle de Myers qui utilise la gestion monomorphe, avec les clauses throws de Java. Leur analyse est assez pr´ecise et ils pr´esentent aussi la preuve de non-interf´erence associ´ee.

Programmation orient´ee objet La programmation orient´ee objet est ´egalement un concept important pour la majorit´e des langages de programmation r´ e-cents. Le langage JFlow, pr´esent´e par Myers [32] est une extension du langage orient´e objet tr`es populaire Java. JFlow rajoute au langage Java, des annota-tions pour lune analyse statique du flot d’information. Un syst`eme de types permet de v´erifier si le flot d’information du programme est s´ecuritaire. Le compilateur Jif d´ecrit par Myers et al.[33] a ´et´e impl´ement´e en int´egrant le syst`eme de types pour pouvoir traiter ce langage.

Abadi et Cardelli [2] notant l’absence d’une vraie th´eorie des objets, semblable au λ − calcul pour les langages fonctionnels, en proposent dans leur ouvrage qu’ils nomment les Objet-calculs. Une de leur version d’Objet-calcul est le F Ob1≤: qui est muni du sous-typage d’objet et de la subsomption. Barthe

et Serpette [6] analysent le flot d’information dans un langage orient´e-objet simple bas´e sur F Ob1≤:. Ils d´emontrent que leur syst`eme de types assurent la

non-interf´erence.

Banerjee et Naumann [5] ont travaill´e sur un langage orient´e-objet s´ equen-tiel qui est muni entre autres de pointeurs, de l’h´eritage et des liaisons dy-namiques. Ils ´etudient l’allocation dynamique de m´emoire. Leur syst`eme de s´ecurit´e ´etend celui de Volpano et Smith [50] avec les flots de donn´ees incluant les attributs d’objets mutables. Il contrˆole le flot d’information lors d’invoca-tions de m´ethodes qui sont associ´ees dynamiquement `a la bonne classe. Ils d´emontrent que leur syst`eme de types assurent la non-interf´erence.

B - Concurrence.

La concurrence est un domaine de recherche important et `a part enti`ere qui a fait l’objet de plusieurs ´etudes. Le non-d´eterminisme est un des aspects, ´etudi´es, les plus importants en concurrence. On peut aussi ajouter `a celui-ci la concurrence de threads comme autre aspect ayant fait l’objet d’´etude.

Non-d´eterminisme : Le non-d´eterminisme a ´et´e ´etudi´e sous plusieurs angles en ce qui concerne la concurrence. L’un de ceux concerne les processus s’ex´ e-cutant avec une m´emoire partag´ee. Bien souvent, un programme peut ˆetre ex´ecut´e dans un environnement multi-processus, o`u tous les processus sont ex´ecut´es dans une m´emoire partag´ee, on pourrait s’attendre `a ce que le mˆeme programme ne produise pas les mˆemes valeurs de sortie avec deux ex´ecutions diff´erentes. La d´efinition initiale de Volpano et al. [48] n’est donc plus tout `

a fait appropri´ee. Smith [45] propose une autre d´efinition d´esign´ee par non-interf´erence possibiliste qui vise `a consid´erer l’aspect non d´eterministe des programmes. Elle est ´enonc´ee de la fa¸con suivante :

D´efinition 4. (Non-interf´erence possibiliste) : Un programme c satisfait la non-interf´erence possibiliste si, pour toutes m´emoires µ et ν qui co¨ıncident sur les variables de niveau L, si l’ex´ecution de c sur la m´emoire µ peut produire la m´emoire finale µ 0 , alors l’ex´ecution de c sur ν peut produire une m´emoire finale ν 0 telle que µ 0 et ν 0 co¨ıncident ´egalement sur les variables de niveau L.

Les r`egles de typage de la figure 2.1 ne sont plus appropri´ees pour as-surer l’interf´erence possibiliste comme le montre l’exemple de la figure 2.3

Thread α :

while (mask != 0) { while (trigger0 == 0)

;

leak = leak | mask ; ( ou binaire) trigger0 = 0 ; maintrigger = maintrigger+1 ; if (maintrigger == 1) trigger1 = 1 ; } Thread β : while (mask != 0) { while (trigger1 == 0) ;

leak = leak & mask ; ( et binaire avec le compl´ementaire de mask) trigger1 = 0 ; maintrigger = maintrigger+1 ; if (maintrigger == 1) trigger0 = 1 ; } Thread γ : while (mask != 0) { maintrigger = 0 ; if (secret & mask == 0)

trigger0 = 1 ; else trigger1 = 1 ; while (maintrigger != 2) ; mask = mask/2 ; } trigger0 = 1 ; trigger1 = 1 ;

Table 2.3 – Programme multithread avec fuite d’information

, tir´e de Smith et Volpano [46]. Les valeurs initiales de toutes les variables sont 0, except´e mask, dont la valeur est une puissance de 2, et secret dont la valeur est un naturel arbitraire inf´erieur au double de mask. On peut re-marquer qu’avec un ordonnanceur ´equitable, ce programme copie toujours secret dans leak. Pourtant tous les trois threads sont bien typ´es lorsque que secret, trigger0 et trigger1 sont de type H et leak, maintrigger, et mask sont de type L.

Il faut donc ajouter de nouvelles restrictions pour les programmes multi-processus. Smith et Volpano [46] pour r´etablir la propri´et´e de non-interf´erence dans un environnement multi-processus, imposent deux nouvelles restrictions

pour typer les boucles while : ils exigent que la garde de la boucle while soit de type L, et que la boucle while elle-mˆeme soit de type L cmd. Ces nouvelles restrictions permettent effectivement d’´eliminer l’exemple pr´ec´edent du fait que trigger0 et trigger1 soient de type H, ils ne peuvent ˆetre utilis´es dans les gardes des boucles while des processus α et β.

Cependant Smith [45] s’int´eresse `a l’ordonnanceur de processus et fait remar-quer que la notion de non-interf´erence possibiliste n’est suffisante que si nous supposons un ordonnanceur purement non-d´eterministe. Avec un tel ordon-nanceur , il n’y a pas d’approximation concernant la m´emoire pouvant r´esulter de l’ex´ecution du programme, une m´emoire finale est simplement soit possible soit impossible. Pourtant un vrai ordonnanceur est forc´ement plus pr´evisible. Consid´erons l’exemple d’un ordonnanceur qui lance un pi`ece de monnaie `a chaque ´etape pour choisir quel processus ex´ecuter. Prenons l’exemple suivant de Mclean [28]. Le programme est constitu´e de deux processus :

Processus β

leak = secret ; Processus α

leak = random(100) ;

Supposons que random(100) retourne un nombre al´eatoire entre 1 et 100 et que la valeur de secret est entre 1 et 100. Ce programme satisfait la non-interf´erence possibiliste, car la valeur finale de leak peut ˆetre n’importe quelle valeur entre 1 et 100 ind´ependamment de la valeur de secret. Mais avec un ordonnanceur probabiliste comme celui qui se sert des r´esultats d’un jet de pi`ece de monnaie, la valeur de leak sera la valeur de secret avec la probabilit´e 101/200 et pour tous les autres nombres entre 1 et 100, la probabilit´e 1/200. Cet exemple justifie le choix d’une propri´et´e de s´ecurit´e plus forte, la non-interf´erence probabiliste. Nous proposons une d´efinition informelle de celle-ci.

D´efinition 5. (Non-interf´erence probabiliste) : Un programme c satisfait la non-interf´erence probabiliste si, pour toutes m´emoires µ et ν qui co¨ıncident sur les variables de niveau L, si l’ex´ecution de c sur la m´emoire µ peut produire la m´emoire finale µ0 avec une distribution conjointe de probabilit´e des valeurs de niveau L, d , alors l’ex´ecution de c sur ν peut ´egalement produire une

m´emoire finale ν 0 telle que la distribution conjointe de probabilit´e des valeurs de niveau L, est ´egalement d .

Smith [45] d´ecrit un syst`eme de types pour assurer la non-interf´erence pro-babiliste dans les programmes multi-processus. Ce syst`eme de types permet aux gardes de boucles while de contenir des variables H, mais pour empˆecher une interf´erence due au temps d’ex´ecution, il exige qu’une commande dont le temps d’ex´ecution, d´epend de variables H ne puisse ˆetre suivie d’une as-signation `a une variable L. Cela s’explique intuitivement par le fait qu’une affectation `a une variable L est dangereuse dans un environnement multi-processus. Car si un autre processus fait une affectation `a la mˆeme variable, alors l’ordre possible dans lequel les affectations s’effectuent (et ainsi la valeur finale possible de la variable de type L) d´epend de l’information H. Le syst`eme de types utilise les ensembles de type suivants :

(types de donn´ees) τ : := L | H

(types de phrases) ρ : := τ | τ var | τ1 cmd τ2 | τ cmd n

On note la substitution de la r`egle τ cmd par les deux derni`eres. Celles-ci peuvent ˆetre traduites :

• Une commande c est typ´ee τ1 cmd τ2 si elle assigne uniquement `a des

variables de type τ1 ou plus ´elev´es et son temps d’ex´ecution d´epend

uni-quement de variables de type τ2 ou plus bas.

• Une commande c est typ´ee τ cmd n si elle assigne uniquement `a des variables de type τ ou plus ´elev´es et si c’est garanti qu’elle termine en exactement n ´etapes.

Joshi et Leino [21], contrairement aux auteurs pr´ec´edents, arrivent `a traiter le non-d´eterminisme en utilisant une approche diff´erente. Au lieu d’utiliser une approche syntaxique, ils se servent plutˆot d’une approche s´emantique avec une propri´et´e de s´ecurit´e ´equationnelle. Ils d´efinissent un programme HH (“destruction de h”) qui signifie informellement “affecter une valeur arbitraire”. Un programme C est consid´er´e s´ecuritaire si et seulement si :

∀s ∈ S. [HH; C; HH]_s ≈ [C; HH]_s

pour une relation d’´equivalence ≈ appropri´ee sur les ensembles de valeurs fi-nales. La pr´esence de HH apr`es C dans les deux ´equations permet d’´egaliser l’ensemble des valeurs finales possibles de h. Cette ´equation se traduit intui-tivement par : “la modification de la valeur initiale de h ne se refl`ete pas dans l’ensemble des valeurs finales de l ”. Ce qui en fait une condition de s´ecurit´e possibiliste. Ils utilisent la logique des pr´edicats pour d´emontrer l’´equivalence

de leur notion de programme ayant un flot d’information s´ecuritaire `a celle de la non-interf´erence de Volpano et al. [48].

Sabelfeld et Sands [41] se servent de Relations d’´Equivalence Partielles (PER) pour sp´ecifier de fa¸con formelle les propri´et´es de s´ecurit´e. La sp´ecification for-melle est faite en utilisant la s´emantique d´enotationnelle. Ils montrent que la propri´et´e de s´ecurit´e ´equationnelle de Joshi et Leino [21] est une instance de leurs sp´ecifications et traitent le non-d´eterminisme en ´etendant l’approche avec une s´emantique de domaines puissance. Ils proposent ´egalement une m´ e-thode de formalisation des propri´et´es de s´ecurit´e probabilistes en se servant de s´emantiques de domaines puissance probabilistes.

Langar et al. [26] adoptent une d´emarche diff´erente. Ils proposent une tech-nique formelle et modulaire pour assurer de mani`ere automatique une poli-tique de s´ecurit´e dans un syst`eme concurrent. Etant donn´e un programme concurrent P et une politique de s´ecurit´e φ, ils g´en`erent automatiquement un autre programme P0 qui satisfait φ. Le programme ainsi g´en´er´e se comporte comme P dans tous les cas, sauf lorsque P viole la politique de s´ecurit´e φ. Dans ce cas, il arrˆete son ex´ecution. Ils utilisent une version ´etendue de l’al-g`ebre de processus ACP (Algebra of Communicating Process) [4] et l’alg`ebre de processus qu’ils nomment BPA∗<sub>δ,1</sub> (Basic Process Algebra) comme langages formels pour sp´ecifier respectivement les syst`emes concurrents et les politiques de s´ecurit´e.

Concurrence de threads : Dans le cas de programmes multithreads s’ex´ ecu-tant avec un mˆeme processeur, d’autres consid´erations doivent ˆetre prises en compte. Ainsi l’ordre d’ex´ecution des threads peut rendre non s´ecuritaire, un thread qui de fa¸con ind´ependante serait s´ecuritaire. Par exemple, consid´erons le programme (thread) suivant :

h := 0 ; l := h

Ce programme est s´ecuritaire dans un typage sensible au flot. En effet, mˆeme si la variable h est consid´er´ee de niveau ´elev´e (DeclareRobustCommand), lorsqu’on lui affecte la constante 0, elle deviendra une variable publique (low) comme cette constante. Alors l’affectation suivante est s´ecuritaire aussi et mettra l `a h qui est dor´enavant une variable publique. Cependant la s´ecurit´e peut ˆetre compromise si un autre programme(s´ecuritaire) est ex´ecut´e en pa-rall`ele. Ainsi si ce programme modifie la valeur de h avec une valeur secr`ete DeclareRobustCommand : h := h’, imm´ediatement avant que le thread pr´ e-c´edent n’ex´ecute la commande l := h, celui-ci n’est plus s´ecuritaire. Car lors

de cette affectation la valeur affect´ee n’est plus celle de la constante publique 0, mais bien la valeur priv´ee h0.

Volpano et Smith [46] sont les premiers `a d´emontrer pour un langage mul-tithread, la non-interf´erence. C’est une non-interf´erence possibiliste, c’est `a dire qui est ´etablie par rapport aux valeurs de sortie possibles. Deux condi-tions sont n´ecessaires dans leur syst`eme pour assurer la non-interf´erence. La premi`ere est qu’une boucle while ne devrait pas avoir de garde de niveau de s´ecurit´e ´elev´e DeclareRobustCommand. La deuxi`eme impose que les boucles while elles-mˆemes soient de type low cmd. Il faut cependant noter que cette non-interf´erence s’appuie aussi sur le fait que l’ordonnanceur utilis´e pour s´ elec-tionner le thread `a ex´ecuter doit ˆetre purement non-d´eterministe. Les auteurs mentionnent n´eanmoins qu’ils ne savent pas comment mettre en place un tel ordonnanceur en pratique. Avec la plupart des ordonnanceurs employ´es comme le round-robin, la propri´et´e de non-interf´erence n’est plus valable. Cela est dˆu au fait que ces ordonnanceurs ne sont pas en r´ealit´e vraiment non-d´eterministe dans leur choix de thread, causant une fuite d’information. Pour arriver `a restaurer la non-interf´erence, les auteurs proposent une nouvelle condition encore plus contraignante que les deux pr´ec´edentes : les gardes de branchements conditionnels doivent ´egalement ˆetre de niveau de s´ecurit´e bas low. Cependant mˆeme si la non-interf´erence est ainsi pr´eserv´ee, cette derni`ere condition est trop restrictive en pratique.

Volpano et Smith [51] ont travaill´e aussi avec un ordonnanceur probabi-liste. Dans leur travail, ils consid`erent que l’ordonnanceur choisira le prochain thread `a ex´ecuter suivant une distribution de probabilit´e uniforme. Dans ce cas, la non-interf´erence possibiliste n’est pas suffisante. Ils utilisent ici une ap-proche diff´erente de la pr´ec´edente qui pour restaurer la non-interf´erence, a dˆu imposer la condition contraignante de ne pas permettre des gardes de condi-tionnelles de niveau de s´ecurit´e ´elev´e high. Ils imposent plutˆot de transformer les conditionnelles ayant une garde de niveau high en commandes atomiques, grˆace `a une nouvelle commande protect. Cela correspond en fait `a faire fonc-tionner le thread en exclusion mutuelle jusqu’`a la fin de la conditionnelle. En r´ealit´e, un nouveau type de flot d’information non s´ecuritaire qui survient avec les ordonnanceurs probabilistes est celui li´e au temps d’ex´ecution des commandes. Ils d´emontrent par la suite que les programmes “prot´eg´es” bien typ´es dans le syst`eme respectent la non-interf´erence probabiliste 5.

nou-veau typage des commandes qui est identique `a celui qu’il pr´esente dans [45] et que nous avons pr´ealablement mentionn´e. C’est `a dire que les commandes sont typ´ees plutˆot :

τ1 cmd τ2 | τ cmd n

Ce nouveau typage permet d’imposer des restrictions plus pr´ecises concernant la fuite d’information li´ee au temps d’ex´ecution de la commande. Ainsi les conditionnelles avec une garde de niveau de s´ecurit´e ´elev´e high, ne sont plus syst´ematiquement rejet´ees. Il ne faut rejeter que celles qui sont imm´ediatement suivies par une affectation `a une variable de niveau de s´ecurit´e publique, low. De ce fait, un thread ne manipulant que des variables de niveau de s´ecurit´e ´

elev´e high, est toujours consid´er´e s´ecuritaire.

Pottier [35] adopte une m´ethode syntaxique pour traiter la non-interf´erence dans une situation de concurrence de threads . Il choisit d’´etendre le π-calcul de Milner [30] avec des ´etiquettes de s´ecurit´e et nomme le nouveau langage hπi-calcul. Ce langage d´ecrit l’ex´ecution ind´ependante d’une paire de processus, tout en gardant une trace des sous-processus qu’ils partagent. Son approche pour ´etablir la non-interf´erence consiste `a r´eduire celle-ci `a une simple pro-pri´et´e de r´eduction du langage. C’est une bisimulation faible qui stipule que l’´elimination de sous-termes ayant une ´etiquette de s´ecurit´e de niveau ´elev´e n’est pas visible par un observateur public. Notons que ce travail ´etudie plutˆot la non-interf´erence possibiliste 4 et pas celle probabiliste5.

C - Canaux cach´es.

Les canaux cach´es sont des vecteurs d’information, au sein d’un syst`eme infor-matique, par le biais de m´ecanismes qui `a la base ne sont pas cens´es fonctionner comme des canaux d’information. Certains flots d’information implicites sont des exemples de canaux cach´es li´es au stockage de l’information. Ils sont parfois plus difficiles `a d´etecter. C’est le cas des flots d’information caus´es par des d´ependances existantes entre des donn´ees sensibles et le temps d’ex´ecution ou le comportement probabiliste d’un programme.

Canaux li´es `a la terminaison : Supposons qu’un attaquant puisse d´etecter la terminaison (ou non-terminaison) du programme suivant :

while h = 1 do skip

C’est un cas de flot d’information implicite car cela nous renseigne sur la va-leur de la variable secr`ete h. Volpano et Smith [49] s’int´eressent `a ce type de flots d’information implicites. L’id´ee principale de leur travail est d’imposer

que les constructions bien typ´ees aient le niveau de s´ecurit´e minimum. Une nouvelle commande try est introduite pour analyser les cas de lancement d’exception comme une division par z´ero, par exemple. La commande try ne poss`ede pas un bloc catch pour attraper l’exception qui serait ainsi lanc´ee. En fait les valeurs enti`eres sont les seules valeurs possibles. Leur d´ emonstra-tion de la non-interf´erence est faite en trois ´etapes. La premi`ere est appel´ee accord de terminaison. Elle correspond `a stipuler que si deux ex´ecutions d’un programme ont les mˆeme valeurs pour les variables de niveau minimum en m´emoire, alors si l’ex´ecution de l’une ne se termine pas, il en sera de mˆeme pour l’ex´ecution de la seconde. Dans le cas o`u les deux ex´ecutions arrivent `a terme, alors les m´emoires produites par les deux ex´ecutions contiennent les mˆeme valeurs pour les variables de niveau minimum. Par la suite, ils disent que l’accord de terminaison est une contrainte trop faible et qu’elle ne traite pas les cas o`u l’une des ex´ecution ne se termine pas, alors que l’autre se termine de fa¸con anormale (`a cause du lancement d’une exception). Ils en arrivent `a une nouvelle notion, qu’ils nomment la progression mutuelle. Elle correspond `a dire que pour deux ex´ecutions du mˆeme programme `a partir de deux m´emoires qui sont identiques pour les variables de niveau minimum, si l’une des ex´ecutions ne peut arriver `a terme, alors en il en sera de mˆeme forc´ement pour la seconde. En somme si l’une des ex´ecution peut progres-ser, il faut qu’il en soit de mˆeme pour l’autre. Finalement ils montrent que la progression mutuelle n’est pas vraiment suffisante car elle ne permet pas d’imposer aux deux ex´ecutions du mˆeme programme d’atteindre leur ´etat de terminaison (ou non-terminaison dans le mˆeme temps). La troisi`eme notion qu’ils introduisent est donc un accord de temps d’ex´ecution. Mais pour pou-voir l’assurer, des restrictions importantes ont dˆu ˆetre impos´ees. Ainsi, toutes les conditionnelles doivent aussi avoir un type minimal, les boucles ne pouvant ˆ

etre de niveau de s´ecurit´e ´elev´e.

Abadi et al. [1] identifient un point commun entre une analyse de la s´ecurit´e d’un programme, une analyse dite binding-time analysis, le suivi des appels de fonctions et le d´ecoupage de programme (Program slicing). L’objectif de l’analyse dite binding-time analysis est de s´eparer dans un programme ce qui peut ˆetre ´evalu´e statiquement de ce qui ne peut l’ˆetre que dynamiquement. Le point commun `a toutes ces analyses est qu’elles identifient des propri´et´es de d´ependance. Elles expriment ces d´ependance avec des Relations d’´Equivalence Partielles (PER) pour un langage qui est une variante du λ-calcul. Ce langage

est nomm´e le DCC (Dependency Core Calculus). Leur m´ethode consiste `a traduire chacune de ces analyses en DCC. Ils traduisent ainsi le syst`eme de type de Volpano et Smith [46] en DCC et d´emontrent la non-interf´erence.

Canaux li´es au temps d’ex´ecution : En fait les canaux li´es `a la terminaison peuvent ˆetre consid´er´es comme une instance des canaux li´es au temps d’ex´ e-cution. Car en pratique, on ne peut faire la diff´erence entre la non-terminaison et une ex´ecution qui prend ´enorm´ement de temps. Mˆeme si plusieurs facteurs peuvent rendre ce type de canaux tr`es peu efficaces, il ne faut pas les n´ egli-ger. Un exemple bien int´eressant montre que certaines impl´ementations de l’Algorithme RSA permettent une fuite d’information concernant la clef de cryptage, du fait de leur comportement en fonction du temps. En effectuant un certain nombre de cryptages et en ´evaluant leur temps d’ex´ecution, l’atta-quant pourrait deviner la clef enti`ere.

Agat [3] propose une approche pour supprimer les canaux cach´es li´es au temps d’ex´ecution des programmes. Cette approche se sert d’une technique de trans-formation de programme. Il pr´esente un syst`eme de types et un algorithme de transformation s’appuyant sur le typage. Cette transformation supprime les canaux cach´es des programmes afin de les rendre s´ecuritaires par rapport `

a une condition de s´ecurit´e bas´ee sur la s´emantique qui est exprim´ee comme une bisimulation. La transformation peut ˆetre repr´esent´ee comme un syst`eme de types avec des mises `a jour de type de la forme : C ,→ C₁0 : Sl.

Avec C, le programme original, C0 le r´esultat de la transformation et Sl, la tranche de bas niveau de C0. C0 et C sont s´emantiquement ´equivalents, en effet ils effectueront la mˆeme s´equence d’outputs et d’assignations aux variables globales . La diff´erence entre Sl et C0 est que dans Sl, les sous-commandes de C0 qui manipulent des donn´ees de niveau de s´ecurit´e ´elev´e, sont remplac´ees par des commandes al´eatoires sans effet sur les variables de niveau ´elev´e. Cela permet de conserver la relation d’´equivalence entre Sl et C0 par rapport aux variables de niveau de s´ecurit´e bas. L’analyse du programme C se conclut soit par le rejet direct de celui-ci (dans le cas de flot d’information implicites ou explicites), soit `a son acceptation suivie de sa transformation pour en retirer ´eventuellement toutes possibilit´es de flot d’information li´e au temps d’ex´ecution. Le syst`eme de types puis de transformation pourrait se r´esumer en la r`egle suivante :