Sécurité des Systèmes Répartis- Partie2 - non interférence

Dr. Lilia SFAXI

Sécurité des ��Systèmes Répartis Partie 1I : Contrôle de Flux D’Information

et Non-Interférence

Doctorants ETIC, Ecole Polytechnique de Tunisie 2014

Rappel ��Mécanismes de Sécurité Usuels

Contrôle d’accès Vérifier l’authentification et l’autorisation Définir une matrice de contrôle d’accès

Primitives Cryptographiques Hachage : Assurer l’intégrité du message Chiffrement : Assurer la confidentialité du message Signature : Assurer l’intégrité et la non répudiation Certificat : Assurer l’authentification

Délégation Délégation des droits et permissions à un sujet tierce Optimisation du nombre d’identités stockées 2

Problème …

Mécanisme de sécurité ponctuels

Ne garantissent pas une sécurité de bout en bout

è  Nécessité du contrôle de la propagation de l’information

3

Notions de Base��Donnée, Information

Donnée Élément brut, sans interprétation ni contexte

Exemple: String mdp = « azerty » è Donnée

Information Donnée interprétée, mise en contexte Crée une valeur ajoutée pour son intercepteur

Exemple: la variable mdp entrée comme mot de passe pour accéder à une application en fait une information, qui peut être dangereuse si elle est divulguée

4

Notions de Base��Flux d’Information

Flux d’Information Acheminement d’une information d’une donnée à une autre Suivi du flux d’information: permet de voir quelles entités ont eu accès à une information

Exemple: String mdpModif = mdp + « ! » è Flux d’information de mdp vers mdpModif

Suivi du Flux d’Information Trouver toutes les données/entités ayant eu accès à une information

Exemple: mdp et mdpModif ont eu accès à l’information « mot de passe » 5

Suivi du Flux d’Information L’information circule dans un système:

Entre les données Entre les modules et composants (logiciels et matériels) Entre les acteurs / sujets

Assurer les propriétés d’authentification, de confidentialité et d’intégrité ne garantit pas toujours que les données circulent de manière autorisée par leurs propriétaires

6

A!

B!

C!

Suivi du Flux d’Information

7

LA NON-INTERFÉRENCE : �� CONCEPT ET DÉFINITIONS

Contrôle de Flux D’Information et Non-Interférence

8

Non-Interférence Modèle de Contrôle de Flux d’Information (CFI) Définie par Goguen et Meseguer en 1982

Mais implémentée récemment

Objectif : S’assurer que les données sensibles n’affectent pas le comportement publiquement visible du système

Permet : Le suivi de l’information dans le système L’application de la confidentialité et de l’intégrité de bout en bout

9

NI : Définition Informelle

Si un attaquant peut observer des données jusqu’à un

niveau de sécurité o , alors une modification d’une variable

de niveau de sécurité plus haut que o est indiscernable

pour cet attaquant

10

Les sorties observables à un niveau o doivent être

indépendantes des entrées à des niveaux plus restrictifs que o

NI : Définition Informelle

Si un attaquant peut observer des données jusqu’à un

niveau de sécurité o , alors une modification d’une variable

de niveau de sécurité plus haut que o est indiscernable

pour cet attaquant

11

Les sorties observables à un niveau o doivent être

indépendantes des entrées à des niveaux plus restrictifs que o

Niveaux de Sécurité : Étiquettes

Données sont classifiées selon leur niveau de sécurité

Pour définir un niveau de sécurité, on associe à la donnée une étiquette (label)

Étiquette de sécurité : Paire de : Niveau de confidentialité (S pour Secrecy) Niveau d’intégrité (I pour Integrity)

Notée { S ; I } 12

Niveaux de Sécurité : Étiquettes Les étiquettes de sécurité sont classées par ordre de

restriction

Une étiquette de sécurité e1 est au plus aussi restrictive qu’une étiquette e2 si le niveau de sécurité de e1 est

