• Aucun résultat trouvé

Caractérisation selon la théorie de la calculabilité

3.8.1

Présentation

Dans [51], Hamlen, Morrisett, et Schneider proposent une nouvelle taxonomie de poli- tiques de sécurité applicables par les mécanismes de sécurité. Il s’agit d’une classification plus générale que celle établie par Ligatti et al. En effet, Hamlen et al. ont exploré une plus grande classe de mécanismes de sécurité et ne se sont pas contentés de classer les po- litiques applicables seulement par monitorage d’exécution. Les mécanismes considérés par cette contribution sont répartis en trois catégories : l’analyse statique, le monitorage d’exé- cution (sans considérer les contraintes sur l’historique), et la réécriture de programmes. Les auteurs ont connecté leur taxonomie à la hiérarchie arithmétique de la théorie de la calcula- bilité. Ils ont principalement abouti aux trois résultats suivants :

– Les politiques de sécurité statiquement applicables correspondent aux propriétés récur- sivement décidables.

– La classe de politiques applicables par monitorage d’exécution est la classe des pro- priétés co-récursivement énumérables (coRE).

– La classe de politiques de sécurité applicables par réécriture de programmes n’est équi- valente à aucune classe de la hiérarchie arithmétique.

Cette contribution est d’un très grand intérêt, notamment par rapport au formalisme utilisé pour modéliser les programmes et leur interaction avec les mécanismes de sécurité déployés. Dans ce modèle, un programme est modélisé par une machine programme (PM, Program Ma- chine) qui est en fait une machine de Turing déterministe manipulant trois rubans de longueur infinie :

– Le ruban d’entrée : contient la séquence d’entrée du programme.

– Le ruban de travail : modélise l’espace de travail fourni au programme durant l’exécu- tion.

– Le ruban trace : enregistre les actions pertinentes à la sécurité. Ces actions sont exé- cutées par une PM et peuvent être observées par le mécanisme de sécurité. Soit E l’ensemble de tous les événements observables.

Cette modélisation en termes de rubans, nous permet de distinguer les raisons qui ex- pliquent l’échec d’un mécanisme dans l’application d’une politique de sécurité donnée [51] : – Le mécanisme de sécurité ne dispose pas d’assez d’événements observables pour lui permettre d’appliquer la politique de sécurité. Dans ce cas, c’est l’univers des événe- ments E qui ne convient pas à l’application de la politique de sécurité et non pas le mécanisme.

– Le mécanisme de sécurité ne possède pas la puissance de calcul requise pour l’applica- tion de la politique. Dans ce cas ce n’est pas l’univers E qui doit être remis en question. Il suffit de tenter d’appliquer la politique avec un autre mécanisme d’application plus puissant.

Comme les mécanismes de sécurité ne peuvent observer des événements qu’à partir de l’ensemble E, les exécutions d’un programme sont modélisées comme étant des séquences de E. Les propriétés de sécurité sont définies par un prédicat sur des exécutions individuelles. Par conséquent, un programme satisfait la politique lorsque toutes les exécutions possibles de ce programme respectent le prédicat.

À partir de ce modèle formel, les trois classes de mécanismes d’application ont été mo- délisées de sorte à produire les résultats suivants :

FIGURE 3.7 – Machine de turing modélisant l’analyse statique.

– Un mécanisme de sécurité qui applique statiquement une politique P est modélisé par une machine de Turing MP (Figure3.7) qui prend comme entrée un encodage d’une machine programme M modélisant le programme à contrôler. Si M satisfait P, alorsMP accepte M dans un temps fini ; sinonMP rejette M en un temps fini. Cette modélisation correspond précisément à la définition des propriétés récursivement décidables. Les politiques répondant à cette définition sont dites politiques statiquement applicables.

FIGURE3.8 – Machine de turing modélisant un moniteur d’exécution.

– Un mécanisme de sécurité agissant par monitorage d’exécution afin d’appliquer une politique P est modélisé par une machine de Turing MP (Figure 3.8) qui prend une machine programme M comme entrée. MP rejette M dans un temps fini si M ne sa- tisfait pas P ; sinonMP boucle à jamais. Cette modélisation correspond aux propriétés co-récursivement énumérables. Les politiques appartenant à cette définition sont dites politiques EM-applicables.

