MAC Mandatory Access Control Contrôle d’accès obligatoire (Méthodes de contrôle de flux) http://w3.uqo.ca/luigi/INF6153/index.html INF6153.

Présentation au sujet: "MAC Mandatory Access Control Contrôle d’accès obligatoire (Méthodes de contrôle de flux) http://w3.uqo.ca/luigi/INF6153/index.html INF6153."— Transcription de la présentation:

1 MAC Mandatory Access Control Contrôle d’accès obligatoire (Méthodes de contrôle de flux)
INF6153

2 Pourquoi MAC Dans les organisations, il existe normalement des ressources qui doivent être administrées par le gérant du système selon des politiques rigides qui échappent à l’usager Le but principal des systèmes MAC est de protéger les données Confidentialité et intégrité Ce but est obtenu en limitant les droits des usagers sur les objets qui contiennent les donnés La protection des données implique le contrôle de flux des données dans l’organisation Ces modèles se préoccupent surtout des droits de lecture-écriture Plus indirectement de l’exécution INF6153

3 Classification des sujets et données
Caractéristique commune à tous ces modèles est le fait que les sujets et les données sont classés ou étiquetés Les classifications déterminent quels sujets peuvent avoir accès à quelles données INF6153

4 Exemples de MAC Bell-LaPadula Biba Multi-level Access Control (MLS)
Lattice-Based Access Control Muraille de Chine Label Based Access Control Plusieurs autres … INF6153

5 Bell-La Padula (BLP) pour la confidentialité (aussi appelé modèle multiniveaux)
INF6153

6 Premier exemple Marc travaille sur un projet A1: secret
Anne travaille sur un projet A2: public Aucune données ne peut circuler A1A2 Quelles seraient les règles pour ceci? Marc Fichier de Marc Projet A1 Barrière Anne Fichier de Anne Projet A2 INF6153 INF6153

7 Règle simple Marc Fichier de Marc Projet A1 / Barrière Anne Fichier de Anne Projet A2 Les participants du projet A2 ne peuvent pas lire les fichiers du projet A1 Suffisante? INF6153

8 Règle * Marc Fichier de Marc Projet A1 / Barrière / Anne Fichier de Anne Projet A2 Les participants du projet A1ne peuvent pas écrire dans les fichiers du projet A2 INF6153

9 Bell-LaPadula: motivation
Dans un environnement hiérarchique, p.ex. militaire Les supérieurs peuvent s’informer au sujet des inférieurs, pas le contraire Les inférieurs peuvent informer les supérieurs, Personne ne peut divulguer à des niveaux inférieurs les données acquises Autrement dit, les données peuvent être transférées seulement vers l’haut de la hiérarchie INF6153

10 Bell-LaPadula: besoins
Hypothèse: Nous avons un ensemble ordonné de niveaux de permission P.ex. de soldat (bas) à général (élévé) Nous avons des données qui sont plus ou moins ‘sensibles’ Besoin Les données peuvent être transférées des niveaux bas vers les niveaux plus élevés, mais pas dans le sens contraire INF6153

11 Implémentation Pour contrôler le flux des données, nous contrôlerons le opérations sur les fichiers (objets) qui les contiennent Les opérations de lecture ou écriture qui transfèrent les données vers l’haut sont permises Les opérations de lecture ou écriture qui transfèrent les données vers le bas ne sont pas permises INF6153

12 Implémentation: Niveaux de sujets et objets
Les sujets sont classés par Niveau d’autorisation Les objets sont classés par Niveau de sensibilité Pour simplicité, nous ferons l’hypothèse qu’il y ait une correspondance 1-1 entre ces deux niveaux, nous les appellerons niveaux de sécurité: P.ex. Très secret = Général Secret = Colonel Confidentiel = Major Public = Capitaine INF6153

13 Généralisation La correspondance 1à 1des niveaux d’autorisation et de sensibilité n’est pas nécessaire On pourrait avoir un niveau d’autorisation qui correspond à plusieurs niveaux de sensibilité ou le converse Cependant le modèle reste essentiellement le même donc nous ne parlerons pas de ces cas INF6153

14 Propriétés (Propriété simple, lecture) Read down, No read up
Un sujet à un niveau peut lire un objet ssi le niveau de l’objet est inférieur ou égal au niveau du sujet Suffisant? INF6153

15 Propriétés ou règles (Propriété simple, lecture) Read down, No read up
Un sujet à un niveau peut lire un objet ssi le niveau de l’objet est inférieur ou égal au niveau du sujet Cette propriété n’est pas suffisante pour limiter la diffusion des données! (Propriété *, écriture) Write up, No write down Un sujet à un niveau peut écrire sur un objet ssi le niveau de l’objet est supérieur ou égal au niveau du sujet Car il faut empêcher à un sujet de déclassifier les données en recopiant les objets qui les contiennent à des niveaux inférieurs Propriété est une terminologie très utilisée, mais selon moi erronée dans ce cas INF6153

16 Graphiquement Propriété simple Propriété * Dessins de Sofiene Boulares
Top Secret Top Secret Secret Secret Confidentiel Confidentiel Ne pas lire en haut Ne pas écrire en bas Dessins de Sofiene Boulares INF6153

17 Exemple Quels fichiers peut lire Kamel?
Sur quels fichiers peut-il écrire? INF6153

18 Exemple Kamel peut lire Courriels, Mémorandums, Communiqués
Très sécret Johanne Fichier Personnel Secret Kamel Courriels Confidentiel Jocelyne Mémorandum Public Richard Communiqués Kamel peut lire Courriels, Mémorandums, Communiqués Il peut écrire dans les fichers Courriels et Personnel S’il pouvait écrire dans Mémorandums ou Communiqués, il pourrait par ex. rendre dispo à Jocelyne ou Richard l’information des Fichiers Personnel Déclassant donc ces fichiers et les infos y contenues INF6153