moins haut ou égal à celui de e2

Notée : e1 ⊆ e2 13

Treillis de Sécurité La relation ⊆ détermine le sens de circulation d’une

information

Restriction de non-interférence :

Quand l’information circule dans le système, les étiquettes deviennent uniquement plus restrictives

Les étiquettes du système, régies pas la relation de restriction, permettent de définir un treillis de sécurité

14

Treillis de Sécurité Treillis : ordonne les étiquettes du système de la

moins restrictive (en bas du treillis) vers la plus restrictive (en haut du treillis)

Exemple de treillis :

15

e1

e2 e3

e4

e4 ⊆ e2 ⊆ e1

e4 ⊆ e3 ⊆ e1

e2 et e3 sont incomparables

Circulation de l’Information

NI : Définition Formelle Plusieurs définitions formelles de la non-interférence

dans la littérature [Goguen82, Rushby92, Malecha10, Myers06]

Nous avons opté pour la définition de [Malecha10] La plus récente Applicable aussi bien pour un programme que pour des composants interconnectés (notre cas)

[Malecha10] ramène le problème de la non-interférence à un problème d’indiscernabilité (indistinguishability) entre plusieurs états de la mémoire

16

NI : Définition Formelle (1/3) Soit le vocabulaire suivant s : programme L : ensemble de niveaux de sécurité dans le programme ⊆L: ordre partiel sur L, définit les informations pouvant

circuler entre deux niveaux de sécurité Φ = (L , ⊆L ) : la politique de sécurité UL : Opérateur de jointure :

Pour les niveaux de sécurité p et q, il existe p UL q ∈ L qui a pour limite supérieure à la fois p et q.

σ = [x ⟼ v] : mémoire. Représente une configuration associant une variable x à une valeur v.

17

NI : Définition Formelle (2/3) Soit le vocabulaire suivant Γ : environnement de variables. Représente un sous ensemble de

variables, dont un observateur à un niveau de sécurité o ∈ L peut observer les valeurs •  Γ ⊢ σ1 ≈o σ2

σ1 et σ2 sont indiscernables par rapport à o dans Γ Pour toutes les variables x que le niveau de sécurité o peut observer, on a :

σ1(x) = σ2(x) •  On dit aussi que « Γ protège x au niveau o » si x n’est observable à

aucun niveau de sécurité moins restrictif que o Φ ⊢ s, σ →* v, σ’

•  Fermeture transitive de la sémantique opérationnelle à petits pas •  Pour la politique de sécurité Φ et avec la configuration σ, le

programme s est évalué à la valeur v et à la mémoire σ’ 18

NI : Définition Formelle (3/3) Un programme s satisfait la propriété de non-interférence

pour un niveau de sécurité o sous l’environnement Γ si, •  pour toutes les politiques de sécurité Φ, •  pour toutes les configurations σ, •  pour toutes les variables h telles que Γ protège h à un

niveau o’ avec o ⊈L o’ , et •  pour toutes les valeurs v1 et v2 du même type :

Si Φ ⊢ s, σ [h ⟼v1] →* v’1 , σ’1 et Φ ⊢ s, σ [h ⟼v2] →* v’2 , σ’2 alors

Γ ⊢ σ’1 ≈o σ’2 et v’1 = v’2

19

Pour Résumer… Si un attaquant peut observer des données jusqu’à

un niveau de sécurité o, alors une modification d’une variable de niveau de sécurité plus haut est indiscernable pour cet attaquant. Les résultats ou sorties observables à un niveau o

doivent être indépendants des entrées à des niveaux plus restrictifs que o.

20

Interférences dans le Code��Interférence Explicite Affectation :

21

class NI {

boolean secretVar;

boolean publicVar;

public void start(){

secretVar = publicVar;

publicVar = ! secretVar;

}

}

INTERFERENCE! Flux d’information d’une donnée secrète

vers une donnée publique!

