Compatibilité de contextes

Comme nous le verrons dans les sections 3.4 et 3.5, une notion de compatibilité est indispensable pour manipuler les contextes de sécurité. En effet, l’expression des propriétés de sécurité reposant sur les contextes, la sélection d’une propriété se base également sur ceux-ci. De plus, les contextes étant associés aux ressources, il est nécessaire de pouvoir obtenir l’ensemble des ressources identifiées par un contexte donné.

3.3.2.1 Filtrage des types de contextes

Nous définissons tout d’abord la notion de type de contexte qui correspond à un contexte réduit à son ensemble de clefs d’attributs.

3.3. CONTEXTES

Définition 3.3.5: Type de Contexte Soit un contexteSC tel que :

SC := (K1= ”V1”) : (K2= ”V2”) : [...] : (Kn= ”Vn”) := (Ki, Vi)_1in

Alors, le type du contexte SCest défini par :

Type(SC) := K1: K2: [...] : Kn

:= (Ki)1in

Considérons par exemple le contexte mailConfig:

mailConfig := (Type.Passive.Data.File.Configuration="conf"):(Domain="mail"):( Hardware.Computer="mailServer");

Le type de ce contexte est l’ensemble des clefs de ses attributs, soit :

Type(mailConfig) := Type.Passive.Data.File.Configuration:Domain: Hardware.Computer;

Inclusion de clefs d’attribut L’inclusion de clefs d’attribut entre plusieurs types de contextes est nécessaire afin de déterminer quelles propriétés de sécurité sont applicables pour un contexte donné.

Un type de contexte étant composé de clefs d’attributs, il faut, pour déterminer si un type de contexte est présent dans un autre type, être capable de déterminer la présence ou l’absence d’une clef d’attribut dans une autre clef. L’inclusion de clef d’attribut est donc définie comme suit :

Définition 3.3.6: Inclusion de clefs d’attribut On note P (Ki) le chemin d’une clef d’attribut Ki.

Soient K1 et K2 deux clefs d’attributs de longueurs respectives n et m.

Soient P (K1) := (k_1,i)_1in et P (K2) := (k_2,j)_1jm leurs chemins associés dans l’arbre des clefs de contextes, où les k1,i et k2,j sont les nœuds de l’arbre.

Alors, la clef K1 est incluse dans K2 si et seulement si le chemin de K1 est inclus dans celui de K2, soit :

K₁ ⇢ K2 , P (K1)⇢ P (K2) , 8i 2 [1, n], k1,i == k_2,i

Considérons par exemple les clefs K1 et K2 suivantes et leurs chemins associés :

K1:= Hardware.Computer P (K1) := (Hardware, Computer) K2:= Hardware.Computer.V M P (K2) := (Hardware, Computer, V M )

Alors, le clef K2 contient la clef K1 puisque le chemin P (K1) est inclus dans P (K2). Inclusion de types de contextes Un type de contexte est un ensemble d’attributs qui peut être représenté sous forme d’arbre. La détermination de l’inclusion de deux types de contextes peut ainsi être vue comme un problème simplifié d’inclusion d’arbres. On définit donc la règle suivante :

Règle 3.3.7: Inclusion de types de contextes

L’inclusion d’un type de contexte T1 dans un type de contexte T2 peut être ramené à un problème d’inclusion de chemins dans un arbre.

Justification 3.3.8:

Dans le cas général, un arbre T1 est dit inclus dans un arbre T2 s’il est possible de trans-former T2 en T1 en effectuant une série de suppressions de nœuds sur T2. Dans notre cas, il est nécessaire de conserver le chemin de chaque nœud, puisque la hiérarchie des nœuds est significative. Par conséquent, on ne considère que les opérations de suppression sur les feuilles de l’arbre ou sur la totalité d’un sous-arbre (si un nœud interne est supprimé, tous ses descendants le sont également). Il s’agit donc d’un calcul d’inclusion de chemins.

On peut donc déterminer l’inclusion d’un arbre T1 dans un arbre T2 en utilisant l’algo-rithme 1. Pour chaque feuille fi de l’arbre T1, on recherche dans l’arbre T2 une feuille dont le chemin contient le chemin de fi. Si toutes les feuilles de T1 sont présentes dans T2, alors T₁ est inclus dans T2.