– Un mécanisme de réécriture appliquant une politique P est modélisé par une fonction de réécriture totale et calculableR : P M → P M, telle que pour toute machine pro-

gramme M :

P (R(M)) (RW1)

P (M) ⇒ M ≈ R(M) (RW2)

où ≈ est une relation d’équivalence à travers les machines programme. Par consé- quent, pour qu’une politique de sécurité P soit applicable par réécriture, il doit y avoir un moyen de transformer M de sorte que le résultat satisfasse P (condition RW1). Aussi

si la machine programme d’origine M satisfait déjà P, alors le résultat de la réécri- ture R(M) doit être équivalent à la version d’origine du programme (condition RW2)

[51]. Hamlen et al. ont prouvé que la classe de politiques applicables par réécriture de programmes n’est équivalente à aucune classe de la hiérarchie arithmétique. L’en- semble de politiques se situant dans cette définition est noté politiques RW-applicables.

L’étude de Hamlen et al. a permis d’avoir une caractérisation plus précise des politiques applicables par monitorage d’exécution. Plus précisément, ils ont identifié cette classe de politiques comme étant l’intersection des politiques RW-applicables et des politiques EM- applicables. Aussi toute politique EM applicable se trouvant à l’extérieur de cette intersection ne peut être assurée (appliquée) pratiquement, et ce, quel que soit le moniteur d’exécution. Un autre résultat important qui découle de cette nouvelle modélisation est la fait qu’il est toujours possible de prendre un moniteur d’exécution appliquant une politique de sécurité appartenant à cette intersection, et de l’implémenter comme étant un moniteur de référence embarqué. Ce qui permet de générer des programmes satisfaisant la politique à appliquer. La contribution la plus pertinente de Hamlen et al. consiste en la taxonomie des politiques appli- cables : statiquement, par monitorage d’exécution et par réécriture de programmes comme le montre la figure3.9.

3.8.2

Mobile

Hameln a proposé dans le cadre de sa thèse (portant sur la réécriture des programmes) un système de type de bas niveau qu’il a nommé Mobile [49]. Ce dernier est une extension du système de type CIL de l’architecture .NET. La principale caractéristique de ce système enrichi est que le vérificateur de type Mobile peut appliquer des politiques de sécurité de façon formelle à un code écrit en CIL et généré par un réécriveur de programmes. Cette contribution se situe, dans de le cadre la formalisation des systèmes de réécriture certifiées. Grâce au système de type proposé, le réécriveur de programme peut demeurer à l’extérieur

FIGURE3.9 – Taxonomie des politiques de sécurité applicable selon Hamlen et al. [51]. de la TCB (Trunsted Computing Base1), du moment qu’un petit vérificateur de type permet de vérifier si le code réécrit respecte la politique de sécurité à appliquer.

Tout d’abord, le code CIL “potentiellement malicieux” est automatiquement réécrit, se- lon la politique de sécurité à appliquer. Cela permet de générer un programme Mobile an- noté qui est auto-monitoré. La réécriture peut être effectuée que se soit par le producteur du code, ou par son consommateur, puisque le programme réécrit ne sera considéré comme sûr qu’une fois que le vérificateur de type aura certifié que ce programme respecte la politique de sécurité. Par conséquent, le code qui satisfait la politique de sécurité sera approuvé par le vérificateur de type, et sera exécuté en toute sécurité. Tandis que tout code qui est mal typé sera rejeté en indiquant un échec du réécriveur.

Mobile peut être implémenté comme étant du binaire CIL utilisant des attributs CIL, afin de stocker les annotations de type. Par conséquent, les systèmes de réécriture de programmes certifiée peuvent être également définis pour la plateforme .NET sans modifier la machine virtuelle, le compilateur ou le système d’exécution.

1. La TCB (Trunsted Computing Base) regroupe tous les composants système sur lesquels repose un méca- nisme de sécurité. En d’autres termes, ce sont les composants auxquels le mécanisme peut faire confiance et par conséquent sont censés être non corruptibles.