L’analyse dynamique est une analyse qui se fait lors de l’ex´ecution du programme. L’approche adopt´ee par celle-ci est de contrˆoler l’action des programmes par le biais de tests pr´ecis pendant l’ex´ecution pour s’assurer que l’ex´ecution courante du programme respecte la politique de s´ecurit´e choisie.
Cette analyse a l’avantage d’ˆetre pr´ecise, dans la mesure o`u elle ne rejette que les ex´ecutions erron´ees du programme. Aucune ex´ecution correcte ne sera rejet´ee de fa¸con conservatrice. Elle empˆeche l’ex´ecution d’une action suspecte juste avant son ex´ecution et ne peut pr´evoir celle-ci avant qu’elle ne survienne. Il faut mentionner que cette analyse s’effectuant lors de l’ex´ecution, elle rajoute une charge suppl´ementaire d’ex´ecution qui peut repr´esenter une charge importante qui n’est pas celle li´ee `a la s´emantique du programme initial. En outre, si elle ne se sert pas de r´esultats d’analyses statiques, elle souffre ´egalement de limitations notamment pour ce qui est li´e aux propri´et´es de vivacit´e.
Trois m´ethodes existent pour impl´ementer un analyseur dynamique : la premi`ere est l’utilisation d’un moniteur qui intercepte tout appel de fonctions critiques, la deuxi`eme qui est l’encapsulation consiste `a modifier les fonctions syst`eme pour s’assurer que les propri´et´es de s´ecurit´e sont respect´ees. Une version s’assurant des politiques de s´ecurit´e est produite pour remplacer l’originale. Enfin la troisi`eme qui est l’instrumentation du code. Elle consiste `a rajouter du code au code initial pour s’assurer du respect de la politique de s´ecurit´e. Le code rajout´e consiste en des tests ou encore des actions suppl´ementaires pour s’assurer que la politique est respect´ee. On pourrait par exemple rajouter du code pour s’assurer que le programme apr`es avoir lu sur un port, ferme bien celui-ci.
2.4.1
Le monitorage
De fa¸con g´en´erale, le monitorage de programme consiste `a surveiller celui-ci lors de son ex´ecution. Par la suite on peut instantan´ement r´eagir en empˆechant l’action concer- n´ee ou tout le programme. Le monitorage en lui-mˆeme, n’implique pas forc´ement de r´eagir instantan´ement. Ainsi nous pouvons citer les outils d’enregistrement de tˆaches effectu´ees par une application et mˆeme les d´ebogueurs comme des outils de monitorage. Un outil important de monitorage du type d’enregistreur de tˆaches d’application est
celui d´evelopp´e dans le cadre du projet LTTng (linux trace toolkit). Ce projet a permis une r´e´ecriture de linux en permettant un enregistrement de tous les appels de fonctions critiques du noyau linux5. Les d´ebogueurs sont ´egalement un outil de monitorage for- tement utilis´es par les d´eveloppeurs d’application pour tester ceux-ci. Un moniteur qui v´erifie des politiques de s´ecurit´e en g´en´eral est plac´e de telle sorte qu’il intercepte les dif- f´erents appels par un programme de fonctions du noyau. Son rˆole alors est de s’assurer que l’action souhait´ee viole la politique de s´ecurit´e. Si c’est le cas selon le choix d’impl´e- mentation il peut, le cas ´ech´eant arrˆeter compl`etement l’ex´ecution du programme soit arrˆeter seulement l’action concern´ee. Si ce n’est pas le cas, il transmet l’appel au noyau pour l’ex´ecution de l’action. Comme exemple nous pouvons citer les parefeux (firewalls) permettant de faire respecter la politique de s´ecurit´e du r´eseau, celle-ci d´efinissant quels sont les types de communication autoris´es sur ce r´eseau informatique.
2.4.2
L’encapsulation
Cette approche consiste `a r´e´ecrire les fonctions syst`emes (en l’occurrence celles dont l’utilisation pose un probl`eme de s´ecurit´e), pour leur ajouter des tests qui s’assure- ront lors de l’ex´ecution du respect des politiques de s´ecurit´e en question. Une nouvelle version du code est ainsi produite dans laquelle la version originale est enti`erement en- capsul´ee par des tests. La difficult´e de cette approche est qu’en g´en´eral il faut r´e´ecrire le programme pour chaque politique de s´ecurit´e souhait´ee.
Un exemple de l’utilisation de cette approche est le projet Naccio, Evans et Twyman [14] du MIT. L’objet de ce projet est d’offrir un outil qui permet de sp´ecifier dans un langage de haut niveau des politiques de s´ecurit´e ; puis de fournir le programme qu’on aimerait encapsuler et cet outil fournit une nouvelle version du programme qui encapsule l’originale en des tests qui respectent la politique de s´ecurit´e, et ce, sans se pr´eoccuper de la plateforme sur laquelle sera ex´ecut´e le programme. L’outil a ´et´e con¸cu pour permettre l’encapsulation de programmes, aussi bien pour la machine virtuelle de Java que pour une plateforme Win32.
Pour traduire la politique de s´ecurit´e, le g´en´erateur de politiques de Naccio requiert que l’utilisateur entre la description abstraite des ressources syst`emes utiles, la politique de s´ecurit´e qui stipule comment les ressources doivent ˆetre manipul´ees, l’interface de la plateforme cible qui dit comment ses appels syst`emes manipulent les ressources. Enfin il doit aussi fournir la biblioth`eque de la plateforme comme les API des classes Java.
Figure 2.6 – Architecture de Naccio.
Le g´en´erateur produit alors une version de la biblioth`eque de la plateforme qui inclut du code de contrˆole n´ecessaire `a la v´erification de la politique. Il produit ´egalement un fichier de description de la politique qui inclut des r`egles de r´e´ecriture n´ecessaires pour appliquer la politique. Le module de r´e´ecriture d’applications prend le programme source et le fichier de description de la politique et va finalement transformer le code pour l’amener `a appeler les m´ethodes transform´ees de la biblioth`eque de la plateforme `
a la place de celles dans la version originale. L’ex´ecution du programme se fait alors de fa¸con conforme `a la politique de s´ecurit´e. Comme politique, on pourrait empˆecher d’´ecrire dans un certain fichier plus d’un certain nombre d’octets. L’architecture de Naccio est pr´esent´ee `a la figure 2.6.
2.4.3
L’instrumentation de code.
L’instrumentation de code ou r´e´ecriture correspond aux techniques qui modifient un programme avant son ex´ecution. Ici, la modification peut aller au del`a de l’ajout de simples tests et peut ˆetre mˆeme un ajout d’actions qui permettent le respect d’une certaine politique de s´ecurit´e.
Cette technique a ´et´e utilis´ee par exemple par Erlingsson et Schneider [13] pour SASI (Security Automata SFI Implementation). L’objectif de ce projet est de permettre l’in- sertion dans le code original d’un moniteur de r´ef´erence qui arrˆete le programme lorsque la politique de s´ecurit´e est viol´ee. Un moniteur de r´ef´erence est un moniteur qui sur- veille l’ex´ecution du programme cible et l’arrˆete d`es que celui-ci est sur le point de violer la politique de s´ecurit´e. Le moniteur de r´ef´erence ins´er´e est en fait un automate de s´ecurit´e. Celui-ci a la capacit´e d’arrˆeter l’ex´ecution du programme si la politique de s´ecurit´e n’est pas respect´ee. Par exemple, on pourrait repr´esenter la propri´et´e qui dit qu’aucune action de lecture ne doit ˆetre suivie par un envoi de message, par l’auto- mate de la figure 2.7. L’insertion de l’automate de s´ecurit´e dans le code source se fait en quatre ´etapes. Premi`erement on ins`ere une copie de l’automate de s´ecurit´e apr`es chaque instruction du code cible. Ensuite on ´evalue tous les pr´edicats de transitions possibles, ´etant donn´e l’instruction du programme cible suivante. Ensuite, il faut sim- plifier l’automate en supprimant les pr´edicats de transition s’´evaluant `a faux. Enfin il faut traduire l’automate r´esiduel en code qui est plac´e aux endroits appropri´es de telle sorte que le programme simule les op´erations de l’automate de s´ecurit´e. Une action “Fail” est utilis´ee au besoin pour arrˆeter le syst`eme si l’automate doit rejeter une ac- tion. La figure2.7 pr´esente ´egalement le code instrument´e correspondant `a l’automate de s´ecurit´e pr´ec´edent. Il faut noter que SASI a eu deux impl´ementations : une pour la plateforme x86 de processeurs, mais aussi pour la machine virtuelle Java. SASI prend en compte certains aspects s´ecuritaires qui empˆechent le programme cible d’attaquer le code instrument´e. Ces aspects sont : empˆecher le programme d’utiliser des variables sensibles utilis´ees par l’automate de s´ecurit´e, empˆecher le programme cible de contour- ner le code impl´ementant les transitions de l’automate de s´ecurit´e, empˆecher le syst`eme cible de s’automodifier ou d’invoquer du code externe non contrˆol´e.
La technique d’instrumentation de code a ´et´e ´egalement utilis´ee par de Oliveira et al. [10]. Plus pr´ecis´ement elle a ´et´e utilis´ee pour la r´e´ecriture de politiques de contrˆole d’acc`es. Il faut noter que l’objectif est de produire un moniteur de r´ef´erence qui sera ins´er´e dans le code pour s’assurer du respect de la politique. Une politique de contrˆole d’acc`es ´etant d´efinie comme un quintuple : (F, D, R, Q, ζ). Avec : F : une signature qui contient le vocabulaire de la structure de donn´ee comme les objets, les sujets, les requˆetes, les d´ecisions.
D : un ensemble non vide de termes ne comportant pas de variables de F, qui repr´esente les d´ecisions possibles (permis, refus´e, nonApplicable).
gnature, pour permettre d’exprimer la politique.
Q : un ensemble de termes ne comportant pas de variables de F pour d´ecrire la forme des requˆetes acceptables.
ζ : est une strat´egie de r´e´ecriture pour R, afin d’orienter l’application des r`egles. C’est Tom6, une extension de Java qui ajoute `a Java la possibilit´e de r´e´ecriture de code
qui sert `a exprimer en java la politique souhait´ee. Ainsi on ´ecrit en code Java, la poli- tique de s´ecurit´e en d´efinissant le vocabulaire et les r`egles de la politique. La politique ne d´efinit pas comment le syst`eme ´evolue mais si les transitions de celui-ci sont permises ou pas. L’´etat courant de l’application est ´ecrit comme un terme, qui est modifi´e le long de son ex´ecution. Chaque fois que l’application ex´ecute une action qui concerne la po- litique, ce terme est ´evalu´e afin de prendre une d´ecision d’acc`es en appliquant les r`egles de r´e´ecriture qui d´efinissent la politique. La programmation orient´ee aspect Kiczales et al. [23] est exploit´ee grˆace `a AspectJ [22]. En se servant de cette forme de program- mation, on identifie les points du programme qui touchent `a la politique de s´ecurit´e, comme les appels de fonctions qui n´ecessitent de contrˆoler le respect de la politique de s´ecurit´e. Pour chacun de ces points on con¸coit le code appropri´e qui pourrait consister par exemple `a noter des informations sensibles comme l’entit´e qui essaie d’acc´eder `a l’information. La derni`ere ´etape consiste `a ins´erer dans le code cible le code appropri´e pr´ealablement con¸cu qui servira de moniteur de r´ef´erence ins´er´e dans le programme de base par instrumentation. L’architecture g´en´erale du syst`eme est repr´esent´ee `a la figure
2.8.
Il est bien souvent ardu de sp´ecifier clairement `a laquelle des trois m´ethodes d’impl´e- mentation, pr´esent´ees pr´ec´edemment, un moniteur donn´e appartient. Par exemple, un programme instrument´e qui se comporte comme un moniteur ou qui exploite mˆeme des r´esultats de l’analyse statique pourrait ˆetre difficilement class´e. Une solution possible `
a ce probl`eme est de faire la classification suivant plutˆot les propri´et´es qu’il permet d’appliquer. Schneider [42] introduit pour la premi`ere fois cette m´ethode de classifica- tion de moniteurs en fonction des politiques qu’ils peuvent appliquer. Il d´efinit ainsi un automate de s´ecurit´e, celui-ci sera ´etendu par Ligatti et al. [27] et une nouvelle forme d’automate. Nous pr´esenterons ces deux approches. Mentionnons qu’il en existe d’autres comme celles de Fong [15] et celle de Talhi et al. [47].
Figure 2.7 – Exemple d’automate de s´ecurit´e et instrumentation associ´ee.
Analyse statique versus analyse dynamique.
Historiquement, les techniques dynamiques ont ´et´e les pionni`eres dans le domaine de l’analyse de flot d’information durant les ann´ees 70. On peut citer entre autres, Wulf et al. [53]. Ces techniques contrˆolent les flots d’information explicites. Certaines contrˆolent aussi les flots d’information implicites en assurant qu’il n’y ait pas d’effets de bord (fuites d’informations) dans un contexte priv´e. [11] en est un exemple. En g´en´eral, ces travaux ne pr´esentent pas une preuve de coh´erence de leur approche. Dans leur tra- vail majeur, Denning et Denning [11] proposent une approche statique pour l’analyse de flot d’information. Ils pr´esentent l’atout de l’analyse statique qui est de supprimer la surcharge d’ex´ecution li´ee aux v´erifications de s´ecurit´e. Cette analyse empˆeche sta- tiquement aussi bien les flots d’information explicites qu’implicites. Ces derniers sont
Figure 2.8 – Architecture du syst`eme de r´e´ecriture de politiques d’acc`es.
empˆech´es en assurant qu’aucune affectation `a une variable publique n’est permise dans un contexte priv´e. Volpano et al. [48] d´emontrent la coh´erence du syst`eme de Denning en d´emontrant la non-interf´erence non sensible `a la terminaison du programme. Cette forme de non-interf´erence assure qu’en d´emarrant l’ex´ecution `a partir de deux m´emoires qui s’accordent sur les donn´ees publiques, deux ex´ecutions du programme qui vont jus- qu’`a terme, produisent ´egalement deux m´emoires finales qui s’accordent sur les donn´ees publiques.
Les ann´ees 90 connurent l’h´eg´emonie des techniques statiques. Le reproche fait princi- palement aux techniques dynamiques est qu’elles ne sont pas suffisamment s´ecuritaires. En effet, le fait d’analyser une seule ex´ecution ne permet pas de surveiller les ´even- tuels effets de bord publics qui peuvent subvenir dans les autres ex´ecutions. On note r´ecemment un regain d’int´erˆet pour les techniques dynamiques du fait qu’elles offrent une plus grande permissivit´e que les techniques statiques. Car certaines informations
hskip, mi−−→ hstop, minop m(e) = v hx := e, mi−−−−→ hstop, m[x 7→ v] ia(x,e) hc1 , mi α −→ hstop, m0i hc1;c2 , mi α −→ hc2, m0i hc1 , mi α −→ hc0 1, m0i c016= stop hc1;c2 , mi α −→ hc0 1; c2, m0i m(e) 6= 0 h if e then c1 else c2, mi b(e) −−→ hc1; end, mi m(e) = 0 h if e then c1 else c2, mi b(e) −−→ hc2; end, mi m(e) 6= 0
h while e do c , mi−−→ hc; end; while e do c , m ib(e)
m(e) = 0
h while e do c , mi−−→ hend, mib(e) hend, mi−→ hstop, mif
Table 2.5 – S´emantique des commandes.
ne sont disponibles que lors de l’ex´ecution pour d´ecider effectivement si une ex´ecution est s´ecuritaire. Par d´efaut d’information, l’analyse statique prend souvent une d´ecision conservatrice et rejette le programme. Sabelfeld et Russo [40] d´emontrent qu’il est pos- sible avec une analyse purement dynamique insensible au flot d’information, d’assurer la mˆeme politique de s´ecurit´e qu’une analyse statique du style Denning et Denning [11] peut assurer, `a savoir la non-interf´erence insensible `a la terminaison. La fuite d’in- formation du fait de la terminaison de programme survient dans des cas de boucles. Par exemple, en observant la terminaison du programme while secret do skip, on peut d´eduire la valeur de secret `a cet instant qui est 0. Les analyses statiques du style de Den- ning et Denning [11] ne peuvent empˆecher ce type de flot d’information. Ces analyses ne peuvent donc assurer que la non-interf´erence insensible `a la terminaison. Les moniteurs surveillent l’ex´ecution des instructions `a un moment donn´e pour garantir les propri´et´es de s´ecurit´e. Avant d’ˆetre ex´ecut´ees, les instructions sont observ´ees par le moniteur pour ´
evaluer si elles sont assez s´ecuritaires dans un contexte donn´e. Lorsqu’une instruction est non s´ecuritaire, le moniteur peut avoir diverses r´eactions : bloquer l’ex´ecution du programme ou transformer l’instruction non s´ecuritaire en une s´ecuritaire.
Pr´esentons l’analyse de Sabelfeld et Russo [40] qui d´emontre qu’une analyse dynamique insensible au flot assure le mˆeme type de non-interf´erence qu’une analyse statique du style de Denning et Denning [11]. La figure 2.5 pr´esente la s´emantique d’un langage imp´eratif simple. Les configurations sont de la forme hc, mi, avec c une commande et m une m´emoire associant des valeurs `a des variables. Les r`egles s´emantiques sont de la
st−−→ stnop lev(e) v Γ(x) lev(st) v Γ(x) st−−−−→ sta(x,e)
st−−→ lev(e) : stb(e) hd : st−→ stf
Table 2.6 – R`egles de transition du moniteur.
forme hc, mi−→ hcα 0, m0i. Si une transition conduit `a une configuration avec la commande sp´eciale stop et une certaine m´emoire m, alors on dit que l’ex´ecution se termine en m. La commande stop ne provoque pas de transition. La commande sp´eciale correspond `a la sortie d’une port´ee de conditionnelle if ou while. Par souci de simplicit´e, ce langage ne g´en`ere que des expressions enti`eres simples (c’est-`a-dire les constantes, les op´era- tions binaires, les variables). La s´emantique des expressions est standard. Le r´esultat de l’´evaluation de l’expression dans la m´emoire m est not´e m(e). Les r`egles sont d´eco- r´ees d’´ev´enements α pour communiquer les ´ev´enements du programme `a un moniteur d’ex´ecution. L’´ev´enement nop signale que le programme effectue un skip. L’´ev´enement a(x, e) informe que le programme affecte la valeur de e dans la m´emoire courante `a la variable x. L’´ev´enement b(e) indique que le programme effectue un branchement condi- tionnel sur l’expression e. Enfin, l’´ev´enement f est g´en´er´e lorsque l’ex´ecution du corps d’un branchement conditionnel (if ou while) arrive `a terme.
Soit cfg, cfg0, ... les configuration de commandes et cfgm, cfgm0, ... les configurations de moniteur. Dans leur analyse, les auteurs pr´esentent les configurations de moniteur comme de simples piles de niveaux de s´ecurit´e. Le moniteur est un param`etre de la s´emantique et il est d´ecrit par les transitions entre configurations de moniteur. La r`egle pour une ex´ecution surveill´ee par un moniteur est :
cfg −→ cfgα 0 cfgm −→α
µ cfgm0
hcfg |µ cfgmi −→ hcfg0 |µ cfgm0i
La figure 2.6 pr´esente le moniteur µ1 . Ce moniteur accepte un ´ev´enement g´en´er´e par
le programme ou bien le bloque en n’effectuant plus de transition. La configuration du moniteur est une pile de niveaux de s´ecurit´e, qui sert `a garder une trace du contexte de s´ecurit´e courant, c’est-`a-dire les niveaux de s´ecurit´e des gardes de branchements conditionnels visit´es par l’ex´ecution courante. Ceci correspond `a une adaptation dyna- mique de la notion de program counter pc. L’´ev´enement nop, g´en´er´e par une commande skip, est toujours accept´e sans changement `a l’´etat du moniteur. L’´ev´enement a(x, e), g´en´er´e par une affectation, est accept´e sans changement `a l’´etat du moniteur mais `a
deux conditions. Premi`erement, le niveau de s´ecurit´e de l’expression e ne doit pas ˆetre plus ´elev´e que celui de la variable x. Deuxi`emement, le niveau de s´ecurit´e le plus ´elev´e dans la pile de contexte (not´e lev(st) pour la pile st) ne doit pas ˆetre plus ´elev´e que le niveau de s´ecurit´e de la variable x. La premi`ere condition sert `a empˆecher les flots d’information explicites, quant `a la seconde elle sert `a empˆecher les flots implicites. Les