Algorithme 1 Inclusion d’un type de contexte T1 dans un type de contexte T2 1: function InclusionDeTypesContextes (T1, T2)

2: F1 les feuilles de T1

3: F2 les feuilles de T2

4: for all feuille fidans F1 do 5: P (fi) le chemin de fi

6: inclusionFeuille Faux 7: for all feuille fj dans F2 do 8: P (fj) le chemin de fj

9: if P (fi)est inclus dans P (fj)then 10: inclusionFeuille Vrai 11: end if

12: end for

13: if inclusionFeuille est Faux then 14: return Faux

15: end if 16: end for 17: return Vrai 18: end function

Score d’inclusion Cette définition de l’inclusion des types de contextes nous permettra de sélectionner les capacités et les propriétés qui peuvent être appliquées sur des contextes spécifiques. Cependant, dans le cas où plusieurs capacités ou propriétés peuvent être ap-pliquées à un contexte, il est nécessaire de choisir la plus adaptée. Nous définissons donc un score représentant la qualité de l’inclusion.

Définition 3.3.9: Score d’inclusion

Le score d’inclusion correspond à la distance d’édition d’arbre [Tai, 1979], définie par : d(T₁, T₂) = min(cost(S))

où S est une série d’opérations d’édition (insertions, suppressions, substitutions) permettant de transformer T1 en T2.

Dans notre cas, cette distance n’est calculée que si T1est inclus dans T2. Par conséquent, le calcul de la distance d’édition peut être ramené au calcul de la différence de taille entre les deux arbres, comme montré par la justification 3.3.10.

Justification 3.3.10:

Soient T1 et T2 deux types de contextes tels que T1 est inclus dans T2. En raison de cette inclusion, T1 peut être obtenu à partir de T2 en effectuant uniquement des opérations de

3.3. CONTEXTES

suppression de nœuds. Par conséquent, le calcul de la distance d’édition est équivalente au calcul du nombre de nœuds de T2 à supprimer pour obtenir T1. Or, le nombre de nœuds à supprimer est égal à la différence de nombre de nœuds entre T2 et T1, c’est-à-dire à la différence de taille entre les deux arbres. On peut donc en conclure que la distance d’édition entre T1 et T2 est égale à la différence de taille entre T2 et T1.

On obtient donc la définition suivante :

Définition 3.3.11: Score d’inclusion de types de contextes

Soient T1 et T2 deux types de contextes tels que T1 est inclus dans T2. Le score d’inclusion de T1 dans T2 est :

d(T₁, T₂) = size(T₂) size(T₁)

où size(Ti) est la taille de l’arbre, c’est-à-dire son nombre de nœuds.

Par convention, un score d(T1, T₂) strictement négatif indique que T1 n’est pas inclus dans T2. Dans le cas contraire, si T1est inclus dans T2, le score sera positif ou nul. Un score nul indique que les deux types de contextes sont identiques, alors qu’un score de 1 indique qu’il faut supprimer un nœud pour transformer T2 en T1. On définit la règle suivante : Règle 3.3.12: Comparaison des scores d’inclusion

Si le score d’inclusion de T1 dans T2 est positif ou nul, alors plus le score est faible, meilleure est l’inclusion. Un score d’inclusion négatif indique que T1 n’est pas inclus dans T2.

Le score d’inclusion peut ainsi être calculé à l’aide de l’algorithme 2.

Algorithme 2 Calcul du score d’inclusion d’un type de contexte T1 dans un type T2 1: function scoreInclusion (T1, T2)

2: if InclusionDeTypesContextes(T1,T2) est Fauxthen 3: return -1

4: end if

5: taille_T1 nombre de nœuds de T1

6: taille_T2 nombre de nœuds de T2

7: score = taille_T2 - taille_T1

8: return score 9: end function

Considérons les quatre types de contextes de la figure 3.4.

Les types de contextes T2et T3sont tous deux inclus dans T1. En revanche, T4 n’est pas inclus dans T1: le nœud Symmetric de T4 n’est pas présent dans T1. Les scores d’inclusion ne sont donc calculés que pour T2 et T3. On obtient ainsi les scores suivants :

d(T2, T1) = size(T1) size(T2) = 1 d(T3, T1) = size(T1) size(T3) = 2

