Formalisation de propriétés de flux d information avec une logique temporelle du premier ordre pour assurer la sécurité d une infrastructure de Cloud

Transcription

1 Formalisation de propriétés de flux d information avec une logique temporelle du premier ordre pour assurer la sécurité d une infrastructure de Cloud Arnaud Lefray,, Jonathan Rouzaud-Cornabas Université de Lyon - Laboratoire LIP UMR CNRS - ENS de Lyon - INRIA - UCB Lyon 5668 INSA Centre Val de Loire - Université d Orléans, LIFO EA 4022, Bourges, France nom.prénom@ens-lyon.fr Résumé L adoption massive du Cloud est principalement freinée par le manque de sécurité. Le concept de sécurité à la demande consiste à proposer et appliquer les objectifs de sécurité du client. Dans ce papier, nous présentons une approche, nommée Information Flow Past Linear Time Logic (IF-PLTL), pour spécifier un large panel de propriétés de sécurité d un système. Nous présentons également comment contrôler les flux d information à partir d évènements de bas niveau. Nous décrivons en détail la syntaxe et la sémantique de IF-PLTL. De plus, cette logique permet de formaliser un large ensemble de politique de sécurité paramétrable par un client. Nous illustrons cette approche avec une politique d isolation basée sur des propriétés de non-interférence. Enfin, nous discutons l extension avec des ensembles dynamique de IF-PLTL pour inclure des cas d usage plus réalistes comme la politique d isolation dynamique des domaines. Mots-clés : Sécurité, Flux d information, Cloud, Système formel, Sémantique. 1. Introduction L adoption massive du modèle Cloud est principalement freinée par le manque de sécurité [16]. Un environnement de Cloud fait face à diverses menaces allant des attaques traditionnelles sur les systèmes d exploitation (SE) (au niveau hyperviseur ou machine virtuelle) ou les réseaux, jusqu aux nouvelles menaces issues des environnements partagés tels que les ressources matérielles partagées au niveau IaaS [5], les ressources (virtuelles) systèmes partagées au niveau PaaS [14], et les ressources applicatives partagées au niveau SaaS. Une politique de sécurité efficace doit prendre en compte tous les niveaux multi-tenants, à savoir, IaaS, PaaS et SaaS. Sécuriser les Clouds est un domaine de recherche très actif dont témoigne les nombreux projets académiques et industriels en cours. Nous pensons qu un concept clé est de délivrer une sécurité à la demande. Un utilisateur doit pouvoir spécifier quel est le comportement sécurisé de son système. Ainsi, nous devons proposer un langage qui permet l expression d objectifs de sécurité spécifiques à un client. Cependant, spécifier ou configurer une politique de sécurité est très souvent complexe et sujet à erreur. Même en tant qu expert de la sécurité, un humain peut toujours effectuer une mauvaise

2 configuration donnant lieu à des failles. Pour cette raison, les politiques de sécurité doivent être appliquées de manière automatique, c est-à-dire où l intervention humaine est réduite à sa stricte nécessité. Par exemple, le comportement souhaité d un système, c est-à-dire ce qu il doit ou ne doit pas faire, ne peut être spécifié que par le client. Par conséquent, après cette première étape de spécification, le système doit adopter un contrôle d accès obligatoire (Mandatory Access Control) où même l utilisateur ayant tous les privilèges (root) ne peut modifier la politique de sécurité. Halpern et al. [10] avancent que des politiques de sécurité décrites dans un langage naturel ont une sémantique ambigüe. En revanche, un langage formel (ou une logique) ont une syntaxe et une sémantique très claires. Dans ce papier, nous proposons une logique adéquate pour un système concurrent, nondéterministe et multi-tenant. Pour être utilisable en pratique, notre système formel doit satisfaire les contraintes suivantes : 1. Il doit modéliser la manière dont l information est échangée, à savoir des flux d information directs, transitifs ou intransitifs. 2. Il doit modéliser des systèmes multi-domaines, concurrents et non-déterministes. 3. Il doit être utilisable par des non logiciens tels qu un client IaaS. Lorsque qu ils sont correctement configurés, de nombreux mécanismes de sécurité ont prouvé leur efficacité pratique, par exemple SELinux ou Iptables. Considérant qu une sécurité ne doit pas dépendre d une technologie unique, la formalisation d objectifs de sécurité doit être suffisamment expressive pour être projetée vers la logique interne de ces mécanismes de sécurité. Le papier est organisé comme suit. La section 2 discute des trois contraintes et motive notre travail en examinant les approches de sécurité existantes. La section 3 décrit comment modéliser un système avec des traces de flux d information. La section 4 décrit la syntaxe et la sémantique de notre logique IF-PLTL. La section 5 illustre les propriétés de haut-niveau et étend IF-PLTL avec des annotations pour forcer la dynamicité des ensembles de contextes en montrant son intérêt avec une politique d isolation dynamique des domaines. Enfin, la section 6 conclut avec les perspectives et les questions ouvertes. 2. Motivations Le contrôle de flux d information (IFC) et le contrôle d accès peuvent être vus comme des approches différentes mais potentiellement complémentaires pour assurer la sécurité [11]. En effet, le contrôle d accès spécifie explicitement les permissions d un acteur vis à vis d une action sur une ressource tandis que les flux d informations (IF) sont implicites. Le contrôle de flux d information spécifie explicitement les flux autorisés tandis que les permissions pour réaliser une action particulière sont implicites. Une politique d IF entre deux entités est soit directe, transitive ou intransitive. Supposons une politique autorisant des flux directs d une entité A vers une autre B et également de B vers C. Une politique transitive autorisera un flux direct de A vers C par transitivité. Cependant une politique intransitive refusera un flux direct de A vers C mais permettra un flux de A vers C passant par B. Ces politiques d IF sont difficiles à exprimer [15] mais elles sont essentielles. C est pourquoi, nous devons les inclure dans notre formalisme. Les systèmes d IFC abordent tous types d environnements depuis les systèmes statiques jusqu aux moniteurs de référence (à l exécution). Dans le cas statique, les propriétés d IF sont vérifiées sur un modèle complet du système [8]. Dans le cas dynamique, les propriétés d IF sont

