Partie3 cif et dcif

Dr. Lilia SFAXI

Sécurité des ��Systèmes Répartis Partie III : CIF et DCIF

Doctorants ETIC, Ecole Polytechnique de Tunisie 2014

Modèle de Représentation des ��Systèmes Répartis

Besoin d’un modèle de représentation des systèmes répartis qui soit : Flexible Modulaire Configurable à la compilation et à l’exécution Offre une séparation nette entre l’architecture et le comportement de l’application ��

2

SYSTÈMES À BASE DE COMPOSANTS CIF et DCIF

3

CBSE : Ingénierie Logicielle��à Base de Composants CBSE (Component-based Software Engineering)

Représentation du système sous forme d’interconnexion de composants Favorise la séparation des préoccupations (separation of concerns)

Composant : Unité de composition Assemblé avec d’autres composants Peut être déployée indépendamment des autres

4

Composant D’après [Broy98] : Les composants sont des entités

qui doivent : Encapsuler les données Être implantables dans la plupart des langages de programmation Être hiérarchiquement entrelacés Avoir des interfaces clairement définies Pouvoir être incorporés dans des canevas (frameworks)

5

Composant Composé de :

Attributs : Interfaces de configuration Ports : Principalement 2 types:

Ports Serveurs : Reçoivent des requêtes d’autres composants Ports Clients : Émettent des messages vers d’autres composants

Liaisons : Permettent de relier les différents composants

6

C1

C3

C2

C_parent

Composant Un composant peut être hiérarchique

7

C C1

C3

C2

CBSE Représentation orientée composants

Séparation de l’architecture du système et de son implémentation

Architecture : Utilisation du Langage de Description d’Architecture (ADL)

Implémentation : Utilisation d’un langage impératif (Java par exemple)

8

CBSE : Avantages •  Couplage faible

Composants intégrés sans besoin de savoir que font les autres

•  Flexibilité Composant peuvent être facilement remplacés par d’autres

•  Composition

•  Hétérogénéité Possible de combiner plusieurs langages d’implémentation, et mécanismes de communication

9

Exemples de Modèles à base de Composants��Fractal Définition du terme « Fractale » « Forme géométrique de forme irrégulière ou fragmentée qui

peut être découpée en parties, chacune d’elles étant approximativement une copie de taille réduite du tout » Mandelbrot 1982

10

Exemples de Modèles à base de Composants��Fractal Réalisé par INRIA et l’unité R&D de France Telecom

en Juin 2002 Modèle à base de composants modulaire et

extensible pour la construction de systèmes répartis hautement adaptables et reconfigurables

Terminologie Composant Interface Liaison

11

Exemples de Modèles à base de Composants��Fractal : Composant Entité de conception (compile-time) et d’exécution(run-time)

Modèle de type et d’instance

Encapsulation de données et comportement

Composé de : Contenu : ensemble fini de sous-composants Membrane : contrôleur contenant l’ensemble des interfaces et permettant de gérer les sous-composants

Modèle hiérarchique Composant composite Composant primitif

12

Exemples de Modèles à base de Composants��Fractal : Interface Point d’accès à un composant Interne vs Externe

Interface interne : accessible à partir des sous-composants Interface externe : accessible à partir de l’extérieur du composant

Métier vs Contrôle Interface métier : fonctionnalité fournie ou requise du composant Interface de contrôle : aspect non-fonctionnel, permettant la configuration ou l’introspection du composant

Interfaces de contrôle prédéfinies dans Fractal

Client vs Serveur Interface client : services requis Interface serveur : services fournis

13

Exemples de Modèles à base de Composants��Fractal : Liaison (Binding) Chemin de communication entre composants Explicite les dépendances entre composants Manipulable à l’exécution : reconfiguration dynamique 2 types :

Primitive Entre interface client et interface serveur Une interface client peut être liée au plus à une interface serveur Une interface serveur peut être liée à une ou plusieurs interfaces client

Composite Ensemble de liaisons primitives et de composants de communication

14

