3.2 Politiques de flux d’information
3.2.2 Le modèle décentralisé
Le modèle de Myers
Myers ([ML97]) propose d’associer aux conteneurs d’information d’un sys- tème une étiquette de sécurité décrivant la politique de sécurité associée à ce conte- neur.
Une étiquette de sécurité est d’abord formée par un ensemble d’utilisateurs, propriétaires du conteneur associé à cette étiquette. A chaque propriétaire est en- suite associé un certain nombre d’utilisateurs, appelés lecteurs, autorisés à accéder aux conteneurs associés à cette étiquette de sécurité. La politique de sécurité est interprétée de la façon suivante : pour qu’un utilisateur soit autorisé à accéder au conteneur associé à une étiquette de sécurité, il faut qu’il soit désigné comme lec- teur de cette étiquette de sécurité par l’ensemble des propriétaires de cette étiquette de sécurité. Chaque propriétaire d’une donnée est autorisé à modifier l’étiquette de sécurité de cette donnée en lui ajoutant un certain nombre de lecteurs.
Afin de définir formellement les étiquettes de sécurité les éléments suivants sont définis :
Les utilisateurs : U = {u1, u2, ..., un} est l’ensemble des utilisateurs du système.
Les propriétaires associés à une étiquette de sécurité e sont des utilisateurs notés prop(e) ⊆ U .
Les lecteurs associés à une étiquette de sécurité e sont des utilisateurs définis par les propriétaires dee notés lec(e) ⊆ U . Chaque propriétaire pouvant définir un ensemble de lecteurs, on note alorslec(e, u) ⊆ U l’ensemble des lecteurs dee autorisés par u. On a alors :
lec(e) = \
u∈prop(e)
lec(e, u) (3.1)
Les étiquettes de sécurité associées aux données sont de la forme
e = {pα: lα1, ..., lαm; ...; pβ : lβ1, ..., lβn}
oùprop(e) = {pα} ∪ ... ∪ {pβ}, lec(e, pα) = {lα1, ..., lαm} et lec(e, pβ) =
{lβ1, ..., lβn}.
Considérons par exemple l’étiquette e1 = {p1 : l1, l2; p2 : l2, l3}. Nous
avons alors prop(e1) = {p1, p2}, lec(e1, p1) = {l1, l2}, lec(e1, p2) =
{l2, l3}. Donc lec(e1) = lec(e1, p1) ∩ lec(e1, p2) = l2. Les conteneurs as-
sociés à l’étiquette de sécuritée1 ont donc deux propriétairesp1 etp2 et un
Relation d’ordre Une relation d’ordre est définie entre les étiquettes de sécurité. Considérons deux étiquettes de sécuritée1ete2,e1est une restriction dee2,
notéee1 ⊑ e2 si les propriétaires dee1sont inclus dans ceux dee2(c’est-à-
dire quee2a plus de propriétaires quee1, un propriétaire n’est pas un lecteur
autorisé d’une donnée, pour pouvoir lire une donnée, il faut être autorisé par l’ensemble des propriétaires) et si pour chaque propriétaire dee1, les lecteurs
autorisés par ce propriétaire poure2 sont aussi autorisés par ce propriétaire
poure1(c’est à dire quee2a moins de lecteurs autorisés quee1) :
Définition 3.2.1 (e1⊑ e2). si et seulement si :
prop(e1) ⊆ prop(e2)
∀p ∈ prop(e1), lec(e1, p) ⊇ lec(e2, p)
Etiquette de sécurité des conteneurs dérivés Lorsqu’un programme combine deux conteneurs dans un troisième, l’étiquette de sécurité associée au nouveau conteneur doit refléter la politique de sécurité associée à ces deux conteneurs. Les propriétaires du conteneur dérivé sont l’ensemble des propriétaires des deux conteneurs initiaux. Les lecteurs du conteneur dérivé sont l’intersection des lecteurs des deux conteneurs initiaux. La règle d’union de deux étiquettes de sécurité est la suivante :
Définition 3.2.2 (e1⊔ e2). est défini par :
prop(e1⊔ e2) = prop(e1) ∪ prop(e2)
lec(e1⊔ e2, p) = lec(e1, p) ∩ lec(e2, p)
La politique de contrôle de flux d’information est donc définie par :
– E l’ensemble des étiquettes de sécurité que l’on peut exprimer à l’aide de l’ensembleU des utilisateurs du système ;
– ⊑ la relation d’ordre entre les classes de sécurité ; – ⊔ la relation d’union entre les classes de sécurité.
Le modèle d’étiquettes de sécurité proposé par Myers permet donc d’exprimer des politiques de sécurité complexes. Il a été mis en œuvre dans un compilateur Java [Mye99]. Des évolutions du modèle original ont été proposées permettant la mise en pratique d’une politique de contrôle de flux décentralisée au sein d’un système d’exploitation [EKV+05, KYB+07].
Néanmoins il reste un modèle bien adapté aux architectures orientées services. En effet un processus BPEL fait intervenir de nombreux services qui peuvent être vus comme des utilisateurs. Ce modèle a en particulier été utilisé par les auteurs de [ZA11] et [SARL12] qui proposent une analyse statique d’orchestrations de services afin de vérifier que celles-ci ne violent pas une politique de sécurité basée sur le modèle décentralisé de contrôle de flux d’information.
Les évolutions du modèle décentralisé
Le système Asbestos Afin de contrôler la confidentialité des données, les auteurs du système Asbestos ([EKV+05]) utilisent 4 niveaux de sécurité à la manière du
3.2 Politiques de flux d’information 33
modèle en treillis notés ainsi [∗, 0, 1, 2, 3]. 0 étant le niveau non confidentiel, 3 étant le niveau le plus protégé. Le symbole∗ est utilisé pour gérer les déclassifica- tions (c’est à dire les modifications de la politique de flux).
A la manière des utilisateurs chez Myers, les auteurs de Asbestos proposent de définir des catégories, une catégorie désignant une catégorie de données. A chaque utilisateuru est associée une catégorie marquée um.
Les classes de sécurité proposées dans le modèle de Asbestos consistent à asso- cier à chaque catégorie un niveau de sécurité. Elles sont de la forme{c10, c21, 2}.
Ainsi le niveau 0 est associé à la catégoriec1, le niveau 1 est associé à la catégorie
c2et le niveau par défaut 2 est associé à l’ensemble des autres catégories.
Une relation d’ordre ⊑ est définie entre les classes de sécurité en comparant chacune des composantes selon la définition suivante :
Définition 3.2.3 (cl1 ⊑ cl2). Soitcl1etcl2deux classes de sécurité,cl1 ⊑ cl2si et
seulement si :
cl1(c) ≤ cl2(c) pour tout c appartenant à l’ensemble des catégories de don-
nées.
La relation d’union entre deux classes de sécurité⊔ est définie par :
Définition 3.2.4 (cl1 ⊔ cl2). Soitcl1 etcl2 deux classes de sécurité,cl1⊔ cl2 est
défini par :
(cl1⊔ cl2)(c) = max(cl1(c), cl2(c)) pour tout c appartenant à l’ensemble des
catégories de données.
Cependant, décrire une politique de flux pour Asbestos est difficile, c’est pour- quoi les auteurs de [EK08] proposent un langage dédié pour la spécification de politique de flux. Ils définissent à cet effet des compartiments qui représentent un ensemble d’objets ayant la même politique de sécurité. Les relations entre les com- partiments sont alors décrites paire à paire. Ainsi il existe quatre possibilités de communication entre deux compartimentsX et Y :
– X!Y , aucune communication entre X et Y n’est possible ;
– X > Y , X peut envoyer des messages à Y mais ne peut en recevoir de Y ; – X < Y , X peut recevoir des messages de Y mais ne peut lui en envoyer ; – X <> Y , X et Y peuvent communiquer librement.
Ils décrivent ensuite un algorithme permettant de transformer une telle politique de flux en classe de sécurité d’Asbestos.
Le système Flume Les auteurs de Flume [KYB+07] ont proposé un autre mo-
dèle de sécurité pour les systèmes d’exploitation permettant le contrôle de flux d’information. Ce système permet de protéger à la fois l’intégrité et la confidentia- lité des données.
Ce système considère des processus c’est-à-dire soit des threads soit des objets (des conteneurs d’information).
Dans ce système, le contrôle de flux est assuré par des marques, chacune des marques est associée à un ou plusieurs processus. Une classe de sécurité est consti- tuée d’un ensemble de marques. Chaque processus est associé à deux classes de sécuritéSp (confidentialité) etIp(intégrité). Les classes de sécurité des objets ne
sont pas modifiables alors que ceux des threads sont dynamiques.
A chaque thread est associé un ensemble de capacités, un ensemble de marques indiquant la capacité d’un thread à modifier ses classes de sécurité. Pour une marque t, la capacité t+ indique la capacité d’un thread à ajouter la marque t à une de
ses classes de sécurité, la capacitét− indique la capacité d’un thread à enlever la marquet à une de ses classes de sécurité. Chaque thread a un ensemble de capacités Op. Il existe aussi un ensemble de capacitésO détenu par l’ensemble des threads.
Ces classes de sécurité permettent de gérer la confidentialité. Un thread ayant la capacitét+peut recevoir des données marquées part si t est une marque de confi- dentialité. Si il a la capacitét−, il peut alors déclassifier une donnée marquée part.
Un thread possédant les capacitést+ ett−est donc l’équivalent d’un propriétaire du modèle de Myers ou de Asbestos.
Ces classes de sécurité gèrent également l’intégrité. Sit est un marqueur d’in- tégrité alors tous les processus ont par défaut la capacitét−d’enlever ce label t.
L’autorité de certification possède quant à elle la capacitét+d’ajouter le tagt.