19 Tableau de contrôle d’accès
Fichier Personnel = TS Courriels = S Mémos = C Communiqués = P Johanne = TS R, W R Kamel = S W Jocelyne = C Richard = P P < C < S < TS Donc TS doit avoir la plus grande sécurité INF6153

20 Propriété globale Par un simple raisonnement inductif, on voit que la propriété globale suivante est préservée: Aucun sujet ne peut arriver à lire des données qui sont à un niveau supérieur à son niveau d’autorisation, par n’importe quelle suite d’opérations de lecture ou écriture Ceci peut arriver seulement si ces données peuvent être stockées à son niveau ou à un niveau inférieur On voit que ceci n’est pas possible car: Ces données ne seront pas stockées là au début (il faut croire à ça) N’importe quelle séquence d’opérations de lecture-écriture ne peut les déplacer à un niveau inférieur! Persuadez-vous bien de ceci – il peut être prouvé de manière simple et formelle INF6153

21 Séparation entre objets et données
Pour bien comprendre BLP, il est nécessaire d’insister sur la distinction entre Données et Objets, ou fichiers, qui contiennent les données Le niveau de sensibilité des données reste inchangé malgré que le niveau de sensibilité de leurs contenants, les objets ou fichiers, change si on recopie les données à des niveaux différents Le niveau de sensibilité de votre NAS est le même qu’il soit dans un document d’impôt ou dans un document de police Au lieu, on peut confondre la distinction entre sujets et objets On se concentre donc sur le flux de données entre niveaux de sécurité Car les sujets peuvent lire et écrire dans les objets de leurs niveaux Les données sont protégées en forçant un certain flux Du bas à l’haut Ce flux est forcé en limitant ce que les sujets aux différents niveaux peuvent faire avec les objets-fichiers INF6153

22 Exercice: Cheval de Troie
Revenir à l’exemple du Cheval de Troie du cours précédent et voir comment les chevaux de Troie peuvent être empêchés dans BLP Solutions dans www INF6153

23 BLP Extension 1 (pour permettre la transmission en bas)
La prohibition d’écrire à un niveau inférieur ne permet pas la transmission des ordres! Pour ce faire, un usager peut décrémenter son niveau à un niveau inférieur Il peut donc avoir un niveau maximal Et un niveau courant P.ex. un colonel peut descendre au niveau d’un sergent pour (et seulement pour) donner des ordres à un sergent ou à niveau entre sergent et colonel Il faut supposer qu’il n’en profitera pas pour répandre des autres données … Concept de sujet fiable = trusted subject INF6153

24 BLP extension 2 (Pour limiter les droit d’accès à certains types d’info)
Pour implémenter le critère de ‘besoin de savoir’ on a dans BLP des catégories de données dans chaque niveau P.ex. dans l’ensemble des fichiers d’une organisation on peut avoir: Fichiers ‘Nucléaire’, ‘Europe’, ‘Asie’ etc. En plus d’avoir des niveaux de sensibilité et d’autorisation, les usagers et les objets appartiennent aussi à des catégories de données Les catégories traversent les niveaux Contrainte additionnelle: un sujet ne peut accéder qu’à des données dans sa propre catégorie: partition des données à travers tous les niveaux de sécurité Nuc Etc. Eur Asie INF6153

25 Modèles Treillis Lattice Models INF6153

26 Treillis de catégories de données
Les données peuvent être structurées, et un sujet peut avoir accès à des sous-ensembles de catégories Ceci conduit à un modèle plus complexe INF6153

27 Exemple Marie: (TopSecret, {NUC, EUR, ASI})
Jean: (Secret, {NUC, ASI } ) Tom: (Confidential, {EUR, ASI } ) Marie a plus de droit d’accès que Jean ou Tom, Jean a plus de droits d’accès que Tom aux objets dans la catégorie ASI, Cependant Tom a des droits d’accès dans la catégorie EUR, que Jean ne peut pas toucher Marie Jean Tom INF6153

28 Rélation dom Si A est un niveau de sensibilité et C un ensemble de categories: (A,C) dom (A,C) ssi A≤ A et C C Exemples (Top Secret, {NUC, ASI}) dom (Secret, {NUC}) (Secret, {NUC, EUR}) dom (Confidential,{NUC, EUR}) (Secret, {NUC, EUR}) dom (Secret, {NUC}) (Top Secret, {NUC}) dom (Confidential, {EUR}) INF6153

29 Propriétés simple et * avec dom
Simple: Un Sujet peut lire un Objet ssi Sujet dom Objet * : Un sujet peut écrire un Objet ssi Objet dom Sujet Elle peuvent expliquées de la manière suivante: Un sujet peut lire un objet ssi l’objet contient exclusivement des données pour lesquelles le sujet a droit d’accès Un sujet peut écrire sur un objet ssi le sujet a droit d’accès exclusivement à des données que l’objet peut contenir INF6153

30 Ensembles partiellement ordonnés
Un ensemble partiellement ordonné (L,R) est un ensemble L muni d’une rélation R qui est réfléxive, antysimétrique et transitive Les rélations ≤ et  sont de ce type La rélation dom l’est aussi Réfléxive: pour tout a, aRa Antisimétrique: aRb et bRa implique a=b Transitive: aRb et bRc implique aRc INF6153

31 Treillis (mais voir discussion à la fin)
Un treillis est un ensemble partiellement ordonné (L, ≤) qui satisfait aux conditions suivantes: Pour n’importe quel paire d’éléments (a,b) ∈ LxL il existe Un élément unique c tel que a≤c et b≤c et qui est le plus petit de tous les éléments ayant cette propriété (borne supérieure) Cet élément c sera écrit a⊕b Un élément unique d tel que d≤a et d≤c et qui est le plus grand de tous les éléments ayant cette propriété (borne inférieure) Cet élément sera écrit ⊗ Par conséquence, un treillis a Un ‘plus grand élément’, borne supérieure de tous Un ‘plus petit ‘élément’, borne inférieure de tous INF6153