Exemples de Modèles à base de Composants��Fractal : Exemple

15

Client Serveur

CC BC LC

BC AC

m m s s

LifecycleController Démarrage/arrêt du

composant

BindingController Gestion des liaisons

entre les composants

ContentController Contrôle du contenu

d’un composite

AttributeController Contrôle des attributs

du composant

Interface serveur

Interface client Binding

Exemples de Modèles à base de Composants��Fractal : Exemple d’ADL

16

Exemples de Modèles à base de Composants��SCA : Service Component Architecture Produit d’un effor t conjugué entre plusieurs

entreprises (IBM, Oracle, Sun…)

Standard OASIS

Ensemble de spécifications

Permet de simplifier la création, implémentation et déploiement de services dans l’architecture SOA en f a i s an t abs t r ac t ion des dé ta i l s de communication sous-jacente

17

Exemples de Modèles à base de Composants��SCA : Service Component Architecture Entité principale : Composant

Instance d’une implémentation configurée Offre des services à d’autres composants Requiert des références à partir d’autres composants Définit des propriétés Communique avec les autres composants via des liaisons, de différents types : Web service binding JMS binding EJB Session Bean binding “SCA Binding” (liaison par défaut)

Propose plusieurs implémentations, dont: Tuscany : implémentation de référence de SCA Frascati

18

Exemples de Modèles à base de Composants��SCA : Politiques Dans SCA, les politiques représentent les aspects non

fonctionnels de l’application Recueil de données (logging) Supervision (monitoring) Sécurité

Définies dans le fichier definitions.xml Représentés sous forme de :

Intentions (Intents) : besoins abstraits des composants, services et références Paramètres de politiques (Policy Sets) : caractéristiques énoncées dans les intents en appliquent des politiques particulières à un composant ou à une liaison d’un service ou d’une référence, tout en spécifiant les détails techniques.

19

Exemples de Modèles à base de Composants��SCA : Exemple

20

Propriété

Service

Référence

Liaison

Exemples de Modèles à base de Composants��SCA : Exemple d’ADL

21

Besoins : Non-Interférence dans les Systèmes Répartis Besoin d’une solution qui :

Configure la politique de sécurité à un haut niveau d’abstraction Applique le CFI à un niveau de granularité fin Ne requiert pas d’expertise particulière en langages typés sécurité Offre la possibilité de relaxer la propriété de non-interférence Sépare les contraintes fonctionnelles des contraintes de sécurité Propose une solution pour les modules patrimoniaux Soit applicable aux systèmes répartis réels

Soit applicable dynamiquement, peu de surcoût en terme de performances

22

CIF : Component Information Flow

DCIF : Distributed Component Information Flow

CIF : COMPONENT INFORMATION FLOW CIF et DCIF

23

CIF Intergiciel (Middleware) pour la construction de systèmes répartis non-

interférents

Offre un modèle et un ensemble d’outils

S’applique aux systèmes répartis à base de composants Applications Réparties

Sys. Exp. Sys. Exp. Sys. Exp.

Noyau Noyau Noyau

Réseau

OUTILS CIF

CIF��Configuration de Sécurité

Étiquettes de sécurité au niveau des : Ports Attributs

Capacités (capabilities) : Besoins de rétrogradation

25

C2 C1

M

P1

P2

{S1 ; I1}

{S2 ; I2}

{Sm ; Im} C

CIF��Configuration de Sécurité

Exemple ADL SCA

<composite name = "C"> <component name = "C1">

<reference name = "P1" target = "C2/P2 "> <interface.java interface = "pack.PItf"/> </reference> <property name="M"> Hello World! </property> <implementation.java class="pack.C1Impl"/>

</component> <component name = "C2">

<service name = "P2"> <interface.java interface = "pack.PItf"/> </reference> <implementation.java class="pack.C2Impl"/>

</component> </composite>

Exemple Policy <policy targetComposite= "C">

<component name = "C1"> <port name= "P1" label= "{S1;I1}"/> <attribute name= "M" label= "{Sm;Im}"/> <capabilities> <capability> cap1 </capability> </capabilities> </component> <component name = "C2"> <port name= "P2" label= "{S2;I2}"/> </component>

