Dans le contexte de l’application de la sécurité des logiciels, l’efficacité des automates d’édition repose essentiellement sur leur capacité à simuler les actions potentiellement dan- gereuses et à différer leur exécution jusqu’à l’identification d’une séquence valide d’actions. Cependant, il existe quelques actions qui ne peuvent être simulées. En effet, cette faiblesse est clairement mentionnée et reconnue dans [73,74]. En outre, la simulation des actions de- vrait être effectuée d’une manière correcte et transparente. La correction signifie que toutes les exécutions de la nouvelle version du programme réécrit satisfaisant une propriété de sé- curité doivent appartenir à sa version originale. La transparence veut dire que toute exécution valide par rapport à une propriété de sécurité donnée doit être préservée par l’application de cette propriété. Par conséquent, la satisfaction de la correction et de la transparence par un mécanisme de sécurité basé sur la réécriture est impérativement conditionnée par le maintien du programme dans un état cohérent par rapport à sa sémantique d’origine.
Dans ce qui suit, nous montrons comment la simulation (suppression dans le contexte d’édition) des actions, lorsqu’elle est effectuée par un moniteur d’exécution, peut violer les critères de correction et de transparence. Pour les deux cas présentés, nous montrons égale- ment comment la réécriture de programmes réussit à corriger la situation.
BEGIN 1: x := 3; 2: y := 4; 3: If (x>1) then 4: inc(y); 5: If (y>4) then 6: send(y); END
FIGURE5.1 – Programme P - Version A -
BEGIN 1: x := 3; 2: y := 4; 3: If (x>1) then 4: If (y+1>4) then{ 5: inc(y); 6: send(y); 7: }
6: Else If (y>4) then
8: send(y);
END
FIGURE 5.2 – Programme P - Version B -
5.2.1
Violation de la transparence
Soit φ1 la propriété qui décrit le fait que toute action inc incrémentant la valeur d’une
variablex devrait être immédiatement suivie par l’action send consistant à envoyer la valeur
de cette même variable. L’expression régulièreLφ1 spécifiant la propriétéφ1est la suivante :
Lφ1 = {((¬inc(x))
∗inc(x).send(x))∗}
La propriétéφ1 n’est pas une propriété de sûreté (pour une propriété de sûreté, les mau-
vaises traces d’exécution ne peuvent jamais être prolongées pour devenir valides) car la trace composée de l’action unique inc(x) est non valide. Néanmoins, elle peut être étendue en
lui concaténant l’action send(x) pour devenir valide. De même, cette propriété n’est pas
BEGIN 1: x := 3; 2: y := 4; 3: If (x>1) then 4: inc(y); 5: If (y <= 4) then 6: send(y); END
FIGURE5.3 – Programme P’ - Version A -
peuvent être toujours prolongées pour devenir valides) puisque la traceinc(x).a ne peut être
prolongée pour former une trace valide lorsque l’actiona 6= send(x).
Nous supposons que le moniteur d’exécution spécifiant la propriétéφ1 intercepte les ac-
tions du programmeP (Version A) listé dans la figure5.1. Selon les exigences de la propriété
φ1, à l’interception de l’action inc(y) (ligne 4-figure 5.1), le moniteur d’exécution ne doit
pas accepter une telle action et la laisser s’exécuter, du moment qu’il ignore la structure du programmeP . Par conséquent, il doit la supprimer. Néanmoins, puisque l’action inc(y) n’a
pas été exécutée, alors l’actionsend(y) (ligne 6-figure5.1) ne peut pas être exécutée vu que
y = 4 (valeur initiale), ce qui ne satisfait pas la condition de déclenchement y > 4 (ligne
5-figure5.1). Dans ce cas, on voit clairement que le moniteur d’exécution a empêché l’exé- cution d’une séquence valide. Ceci est à l’encontre de la propriété de transparence que doit observer tout mécanisme de sécurité qui cible une application effective des propriétés de sécurité.
Ce problème ne peut être résolu sans la modification du corps du programme (réécriture ou instrumentation). Une solution possible à cette situation consiste à réécrire le programme selon la version B listée dans la figure5.2. Dans cette nouvelle version du programmeP , dans
le cas où la condition déclenchant l’incrémentation dey est vraie, c.à.d. x > 1 (ligne 3-figure
5.2), l’exécution de l’action incrémentanty (inc(y)) est différée (ligne 5-figure5.2) jusqu’à ce que la condition de l’envoi dey soit satisfaite, c.à.d. y > 4 (ligne 4-figure5.2). Cependant, comme la condition y > 4 est censée être testée sur la valeur de y après l’incrémentation,
nous avons modifié cette condition de sorte qu’elle manipule y + 1 au lieu de y (donc la
condition devienty + 1 > 4 au lieu de y > 4). Cela permet d’assurer la cohérence du test
sans compromettre pour autant l’intégrité du programme, puisque nous n’avons pas modifié la valeur de la variable y. En d’autres termes, nous avons simulé l’incrémentation sur les
5.2.2
Violation de la correction
Dans cet exemple, on suppose que le moniteur d’exécution appliquant la propriété φ1,
spécifiée ci-haut, intercepte les actions du programmeP′(Version A) listé dans la figure5.3.
Le programmeP′ est une variante du programmeP , en remplaçant la condition “y > 4” par
“y <= 4” (voir ligne 5).
Selon les exigences de la propriétéφ1, à l’interception de l’actioninc(y) (ligne 4-figure
5.3), le moniteur d’exécution doit supprimer cette action. Néanmoins, puisque l’actioninc(y)
n’a pas été exécutée, alors l’actionsend(y) (ligne 6-figure5.3) sera générée durant l’exécu- tion puisque la condition “y <= 4” est vérifiée sur la valeur non incrémentée de y (va-
leur égale à 4). À cette étape de l’exécution, le moniteur reconnaît une séquence valide (inc(y).send(y)) et donc permet son exécution. Cependant, la séquence inc(y).send(y) n’est
pas une exécution possible du programmeP′, en considérant les valeurs initiales dex, y. Dans
ce cas, on voit clairement que le moniteur a permis l’exécution d’une séquence valide selon la propriété φ1 mais qui n’appartient pas aux exécutions possibles du programme contrôlé
P′. Cette situation viole la propriété de correction qui exige que toutes les séquences valides
émises par le moniteur d’exécution appartiennent à la sémantique du programme à contrôler. Une fois de plus, ce problème ne peut être résolu sans la modification du corps du pro- gramme (réécriture). Une solution possible consiste à réécrire le programme selon la version B listée dans la figure 5.4. Dans cette nouvelle version du programme P′, dans le cas où
la condition déclenchant l’incrémentation de y est vraie, c.à.d. x > 1 (ligne 3-figure 5.4), l’exécution de l’action incrémentanty (inc(y)) est différée (ligne 5-figure5.4), jusqu’à ce que la condition de l’envoi de y soit satisfaite, c.à.d. y <= 4 (ligne 4-figure 5.4). Cependant, comme la conditiony <= 4 est censée être testée sur la valeur de y après l’incrémentation,
nous avons modifié cette condition de sorte qu’elle manipuley + 1 au lieu de y. Comme nous
l’avons montré dans l’exemple précédent, cette manipulation des conditions du programme garantit la validité du test sans affecter la sémantique du programme d’origine.
5.2.3
Nos contributions
Les deux exemples que nous venons de présenter mettent en évidence les limites de l’ap- plication de la sécurité par monitorage d’exécution. Ils montrent également comment la ré- écriture de programmes réussit à assurer des propriétés de sécurité que les moniteurs d’exé- cution ne seraient capables d’appliquer sans compromettre la sémantique des programmes.
BEGIN 1: x := 3; 2: y := 4; 3: If (x>1) then 4: If (y+1<=4) then{ 5: inc(y); 6: send(y); 7: }
6: Else If (y<=4) then
8: send(y);
END
FIGURE 5.4 – Programme P’ - Version B -
nismes de sécurité basés sur la réécriture de programmes. Nous traitons particulièrement la simulation des effets des actions supprimées sur les conditions des programmes. Notre ap- proche de réécriture de programmes permet d’appliquer d’une manière effective les propriétés spécifiables par les automates d’édition. Nous ciblons principalement l’application de n’im- porte quelle propriété de sécurité portant sur des séquences finies. On entend par application effective le fait de satisfaire deux critères cruciaux : la correction et la transparence. Le mode d’application que nous adoptons dans notre approche consiste à supprimer toutes les actions critiques interceptées par l’automate d’édition, et ce, jusqu’à ce qu’il puisse confirmer que le préfixe résultant respecte la propriété à appliquer. À ce moment, il insérera toutes les actions supprimées auparavant dans le même ordre de leur interception.
En adoptant le même concept d’intégration efficace des moniteurs décrit dans le cha- pitre précédent, l’approche que nous proposons est basée sur un opérateur de composition plus élaboré opérant sur les machines à états finis étendues MEFEs (Extended Finite State Machines en anglais). En effet, notre technique nous permet de simuler les actions d’une ma- nière transparente au système, il s’agit d’une question stimulante qui n’a pas été traitée par les travaux précédents. D’une façon sommaire, étant donnés un programme non fiable et un automate d’édition spécifiant une propriété de sécurité, il s’agit de produire une nouvelle ver- sion du programme (équivalente au programme d’origine) satisfaisant la propriété de sécurité à appliquer.