32 Treillis pour l’exemple précédent: catégories
L’ensemble de tous les sous-ensembles des catégories précédentes forme un treillis pour la rélation dom : NUC, EUR, US NUC, EUR NUC, US EUR, US NUC EUR US ∅ INF6153

33 Treillis pour l’exemple précédent: Niveaux de sécurité (simplifié à 3 niveaux)
TopSecret ≥ Secret ≥ Confidential INF6153

34 Treillis global Le treillis global pour notre exemple est le produit des deux treillis précédents Le produit de deux treillis est un treillis, donc le treillis global sera aussi un treillis Le ‘plus grand élément’ de ce treillis est: (TopSecret, {NUC, EUR, US}) (l’usager qui a accès à tout) Le ‘plus petit élément’ est: (Confidential, ∅) (l’usager qui n’a accès à rien) Le treillis a 3x8=24 éléments: Exercice: Énumérez-les! Ce treillis montre la direction du transfert des données permis dans l’organisation concernée INF6153

35 Le niveau supérieur et le plus bas … diagramme à compléter
(TopSecret, {NUC, EUR, US}) (TopSecret,{NUC, US}) (TopSecret,{EUR,US}) (TopSecret,{NUC, EUR}) (TopSecret,{NUC}) (TopSecret,{EUR}) (TopSecret,{US}) (TopSecret, ∅) … (Confidential, ∅) INF6153

36 Exemple plus petit 2 niveaux et 2 catégories
people.sabanciuniv.edu/levi/cs432/AccessControl.ppt Dessin refait par Amine Chiali INF6153