Interférences dans le Code��Interférence Implicite Bloc de Contrôle :

22

class NI {

boolean secretVar;

boolean publicVar;


if (secretVar){

publicVar = true;

} else{

publicVar = false;

}

}

}

INTERFERENCE! Équivalent à publicVar = secretVar ! Modification d’une donnée dans un

contexte plus restrictif

Interférences dans le Code��Interférence Implicite Appel de Méthode :

23

class NI {

boolean secretVar;

boolean publicVar = false;


if (secretVar){

modif();

}

}

public void modif(){

publicVar = true;

}

}

INTERFERENCE! Appel d’une méthode, modifiant une variable publique, dans un contexte

plus restrictif

Interférences dans le Code��Référencement

Cas des langages orientés objet

Référencement (aliasing) des objets peut créer une interférence

Un même objet peut être référencé par plusieurs variables de niveau de sécurité différents

24

Interférences dans le Code��Référencement

25

class MyClass { int pa = 0;}

class NI {

MyClass p1= new MyClass(); MyClass p2= new MyClass();

MyClass s1;

int s2;


if (s2>0) {

s1= p1;

} else {

s1= p2;

}

s1.pa= 40;

}

}

Pas d’Interférence dans le bloc de contrôle La variable modifiée dans un contexte

restrictif est une variable privée

INTERFERENCE! En observant p1.pa et p2.pa, je peux savoir

si s2>0 ou non

Pour Avoir un Code ��Non-Interférent : •  Il ne faut pas faire d’affectation directe d’une

variable privée vers une variable publique •  Il ne faut pas modifier une variable dans un

contexte plus restrictif •  Attention aux blocs de contrôle, surtout imbriqués! •  Attention aux appels de méthodes!

•  Il ne faut pas modifier les attributs publics d’un objet à partir d’une référence privée

26

Sans oublier…

Les exceptions

Les threads

Les canaux temporels

Les ressources partagées

…

27

Cependant… TOUS les systèmes sont interférents! Il est impossible, voire même indésirable, d’obtenir un système

complètement non-interférent L’interférence la plus connue, et la plus inévitable : La

vérification du mot de passe Variable secrète : mot de passe Variable publique : la réponse du serveur (mot de passe valide ou pas) ⇒ La modification de la variable secrète entraîne celle de la variable publique

Même minime, c’est une interférence, qui peut fragiliser le système si l’attaquant utilise un script pour essayer les combinaisons possibles du mot de passe

28

Mais également… Autre interférence célèbre et inévitable :

Le Chiffrement!

La variable publique (le cryptogramme) dépend de la valeur de la variable privée (le message secret à chiffrer)

Mais, comme on peut le remarquer, certaines interférences peuvent être tolérées, mais surveillées de près: Interdire plusieurs essais de mots de passes pas la même personne Les questions de sécurité (pour vérifier qu’on est un être humain) Algorithmes de chiffrement complexes impossibles à déchiffrer …

29

Rétrogradation Il faut donc un mécanisme pour permettre de relaxer le

niveau de sécurité d’une donnée, et autoriser ainsi une interférence, sous certaines conditions

Mécanisme de Rétrogradation (Downgrading)

Une rétrogradation peut être possible : Pour un acteur particulier, après qu’il ait payé pour obtenir l’information Après une certaine période de temps Si la quantité d’information révélée est trop mince pour être une menace (login, chiffrement…)

30

MODÈLES DES ÉTIQUETTES DE SÉCURITÉ Contrôle de Flux D’Information et Non-Interférence

31

Étiquettes de Sécurité Attribuent un niveau de sécurité aux données

Étiquette d’une donnée d dans l’ensemble d’étiquettes L est noté : l (d )

Si le contenu d’une donnée d1 affecte celui d’une autre donnée d2, c’est qu’il existe un flux d’information de d1 vers d2. Le flux est non-interférent ssi :

l (d1 ) ⊆ l (d2 ) Il existe plusieurs modèles dans la littérature…

