Théorie de sécurité

Pour pouvoir appliquer une politique sur un système, il est nécessaire que ces deux éléments s’expriment en fonction d’un vocabulaire commun permettant d’identifier les éléments auxquels ils font référence. Ce vocabulaire doit permettre de décrire les informations contenues dans chaque état ainsi que les événements (actions et décisions). La donnée d’un tel vocabulaire et de contraintes sémantiques sur les éléments de ce vocabulaire est appelée théorie de sécurité et se définit comme suit :

Définition 4.2.Une théorie de sécurité teo est la donnée :

• d’une signature Σteo={S, F} ;

• d’une extension de Σteo, notée ˜ΣEnv

teo = (S, F ∪ FEnv,PEnv);

• d’une seconde extension de Σteo, notée ˜ΣAct

teo = (S, F, PAct) dont les éléments de PAct sont appelés symboles d’actions,

• un ensemble fini Dteode décisions,

• une application Cteode PEnv dans {empty, total−order, partial−order} telle que si Cteo(p) 6= empty, alors p : s × s pour une certaine sorte s ∈ S telle qu’il n’existe aucun symbole fonctionnel de coarité s ni de prédicat, hormis p, dont le profil contient s (dans ce cas, s est dite abstraite).

Tous les symboles fonctionnels définis dans une théorie de sécurité sont considérés comme des constructeurs : ils ont donc une vocation descriptive et ne doivent pas modéliser de processus d’évaluation.

La signification intuitive de ces éléments est la suivante : la signature Σteodéfinit les éléments communs aux états et aux transitions du système de sécurité que l’on modélise ; la signature ˜ΣEnv

teo décrit le langage des états tandis que ˜ΣAct

teo définit le langage des étiquettes (c.-à-d. des actions).

Deux faits notables doivent être soulignés : 1. l’absence de symbole fonctionnel défini et

2. la présence de prédicats associés à des contraintes d’ordres et définis sur des sortes sans constructeur.

Ces deux aspects sont motivés par les techniques que nous utiliserons dans la sec-tion 4.3 pour permettre la vérificasec-tion des systèmes et des politiques modélisés. Ces techniques reposent sur l’existence d’un isomorphisme entre l’ensemble des envi-ronnements construits sur une théorie de sécurité donnée et l’ensemble des termes construits sur une signature particulière (déterminée à partir de la théorie en ques-tion). Un environnement correspond à une interprétation de la signature ˜ΣEnv

teo . Pour permettre le raisonnement automatique sur les environnements, les relations seront symboliquement représentées (c.f. détails dans la section 4.2) par des listes de tuples de termes. Ce type de modélisation ne permet pas d’assurer syntaxiquement le ca-ractère fonctionnel d’une relation. Par exemple, si l’on considère un symbole défini f : s → s0, alors une interprétation de f sera représentée par un terme de la forme h n1, n⁰₁i :: h n2, n⁰₂i :: . . . indiquant que f est interprété par la fonction associant n⁰1

à n1, n0

2 à n2, . . . Cependant, le terme h n1, n0

1i :: h n1, n00

1i :: . . . ne correspondra à aucune interprétation de f puisqu’il représente une relation non fonctionnelle. On ne peut en effet pas assurer syntaxiquement (c.-à-d. par la seule donnée d’une si-gnature) que tous les couples possèdent une première composante distincte. Pour autant, cela ne signifie pas que l’on ne peut pas effectuer d’association fonctionnelle entre un élément et un attribut. Il est évident que le cadre de spécification doit per-mettre d’associer, par exemple, un niveau de sécurité à tout utilisateur. La vision que l’on adopte dans notre cadre est fondée sur une représentation des éléments du système par l’ensemble des attributs qui le caractérisent. Un terme n’identifie pas un élément mais le décrit. La méthode proposée se distingue de la méthode de modé-lisation usuelle consistant à associer à tout élément un objet qui l’identifie (le plus souvent un entier ou une chaîne de caractères) et d’associer cet objet, au moyen de fonctions, aux attributs qui caractérisent l’élément qu’il représente. Suivant cette méthode, un individu pourrait être représenté par une chaîne correspondant à son nom. Pour lui associer une couleur de cheveux et une taille, on définirait alors deux fonctions hair_color et height à valeurs respectivement dans un ensemble fini de 74

4.1. SYSTÈMES SÉCURISÉS ET POLITIQUES DYNAMIQUES