</policy>

26

C2 C1

M

P1

P2

{S1 ; I1}

{S2 ; I2}

{Sm ; Im} C

CIF��Non-Interférence

La propriété de non-interférence doit être vérifiée à deux niveaux : Entre les composants (Inter-Component Verification) À l'intérieur de chaque composant (Intra-Component Verification)

27

C2 C1

M

P1

P2

{S1 ; I1}

{S2 ; I2}

{Sm ; Im} C

CIF��Sécurité Intra-Composant Propagation de l’étiquette de sécurité dans l’implémentation de chaque

composant

Distinction entre deux types d’étiquettes : Etiquettes immuables : Etiquettes des ports et attributs, attribuées dans le fichier Policy Etiquettes générées : Etiquettes intermédiaires déterminées par le compilateur

⇒ Le flux d’information entre les entités Java doit être non-interférent

28

Exemple Implémentation package security; class C1 implements StartItf{ String {Sm;Im} message; SendItf {S;I} p;

public void start() { String{Sint;Iint} messageSent = "Hello " + message; p.send(messageSent); } }

C1

M {Sm ; Im}

P {S ; I} Start { }

CIF��Sécurité Inter-Composant Sémantiquement, si l (C1.P1) = {S1 ; I1} et l (C2.P2) = {S2 ;I2}

Confidentialité C1 : Je veux que le message envoyé à travers P1 garde au moins le niveau de confidentialité S1 C2 : Je garantis la protection du message reçu à travers P2 si son niveau de confidentialité est S2

Intégrité C1 : Je garantis que le niveau d’intégrité du message envoyé à travers P1 est au moins I1 C2 : Je veux que le message reçu par P2 ait au moins l’intégrité I2

29

C2 C1

P1 {S1 ; I1}

P2 {S2 ; I2}

M {Sm ; Im} C

CIF��Sécurité Inter-Composant La vérification inter-composant assure que :

1.  Le flux d’information entre les composants est non-interférent Pour chaque liaison, vérifier que :

l (portClient) ⊆ l (portServeur)

2.  Les données envoyées sont préservées Inser tion de composants cryptographiques entre les composants fonctionnels

30

C2 C1

C P1 {S1 ; I1}

P2 {S2 ; I2}

M {Sm ; Im}

CIF��CIF Tools Ensemble d’outils

Vérification des contraintes de sécurité à la compilation Génération du code de sécurité

Applications conçues avec un modèle orienté composant qui respecte les conditions suivantes : Utilisation d’un ADL pour la représentation de l’architecture Utilisation d’un langage orienté objet pour la description du comportement

Prototypes appliqués à : Modèle Orienté Composants : SCA et Fractal Modèle d’Etiquettes : DLM et modèle à base de Jetons

Langages utilisés ADL : XML Implémentation : Java 6

31

CIF��CIF Tools : Étapes d'Exécution

32

CIF��Générateur CIForm

CIF Intermediate Format

API en Java décrivant : L’architecture du système Les contraintes de sécurité

Construit à partir des fichiers ADL et Policy avec un analyseur DOM (Java Xerces)

Facilement extensible pour : D’autres modèles orientés composants D’autres modèles d’étiquettes

33

CIF��Générateur CIForm

34

CIF��CIFIntra

35

Utilisation du compilateur Polyglot [Nystrom03]

1.  Extraction d’un AST à partir du code de chaque composant 2.  Parcours de l’AST grâce à des classes Visiteur 3.  Affectation des étiquettes immuables aux attributs et méthodes Java 4.  Calcul des étiquettes générées pour les éléments intermédiaires

Dans le cas d’une interférence, appel au composant Contrôleur Quand le composant est jugé non-interférent, son code annoté est

généré

CIF��CIFIntra

36

CIF��CIFIntra : Polyglot

37

Polyglot : Compilateur extensible Réalisé pour créer des extensions à Java Basé sur le principe de visiteurs et de passes Initialement :