3 vérifiées à l exécution [7]. Dans notre approche, nous proposons un système formel incluant à la fois le cas statique et celui dynamique. A notre connaissance, les travaux les plus proches des nôtres ont été effectués par Basin et al. dans [2]. Leur approache est similaire à la nôtre dans le sens où elle inclut les modalités de temps de la logique temporelle linéaire passée (P-LTL) et elle modélise le comportement d un système avec des (ensembles de) traces. Néanmoins, leur proposition diffère de la nôtre en ne modélisant pas explicitement des flux d information et en définissant un ensemble de relations dépendant du cas d utilisation. Utiliser un IFC dans les Clouds pour assurer des objectifs de sécurité a été mis en avant [1, 16] mais jamais appliqué. L utilisabilité est également un facteur qui doit être pris en compte lorsque l on propose une nouvelle approche de sécurité. En effet, si la description d objectifs de sécurité est trop complexe, alors l approche ne peut être utilisée en pratique. C est pourquoi nous proposons une API de haut-niveau composée de politiques de sécurité généralistes, chaque propriété les composant étant définie formellement. La formalisation présentée dans ce papier est issue du langage PIGA mais revisitée avec plus de formalisme et de généralisation. Le langage PIGA a été utilisé pour implanter des moniteurs de référence dans divers environnements comme PIGA-OS, PIGA-Virt, PIGA-Cluster et PIGA- Dalvik [3, 4]. Aperçu de notre approche Dans cette section, nous avons discuté de la contrainte suivante Il doit modéliser la manière dont l information est échangée, à savoir des flux d information directs, transitifs ou intransitifs et défini le spectre de notre étude aux IFCs systèmes avec analyse statique et monitoring dynamique. La deuxième contrainte Il doit modéliser des systèmes multi-domaines, concurrents et nondéterministes a été motivée principalement par l architecture multi-tenante des Clouds. La dernière contrainte Il doit être utilisable par des non logiciens tels qu un client IaaS est plus intuitive et peut être achevée en proposant une API simple de haut-niveau. Notre objectif est de décider si le comportement d un système, modélisé par des traces, satisfait une politique de sécurité formalisée par des formules logiques. Une trace est une séquence de transitions d états. Un système ne produit par directement des flux d information mais des évènements observables de bas niveau. Ces évènements sont transformés en évènements fonctionnels et finalement en flux d information. Une trace d IF satisfait (ou non) une politique de sécurité, c està-dire un ensemble de formules closes appelé théorie. Enfin, une API adaptée à l utilisateur est proposée via un ensemble de propriétés de haut niveau paramétrables, l exemple de la politique d isolation dynamique des domaines étant donnée dans la section Modélisation d un système : les traces Dans cette section, nous présentons comment construire des traces d IF à partir d évènements de bas niveau. Pour définir la sécurité dans un Cloud IaaS composé de SEs virtuels et physiques, nous devons représenter un système concurrent et non-déterministe. Nous définissons un système primitif comme une boîte noire avec un état interne et une interface acceptant un ensemble d actions. Ainsi, un système est une composition (récursive) de systèmes primitifs (ou systèmes). Toutes entités d un environnement type SE, à savoir les fichiers, processus, bases de données, peuvent être vue comme des systèmes. Chaque machine virtuelle est également un sous-

