sécurité des systèmes répartis- partie2 - non interférence
DESCRIPTION
Visitez http://liliasfaxi.wix.com/liliasfaxi !TRANSCRIPT
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;
public void start(){
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;
public void start(){
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;
public void start(){
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
Modèle d’Étiquettes Décentralisé���Étiquettes de Confidentialité
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
Modèle d’Étiquettes Décentralisé���Étiquettes de Confidentialité
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
Modèle d’Étiquettes Décentralisé���Étiquettes d’Intégrité
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
Modèle d’Étiquettes Décentralisé���Étiquettes d’Intégrité
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
Modèle d’Étiquettes à base de Jetons���Relation d’ordre
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
Modèle d’Étiquettes à base de Jetons���Relation d’ordre
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
Vérification Statique de la NI���Solutions Centralisées : JIF
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
Vérification Statique de la NI���Solutions Centralisées : JIF
É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
Vérification Statique de la NI���Solutions Centralisées : JIF
Exemple : Version JIF de la classe Vector
56
Vérification Statique de la NI���Solutions Centralisées : JIF
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
Solutions de CFI���Étude Comparative
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
Solutions de CFI���Étude Comparative
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