Input : code implémenté avec une extension à Java (ex. JIF) Output : Code Java équivalent

CIF exploite Polyglot pour aller dans l’autre sens Input : Code métier en Java Output : Code Java annoté (JIF-like)

CIF��CIFIntra : Visiteurs (1/3)

38

Visiteurs

Classes qui parcourent l’AST (Arbre de Syntaxe Abstraite) pour réaliser les traitements voulus

Chaque visiteur effectue une opération particulière pour vérifier le flux de données Attribution d'étiquettes aux variables locales et méthodes non annotées

Fonctionnement Si le code est non-interférent è Génération du code Java annoté Si une interférence est trouvée, un module contrôleur est appelé Si l’interférence est non voulue, une exception est lancée


39

SecureTranslator

StoreLabelled FieldsVisitor

MethodVisitor

LabelMethodWith HighestReturnVisitor

BlockVisitor

SecureTranslator : •  Responsable de la génération du code

annoté final •  Parse le code initial et lance les autres

visiteurs successivement StoreLabelledFieldsVisitor : Pour chaque attribut de la classe visitée, lui associer le label correspondant dans l’ADL, s’il existe

MethodVisitor / BlockVisitor : Parcourt l’implémentation de chaque méthode/Bloc LabelMethodWithHighestReturnVisitor : Attribue un label aux méthodes non annotées dans l’ADL


40

StoreHighAndLowLabelVisitor

SecureTranslator

StoreLabelled FieldsVisitor

MethodVisitor

LabelMethodWith HighestReturnVisitor

BlockVisitor

VerifyLocalVisitor

VerifyHigherThan StoredVisitor

VerifyLowerThan StoredVisitor

StoreHighAndLowLabelVisitor Pour une expression donnée, sauvegarde les labels de plus haut et de plus bas niveau de sécurité VerifyLocalVisitor Vérifie si une affectation à une variable locale est autorisée ou pas

VerifyHigherThanStoredLabelVisitor Pour une étiquette donnée, vérifie que toutes les étiquettes d’une expression donnée sont plus élevées qu'elle VerifyLowerThanStoredLabelVisitor Pour une étiquette donnée, vérifie que toutes les étiquettes d’une expression donnée sont moins élevées qu'elle

Exemple Policy <policy targetComposite= "C"> <component name = "C1">

<port name= "P" label= "{}"/> <port name= "start" label= "{}"/> <attribute name= "M" label= "{a;}"/> <capabilities> <capability> a- </capability> <capability> b+ </capability> </capabilities>

</component> </policy>

CIF��CIFIntra : Exemple

41

Exemple Implémentation

package pack; class C1Impl implements StartItf{

String M; SendItf P;

public void start() { String messageSent = "Hello " + message; P.send(messageSent); }

}

C1

M {a ; }

P { } start { }

Exemple ADL SCA <composite name = "C"> <component name = "C1">

<service name="start"> <interface.java interface = "pack.StartItf"/> </service> <reference name = "P"> <interface.java interface = "pack.PItf"/> </reference> <property name="M"> Alice </property> <implementation.java class="pack.C1Impl"/>






42

C1

M {a ; }

P { } start { }

Exemple ADL SCA <composite name = "C"> <component name = "C1">

<service name="start"> <interface.java interface = "pack.StartItf"/> </service> <reference name = "P"> <interface.java interface = "pack.PItf"/> </reference> <property name="M"> Alice </property> <implementation.java class="pack.C1Impl"/>


Elément Type ADL Type Java Label start Service Méthode {} P Reference Attribut {} M Property Attribut {a;}





43

C1

M {a ; }

P { } start { }




String {a;} M; SendItf {} P;

public void{} start() { String messageSent = "Hello " + message; P.send(messageSent); }

}





44

C1

M {a ; }

P { } start { }





public void{} start() { String messageSent = "Hello " + M; P.send(messageSent); }

}





45

C1

M {a ; }

P { } start { }