4 système d un Cloud. Le comportement concurrent d un système peut être modélisé par les traces d exécution générées par ce système [12], où une trace d exécution est une séquence de transitions d états déclenchées par des évènements et vue par un observateur. Nous définissons cet observateur comme une entité passive avec une vue (potentiellement partielle) du système. Supposons un système avec seulement trois entités (a, b, c). a voit une trace partielle composée de tous les évènements partant de ou allant vers lui-même mais il ne peut pas voir les évènements entre b et c. De plus, un évènement de a vers b est à la fois inclus dans les traces de a et de b. Par conséquent, l union de toutes les traces partielles forme une trace complète du système. Les entités étant de types hétérogènes, elles sont identifiées par des contextes, c est-à-dire des références abstraites à des entités ayant un ensemble commun de caractéristiques. Nous supposons l existence d une méthode permettant d attribuer un contexte à toute entité, sachant que deux entités avec le même contexte ont un ensemble commun de caractérisques (comportement, domaine de sécurité, type, etc.). Par la suite, nous notons SC l ensemble de tous les contextes Traces avec évènements observables Le noyau a une vue complète de toutes les traces d un SE. Les appels noyaux, tels que sys_read, sys_write, sys_fork, impliquent une entité source et une entité destination (potentiellement nouvelle dans le cas de sys_fork). Par la suite, nous supposons être capable de capturer le début et la fin de tout appel. À noter qu il est possible d implanter un tel module dans n importe quel noyau [3]. Un évènement observable (Définition 1) est un évènement atomique vu par un observateur. Tous les évènements observables font parti de l ensemble OE (SC EOP SC) où EOP est l ensemble des opérations élémentaires (début_lire, début_écrire, fin_lire,... ). Le triplet (a, eop, b) décrit l opération eop du contexte a vers b. { a, b SC Définition 1 (Évènement observable) oe OE def (a, eop, b) où eop EOP Une trace de bas niveau (Définition 2) produite par le système est un ensemble d évènements observables. La Figure 1a montre un exemple de trace d un système composé de trois entités (a, b, c), une opération de lecture est terminée et une opération d écriture est toujours en cours (pas d évènement de fin). Définition 2 (Trace d évènements observables) T def {oe 1, oe 2,..., oe n } où oe i OE (a) Trace d évènements observables (b) Trace d évènements fonctionnels (c) Trace de flux d information FIGURE 1 Les trois types de traces 3.2. Traces d évènements fonctionnels À partir des évènements de début et de fin, nous pouvons obtenir l évènement fonctionnel correspondant (Définition 3) comprenant l opération fonctionnelle telle que lire, écrire. Une en-

5 tité peut réaliser plusieurs opérations en parallèle. Supposons un contexte a effectuant deux lectures d un contexte b ; par exemple deux entités avec le contexte a lisent un fichier avec le contexte b. Pour associer correctement les évènements de début et de fin, un observateur doit distinguer les deux opérations parallèles de lecture, notamment dans le cas où les sources et les destinations sont identiques. Ainsi, nous supposons deux fonctions est_évènement_début et est_évènement_fin, déterminant respectivement si un évènement observable oe i est le début d une opération fonctionelle op et si un évènement observable oe j est la fin d une opération op commençant avec oe i. Tous les évènements d une trace fonctionnelle (Définition 4) sont dans l ensemble FE (SC FO SC) et toutes les opérations fonctionnelles dans l ensemble FO. Les deux fonctions est_évènement_début et est_évènement_fin sont définies comme suit : est_évènement_début : OE FO {true, false} est_évènement_fin : OE OE {true, false} Définition 3 (Évènement fonctionnel) a, b SC, op FO k [i, j], (a, op, b) k FE def i i, oe i = (a, eop début, b) i est_évènement_début(oe i, op) j j, oe j = (a, eop fin, b) j est_évènement_fin(oe j, oe i ) La notation (a, op, b) k décrit une opération op de a sur b à l instant k. Définition 4 (Trace d évènements fonctionnels) T def {fe 1, fe 2,..., fe n } où fe i FE La Figure 1b illustre le résultat de la projection des évènements observables de la Figure 1a en évènements fonctionnels. Dans cette trace, le premier évènement observable (a, début_lire, b) et le troisième (a, fin_lire, b) sont transformés en un évènement fonctionnel (a, lire, b) ayant lieu à tout instant du début à la fin (inclus) Traces de flux d information Les différents modèles de flux d information diffèrent de part leur expressivité et leurs relations. Cependant, nous pouvons extraire deux relations/opérations communes : La relation propagation vers. Par exemple, une information se propage de a vers b. L opération re-labellisation. Par exemple, une entité labellisée avec a est re-labellisée avec b. Une opération de re-labellisation initiée par une entité est appelé une transition ; par exemple, une entité souhaite transiter du contexte a vers b. Nous considérons trois relations dans nos traces de flux d information : Un flux de a vers b est défini par (a > b). Un anti-flux (l absence de flux) de a vers b est défini par (a b). Une transition de a vers b est définie par (a > t b). Pour transformer des évènements fonctionnels en flux d information, nous introduisons trois fonctions déterminant si une opération fonctionnelle (op FO) est équivalente à une opération lire, écrire ou transiter. est_type_lire, est_type_écrire, est_type_transiter : FO {true, false} Les définitions 5, 6 définissent formellement les deux relations (>, > t ) à partir des fonctions est_type_lire, est_type_écrire, est_type_transiter, la relation étant simplement la négation de >. Tous les évènements d une trace d IF sont inclus dans l ensemble IF.

6 Définition 5 (Relation flux vers) ((b, op, a) est_type_lire(op)) (a > b) IF def op FO ((a, op, b) est_type_écrire(op)) Définition 6 (Relation transition) (a > t b) IF def op FO((a, op, b) est_type_transiter(op)) La Figure 1c illustre le résultat de la projection des évènements fonctionnels de la Figure 1b en flux d information. (a, lire, b) et (c, écrire, b) sont substitués respectivement par (a < b) and (c > b). 4. Propriétés de sécurité : une logique temporelle Un ensemble de traces d exécution d un système est soit généré statiquement à partir d un modèle (sous forme d automate, de réseau de pétri, etc.) soit dynamiquement produit à l exécution. Dans le cas statique, nous obtenons un ensemble de traces (potentiellement) infinies représentant toutes les exécutions possibles vues par un observateur. Dans le cas dynamique, nous obtenons une trace finie par observateur représentant l historique de l exécution courante. Nous présentons dans cette section la syntaxe et sémantique de notre logique temporelle multisortée avec flux d information devant prendre en compte indifféremment les deux cas Logique temporelle multi-sortée avec flux d information Pour modéliser les propriétés de trace, nous utilisons une logique temporelle multi-sortée du premier ordre sur des flux d information. Une logique temporelle définie implicitement l écoulement du temps au cours duquel les formules sont évaluées. Une logique du premier ordre permet l utilisation de quantificateurs pour exprimer des propriétés telles que : Il existe un contexte a depuis lequel un flux est initié. Enfin, une logique multi-sortée, par opposition avec une logique monosorté, permet de définir plusieurs sortes de domaines au lieu d un unique domaine de définition sur lequel les quantificateurs itèrent. La notion de sortes permet de différencier les contextes des domaines sans recourir à une logique du second ordre. Ci-dessous, nous donnons la définition générale d une signature multi-sortée, c est-à-dire les symboles non-logiques (d une logique multi-sortée), puis détaillons la signature concrète de notre logique IF-PLTL. Décrivons tout d abord une signature multi-sortée (Définition 7). Définition 7 (Signature multi-sortée) Une signature multi-sortée est un t-uplet Σ = (S, C, F, P) où : S = {σ 1,..., σ n } où n > 0 et σ i est une sorte. C = {c 1,..., c n } où n 0 et c i est un symbole de constante de sorte σ S. F = {f 1,..., f n } où n 0 et f i est un symbole de fonction d arité m 0 de sortes (σ 1... σ m ) σ où σ i S et σ S. P = {p 1,..., p n } où n 0 et p i est un symbole de prédicat d arité m 0 de sortes (σ 1... σ m ) où σ i S. Les informations de temps peuvent être rendues implicites avec les modalités de PLTL (LTL Passé) [13]. (P-)LTL est un formalisme courant pour exprimer des propriétés de sûreté et de vivacité dans un système concurrent. Clarkson et al. [6] ont démontré qu une propriété de

7 sécurité est une intersection entre une propriété de sûreté et une propriété de vivacité. Alors qu une logique multi-sortée est bien adaptée à la spécification de propriétés d IF, (P-)LTL est bien adapté pour exprimer des propriétés d IF temporelles Syntaxe d IF-PLTL La syntaxe décrit comment construire une formule bien-formée de notre logique. Une formule est dite bien-formée si elle fait partie de notre langage formel. Autrement dit, une formule malformée ne peut être interprétée par notre système. Tout d abord, nous donnons la signature multi-sortée pour des flux d information temporels (Σ IF PLTL ), puis nous décrivons les règles de formation. Σ IF PLTL = (S, C, F, P) avec, {>,,, > t : ctx ctx S = {ctx, dom}, C =, F =, P =, / : ctx domain, / : domain domain} Nous considérons deux sortes ctx et dom pour désigner respectivement des contextes et des domaines (ensembles de contextes). Tout comme pour des traces d IF, les relations d IF (>,, > t ) sont naturellement définies entre contextes. De plus, nous introduisons la relation de flux indirect ( ) sémantiquement différent d un flux direct (>). Ce flux indirect n existe pas dans une trace d IF ; il est inféré à partir d une séquence de flux directs. Par exemple, la trace d IF de la Figure 1c satisfait la propriété c a aux deuxième et troisième instants de part l indirection c > b et b > a. Les relations d appartenance ensembliste (, / ) sont, premièrement, définies entre un contexte et un domaine, mais également entre domaines pour permettre la spécification d ensembles hiérarchiques. Par exemple, supposons un contexte a, un domain Set et un domain SuperSet, nous pouvons définir des relations hiérarchiques avec a Set est vrai, Set SuperSet est vrai et a SuperSet est faux. Ci-dessous, nous détaillons les règles de formations. x σ est une variable de sorte σ. c σ est un symbole de contante de sorte σ. Σ-TERM t ::= x σ c σ f(t 1,..., t n ) où f : σ 1... σ n σ est un symbole de fonction avec Σ-TERM t i de sorte σ i. Σ-ATOM a ::= p(t 1,..., t n ) où p : σ 1... σ n est un symbole de prédicat avec t i Σ-TERM de sorte σ i. Σ-FORMULAE ϕ ::= a ϕ ϕ 1 ϕ 2 ϕ 1 ϕ 2 ϕ 1 ϕ 2 ϕ 1 ϕ 2 σ xϕ(x) σ xϕ(x) X(ϕ) Y(ϕ) ϕ 1 Uϕ 2 ϕ 1 Sϕ 2 où a est un Σ-ATOM et x une variable de sorte σ. Les quatre modalités dérivées sont définies comme suit : Fϕ Uϕ Gϕ F ϕ Pϕ Sϕ Hϕ P ϕ Xϕ (Next) et Yϕ (Previous) sont vrais si ϕ est satisfait respectivement à l instant précédant et à l instant suivant. ϕ 1 Uϕ 2 (Until) est vrai si ϕ 1 est satisfait jusqu à ce que ϕ 2 le soit, ϕ 1 Sϕ 2 (Since) étant l équivalent passé. Nous donnons trois abréviations pour simplifier l expression des formules : ( x y)ϕ(x) ( x)(x y) ϕ(x) ( x y)ϕ(x) ( x)(x y) ϕ(x) (a / s) (a s) Pour simplifier la notation, nous supposerons les sortes comme implicitement définies. Par exemple, dans la formule ( a, b)(a > b), a, b sont de sorte ctx, la relation > n étant définie qu entre deux contextes.

8 Nom Séquent Flux intransitif (a > b) i (b > c) j, i j (a c) j L intérêt de règles de Introduction de l anti-flux (a > b) i (a b) i déduction est de pouvoir réaliser des preuves Implication du flux de transition (a > t b) i (a > b) i Élimination de l anti-flux (a b) i (a > b) i et théorèmes comme Flux de transition transitif (a > t b) i (b > t c) i (a > t c) i prouver l équivalence TABLE 1 Arguments dérivés entre deux formules. Nous disposons de toutes les règles classiques de la logique du premier ordre (Système dit d Hilbert), de PLTL et la Table 1 décrit les arguments pour les quatre relations sur les flux d information (>,, > t, ). La notation simplifiée (a > b) i décrit la relation > entre les variables a, b (de sorte implicite ctx) au moment i Sémantique d IF-PLTL La sémantique décrit comment évaluer une formule arbitraire bien-formée d IF-PLTL. Tout d abord, nous définissons ce qu est une structure multi-sortée du premier ordre (Définition 8) obtenue à chaque moment de l exécution ; il n y a pas de notion de temps dans cette structure. Puis, nous définissons une structure temporelle du premier ordre (Définition 9) interprétant l écoulement du temps. Ensuite, nous donnons la définition de la relation de satisfaction ( =) entre une structure IF-PLTL et une formule IF-PLTL. Enfin, nous illustrons ce qu est une interprétation avec l exemple de la propriété de non-interférence. Une structure multi-sortée du premier ordre M est composée d un domaine D et d une fonction d interprétation I. Le domaine est l ensemble de tous les objets de sortes ctx, dom. La fonction d interprétation définit la signification de tous les symboles pouvant apparaître dans une formule (sans les modalités temporelles). Définition 8 (Structure multi-sortée du premier ordre) Une Σ IF PLTL -structure (ou modèle) temporelle du premier ordre est un t-uplet M = (D, I) avec : 1. D = σ S D σ un domaine multi-sorté avec D σ un domaine non-vide. σ 1, σ 2 S, D σ1 D σ2 =. 2. I une fonction d interprétation sur D satisfaisant les propriétés suivantes : (a) Toute sorte σ S est projetée vers un domaine non-vide D σ. (b) Tout symbole de constante c C de sorte σ est projeté vers un élément c I D σ. (c) Tout symbole de fonction f F d arité σ 1... σ n σ est projeté vers une fonction f I : D σ1... D σn D σ. (d) Tout symbole de prédicat p P d arité σ 1... σ n est projeté vers un sous-ensemble p I D σ1... D σn. Une structure temporelle du premier ordre M est composée de l écoulement du temps F, du même domaine D et d une fonction A associant à tout moment de l exécution une structure multi-sortée du premier ordre telle qu introduite précédemment. Définition 9 (Structure temporelle du premier-ordre) Une Σ IF PLTL -structure (ou modèle) temporelle du premier ordre est définie par M = F, D, A avec : 1. F = T, < une ordre linéaire strict représentant l écoulement du temps avec T N. 2. D = σ S D σ un domaine multi-sorté avec D σ un domaine non-vide. σ 1, σ 2 S, D σ1 D σ2 =. 3. A une fonction associant à tout moment k T une structure multi-sortée du premier ordre A(k) = D, I k avec I k l interprétation au moment k.

9 Nous utilisons la notation (M, k) pour désigner une structure multi-sortée du premier ordre au moment k. La relation de satisfaction (ou de vérité) (M, k) = ϕ entre un modèle (structure) M et une formule ϕ au moment k est definie comme suit : (M, k) = (a > b) ssi (a > b) I k (>) (M, k) = (a > t b) ssi (a > t b) I k (> t ) (M, k) = (a s) ssi (a s) I k ( ) (M, k) = (a b) ssi (M, k) = (a > b) (M, j) = (c > b) (M, k) = (a b) ssi i, j, (0 i j k), ctx c et (M, i) = (a > c) (a c) (M, k) = ϕ ssi (M, k) = ϕ (M, k) = ϕ 1 ϕ 2 ssi (M, k) = ϕ 1 et (M, k) = ϕ 2 (M, k) = ϕ 1 ϕ 2 ssi (M, k) = ϕ 1 ou (M, k) = ϕ 2 (M, k) = ϕ 1 ϕ 2 ssi (M, k) = ϕ 1 ou (M, k) = ϕ 2 (M, k) = ϕ 1 ϕ 2 ssi (M, k) = ϕ 1 ϕ 2 et (M, k) = ϕ 2 ϕ 1 (M, k) = σ xϕ(x) ssi (M, k) = ϕ[x I /x] pour tout x I D σ (M, k) = σ xϕ(x) ssi (M, k) = ϕ[x I /x] pour un x I D σ (M, k) = Xϕ ssi k + 1 < T et (M, k + 1) = ϕ (M, k) = Yϕ ssi 0 < k et (M, k 1) = ϕ (M, i) = ϕ 2 (M, k) = ϕ 1 Uϕ 2 ssi i, (k i < T ), et j, (k j < i), (M, j) = ϕ 1 (M, i) = ϕ 2 (M, k) = ϕ 1 Sϕ 2 ssi i, (0 i k), et j, (i < j k), (M, j) = ϕ 1 Isolation et Non-interférence Un problème majeur dans les Clouds concerne l isolation des tenants. Goguens et Meyers [9] définissent la propriété d isolation à partir de deux propriétés de non-interférence. Les auteurs dénotent par D 1 : D 2 qu un groupe d utilisateurs D 1 n interfère pas avec un groupe d utilisateurs D 2 et l isolation entre D 1 et D 2 est définie comme une non-interférence mutuelle, soit D 1 : D 2 et D 2 : D 1. En terme de flux d information, la propriété de non-interférence D 1 : D 2 signifie que l information ne peut, directement ou indirectement, se propager de D 1 vers D 2, ce qui peut être traduit par u 1 D 1, u 2 D 2, ((u 1 u2) (u 1 > u 2 )). Illustrons maintenant l interprétation avec la propriété FIGURE 2 Scénario d IF avec trois groupes (D 1, D 2, D 3 ) et six entités (a, b, c, d, e, f) de non-interférence. Supposons le scénario représenté par la Figure 2. Cette figure doit être lue comme suit : À l instant 1, l information se propage de a vers b, puis à l instant 2 de f vers e, et ainsi de suite aux instants 3 et 4. À l instant 5, il y a une transition de c vers f signifiant que l entité labellisée avec c souhaite être re-labellisée avec f. La Table 2 détaille pour tout moment k l interprétation de chaque relation (>, > t, ).

10 Instant k Trace (a > b) (f > e) (b > f) (f > d) (c > t f) I k (>) {(a > b)} {(f > e)} {(b > f)} {(f > d)} {(c > f)} I k (> t) {(c > t f)} I k ( ) D 1 = {a, b, c} idem idem idem idem D 2 = {d, e} D 3 = {f} D 1 : D 2 true true true false true TABLE 2 Interprétation et satisfaction de la non-interférence entre D 1 et D 2. Nous avons motivé l utilisation d une logique temporelle multi-sortée avec flux d information et introduit la syntaxe/sémantique de IF-PLTL. De plus, nous avons montré comment spécifier la propriété de non-interférence en IF-PLTL et comment la vérifier sur une trace d IF. 5. Dynamicité : opérateurs sur les ensembles Comme illustré par l exemple de la non-interférence (Figure 2 et Table 2), l interprétation de la relation ensembliste ( ) est identique à tout moment k. De plus, il n y a ni fonction ni relation permettant de changer cette interprétation durant l exécution, c est-à-dire de modifier l appartenance à un ensemble. Ci-après, nous présentons une politique, l isolation des domaines, où des ensembles dynamiques peuvent présenter un intérêt, puis nous détaillons notre proposition basée sur des annotations de formules. Enfin, nous décrivons la politique d isolation dynamique des domaines. En effet, les ensembles dynamiques sont nécessaires pour augmenter la flexibilité des propriétés et ainsi permettre la prise en compte de la dynamicité des systèmes. Supposons une politique d isolation des domaines stricte définie par la propriété 1 où deux entitités (a, b) peuvent échanger des informations si elles sont dans le même domaine (Dom i ). Avec une telle politique, une entité n appartenant à aucun domaine ne peut pas envoyer d information à quiconque. Ainsi, toutes les entités du système doivent être correctement labellisées avec un domaine, ce qui est une tâche complexe et chronophage. Propriété 1 (Isolation des domaines) DI(DOMs) ( a, b)g((a > b) ( Dom i DOMs)(a, b Dom i )) FIGURE 3 Scénario avec différents départements pour une isolation dynamique des domaines. Considérons le scénario décrit par la Figure 3. Une compagnie externalise ses services dans le Cloud. Cette compagnie est composée de deux départements, R&D et ressources humaines (RH), et chaque département possède des données confidentielles. Le département de R&D possède une base de donnée pour un gestionnaire de projet (données_project). Le département des RH possède toutes les données privées des employés (données_employés). Dû à la branche R&D, la société doit tester des versions d un logiciel (app_nonstable) qui sont donc non sûres et doivent être isolées du reste des services. Par ailleurs, la compagnie teste régulièrement des logiciels externes dans lequels elle n a pas totalement confiance (app_nonfiable). Enfin, la société dispose de plusieurs applications (app1_entreprise, app2_entreprise) pouvant varier

11 au fil du temps (par exemple, ajout d une app3_entreprise). La politique de l entreprise définit qu une application ne peut accéder à la fois aux domaines R&D et RH mais sans connaître a priori quelle application accède à quelles données. L idée est donc de contaminer les applications avec le domaine auquel elles appartiennent selon le premier accès réalisé. Par exemple, si app1_entreprise accède à données_project, elle fera partie du domaine R&D. Notre politique d isolation dynamique des domaines est décomposée en trois propriétés. Supposons DOMs contenant les domaines et les bacs à sable, alors l information peut se propager d un contexte a vers un contexte b si : 1. a, b appartiennent au même ensemble Dom i (de DOMs). Cette contrainte correspond à l isolation statique des domaines (propriété 1). 2. ou a n appartient à aucun ensemble. 3. ou a appartient à Dom i et b n appartient à aucun ensemble, alors b devient membre de Dom i. Nous proposons la syntaxe ϕ[[annotation]] signifiant que Annotation est effectué lorsque ϕ est vrai. Une annotation pour modifier l appartenance à des ensembles serait donc [[S S {x}]], c est-à-dire x devient membre de S. La propriété 2 traduit les trois propriétés précédentes en IF-PLTL. Propriété 2 (Isolation dynamique des domaines) DI(DOMs) ( a, b)g((a > b) ( Dom i DOMs)(a / Dom i )) DDI(DOMs) ( a, b)( Dom i DOMs)G ( ((a > b) (a Dom i ) ( Dom j DOMs)(b / Dom j )) [Dom i Dom ) i {b} ] Ainsi, nous avons contruit une propriété d isolation dynamique des domaines (DDI). Un client IaaS doit donc simplement appeler la fonction DDI avec son paramètre DOMs ; par exemple, DDI({R&D, R&H, Env.Test, Autres}). Nous avons montré les bénéfices de l utilisation d annotations pour étendre notre logique avec des ensembles dynamiques. De plus, les annotations peuvent être utilisées pour spécifier des capacités actives de l observateur (qui n est donc plus passif ) ne se limitant pas à l exemple des ensembles dynamiques. 6. Conclusion Tout d abord, nous avons motivé le besoin d un langage d IFC formel pour des systèmes distribués et montré la différence entre notre approche et les précédentes. Puis, nous avons présenté notre langage formel permettant l expression de propriétés de sécurité avancées contrôlant différents types de flux d information : directs, transitifs et intransitifs. En utilisant ces opérateurs, notre Information Flow Past Linear Time Logic (IF-PLTL) permet l expression de diverses propriétés ou politiques de sécurité telles que la non-interférence. De plus, nous avons montré comment construire une trace d IF à partir des évènement de bas niveau d un système. Pour faciliter l utilisation d IF-PLTL, nous avons proposé une API de haut niveau pouvant être utilisée et paramétrée par des clients IaaS pour exprimer leurs objectifs de sécurité. Enfin, nous avons montré comment étendre IF-PLTL pour prendre en compte la dynamicité des systèmes et proposé une nouvelle politique de sécurité nommée isolation dynamique des domaines. Par la suite, nous proposerons des méthodes pour assurer la composabilité des différentes propriétés. Nous travaillerons également sur le découpage de propriétés IF-PLTL pour un ensemble d observateurs collaboratifs, en particulier des observateurs à différents niveaux du Cloud (IaaS, PaaS, SaaS). Enfin, une étude intéressante serait de déterminer la cohérence (ou non) d une théorie exprimée en IF-PLTL.

12 Bibliographie 1. Bacon (J.), Evans (D.), Eyers (D. M.), Migliavacca (M.), Pietzuch (P.) et Shand (B.). Enforcing End-to-End Application Security in the Cloud (Big Ideas Paper). In Proceedings of the ACM/IFIP/USENIX 11th International Conference on Middleware, Middleware 10, Middleware 10, pp , Berlin, Heidelberg, Springer-Verlag. 2. Basin (D.), Klaedtke (F.) et Müller (S.). Policy monitoring in first-order temporal logic. In : Computer Aided Verification, éd. par Touili (T.), Cook (B.) et Jackson (P.), pp Springer Berlin Heidelberg, janvier Blanc (M.), Bousquet (A.), Briffaut (J.), Clevy (L.), Gros (D.), Lefray (A.), Rouzaud-Cornabas (J.), Toinard (C.) et Venelle (B.). Mandatory access protection within cloud systems. In : Security, Privacy and Trust in Cloud Systems, éd. par Nepal (S.) et Pathan (M.), pp Springer Berlin Heidelberg, Briffaut (J.), Peres (M.), Rouzaud Cornabas (J.), Solanki (J.), Toinard (C.) et Venelle (B.). PIGA-OS : Retour sur le Système d Exploitation Vainqueur du Défi Sécurité. In 8ème Conférence Française en Systèmes d Exploitation, St Malo, France, Caron (E.), Desprez (F.) et Rouzaud-Cornabas (J.). Smart resource allocation to improve cloud security. In : Security, Privacy and Trust in Cloud Systems, éd. par Nepal (S.) et Pathan (M.), pp Springer Berlin Heidelberg, Clarkson (M. R.) et Schneider (F. B.). Hyperproperties. J. Comput. Secur., vol. 18, n6, septembre 2010, pp Clemente (P.), Rouzaud-Cornabas (J.) et Toinard (C.). From a generic framework for expressing integrity properties to a dynamic mac enforcement for operating systems. In : Transactions on Computational Science XI, éd. par Gavrilova (M.), Tan (C.) et Moreno (E.), pp Springer Berlin Heidelberg, Dimitrova (R.), Finkbeiner (B.), Kovács (M.), Rabe (M. N.) et Seidl (H.). Model checking information flow in reactive systems. In : Verification, Model Checking, and Abstract Interpretation, éd. par Kuncak (V.) et Rybalchenko (A.), pp Springer Berlin Heidelberg, janvier Goguen (J. A.) et Meseguer (J.). Security policies and security models. In IEEE Symposium on Security and privacy, Halpern (J. Y.) et Weissman (V.). Using first-order logic to reason about policies. ACM Trans. Inf. Syst. Secur., vol. 11, n4, juillet 2008, p. 21 :1 21 : Kafura (D.) et Gracanin (D.). An information flow control meta-model. In Proceedings of the 18th ACM Symposium on Access Control Models and Technologies, SACMAT 13, SACMAT 13, p , New York, NY, USA, ACM. 12. Lamport (L.). Specifying concurrent program modules. ACM Trans. Program. Lang. Syst., vol. 5, n2, avril 1983, p Pnueli (A.). The temporal logic of programs. In the 18th Annual Symposium on Foundations of Computer Science, 1977, pp , Rodero-Merino (L.), M. Vaquero (L.), Caron (E.), Desprez (F.) et Muresan (A.). Building safe paas clouds : a survey on security in multitenant software platforms. Computers & Security, vol. 31, 2012, pp Rushby (J.). Security requirements specifications : How and what. In Symposium on Requirements Engineering for Information Security (SREIS), Sandhu (R.), Boppana (R.), Krishnan (R.), Reich (J.), Wolff (T.) et Zachry (J.). Towards a Discipline of Mission-Aware Cloud Computing. In Proceedings of the 2010 ACM workshop on Cloud computing security workshop, pp , 2010.