T₂ est le type de contexte le plus proche de T1. En effet, son score est plus faible, ce qui implique un nombre d’opérations d’éditions moins important. Par conséquent, pour le contexte T1, une capacité attendant en argument un contexte de type T2 sera préférée à une capacité attendant un argument de type T3.

Ce score d’inclusion sera utilisé dans la suite de ce chapitre afin de sélectionner les capacités (section 3.4.2) et les propriétés (section 3.5.4) les plus adaptées aux contextes. 3.3.2.2 Filtrage de contextes

Afin de déterminer sur quelles ressources une propriété doit être appliquée, une re-cherche de motif dans les contextes complets doit être effectuée. Pour cela, nous définissons tout d’abord la notion de compatibilité entre deux valeurs d’attributs :

Définition 3.3.13: Compatibilité de valeurs d’attributs

Soient T1 et T2 deux attributs. La valeur de T2 est dite compatible avec la valeur de T1

si elle est incluse dans la valeur de T1 en utilisant les règles usuelles de correspondance d’expressions régulières.

On peut alors définir la compatibilité entre contextes : Définition 3.3.14: Compatibilité de contextes

Soient A et B deux contextes. B est compatible avec A si les points suivants sont vérifiés : – Le type de contexte de A est inclus dans le type de contexte de B ;

– Pour chaque valeur d’attribut de A, la valeur de l’attribut de B correspondant est compa-tible. Les attributs supplémentaires de B ne sont pas pris en compte.

La compatibilité d’un contexte SC1 avec un contexte SC2 peut être déterminée en utilisant l’algorithme 3. Il est alors possible de savoir sur quelles ressources une capacité ou une propriété de sécurité doit être appliquée.

L’algorithme 3 commence par vérifier que le type de contexte de SC2 est bien inclus dans celui de SC1 (lignes 2 à 4). Si c’est le cas, l’algorithme parcourt ensuite les feuilles du contexte SC2 (lignes 7 à 23). Pour chacune de ces feuilles, l’algorithme parcourt les feuilles de SC1 (lignes 11 à 19) jusqu’à trouver une feuille ayant un chemin inclus dans celui de la feuille de SC2 (ligne 14). Si une telle feuille est trouvée, les valeurs des deux feuilles sont comparées (ligne 15) : si la valeur de la feuille de SC1 est compatible avec celle de SC2, alors, la feuille de SC1 est compatible avec SC2 (ligne 16), et ce processus est répété pour toutes les feuilles de SC2. Si les valeurs ne correspondent pas ou si aucune feuille n’a le bon chemin, alors le contexte SC1 n’est pas compatible avec SC2 (lignes 20 à 23).

Considérons les contextesmailConfigetserviceConfig suivants :

mailConfig := (Type.Passive.Data.File.Configuration="conf"):(Domain="mail"):( Hardware.Computer="mailServer");

serviceConfig := (Type.Passive.Data.File.Configuration="conf"):(Domain="ssh| mail");

3.3. CONTEXTES

Algorithme 3 Compatibilité d’un contexte SC1 avec un contexte SC2 1: function compatibilitéDeContextes (SC1, SC2)

2: if InclusionDeTypesContextes(Type(SC2), Type(SC1)) == Fauxthen 3: return Faux

4: end if

5: F1 les feuilles de SC1

6: F2 les feuilles de SC2

7: for all feuille fidans F2do 8: P (fi) le chemin de fi

9: V (fi) la valeur de fi

10: inclusionFeuille Faux 11: for all feuille fjdans F1 do 12: P (fj) le chemin de fj

13: V (fj) la valeur de fj

14: if P (fi)est inclus dans P (fj)then

15: if V (fj)est compatible avec V (fi)then 16: inclusionFeuille Vrai

17: end if 18: end if 19: end for

20: if inclusionFeuille est Faux then 21: return Faux

22: end if 23: end for 24: return Vrai 25: end function

Le contexte mailConfig est compatible avec le contexte serviceConfig. En effet, le type de contexte Type(serviceConfig) est inclus dans Type(mailConfig) et les valeurs des attributs demailConfigsont compatibles avec celles deserviceConfig. Cela implique qu’une propriété mettant en jeu le contexteserviceConfigsera appliquée sur les ressources ayant le contextemailConfig.