32

Modèle d’Étiquettes Décentralisé DLM : Decentralized Label Model [Myers00] Modèle décentralisé : la politique de sécurité n’est pas

définie par une autorité centrale, mais contrôlée par les différents acteurs du système

Le système doit ensuite faire en sorte de respecter cette politique

Définition de la notion de propriété d’une étiquette Un participant peut rétrograder le niveau de sécurité de ses étiquettes, mais pas celle des autres

Entités principales : Autorités et Étiquettes

33

Modèle d’Étiquettes Décentralisé��Autorités

Autorités ou Principals : Entités qui possèdent, modifient et publient les informations

Représentent les utilisateurs, groupes ou rôles Quelques autorités ont le droit d’agir pour d’autres

A peut agir pour A’ ⇒ A possède tous les pouvoirs et privilèges de A’

Agit pour : relation réflexive et transitive ⇒ définition d’une hiérarchie ou ordre partiel entre les autorités A agit pour B est notée : A ≽ B

Tous les pouvoirs de B sont délégués à A

34

Modèle d’Étiquettes Décentralisé��Étiquettes

Une étiquette (label) est composée de deux parties: Une étiquette de confidentialité Une étiquette d’intégrité

Chacune des étiquettes contient un ensemble d’éléments d’étiquette : expriment les besoins de sécurité définis par les autorités

Élément d’étiquette a deux parties : Propriétaire : Acteur propriétaire de l’élément Lecteurs (confidentialité) ou Écrivains (intégrité)

Objectif de l’élément d’étiquette : Protéger les données privées de son propriétaire Représente la politique d’utilisation de la donnée

35

Modèle d’Étiquettes Décentralisé��Étiquettes de Confidentialité

Exprime le niveau de secret désiré par le propriétaire d’une donnée

Cite la liste des lecteurs potentiels de la donnée Ce sont les autorités auxquelles l’élément d’étiquette permet de consulter la donnée Propriétaire = Source de la donnée Lecteurs = Destinataires possibles

Les autorités qui ne sont pas listées comme lecteurs ne peuvent pas consulter la donnée

Toutes les politiques d’une étiquette doivent être respectées

Une information étiquetée ne doit être divulguée que suite à un consensus entre toutes ses politiques

36

Seuls les utilisateurs dont les autorités peuvent agir pour r2 peuvent lire les données étiquetées par lC


Exemple :

lC = { o1 → r1, r2 ; o2 → r2, r3}

•  o1, o2, r1, r2 et r3 : autorités

•  Le « ; » sépare deux éléments (politiques) de l’étiquette

•  o1 et o2 représentent respectivement les propriétaires des deux politiques de sécurité, r1, r2 et r3 en représentent les lecteurs

Un utilisateur peut lire les données seulement si l’autorité représentant cet utilisateur peut agir pour un lecteur de chaque politique de l’étiquette

37


Relation d’ordre : au plus aussi restrictive que Soit lC1 = { o1 → r1, r2 ; o2 → r2, r3} et lC2 = { o1 → r1 ; o2 → r2, r3} On dit que : lC1 ⊆ lC2 Car :

•  Du point de vue de o1 , lC1 autorise plus de lecteurs que lC2 •  Une donnée étiquetée lC1 est donc moins restrictive, car plus

publique lC3 = { o1 → r1 ; o2 → r2, r3,r4}

Est incomparable avec lC1, car : { o1 → r1, r2 } ⊆{ o1 → r1 } et {o2 → r2, r3,r4} ⊆ {o2 → r2, r3}

38

Modèle d’Étiquettes Décentralisé��Étiquettes d’Intégrité

Duales aux étiquettes de confidentialité

Politique d’intégrité protège les données contre les modifications inappropriées

Étiquette d’intégrité garde la trace de toutes les sources qui ont affecté la valeur de sa donnée, même indirectement