37 Matrice de contrôle d’accès correspondante (à compléter comme exercice: attention à la relation dom)
objets Private,{pers, eng} Private,{pers} Private,{eng} Private,{} Private,{eng sujets INF6153

38 Matrice de contrôle d’accès correspondante (début de solution)
objets Private,{pers, eng} Private,{pers} Private,{eng} Private,{} Public,{pers, eng} Public,{pers} Public,{eng} Public,{} R,W R W -- sujets INF6153

39 La taille du treillis global
S’il y a C catégories, nous aurons à chaque niveau de sécurité 2C sous-ensembles de cet ensemble Si nous avons N niveaux, la taille totale du treillis sera donc N*2C INF6153

40 Éléments vides Un treillis complet montre toutes les classifications possibles de sujets et objets dans une organisation qui définit ces niveaux et catégories, avec les relations entre elles En pratique, plusieurs de ces classifications pourraient être vides, dans le sens qu’aucun sujet ou objet n’y serait affecté On pourra donc montrer un treillis avec des nœuds manquants INF6153

41 Note sur la direction des flèches
Dans les derniers diagrammes, les flèches sont dans la même direction de la relation dom Autres auteurs mettent les flèches au contraire pour indiquer la direction du flux des données N’importe à condition qu’on sache ce qu’on veut exprimer … INF6153

42 Et encore … Comme nous avons des modèles dans lesquels il n’y a que des niveaux de sécurité Une seule classe Nous pouvons aussi avoir des modèles où il n’y a que des classes Un seul niveau de sécurité INF6153

43 Propriété simple et propriété *
Pour tous les modèles MAC, la théorie fait distinction entre propriété simple et propriété étoile * Propriété simple: concerne la lecture Propriété * : concerne l’écriture Dans BLP, il est difficile de voir l’utilité de la propriété simple toute seule, sans aucune contrainte sur l’écriture Car un supérieur pourrait causer une fuite de données vers le bas Normalement les deux propriétés sont utiles ensemble Mais les deux propriétés pourraient être utiles séparément dans d’autres modèles de protection INF6153

44 Modèle Biba (pour l’intégrité)
INF6153

45 Modèle Biba Dans BLP, le but est de permettre seulement le flux des données vers l’haut Pour la confidentialité Dans Biba, le but est permettre seulement le flux de données vers le bas Pour l’intégrité: éviter que les données situées en haut soient polluées par des sources inférieures : Ex typique: les employés ne peuvent pas changer les directives Autre exemple: un programme exécuté en haut serait plus fiable qu’un programme exécuté en bas BLP: Confidentialité Biba: Intégrité INF6153

46 Propriétés Biba Biba est parfaitement dual par rapport à BLP:
(propriété *, écriture,) Write down, No write up Un sujet à un niveau peut écrire sur un objet ssi le niveau de l’objet est inférieur ou égal au niveau du sujet (propriété simple, lecture) Read up, No read down Un sujet à un niveau peut lire un objet ssi le niveau de l’objet est supérieur ou égal au niveau du sujet Sans ceci des sujets pourraient acquérir des données au bas et les écrire à leur propre niveau, progressivement jusqu’aux niveaux les plus élevés INF6153

47 Permissions et interdictions dans Biba
Dessin de Sofiene Boulares INF6153

48 Tableau de contrôle d’accès pour Biba
Fichier Personnel = TS Courriels = S Mémos = C Communiqués = P Johanne = TS R, W W Kamel = S R Jocelyne = C Richard = P P < C < S < TS Donc TS doit avoir la plus grande intégrité INF6153

49 Exécution de programmes
BLP et Biba peuvent inclure des règles d’exécution de programmes, qui sont identiques aux règles de lecture Les programmes sont des ‘sujets’ qui appartiennent à des niveaux BLP: un sujet X peut exécuter un sujet Y ssi X≤Y Biba: un sujet X peut exécuter un sujet Y ssi X≥Y Dans les deux cas, un sujet ne peut pas augmenter ses possibilités de transférer en exécutant un programme P.ex. dans Biba le droit de Y de transférer les données vers l’haut n’excède pas le droit de X INF6153

50 Combinaisons et modèles reliés
INF6153

51 Variations Politique: Les statistiques sont transférées du bas vers le haut, mais tous peuvent les lire Pour implémenter ceci, il est suffisant d’avoir BLP * sans BLP simple Politique: Les directives sont transférées de haut vers le bas, mais tous peuvent les lire Pour implémenter ceci, il est suffisant d’avoir Biba * sans Biba simple INF6153

52 Antinomie Sécurité-Intégrité
Selon BLP, les niveaux les plus sécuritaires sont les moins intègres … Car les informations flottent vers eux Selon Biba, les niveaux les plus intègres sont les moins sécuritaires Car les informations flottent loin d’eux Il y a cependant des manières de composer les deux méthodes INF6153

53 Combinaison BLP-Biba v. 1
BLP est un modèle de confidentialité, Biba est un modèle d’intégrité Les combiner carrément ensemble pour les mêmes données dans les mêmes niveaux conduit à une situation un peu particulière … Exercice pour vous INF6153

54 Combinaison BLP-Biba v. 2
BLP et Biba peuvent aussi être combinés à condition que chaque modèle s’applique à des catégories de données différentes Cas limites: Supposons que S soit un sujet de confidentialité maximale et d’intégrité minimale : il peut seulement lire des autres niveaux Supposons que S soit un sujet d’intégrité maximale et de confidentialité minimale : il peut seulement écrire dans les autres niveaux Voir Benantar ACS p.143 Exercice: le même type de question mais en partant des objets INF6153

55 Combinaison BLP-Biba v. 3
On pourrait aussi les combiner sur les mêmes catégories de données mais utilisant des niveaux différents P.ex. les données budgétaires d’une cie pourraient être publiques Mais leur intégrité est d’importance maximale Exercice: quels problèmes pourraient surgir et comment on pourrait penser à les résoudre? INF6153

56 Exercice Dans un système qui peut supporter tant BLP que Biba pour différentes catégories de données montrez comment on peut pallier à la difficulté que dans BLP ‘pur’ il est impossible de transmettre les ordres vers le bas INF6153

57 Modèle Lipner Le modèle de Lipner profite de la possibilité de combiner les deux modèles de confidentialité et d’intégrité Voir Bishop: Computer Security Sect Aussi info dans www INF6153

58 Composition de treillis (Bishop: Computer Security, Sect. 8. 1
Composition de treillis (Bishop: Computer Security, Sect , figures prises de ce manuel) INF6153

59 Composition Pourquoi:
Deux ensembles de fichiers sous l’autorité de deux administration différentes Un partage de données est souhaité Les politiques de chacune des deux administrations doivent être respectées conjointement Si un usager n’a pas le droit pour administration X ou Y, il ne doit pas l’avoir dans le système combiné INF6153

60 Composition de treillis
Chacun des deux treillis représente les critères d’une administration différente Pour la composition, il faut établir des relations INF6153

61 Comment composer Observons que quelques étiquettes sont identiques
LOW, EAST sont à gauche et à droite etc. Nous supposons qu’elles veuillent dire la même chose Quelques étiquettes sont différentes HIGH seulement à gauche, SOUTH seulement à droite etc, Nous pouvons établir des relations entre ces deux ensembles d’étiquettes INF6153

62 Relations entre étiquettes différentes
Supposons que les catégories sont indépendantes Nous aurons donc trois catégories différentes EAST, WEST, SOUTH Supposons que LOW veuille dire la même chose et que les niveaux soient dépendants comme suit: LOW≤ S ≤ HIGH ≤ TS Quelques unes des relations résultantes: (S,{WEST}) indépendant de (HIGH,{EAST}) (HIGH,{SOUTH}) ≤ (HIGH,{EAST,SOUTH}) ≤(TS,{EAST,WEST, SOUTH}) INF6153

63 Exercice Dessiner le treillis composé entier
Il n’est pas petit, car il y a quatre niveaux et trois catégories Mais faites les premiers niveaux INF6153

64 Cas de treillis indépendants 1
Il peut aussi arriver que les niveaux dans deux treillis soient indépendants, pas comparables Si on veut que des sujets ou objets puissent appartenir aux deux, chacun d’eux doit avoir deux étiquettes, une pour chaque système Ex: une personne qui travaille pour deux compagnies indépendantes: Il aura deux niveaux, un pour chacune des deux cies Donc, l’ensemble des niveaux dans le treillis résultant serait le produit cartésien des niveaux des deux treillis d’origine Un sujet ou objet aurait donc une paire de niveaux, p.ex. (HIGH, S) Les conditions d’accès sont déterminées par les conditions dans les deux treillis originaires INF6153

65 Exemple pour Cas de treillis indépendants
Supposons une personne qui appartient tant à l’Armée Canadienne qu’à l’Armée des Nations Unies Il est Colonel dans la Canadienne, Major dans les NU Nous disons que son grade est: (Colonel, Major) Peut-il lire un document qui est considéré Secret dans l’Armée Canadienne, mais Confidentiel dans les NU? INF6153

66 Exemple pour Cas de treillis indépendants
Supposons une personne qui appartient tant à l’Armée Canadienne qu’à l’Armée des Nations Unies Il est Colonel dans la Canadienne, Major dans les NU Nous disons que son grade est: (Colonel, Major) Peut-il lire un document qui est considéré Secret dans l’Armée Canadienne, mais Confidentiel dans les NU? Il peut le lire si, en tant que Colonel au Canada, il peut lire les informations sécrètes du Canada *ou*, en tant que Major, il peut lire les informations Confidentielles des NU La règle serait donc la plus faible des règles de toutes les organisations concernées! Mais une FAILLE de SÉCURITÉ pourrait résulter si puis la personne utilise les autorisations de son autre classification pour écrire les résultats ailleurs! Des règles différentes pourraient être imposées mais alors les deux treillis ne sont plus indépendants, ils deviennent reliés par des règles communes qui prennent en considération les deux classifications INF6153

67 Extensions et problèmes
INF6153

68 Extensions de BLP BLP a été très étudié et des nombreuses extensions ont été proposées pour le rendre plus pratique ou pour l’adapter à fins différents Plusieurs extensions ont conduit à des failles, comme l’extension suivante dans laquelle on permet aux sujets de créer des objets et d’en changer le niveau INF6153

69 Concept de canal couvert
Nous avons parlé de canaux indirects Passage de données indirect Peut être voulu, conforme aux politiques Un canal couvert au lieu est un passage données qui est utilisé pour contourner les politiques Storage channels Utilisent des données intermédiaires Timing channels Utilisent le délais de temps Pas traités dans ce cours INF6153

70 Canaux couverts dans BLP Utilisant les données
S, sujet de bas niveau, S’ sujet de haut niveau Ils se mettent d’accord afin que S’ puisse passer un bit d’info à S, dans la manière suivante: S crée un nouveau objet O S’ peut changer ou non le niveau de O, le rendant inaccessible à S Quand S cherchera à lire O, il saura si S’ lui a dit ‘oui’ ou ‘non’ INF6153

71 Principe de tranquillité forte
Les actions d’usager ne peuvent pas causer des changements de niveau de sécurité Changements peuvent être faits seulement par des administrateurs, dans l’espoir qu’ils comprennent les conséquences … En pratique, ceci est trop inflexible et certains changements peuvent être admis, avec précautions INF6153

72 Propriété de tranquillité faible
Une action d’usager peut modifier les étiquettes de sécurité mais seulement d’une manière qui ne viole pas les normes de sécurité Exemple: High Water Mark Policy, ‘laisse haute’ INF6153

73 Exercice (modèle dit de laisse d’eau haute - high watermark)
Cas 1: Un sujet X réussit à lire des données à un niveau supérieur Que pourrait-on faire par rapport à X pour continuer à protéger la confidentialité dans le système? Cas 2: Un sujet réussit à écrire sur des données Y à un niveau inférieur Que pourrait-on faire par rapport à Y pour continuer à protéger la confidentialité dans le système? Considérer la même idée par rapport à la protection de l’intégrité INF6153

74 Aspect discrétionnaire
Les modèles treillis peuvent être combinés avec l’aspect discrétionnaire de DAC On peut ajouter à ces modèles une matrice de contrôle d’accès avec ses propres contraintes Supposons qu’un sujet X puisse lire ou écrire sur un objet Y selon les règles de BLP Il pourrait encore être incapable de le faire car la matrice de contrôle d’accès lui nie ce droit Cependant il est nécessaire de limiter fortement le droit du propriétaire de transférer ses droits Exercice: réfléchir sur ce point: quelles limites sont nécessaires? Ceci était partie de la formulation originaire du modèle BLP INF6153

75 Limites de BLP Fiable quand le système est statique
Défendu de créer des nouveaux sujet ou objets Défendu de changer de niveaux Ou quand il est administré de manière très stricte: p.ex. Les changements de niveaux peuvent être faits seulement après des précautions particulières Un sujet qui passe à un niveau inférieur peut avoir stocké des données au niveau précédent et les rendre disponibles à son nouveau niveau Il pourrait être impossible de structurer une organisation selon BLP ‘stricte’ INF6153

76 Notre simplification …
Pour simplifier, nous avons fait l’hypothèse que les sujets et les objets sont classifiés selon la même échelle Le cas général serait que les sujets et les objets peuvent être classifiés sur des échelles différentes, et qu’il y a des rélations ≤ entre catégories des sujets et catégories des objets La substance reste la même, cependant INF6153

77 Couches de Protection Dans les Systèmes d’exploitation
INF6153

78 Anneaux de protection Le concept de ‘Anneaux de protection’ est une application de BLP aux systèmes d’exploitation et a été implémentée dans quelques matériels et logiciels INF6153

79 Deux anneaux de protection
Dans la plupart des ordis, la machine peut exécuter en un de deux modes: Superviseur ou usager Si la machine est en mode superviseur, elle peut exécuter les instructions privilégiées du SE Elle peut lire les données des usagers Elle ne peut pas transférer des infos privilégiées à l’usager Si la machine est en mode usager, elle ne peut exécuter que les programmes usagers Elle ne peut pas lire dans le SE Elle peut transférer des infos au SE INF6153

80 Généralisation à plusieurs niveaux
Dans le système Multics (approx 1965!) on prévoyait jusqu’à 32 anneaux d’exécution (0-31) L’Unité Centrale a un registre qui contient le numéro de l’anneau où elle est en train d’exécuter Les anneaux les plus internes sont les plus protégés C’est la place des fonctionnalités les plus critiques INF6153

81 Exemples de niveaux 0: Noyau du Système d’exploitation
1: Le reste du SE 2: Utilitaires 3: Programmes d’usager Ceci pourrait être étendu à plus de niveaux P.ex. on pourrait distinguer différentes parties du SE ou d’utilitaires, plus ou moins protégées Les usagers pourraient aussi dire que quelques uns de leur programmes devraient être plus protégés que d’autres INF6153

82 Catégories d’objets Ce système considère aussi les catégories d’objets
À chaque niveau, il pourrait y avoir différentes catégories d’objets avec des protections différentes comme dans BLP INF6153

83 Difficultés Une difficulté majeure est le cas où un processus (=sujet) dans un anneau veut exécuter un processus dans un anneau différent P.ex. un programme A du noyau qui lance un programme d’application B Dans ce cas, A doit passer des paramètres à B – ce flux est dans une direction non-permise Si un processus veut exécuter un programme dans un noyau plus protégé, et il veut voir les résultats, ce sont les résultats qui créent un flux non-permis Il y a donc des règles compliquées et rigoureuses concernant les permissions de Lecture et écriture entre niveaux Appels de procédures entre niveaux INF6153

84 Implémentation Linux Voir SELinux Security Enhanced Linux INF6153

85 LAC: Modèle treillis de Denning: Une abstraction
V. Benantar Chap. 4 INF6153

86 Modèle treillis de Denning (LAC: Lattice-Based Access Control)
Dans le modèle treillis on ne parle plus de sujets et objets mais seulement de flux de données entre niveaux de sécurité Qui forment un treillis Abstraction très utile Mais pour l’implémentation le flux de données est conditionné par les restrictions sur les lectures et écritures des objets INF6153

87 Ensemble SC, Rélation , Opérateurs⊗⊕
Il existe un ensemble fini SC de classes de sécurité La rélation  dans SC dénote le flux de données. Elle est: Réfléxive: AA pour tout A Transitive: AB et BC implique AC Antisymétrique: AB et BA implique A=B L’opérateur ⊕ dans SC est la jonction: A⊕B est le plus grand dénominateur commun entre A et B par rapport à la rélation  AA⊕B et BA⊕B L’opérateur ⊗ dans SC est l’intersection A⊗B A et A⊗B B INF6153

88 Critère de sécurité (safety)
Un système est sécuritaire si on ne peut pas avoir des séquences d’opérations (read, write) qui créent un flux différent de celui spécifié par  Ceci considère les opérations d’affectation a=f(b1,…,bn) qui peuvent être vues comme des lectures de b1,…,bn suivies par une écriture sur a Donc ce modèle peut être utilisé pour analyser le flux de données dans les programmes INF6153

89 Condition pour la sécurité
Essentiellement, si SC est un treillis fini pour les opérateurs , ⊕, ⊗ il est sécuritaire Donc il n’y a pas de flux de données autre que celui spécifié par  Avec son extension transitive, évidemment INF6153

90 Application à BLP BLP respecte ce modèle car:
L’ensemble de niveaux de sécurité est fini L’opérateur  est la relation dom inversée Les données peuvent être transférée de A à B ssi B dom A Nous avons en fait vu comment les systèmes BLP peuvent être représentés comme treillis INF6153

91 Problèmes? Ce modèle est intéressant car il peut être utilisé pour parler de la sécurité à l’intérieur d’un programme, mais ce type de sécurité pourrait être impossible à obtenir: P.ex. un programme usager A peut demander un service d’une procédure P plus protégée A peut passer à P des paramètres: OK Cependant P voudrait transférer à A des résultats: PAS OK! Ce problème affecte les modèles multi-niveaux style Multics et SELinux INF6153

92 Non-Interférence INF6153

93 Non-Interférence Un système est vu comme une machine avec entrées et sorties Les entrées et sorties sont classifiées à niveaux Bas ou haut selon leur niveau de sécurité Un système respecte le critère de non-interférence ssi tout calcul pour des résultats de bas niveau est toujours indépendant des entrées d’haut niveau Les entrées d’haut niveau n’ont aucun effet sur le calcul des sorties de bas niveau Donc il n’y a aucune fuite de données de l’haut niveau vers le bas niveau Un critère très stricte INF6153

94 Cas concret Supposons un programme qui, pour une personne, prend en entrée sa date de naissance, contenant: Le jour de son anniversaire (donnée publique) Son année de naissance (donnée confidentielle) Le programme peut être utilisé pour effectuer L’envoi automatique à tous d’un message de souhaits Ceci doit être effectué sans donner aucune indication qui puisse faire connaître l’année de naissance Cette partie du programme ne devrait pas la lire L’envoi d’un message confidentiel lui annonçant sa date et conditions de retraite Tous les éléments de la date de naissance sont utilisés INF6153

95 Plus formellement Dénotons par
hi une donnée d’haut niveau de sécurité bi une donnée de bas niveau Un calcul bj = F(h1, … ,hn, b1, …, bn) doit être une fonction de b1 … bn exclusivement doit être indépendent des valeurs de h1 … hn Tandis que un calcul hj = F’(h1, … ,hn, b1, …, bn) peut être une fonction de tous les arguments INF6153

96 Trop stricte ou non? Le critère de la non-interférence est trop stricte! Exemple: vérification d’un mot de passe Nous avons une fonction qui prend comme argument une donnée secrète, une publique et donne comme résultat une donnée publique Mais notez que même dans ce cas le critère n’est pas vraiment erroné car utilisant les données publiques on peut dans des cas faciles trouver la donnée secrète Supposez que le mot de passe soit un seul bit … INF6153

97 Prise en compte du chiffrage
L’idée de base du chiffrage est d’utiliser des fonctions F qui permettent de calculer bj = F(h1, … , hn, b1, …, bn) de manière que h1, … ,hn soient pratiquement impossibles à récupérer à partir de bj INF6153

98 BLP et non-interférence
BLP respecte le critère de non-interférence seulement s’il est statique Sinon les canaux couverts sont possibles INF6153

99 Modèle Muraille de Chine Modèle Brewer-Nash
INF6153

100 Muraille de Chine (Chinese Wall)
Exemple d’une compagnie de consultation Peut avoir plusieurs clients en concurrence, p.ex. Nokia et Samsung Doit bloquer le transfert de données confidentielles entre les employés qui s’occupent de Nokia et les employés qui s’occupent de Samsung Après qu’un employé aura lu une donnée de Nokia, tout accès aux fichiers de Samsung devra être défendu et vice-versa Il est aussi nécessaire de bloquer les canaux couverts Cette politique est aussi appelée “Brewer and Nash” du nom de ses inventeurs INF6153

101 Structure Les entités (sujets et objets) sont organisées dans des classes de conflit d’intérêt {Nokia,Samsung} est une telle classe Autre exemple: (Bishop: CS A&S) Bank of America Citibank Bank of the W est Bank COI Class Shell Oil Union ’76 Standard Oil ARCO Gasoline Company COI Class INF6153

102 Autre vision Classes de conflit  Compagnies  Objets 
Un sujet qui peut lire inf2 ne peut pas lire inf4 Il peut cependant lire dans les classes CI2 ou CI3 Pour éviter la fuite de données ce sujet ne peut écrire que dans Banque1 INF6153 Dessin de Sofiene Boulares

103 Besoins (confidentialité) Un sujet ne peut pas recevoir des données de deux organisations en conflit d’intérêt Ni directement ni indirectement (intégrité) Un objet ne peut pas recevoir des données de deux organisations en conflit d’intérêt S O Banque Royale Toronto-Dominion Banque Royale Toronto-Dominion INF6153

104 Concept d’”accès préalable”
Les droits d’un sujet dépendent de ce que le sujet a déjà accédé précédemment P.ex. s’il a déjà lu des données d’une cie A en conflit d’intérêt avec B, il ne peut pas lire dans B Une lecture de données le place dans une classe de conflit d’intérêt, de laquelle il ne pourra pas sortir Évidemment en pratique on pourra admettre ceci, notamment après une longue période de temps … INF6153

105 Propriété simple (les ovales sont sujets, les rectangles objets, donc les flèches sont des lectures)
Consultant Banque A \ Banque B Gaz A Auto A Suffisante? INF6153

106 Propriété * (les ovales sont sujets, les rectangles objets, donc les flèches sont des lectures ou écritures) Consultante A Banque A \ Auto A \ Consultante B Banque B Les consultantes qui ont déjà lu ne peuvent pas écrire dans bases de données différentes pour peur qu’elles transmettent des informations en conflit INF6153

107 Contraintes pour une implémentation
(Propriété simple) Un sujet S peut lire un objet O ssi un des suivants est vrai: Tous les objets que S a déjà lu sont dans des classes de conflit différentes de celle de O S a déjà lu un objet dans la même compagnie (Propriété * ) Un sujet S peut écrire un objet O ssi les deux suivants sont vrais: La propriété simple permet à S de lire O (pourquoi?) S peut lire seulement les objets de la même compagnie de O INF6153

108 Propriétés dérivées Pouvoir d’écriture très limité:
Un sujet qui a déjà lu des objets d’une seule compagnie ne peut écrire que sur les objets de cette même cie Un sujet qui a déjà lu des objets de plus d’une compagnie ne peut plus écrire sur aucun objet Même si les cies ne sont pas en conflit INF6153

109 Pourquoi limiter le pouvoir d’écriture
Alice peut lire des objets dans la Banque Royale et Shell (dans classes de conflit différentes) Bob peut lire Banque Desjardins et Shell (OK pour propr. simple) Si Bob pouvait écrire sur Shell, il pourrait transférer des données de Desjardins à Alice Alice Les infos de BDesj peuvent se trouver dans Shell ShellOil B Roy B Desj \ Bob INF6153

110 Éviter fuites indirectes
Cette contrainte limite beaucoup l’utilité de ce modèle mais elle ne peut pas être évitée Supposons qu’on ajoute la règle que S peut écrire sur O seulement si aucun sujet en conflit avec la cie de O ne peut y lire La fuite peut encore se vérifier par l’entremise de Carole! Alice Les infos de BanqueDesj peuvent se trouver dans Honda Shell Honda B Roy B Desj Bob Carole INF6153

111 Contrainte additionnelle?
On peut renforcer la propriété simple comme suit: Un sujet S peut accéder (=lire ou écrire) à un objet O ssi un des suivants est vrai: Tous les objets que S a déjà accédé sont dans des classes de conflit différentes de celle de O S a déjà accédé à un objet dans la même compagnie Cette contrainte assure une propriété d’intégrité additionnelle: Empêche qu’un sujet puisse écrire dans deux objets dans la même classe de conflit P.ex. sans cette contrainte Alice pourrait écrire dans les bases de données de deux banques des données différentes pour aider l’une et nuire à l’autre Alice Banque1 Banque2 INF6153

112 Flux de données On voit que dans CW les données peut être transférées seulement entre objets d’une même compagnie Le transfert est impossible entre sujets de cies différentes, même si elles sont dans des classes différentes de conflits INF6153

113 Contrainte excessive! Il est clair que la propriété * est trop restrictive D’autres versions moins restrictives existent, mais elles sont un peu plus compliquées à implémenter INF6153

114 Objets désinfectés Le modèle admet que n’importe qui peut faire accès à des objets ‘désinfectés’, où les données critiques ont été éliminées ou déguisées P.ex. des statistiques sans noms de personnes etc. ‘Sanitized’ information INF6153

115 Succès de CW Malgré ses limites, le CW ou des mécanismes semblables sont prescrits dans des lois sur la comptabilité et la finance Sandhu a justement observé que les limitations de CW ne seraient pas raisonnables si appliquées à un usager physique, mais elles peuvent l’être si appliquées à un sujet informatique, tel qu’un Cheval de Troie INF6153

116 Application du modèle treillis
Le modèle treillis peut être appliqué aussi au CW, mais ceci est laissé à vos lectures INF6153

117 Exercice Montrer comment le modèle CW peut être utilisé pour empêcher les Chevaux de Troie INF6153

118 Exercice Représenter les diagrammes précédents comme matrices de contrôle d’accès INF6153

119 LBAC: Étiquettes de sécurité méthode qui combine des éléments de DAC et MAC
Myers et Liskov 1997 (les figures sont prises de cet article) INF6153

120 Modèle des étiquettes de sécurité (LBAC: Label-based Access Control)
Idée: Alice a un dossier A de photos, elle ne veut pas qu’il soit jamais lu par son patron Une étiquette avec cette restriction accompagnera en permanence le dossier A, même s’il est recopié ou modifié Bob a un dossier B de photos, il ne veut pas qu’il soit lu par son père Pareillement, le dossier B aura une étiquette indiquant ce fait Si un nouveau dossier C est produit qui contient des photos provenant de A et B Le dossier C est automatiquement étiqueté qu’il ne peut être lu ni par le patron d’Alice ni par le père de Bob (conjonction des contraintes) INF6153

121 Déclassement Jusqu`à ce point, les dossiers peuvent devenir seulement de plus en plus difficiles à accéder Ce modèle prévoit qu’un dossier puisse être déclassifié par le propriétaire ou par des agents fiés (trusted agents) P.ex. Alice et Bob ensemble décident que toutes les photos ‘délicates’ ont été enlevées et que C peut être étiqueté ‘public’. Ou il peuvent reconnaître un tiers comme agent fié qui peut déclassifier le fichier C INF6153

122 Exemple d’hôpital p: p,H : le propriétaire est le patient et les données peuvent être lues par le patient ou l’hôpital Data extractor: agent fié: nettoie les données des infos privées et les rend dispos aux chercheurs R R deviennent propriétaires et peuvent déclassifier le résultat de leur analyse Aucune restriction INF6153

123 Exemple de banque La banque répond à plusieurs requêtes des clients. Le propriétaire des requêtes est le client mais la banque peut les voir aussi L’agent fié T génère des totaux pour la banque et le résultat est visible seulement par la banque Le propriétaire est un client spécifique Ci et tant le propriétaire que la banque peuvent le lire INF6153

124 Concepts utiles de LBAC
Étiquettent qui disent qui est le propriétaire et qui sont les sujets autorisés à lire (v. DAC et MAC) Les étiquettes sont utilisées pour composer les contraintes au fur et à mesure que les données sont combinées et augmentent d’importance Les propriétaires peuvent changer les étiquettes de leurs données pour les passer à autres (v. DAC) Les agents fiés peuvent nettoyer les données et en conséquence les déclassifier et changer les autorisations INF6153

125 Exercice: Le déclassement et la non-interférence
Nous avons fait l’exemple de la vérification du mot de passe pour montrer que le modèle de la non-interférence pourrait être trop stricte Réfléchir sur comment le concept de déclassement peut résoudre ce problème INF6153

126 Considérations Une idée qui a été bien étudiée en théorie mais qui a peu été exploitée en pratique Se préoccupe surtout de l’aspect ‘protection de la vie privée’ Nous avons vu seulement des exemples de ‘lecture’ Aura un futur … INF6153

127 Conclusion sur les modèles MAC et LBAC
Ces modèles proposent des méthodes rigoureuses pour la protection des données Incluant le contrôle de flux des données Au delà du simple accès aux données Leurs principes ont été très étudiés et implémentés dans nombreux systèmes Cependant pour être vraiment pratiques, ces méthodes doivent subir des exceptions Ce qui ouvre des failles … Nous verrons que des méthodes plus sophistiquées comme RBAC, ABAC … ne se préoccupent pas du contrôle de flux Ce qui peut ouvrir des failles d’autres types INF6153

128 Quelques champions … David Elliott Bell Len La Padula Dorothy Denning
Barbara Liskov Kenneth Biba TCSEC ou Orange Book, 1985 INF6153

129 Curiosité historique D’où vient le nom de la propriété * ?
Dans un écrit, David Bell a expliqué qu’il avait inventé le nom * pour discussion, et il avait dit à ses collègues qu’il fallait trouver rapidement un meilleur nom, sinon le nom serait resté … il est resté … INF6153

130 Exemples de non-treillis (Wikipedia)
c et d n’ont pas de borne supérieure commune. a et b n’ont pas de borne inférieure commune b et c ont des bornes supérieures communes (d,e,f), mais aucune qui est la plus petite a et b ont plusieurs bornes inférieures (0,d,g,h,i) mais aucune d’elles n’est la plus grande INF6153

131 Un exemple bien connu de treillis
Nous avons ici quatre niveaux de sécurité: TS, S, C, U et les catégories: A,K,L,Q,W,X,Y,Z. Ce treillis montre seulement les combinaisons considérées possibles dans ce cas d’étude. La plupart des catégories sont considérées seulement au niveau TS, et elles ne sont pas considérées du tout aux niveaux C et U. Le nombre max. possible de combinaisons est 1,024, mais en pratique seul. 21 sont utilisées dans cette organisation. Source: Sandhu, R.S.: Lattice-Based Access Control Models, Computer, 1993, 26 (11) pages 9-19 INF6153

132 Opinion personnelle … Le concept de treillis a été beaucoup mentionné dans le domaine de la protection des données Cependant les propriétés particulières des treillis ne sont pas nécessaires pour les propriétés importantes des systèmes de sécurité des données En particulier, l’existence de bornes les plus petites, les plus grandes Les exemples qui ont été publiés de véritables treillis dans le contrôle d’accès sont des exemples artificiels, de recherche, peu réalistes Il est vrai que, étant donné un ordre partiel quelconque, on peut en faire un treillis ajoutant des nœuds ‘vides’, mais l’utilité de cet ajout n’est pas évidente … Le simple concept d’ordre partiel est suffisant Les exemples dans la planche précédente sont tous des ordres partiels! Les concepts de ce cours peuvent être compris utilisant seulement ce concept INF6153