public void{} start() { String{a;} messageSent = "Hello " + M; P.send(messageSent); }

}

Interférence!

CIF��CIFIntra : Contrôleur Module dans CIFIntra Permet de vérifier si la rétrogradation des niveaux de

sécurité d'un élément est autorisée ou pas, en cas d'interférence

Il permet de : Vérifier s'il peut résoudre l'interférence à son niveau (sans faire appel à l'utilisateur) grâce aux capacités du composant Sinon, signaler l'interférence à l'utilisateur, qui aura la possibilité de l'autoriser ou pas

46





47

C1

M {a ; }

P { } start { }





public void{} start() { String{a;} messageSent = "Hello " + M; P.send(messageSent); }

}

Interférence!

CIF��CIFIntra : Liaisons Internes

Cas des composants patrimoniaux (Legacy Components) Comment vérifier la non-interférence intra-composant, si on ne dispose pas du code du composant?

Chaque composant patrimonial doit être accompagné d'un IBA (Internal Bindings Artifact) Représente les liaisons internes d'un composant, sans divulguer son code Liaison interne :

Relation entre les entrées et sorties du composant Une entrée et une sortie d'un composant sont liées ssi il existe un flux d'information entre elles

Le composant est non-interférent ssi pour chaque entrée e et sortie s liées :

l (e) ⊆ l (s)

48

CIF��CIFIntra : Liaisons Internes

49

CIF��CIFInter

50

Vérification du flux d’information entre les composants Si aucune liaison ne présente d’interférence, les générateurs fonctionnels :

1.  Insèrent des composants cryptographiques dans l’instance CIForm

2.  Génèrent le nouvel ADL fonctionnel 3.  Génèrent le code des composants cryptographiques

CIF��CIFInter

51

DCIF : DYNAMIC COMPONENT INFORMATION FLOW

CIF et DCIF

52

DCIF Dynamic Component Information Flow

Canevas orienté composants pour la construction de systèmes distribués sécurisés à la compilation et à l’exécution

Définit deux types de composants : Des composants fonctionnels Des composants de gestion

53

DCIF��Architecture

54

DCIF��Architecture Global Manager

Composite Responsable de la gestion des composants fonctionnels

Factory Gère les mises à jour de l'architecture du système Un composant Factory Global et un composant Factory pour chaque domaine

Security Manager Dispatche les informations entre les composants de sécurité, selon leur type

Key Manager Gestionnaire de clefs cryptographiques

IFC Manager Gestionnaire des flux d'information du système

CryptoManager Gestion des opérations de crypto pour chaque noeud

55

DCIF��Architecture : IFC Manager

56

DCIF��Architecture : IFC Manager

Policy Manager Orchestre les communications dans le IFCM Stocke les certificats IBA et les instances CIForm

Policy Extractor Extrait les informations à partir des fichiers Policy

Label Manager Stocke les étiquettes du système

Controller Prend les décisions de rétrogradation

Intra-Component Verifier Vérification dynamique intra-composant

57

DCIF��Reconfiguration Dynamique

Ajout d’un composant Création d’un CM pour son nœud Policy Extractor extrait les étiquettes du fichier Policy, et les stocke dans le Label Manager Le Intra-component Verifier vérifie le code de ce composant, ou son certificat IBA

Suppression d’un composant La clef du composant est supprimée du Key Manager Les étiquettes de ce composant sont supprimées du Label Manager L’instance CIForm est mise à jour

Remplacement d’un composant Suppression + ajout d’un composant

Migration d’un composant Suppression d’un composant d’un domaine + son ajout dans un autre domaine

58

Références [Broy98] : M. Broy, A. Deimel, et al. "What characterizes a (software) component ?”

Software- Concepts & Tools, 19(1) :49–56, June 1998.

[Nystrom03] : N. Nystrom, M.R. Clarkson, and A.C. Myers. “Polyglot : An extensible compiler framework for Java”. In Proceedings of the 12th International Conference on Compiler Construction, pages 138–152. Springer-Verlag, April 2003.

59

Technology

Partie3 cif et dcif