Même structure qu’une politique de confidentialité, sauf qu’elle définit un ensemble d’écrivains : autorités autorisées à modifier la donnée

Plusieurs politiques d’intégrité représentent des garanties indépendantes de qualité de la part de leurs propriétaires

39


Exemple : lI = { o1 ← w1, w2 ; o2 ← w2, w3}

•  o1 et o2 représentent respectivement les propriétaires des deux politiques de sécurité, w1, w2 et w3 en représentent les écrivains

•  o1 ← w1, w2 : garantie fournie par l’autorité o1 que seuls w1 et w2 sont capables de modifier la valeur de la donnée

•  L’étiquette d’intégrité la plus restrictive est celle qui ne contient aucune politique : {} Elle ne fournit aucune garantie sur le contenu de la valeur Peut être utilisée comme valeur d’entrée uniquement quand le destinataire n’impose aucune exigence d’intégrité 40


Relation d’ordre : au plus aussi restrictive que Soit lI1 = { o1 ← w1, w2} et lI2 = { o1 ← w1 } On dit que : lI2 ⊆ lI1 Car :

•  Une variable d’étiquette lI2 a été affectée uniquement par w1 •  lI1 autorise w1 et w2 à la modifier

lI3 = { o1 ← w1, w3} ⊈ lI1 w3 n’est pas autorisé par lI1 à modifier la donnée

lI4 = { o1 ← w1 ; o2 ← w3} ⊆ lI1 Du point de vue de o1, la relation est respectée L’ajout de o2représente une garantie supplémentaire, indépendante pour lI4

41

Modèle d’Étiquettes à base de Jetons

Inspiré de [Krohn07, Zeldovich06] Une étiquette est un couple de niveaux de

confidentialité et d’intégrité Un niveau est un ensemble de jetons (tags)

Jeton : terme opaque qui, sorti de son contexte, n’a pas de signification précise, mais dans une étiquette, permet d’attribuer aux données une catégorie de confidentialité ou d’intégrité

l = {S ; I} avec S: niveau de confidentialité et I: niveau d’intégrité

42

Modèle d’Étiquettes à base de Jetons��Confidentialité

Associer un jeton j de confidentialité (j ∈ S) à une

donnée d : d contient une information privée de niveau de confidentialité j Pour révéler le contenu de d, le système doit obtenir l’accord pour chacun des jetons de confidentialité qui l’ornent

43

Modèle d’Étiquettes à base de Jetons��Intégrité

Associer un jeton i d’intégrité (i ∈ I) à une donnée d :

i attribue une garantie d’authenticité de l’information dans d i permet au destinataire de s’assurer que d n’a pas été modifiée par des parties non fiables

i est une garantie supplémentaire pour la donnée

44

Modèle d’Étiquettes à base de Jetons��Relation d’ordre

Relation d’ordre partielle : peut circuler vers ⊆

Ordonne les étiquettes de la moins restrictive vers la plus restrictive

Décomposée en deux sous-relations : ⊆C : ordonne les niveaux de confidentialité ⊆I : ordonne les niveaux d’intégrité

Soient l1 ={ S1; I1 } et l2 = { S2; I2 } l1 ⊆ l2 ssi S1 ⊆C S2 et I1 ⊆I I2

45


Confidentialité S1 ⊆C S2 ssi ∀j1 ∈ S1, ∃ j2 ∈ S2, tel que j1 = j2

Intégrité I1 ⊆I I2 ssi ∀i2 ∈ I2, ∃ i1 ∈ I1, tel que i1 = i2

Réunion Soient deux étiquettes l1 ={ S1; I1 } et l2 = { S2; I2 }. l ={ S; I } est la réunion de l1 et l2 ssi:

S = S1 U S2 et I = I1 ∩ I2

Corollaire ∀l, l1, l2 ∈ L, si l ⊆ l1 et l ⊆ l2 alors l ⊆ l1 U l2

46