couleurs et dans l’ensemble des entiers. Dans notre cadre, les éléments ne sont pas identifiés mais entièrement définis par les attributs qui leur sont associés. Ainsi, un individu au cheveux noirs mesurant 170cm pourrait être représenté par un terme de la forme user(black, succ170(zero)). Il est alors important de noter qu’une telle modélisation implique que deux éléments possédant les mêmes caractéristiques sont indistinguables. En conséquence, lors du raisonnement, sont faites les hypothèses d’existence et d’unicité d’un élément correspondant à chaque terme. Si l’on souhaite modéliser le fait qu’il existe plusieurs éléments possédant les mêmes caractéristiques, il est alors nécessaire d’ajouter une composante au terme décrivant l’élément en ques-tion. Par exemple, si l’on souhaite indiquer qu’il existe plusieurs individus ayant une même couleur de cheveux et une même taille, alors ces derniers peuvent être modé-lisés par un terme de la forme user(n, black, succ170(zero)) où n est un entier.

Le deuxième aspect remarquable de notre définition est la présence de prédicats associés à des contraintes d’ordres et définis sur des sortes sans constructeur. Nous l’avons évoqué précédemment, la représentation symbolique des relations ne permet pas de contraindre ces dernières par une théorie particulière. Toutefois, comme nous le verrons dans la section 4.2.1, il est possible de raisonner modulo l’existence d’un ordre total ou partiel sur les éléments du système. Ceci requiert en particulier de ne pas connaître la représentation explicite des éléments à comparer. Ceci peut paraître suprenant de prime abord et pourtant, si l’on analyse les principales politiques (et principaux modèles) dans la littérature, on s’aperçoit que les éléments qui sont or-donnés (comme par exemple les niveaux) n’ont pas d’intérêt autre que de permettre de comparer les éléments qui sont associés à ces niveaux. Par exemple, lorsque l’on attribue des niveaux de sécurité aux utilisateurs et aux objets, la question d’inté-rêt n’est pas de connaître le niveau d’un utilisateur particulier, mais de pouvoir le comparer avec le niveau d’un autre utilisateur ou d’un objet. Il est donc, dans ce contexte, inutile de donner un « nom » aux différents niveaux. Le raisonnement effec-tué sur les spécifications établies dans notre cadre est alors générique en ce sens où il n’est pas « attaché » à une instance particulière de certains éléments du système. En effet, dans la plupart des travaux existants, le raisonnement s’effectue après avoir fixé un ensemble de noms représentant les utilisateurs ou encore un ensemble de ni-veaux ainsi que l’ordre associé. Les questions que l’on se pose sont alors de la forme « étant donnés ces ensembles d’utilisateurs et de niveaux ainsi que cet ordre sur les niveaux, la politique vérifie-t-elle la propriété p ? ». Dans notre cadre, les questions d’intérêt sont de la forme « existe-t-il un ensemble d’utilisateurs et un ensemble de niveaux partiellement (ou totalement) ordonné pour lesquels la politique ne vérifie pas la propriété p ? ».

Pour faciliter l’écriture et la lecture des spécifications, nous nous munissons d’un langage dont la syntaxe est illustrée par l’exemple suivant.

Exemple 4.3. Nous considérons dans cet exemple une théorie teo permettant de décrire un système de sécurité basé sur la notion de niveaux. Cette théorie décrit un système dans lequel les sujets (Subject) accèdent aux objets (Object) selon un mode d’accès (Mode). Chaque sujet et objet est partiellement caractérisé par un niveau de sécurité mais le mode de repré-sentation des sujets et des objets n’importe pas (user : Nat × Level → User

et object : Nat × Level → Object). Les modes d’accès sont quant à eux fixés (read, write :→ Mode). Les niveaux sont partiellement ordonnés (inf : Level × Level ∈ PEnv et Cteo(inf ) = partial−order). Un état du système se caractérise par l’ordre partiel que nous venons d’évoquer ainsi que par l’ensemble des accès courants (accesses : Subject × Object × Mode), l’ensemble des sujets appartenant au groupe des « super-utilisateurs » (sudo : Subject) ainsi que les ensembles des utilisateurs sur listes rouge et noire (redlist, blacklist : Subject). Les actions possibles dans le système sont la prise et le relâchement d’un accès (take, release : Subject×Object×Mode). Enfin, les deux décisions considérées ici sont la permission et le refus (Dteo={permit, deny}).

SECURITY THEORY Level_Based_T heory Signature

sorts ∆

=

Mode, Subject, Object, Level constructors ∆ =  read : → Mode write : → Mode  States constructors ∆ =       

user : Nat× Level → Subject object : Nat× Level → Object

zero : → Nat succ : Nat → Nat

       predicates ∆ =            sudo : Subject blacklist : Subject redlist : Subject

infp.o. : Level× Level

accesses : Subject× Object × Mode            Events actions ∆ = 

take : Subject× Object × Mode release : Subject× Object × Mode



decisions ∆

=

permit, deny

Les contraintes définies par Cteo sont matérialisées par la mise en exposant de « p.o. » pour partial−order et « t.o. » pour total−order.