3.4 Capacités
3.4.2 Surcharge et priorité des capacités
Les capacités peuvent être surchargées : deux capacités peuvent avoir le même nom si leurs arguments diffèrent. Cela permet de définir des capacités plus ou moins précises selon le type de contexte de leurs arguments. Plus le type de contexte des arguments est explicite, plus la capacité est précise et spécialisée. On définit donc la notion de compatibilité de capacités permettant d’indiquer quelles capacités peuvent être choisies pour appliquer une capacité instanciée :
Définition 3.4.3: Compatibilité de capacités
Soient C une capacité et Cinst une capacité instanciée. C est dite compatible avec Cinst si : – elles ont le même nom ;
– elles ont le même nombre d’arguments ;
– pour chaque argument Arg1(i)de C et Arg2(i)de Cinst, le type de contexte T ype(Arg1(i)) est inclus dans T ype(Arg2(i)).
3.4. CAPACITÉS
L’algorithme 4 est utilisé pour déterminer si des capacités sont compatibles. L’algo-rithme commence par vérifier que les deux capacités ont le même nom et le même nombre d’arguments (lignes 2 à 4). Puis, pour chaque argument des capacités (lignes 5 à 11), l’al-gorithme récupère les types des arguments (lignes 6 et 7) et vérifie leur inclusion (ligne 8). Si le critère d’inclusion n’est pas respecté, les capacités ne sont pas compatibles (ligne 9). S’il est respecté pour tous les arguments, C est compatible avec Cinst (ligne 12).
Algorithme 4 Détermination de la compatibilité de la capacité C avec la capacité Cinst 1: function capacitéCompatibles (C, Cinst)
2: if C.nom 6= Cinst.nom OU C.nbArgs6= Cinst.nbArgsthen 3: return Faux
4: end if
5: for all i dans [1, C.nbArgs] do 6: T T ype(C.arg[i]) 7: Tinst T ype(Cinst.arg[i])
8: if InclusionDeTypesContextes(T, Tinst) == Fauxthen 9: return Faux
10: end if 11: end for 12: return Vrai 13: end function
Pour un ensemble de contextes donnés, la capacité à appliquer est sélectionnée en utilisant le score d’inclusion des capacités, qui est basé sur le score d’inclusion des types de contextes défini à la section 3.3 et donné par la fonction scoreInclusion.
Définition 3.4.4: Score d’inclusion de capacités
Soit Cinst une instance de capacité dont les arguments sont des contextes instanciés notés SCi,1in. Soient C une capacité compatible avec Cinst et Ti,1in les types de contextes qui lui sont passés en argument.
On définit le score d’inclusion d(C, Cinst) de C dans Cinst comme la somme des distances des contextes, au sens de la définition 3.3.11. On a donc :
d(C, Cinst) =
n
X
i=1
d(Ti, T ype(SCi))
Le score d’inclusion peut être calculé à partir de l’algorithme 5. L’algorithme vérifie tout d’abord que les capacités sont compatibles (lignes 2 à 4). Si c’est le cas, alors, pour chacun des contextes passés en argument aux capacités C et Cinst, le score d’inclusion des types de contextes attendus est calculé. Leur somme fournit le score d’inclusion de la capacité (ligne 9). Dans le cas où la capacité C n’est pas compatible avec Cinst, la fonction renvoie -1 (lignes 3 et 11). Sinon, la fonction renvoie le score d’inclusion (ligne 14).
En utilisant le score d’inclusion des capacités et pour un ensemble de contextes donnés, il est possible d’ordonner les capacités surchargées en utilisant la règle suivante.
Règle 3.4.5: Sélection de capacité
Soit Cinst une instance de capacité. Soient Ci,1in les capacités compatibles avec Cinst. Les Ci sont ordonnées selon leur score d(Ci, Cinst), en considérant le score positif le plus faible comme le meilleur.
Considérons les capacités C2 et C3 définies comme suit :
C2 := generate_key(Type.Passive.Data.Key);
Algorithme 5 Calcul du score d’inclusion d’une capacité C dans une capacité Cinst 1: function scoreInclusionCapacité (C, Cinst)
2: if capacitéCompatibles(C, Cinst) == Fauxthen 3: return -1
4: end if 5: score 0
6: for all contexte[i] dans Cinst.listeContextesdo 7: argType C.argument[i]
8: if compatibilitéDeContexte(argType, contexte[i]) then
9: score score+scoreInclusion(argType, Type(contexte[i])) .Déf. 3.3.11 10: else 11: return -1 12: end if 13: end for 14: return score 15: end function
Ces deux capacités fournissent la même fonctionnalité : elles permettent toutes deux de générer une clef de chiffrement, mais C3 ne peut générer qu’une clef symétrique, au contraire de C2. Par conséquent, si une clef asymétrique est nécessaire, seule C2 peut répondre au besoin, mais si une clef symétrique est demandée (c’est-à-dire si l’argument passé est de type Type.Passive.Data.Key.Symmetric), C2 et C3 peuvent toutes deux être utilisées. Dans ce deuxième cas, C3 étant une propriété plus précise, elle sera choisie pour répondre au besoin si un mécanisme pouvant l’appliquer est présent.
Considérons les trois contextes suivants :
SC1 := (Type.Passive.Data.Key="foo"):
SC2 := (Type.Passive.Data.Key.Symmetric="foo"); SC3 := (Type.Passive.Data.Key.Asymmetric="foo");
Les scores d’inclusion, calculés comme décrit par l’algorithme 5, sont donnés dans la table 3.1.
C2 C3
generate_key (SC1) 0 -1
generate_key (SC2) 1 0
generate_key (SC3) 1 -1
Table3.1 – Exemples de scores d’inclusion de capacités
Un score négatif indique que la capacité ne peut pas être utilisée pour le contexte concerné. Pour chaque contexte, la capacité la plus adaptée est donc celle avec le plus faible score positif. Par conséquent, C2 sera choisie pour générer une clef de chiffrement si les contextes SC1 ou SC3 sont utilisés. Dans le cas du contexte SC2, la capacité C3
sera choisie. Cependant, si la capacité C3 ne peut pas être appliquée (par exemple parce qu’aucun mécanisme disponible ne fournit C3), alors C2 pourra être utilisée.
Si deux capacités ont le même score pour un contexte donné, le choix se base sur le score des mécanismes associés, défini à la section 3.4.3. Si les scores des mécanismes ne permettent pas de sélectionner une capacité, alors la première capacité compatible définie est considérée comme prioritaire.
On peut donc définir des capacités s’appliquant sur des contextes plus ou moins précis, ce qui permet d’obtenir différents niveaux d’abstraction des mécanismes de sécurité. Plus la définition d’une capacité est précise (i.e. plus le type de ses arguments est explicite), plus son application sera spécifique à la catégorie des ressources considérées. La protection
3.4. CAPACITÉS
sera donc plus adaptée, ce qui la rendra plus efficace : ce critère est pris en compte par le score d’inclusion des capacités.
Notons cependant l’intérêt des capacités moins précises : elles peuvent être appliquées sur un plus grand nombre de ressources, ce qui permet une généricité plus importante, bien que leur protection soit moins adaptée aux ressources. Une telle capacité ne sera utilisée que dans le cas où des capacités plus précises ne peuvent pas être appliquées, par exemple parce qu’aucun mécanisme disponible ne les fournit.
Les capacités utilisées sont choisies dynamiquement lors de l’application de la politique. Ce choix se base sur la configuration du système (c’est-à-dire sur la liste des mécanismes disponibles) et sur le score d’inclusion des capacités.
L’algorithme 6 décrit le processus de sélection et d’ordonnancement des capacités selon le nom de la capacité et la liste de contextes passée en argument. L’algorithme recherche tout d’abord les définitions de capacités ayant le même nom et le bon nombre d’arguments (ligne 4). Puis, le score d’inclusion de la capacité c recherchée dans la capacité ciest calculé (ligne 6). Si ce score est positif ou nul, les contextes de ci sont inclus dans ceux de c et ci
peut donc appliquer c (lignes 7 à 9). La fonction renvoie l’ensemble des capacités répondant à ces critères d’inclusion, triées par score d’inclusion.
Algorithme 6 Sélection de capacité
1: function chercheCapacitésCompatibles (nom de capacité c, listeContextes) 2: listeCapacitésCompatibles ;
3: for all cidans l’ensemble des capacitésdo
4: if CapacitéCompatible(ci, {c, listeContextes} ) == Vraithen 5: compatible Vrai
6: score ScoreInclusionCapacité(ci, {c, listeContextes}) 7: if score 0then
8: listeCapacitésCompatibles ciordonnée selon le score .Règle 3.3.12 9: end if
10: end if 11: end for
12: return listeCapacitésCompatibles 13: end function