Transitivité si l 1 ⊆ l2 et l2 ⊆ l3 alors l1 ⊆ l3

Réflexivité ∀l ∈ L, l ⊆ l

Antisymétrie l 1 ⊆ l2 et l2 ⊆ l1 ⇔ l1 = l2

47

Modèle d’Étiquettes à base de Jetons��Treillis de Sécurité

Ordonne l ’ensemble des étiquettes d’un système de la moins restrictive vers la plus restrictive

Mont re l ’ a chem inemen t a u t o r i s é d ’ u n fl u x d’information : du bas vers le haut du treillis

Exemple de treillis avec deux jetons de confidentialité j1 et j2 et un jeton d’intégrité i :

48

{ j1,j2 ; }

{ j2 ; } { j1 ; } { j1,j2 ; i }

{ }

{ j2 ; i } { j1 ; i }

{ ; i }

ETAT DE L’ART: ��SYSTÈMES DE CONTRÔLE DE FLUX D’INFORMATION

Contrôle de Flux D’Information et Non-Interférence

49

Systèmes de CFI

Il existe dans la littérature plusieurs solutions pour le Contrôle de Flux d’Information (CFI)

Nous les avons réparti principalement en deux types: CFI statique : le contrôle du flux se fait uniquement à la compilation CFI dynamique : le contrôle de flux se fait pendant l’exécution

50

Vérification Statique de la NI Analyse statique du code source d’un programme, et

ce avant son exécution S’assurer que les opérations qu’ils réalise respectent la politique de sécurité du système Suivi de chaque flux d’information dans le système

Deux types de solutions : Solutions centralisées Solutions réparties

51

Vérification Statique de la NI��Solutions Centralisées : JIF JIF : Java Information Flow [Myers00]

CFI sur des programmes écrits en Java

Ajoute une analyse statique au code

Étend Java en ajoutant des étiquettes Respectent le modèle DLM

Étapes de vérification de la NI 1.  Architecte de sécurité définit l’ensemble des contraintes selon la politique

désirée 2.  Développeur écrit le programme en associant des étiquettes aux différentes

parties du programme (variables, méthodes, blocs…) 3.  Un compilateur (basé sur Polyglot [Nystrom03])

Analyse le programme réalisé (Java + étiquettes) Vérifie qu’il est non-interférent : les politique définie est-elle renforcée? Génère un code Java, qui sera compilé par un compilateur Java standard, puis exécuté

52

Vérification Statique de la NI��Solutions Centralisées : JIF

Types étiquetés Dans JIF, chaque valeur a un type étiqueté composé de:

Type Java standard Étiquette de sécurité

Exemple : int {Alice → } x = 2; x est donc une variable entière, dont le propriétaire est Alice.

Compteur Programme Chaque point dans le programme a une étiquette : PC Limite supérieure des informations pouvant être déduite en ce point

53


Méthode Étend la méthode Java classique, en ajoutant des étiquettes pour le CFI :

À la valeur de retour Aux arguments Aux exceptions

Définit également deux types d’étiquettes particulières Étiquette de début : limite supérieure à la valeur du PC à l’invocation de la méthode Étiquette de fin : valeur du PC au point de terminaison de la méthode, limite supérieure sur l’information qui peut être apprise à la terminaison normale, ou exceptionnelle 54


Étiquettes et Autorités Dynamiques Étiquettes ou autorité dynamique peut être utilisée comme paramètre dans une classe, dont la valeur est déterminée à l’exécution, à l’instanciation d’un objet de cette classe

Rétrogradation (downgrading) Ajout d’un mécanisme pour rétrograder le niveau de sécurité d’une donnée si besoin est Confidentialité : declassification, Intégrité : endorsement Exemple : int {Alice → } x = 2; y = declassify (x, {Alice → Bob});

55


Exemple : Version JIF de la classe Vector

56


Plusieurs travaux sur JIF Système de type pour représenter JIF Propriété de Robustesse de JIF

Assurer que la rétrogradation de l’information n’est pas influencée par un attaquant

Canevas utilisant JIF pour construire des applications web Construction de systèmes répartis non-interférents à base de JIF (JIF/Split)

57

Vérification Statique de la NI��Solutions Réparties : JIF/Split JIF/Split [Zdancewic02]

Implémentation à base de JIF pour le concept de partitionnement sécurisé des programmes Permet de protéger les données dans les systèmes répartis contenant des hôtes mutuellement hostiles

Étapes : 1.  Programme initialement centralisé, écrit avec JIF 2.  JIF/Split permet de le partitionner en un ensemble de

programmes non-interférents 3.  Ces programmes peuvent être exécutés de manière

sécurisée sur des hôtes hétérogènes

58

Vérification Statique de la NI��Solutions Réparties : Compilateur de [Fournet09] Même principe de base que JIF/Split

Renforce en plus la sécurité des communications avec des mécanismes cryptographiques

Étapes : 1.  Partitionnement : Découper le code séquentiel en sous-programmes

non-interférents, selon les étiquettes de sécurité appliquées par le concepteur

2.  Contrôle de flux : Génération d’un code qui garde la trace de l’état du programme, pour le protéger contre un ordonnanceur malicieux

3.  Réplication : Transformation du programme distribué basé sur une mémoire partagée en un programme où les variables sont répliquées à chaque nœud

4.  Cryptographie : Insertion d’opérations cryptographiques pour protéger les répliques, et distribution de clefs

59

Vérification Dynamique de la NI Systèmes répartis sujets à des modifications pendant

l’exécution : Changement du niveau de sécurité des données pendant l’exécution Évolution de l’architecture du système (migration ou panne de certains composants…)

La configuration de sécurité du système doit être revérifiée

Deux types de solutions : Solutions centralisées Solutions distribuées

60

Vérification Dynamique de la NI��Solutions Centralisées : CFI dans les OS Contrôle de flux d’information, sous-jacent, des tâches de l’OS Association d’étiquettes aux processus et messages du système Sécurisation des applications existantes en régulant la

communication et le changement d’étiquettes des processus Objectifs :

Minimiser la quantité de code auquel on doit faire confiance Permettre aux utilisateurs de spécifier les politiques de sécurité sans limiter la structure des applications

Exemples : F l ume [K rohn07 ] , H i S t a r [Ze l dov i c h06 ] , A sbe s to s [Efstathopoulos05]

61

Vérification Dynamique de la NI��Solutions Distribuées : DStar DStar [Zeldovich08]

Protection au niveau de l’OS sur des machines mutuellement hostiles

Extension de HiStar aux systèmes distribués Application de la DIFC (CFI Distribué) entre les système Introduit la notion d’exportateur par machine

Seul processus pouvant communiquer avec d’autres processus via le réseau Vérifie à chaque communicaiton que l’échange d’information n’enfreint pas les restrictions de sécurité

Supporte HiStar, Flume ou Linux Si Linux n’implémente pas la DIFC, il fait confiance à tous les logiciels qui tournent dessus 62

Solutions de CFI��Étude Comparative

Critères de comparaison Dynamicité Granularité

Le CFI peut se faire à la granularité de la variable, objet, processus… Plus la granularité est petit, plus le CFI est précis mais son application difficile

Support de modules patrimoniaux Indique le niveau de flexibilité de la solution : prend-elle en considération les modules hétérogènes? les modules « boîte noire »?

Support automatique de la cryptographie Support de la distribution du système

63


64

Systèmes Centralisés Statiques (JIF) ü  CFI de granularité très fine ～  Support des étiquettes dynamiques, mais CFI globalement statique ✗  Pas de support des systèmes patrimoniaux, ni de la cryptographie

automatique, et systèmes cibles principalement centralisés ✗  Gros effort et expertise requis pour affecter les niveaux de sécurité à grain

très fin

Systèmes Distribués Statiques (Jif/Split et Fournet) ü  CFI de granularité très fine ü  Support de la cryptographie automatiquement générée (Fournet) ü  Support de la distribution ～  CFI Statique (sauf pour étiquettes dynamiques de JIF/Split) ✗  Pas de support des systèmes patrimoniaux, ni de la cryptographie

automatique (JIF/Split) ✗  La répartition du système se fait selon les besoins de sécurité, pas selon les

besoins fonctionnels


65

Systèmes Centralisés Dynamiques (CFI dans les OS) ü  Support de la dynamicité ✗  Pas de support des systèmes patrimoniaux, ni de la

cryptographie automatique, et systèmes cibles principalement centralisés

✗  Granularité grossière

Systèmes Distribués Dynamiques (DStar) ü  Support de la dynamicité et de la distribution ✗  Granularité en général grosse sinon moyenne ✗  Doit être greffé à un OS supportant la DIFC

Solutions de CFI��Pour résumer…

66

Aucune des solutions n’assure tous les critères à la fois Un CFI à grain très fin demande un effort et une expertise élevés de la part du développeur du système Dynamicité est en général négligée au dépend de la granularité, et vice-versa

Car il est délicat de gérer un CFI à grain fin dans un système réparti, si on considère son aspect dynamique

Très peu de solutions suppor tent les systèmes patrimoniaux CFI est très proche du code

Conclusion 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

67 Partie III : CIF et DCIF

Références [Efstathopoulos05] P. Efstathopoulos, M. Krohn, et al. “Labels and event processes in the Asbestos operating system.” In Proceedings of the twentieth

ACM symposium on Operating systems principles, volume 25, page 30. ACM, 2005.

[Fournet09] C. Fournet, G. Le Guernic, and T. Rezk. “A Security-Preserving Compiler for Distributed Programs.” Proceedings of the 16th ACM conference on Computer and communications security, pages 432–441, 2009.

[Goguen82] J.A. Goguen and J. Meseguer. “Security policies and security models.” IEEE Symposium on Security and Privacy, page 11, 1982.

[Krohn07] M. Krohn, A. Yip, et al. “Information flow control for standard OS abstractions”. ACM SIGOPS Ope- rating Systems Review, 2007.

[Malecha10] G. Malecha and S. Chong. “A more precise security type system for dynamic security tests.” Proceedings of the 5th ACM SIGPLAN Workshop on Programming Languages and Analysis for Security - PLAS ’10, pages 1–12, 2010.

[Myers00] A.C. Myers and B Liskov. “Protecting privacy using the decentralized label model”. ACM Transactions on Software Engineering and Methodology (TOSEM), 2000.

[Myers06] A.C. Myers, A. Sabelfeld, and S. Zdancewic. “Enforcing robust declassification and qualified robustness.” Journal of Computer Security, 14(2) :157–196, 2006.

[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.

[Rushby92] J. Rushby. “Noninterference, transitivity, and channel-control security policies”. Technical Report No. CSL-92-02., (650), 1992.

[Zdancewic02] S. Zdancewic, L. Zheng, N. Nystrom, and A.C. Myers. “Secure program partitioning”. ACM Transactions on Computer Systems (TOCS), 20 :328, August 2002.

[Zeldovich06] N. Zeldovich, S. Boyd-Wickizer, E. Kohler, and D. Mazieres. “Making information flow explicit in HiStar.” In Proceedings of the 7th symposium on Operating systems design and implementation, volume pages, page 278. USENIX Association, 2006.

[Zeldovich08] N. Zeldovich, S. Boyd-Wickizer, and D. Mazieres. “Securing distributed systems with information flow control”. In Proceedings of the 5th USENIX Symposium on Networked Systems Design and Implementation, pages 293–308. USENIX Asso- ciation, 2008.

68

Technology

Sécurité des Systèmes Répartis- Partie2 - non interférence