MACMLS Mandatory Access Control Contrle daccs obligatoire niveaux
MAC-MLS Mandatory Access Control Contrôle d’accès obligatoire à niveaux (Méthodes de contrôle de flux) http: //w 3. uqo. ca/luigi/INF 6153/index. h tml INF 6153 1
Pourquoi MAC-MLS • 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-MLS est de protéger les données – Secret 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 • Indirectement de l’exécution INF 6153 2
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 INF 6153 3
Exemples de MAC-MLS • • • Bell-La. Padula Biba Lattice-Based Access Control Muraille de Chine Label Based Access Control Plusieurs autres … – Nombreux modèles théoriques et implémentés INF 6153 4
Bell-La Padula (BLP) pour le secret (le prototype des modèles multiniveaux) INF 6153 5
Premier exemple Marc travaille sur un projet A 1: secret Anne travaille sur un projet A 2: public Aucune données ne peut circuler A 1 A 2 Quelles seraient les règles pour ceci? Mar c Fichier de Marc Projet A 1 Ann e Fichier de Anne Projet A 2 Barrière INF 6153 6
Règle simple Mar c / Barrière Ann e Fichier de Marc Projet A 1 Fichier de Anne Projet A 2 • Les participants du projet A 2 ne peuvent pas lire les fichiers du projet A 1 • Suffisante? INF 6153 7
Règle * Mar c Barrière Ann e / / Fichier de Marc Projet A 1 Fichier de Anne Projet A 2 • Les participants du projet A 1 ne peuvent pas écrire dans les fichiers du projet A 2 INF 6153 8
Bell-La. Padula: motivation initiale • Dans un environnement hiérarchique, p. ex. militaire INF 6153 – 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 9 transférées seulement
Bell-La. Padula: 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 INF 6153 10
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 INF 6153 11
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 INF 6153 12
Généralisation • La correspondance 1à 1 des 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 INF 6153 13
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? INF 6153 14
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 Propriété est une terminologie très utilisée, mais selon moi erronée dans ce cas données en recopiant les objets qui les contiennent à Règle ou politique? des niveaux inférieurs. INF 6153 15
Propriété simple et propriété * • Pour tous les modèles MAC-MLS, 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 INF 6153 16
Graphiquement Propriété * Propriété simple Top Secret Confidentiel Ne pas écrire en bas Ne pas lire en haut Dessins de Sofiene Boulares INF 6153 17
Autrement dit … Read down Write up Secret No read up No write down Confidential … Public Data can flow only upwards INF 6153 18
Flux seulement vers le haut INF 6153 19
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 • Les données sont protégées en forçant un certain flux – Du bas à l’haut – Dans ce modèle aucune donnée ne peut aboutir à un sujet-objet de niveau inférieur INF 6153 20
Niveaux de sécurité comme catégories • Dans le chapitre sur le contrôle de flux, nous avions des ordres partiels de niveaux de sécurité • On peut arriver au même résultat utilisant les catégories pour exprimer les niveaux de sécurité • Supposons l’existence des catégories – P, C, S pour Public, Confidentiel, Secret – Nous avons {P} ⊆ {P, C, S} – Un sujet au niveau {P, C, S} peut lire du INF 6153 21
Flux données pour exemple BLP Le niveau le plus S, C, P secret, pour les données classées S, peut aussi abriter des données C et P C, P P INF 6153 22
Instance de BLP Carl: {S, C, P } Meds. Patients: {S, C, P} Alice: {C, P} Noms. Patients: {C, P} Bob: {P} Médicaments: {P} INF 6153 23
Matrice de CA Médicament s Noms. Patient Meds. Patient s s Carl r r r, w Alice r r, w w Bob r, w w w INF 6153 24
Propriété globale • Par un simple raisonnement inductif, on voit que la propriété globale suivante est préservée: – Un sujet peut arriver à lire des données ssi elles sont à un niveau inférieur ou égal à son niveau d’autorisation, par n’importe quelle suite d’opérations de lecture ou écriture – Un objet peut arriver à stocker des données ssi …. (même chose) INF 6153 25
Cheval de Troie Comment l’empêcher? INF 6153 26
Cheval de Troie schéma Vicky Secret Pirate Programme (Cheval de Troie) X INF 6153 Vicky doit implémenter un modèle à niveaux et placer le fichier X à un niveau inférieur à son fichier Secret 27
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 INF 6153 28
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 Nuc – Contrainte additionnelle: un sujet ne peut accéder qu’à des Etc. Eur données dans sa propre catégorie: • partition des données • à travers tous les niveaux de sécurité INF 6153 Asie 29
Une application: Couches de Protection Dans les Systèmes d’exploitation INF 6153 30
Combinaison avec autres modèles • Bell-La Padula fut conçu pour fonctionner avec DAC – C’e. -à-d. si BLP permet un accès il faudrait voir s’il est aussi permis par le propriétaire des données, voir DAC • En principe, MAC-MLS peut fonctionner ‘en amont’ ou ‘en aval’ d’autres modèles – P. ex. si RBAC permet l’accès il faut puis contrôler s’il est permis aussi par MAC-MLS, etc. • De cette manière, on peut combiner le politiques de contrôle de flux avec les politiques basées sur les rôles • Point de réflexion … INF 6153 31
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 INF 6153 32
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 INF 6153 – Elle peut transférer des infos au SE 33
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 INF 6153 34
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 quelques uns de leur programmes devraient être plus protégés que d’autres INF 6153 35
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 INF 6153 36
Difficultés pour exécution • 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 – Aussi faisant ceci le processus peut s’emparer de fonctionnalités plus critiques • Il y a donc des règles compliquées et rigoureuses concernant les – Appels de procédures et passage de params entre niveaux • Considérez le Cheval de Troie où un sujet à niveau plus protégé fait appel à un programme dans un niveau moins protégé INF 6153 37
Implémentation Linux • Voir SELinux – Security Enhanced Linux – Un système complexe qui peut entre autre implémenter MAC-MLS INF 6153 38
LAC: Modèle treillis de Denning: Une abstraction INF 6153 39
La tradition et la nouveauté • Dans le chapitre « Contrôle de flux » nous avons vu que la notion d’ordre partiel est suffisante pour exprimer les propriétés essentielles des modèles de protection de données • Dans la suite nous verrons la théorie traditionnelle, qui est basée sur la notion de treillis, une structure plus complexe que les ordres partiels INF 6153 40
Modèles treillis (LAC: Lattice-Based Access Control) • Le modèle treillis est une abstraction qui généralise l’idée du modèle BLP • Fut développée par Dorothy Denning dans un article de 1976 et a été le sujet d’énormément de recherche • Modèle relationnel, les autorisations de lecture-écriture sont données en fonction de la position des sujets-objets dans une structure algébrique – Le treillis INF 6153 41
Treillis (Lattices) • Un treillis est un ordre partiel (L, ≤) qui satisfait aux conditions suivantes: – Pour n’importe quel paire d’éléments (a, b) ∈ Lx. L 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 INF 6153 • Un ‘plus petit ‘élément’, borne inférieure de tous 42
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érieure s communes (d, e, f), mais aucune qui est la plus petite INF 6153 a et b ont plusieurs bornes inférieures (0, d, g, h, i) mais aucune d’elles ne correspond à la déf de borne inférieure 43
Modèle treillis de Denning • 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 INF 6153 44
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 INF 6153 45
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(b 1, …, bn) • qui peuvent être vues comme des lectures de b 1, …, bn suivies par une écriture sur a – Donc ce modèle peut être utilisé pour analyser le flux de données dans les INF 6153 46
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 INF 6153 47
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 INF 6153 48
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 INF 6153 49
Relation avec le modèle d’ordre partiel • Le modèle d’ordre partiel, développé dans le chapitre « Contrôle de flux » est basé sur les mêmes idées • Cependant il est plus général et pratique parce que – Tout treillis est un ordre partiel, mais pas vice-versa – Les ordres partiels mentionnés sont toujours présents dans tout diagramme de flux – Tandis que le modèle treillis doit être créé • Comme nous avons vu, créer un treillis pourrait demander d’introduire des entités inexistantes INF 6153 50
Exemple • Marie: (Top. Secret, {NUC, EUR, US}) • Jean: (Secret, {NUC, US } ) • Tom: (Confidential, {EUR, US } ) • 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 Mari e Jea n INF 6153 Tom 51
Rélation dom Si A est un niveau de secret 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}) INF 6153 52
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 INF 6153 53
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 ∅ INF 6153 54
Treillis pour l’exemple précédent: Niveaux de sécurité (simplifié à 3 niveaux) Top. Secret ≥ Confidential INF 6153 55
Note sur la direction des flèches • Dans cette section, les flèches sont dans la même direction que la relation dom – C’est la manière la plus usuelle dans la littérature • Mais si les flèches sont pour exprimer la relation de flux de données, elles doivent être en direction opposée! • A peut envoyer des données à B ssi B à une autorisation au moins égale à celle de A – Donc si B domine A INF 6153 56
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: – (Top. Secret, {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 3 x 8=24 éléments: – Exercice: Énumérez-les! • Ce treillis montre la direction du transfert des données permis dans l’organisation concernée INF 6153 57
Le niveau supérieur et le plus bas … diagramme à compléter (Top. Secret, {NUC, EUR, US}) (Top. Secret, {NUC, EUR}) (Top. Secret, {NUC, US}) (Top. Secret, {EUR, US} ) (Top. Secret, {US}) (Top. Secret, ∅) … (Confidential, ∅) INF 6153 58
Exemple plus petit 2 niveaux et 2 catégories INF 6153 59
Matrice de contrôle d’accès correspondante (à compléter comme exercice: attention à la relation dom) objets Private, { pers, eng} Private, Privat {pers} {eng} e, {} sujets Private, { pers, eng} Private, { pers} Private, { eng Private, { } INF 6153 60
Matrice de contrôle d’accès correspondante (début de solution) sujets objets Private, { pers, eng} Private, { pers} Private, { eng} Private, { } Public, { pers, eng} Public, { pers} Public, { eng} Public, {} Private, { pers, eng} R, W R R R R Private, { pers} W R, W -- R Private, { eng} W -- R, W R Private, { } W W W R, W Public, { pers, eng} Public, { pers} Public, { eng} Public, {} INF 6153 61
La taille du treillis global • S’il y a C catégories, nous aurons à chaque niveau de sécurité 2 C sousensembles de cet ensemble • Si nous avons N niveaux, la taille totale du treillis sera donc N*2 C INF 6153 62
Éléments vides • Un treillis 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é INF 6153 63
Exemple de treillis représentant une situation pratique de sécurité 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. P. ex. Il n’y a pas un élément S-ALW 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. INF 6153 Le nombre max. possible de combinaisons est 1, 024, mais seul. 21 sont utilisées dans cette organisation. 64
Exercice (à côté) • Comment ais-je calculé 1024 dans le transparent préc. ? – Fait: étant donné un ensemble de taille n, le treillis le plus grand qu’on peut construire est l’ensemble de tous les sous-ensemble de cet ensemble, donc il est de taille 2 n • Nous avons 8 catégories, donc le treillis le plus grand est de taille 28=256 éléments • Ce treillis est composé avec un treillis de 4 éléments, et 256*4=1024 INF 6153 65
Cas limites … • On peut avoir des modèles dans lesquels il n’y a que des niveaux de sécurité – Une seule catégorie, mais les règles de lectureécriture à travers les niveaux doivent être respectées • Nous pouvons aussi avoir des modèles où il n’y a que des catégories – Un seul niveau de sécurité, mais avec séparation de catégories • un sujet autorisé à lire NUC pourrait ne pas être autorisé à lire EUR, etc. INF 6153 66
Modèle Biba (pour l’intégrité) INF 6153 67
‘Inversion de direction’ pour Biba • Le modèle d’intégrité de Biba est normalement décrit comme l’inverse de BLP, avec les flux permis vers le bas, donc il sera décrit ici de cette manière • Cependant nous avons vu qu’il peut être décrit aussi comme modèle ‘vers l’haut’ et ceci rend plus facile sa combinaison avec le modèle de secret INF 6153 68
Modèle Biba • Dans BLP, le but est de permettre seulement le flux des données vers l’haut • Pour le secret • 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: Secret Biba: Intégrité INF 6153 69
Autrement dit … Read up Write down Données très fiables … … No read down No write up Données peu fiables Data can flow only downwards INF 6153 70
Propriétés 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, INF 6153 71
Biba: Permissions et interdictions essentiellement, opposé de BLP Très fiable S 2 Fiabilité moyenne O 1 Peu fiable S 2 Flux permis Flux défendus INF 6153 72
Tableau de contrôle d’accès pour Biba Fichier Courriels Mémos Commun Personnel = = iqués = = Fiabilité 2 Fiabilité 0 3 1 Johanne = 3 R, W W Kamel = 2 R R, W W W Jocelyne = 1 R R R, W W Richard = 0 R R R, W R INF 6153 73
Exercice • Définir formellement Biba utilisant la fonction dom que nous avons utilisée pour les treillis. INF 6153 74
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 INF 6153 75
Combinaisons et modèles reliés INF 6153 76
Variations • Politique: Les statistiques sont transférées du bas vers le haut, mais tous peuvent les lire – Supposons qu’elles sont toujours créées au niveau le plus bas, donc tous peuvent les lire pour cette raison – Ou sinon il faut penser à modifier la règle ‘simple’ • Politique: Les directives sont transférées de haut vers le bas, mais tous peuvent les lire – Si elles sont toujours créées au niveau le plus haut, donc tous peuvent les lire – Ou sinon … comme dit avant INF 6153 77
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 INF 6153 78
Combinaison BLP-Biba v. 1 • BLP est un modèle de secret, 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 … INF 6153 79
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 secret maximal et d’intégrité minimale : • il peut seulement lire des autres niveaux – Supposons que S soit un sujet d’intégrité maximale et de secret minimal : • il peut seulement écrire dans les autres niveaux INF 6153 80
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? INF 6153 81
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 – Enfin, je viens de donner la réponse … INF 6153 82
Modèle Lipner • Le modèle de Lipner profite de la possibilité de combiner les deux modèles de secret et d’intégrité – Voir Bishop: Computer Security Sect. 6. 3. 2 – Aussi info dans www INF 6153 83
Modèle Clark-Wilson • Une alternative au modèle Biba pour l’intégrité – Mais plus complexe • Se préoccupe surtout du problème de la cohérence mutuelle des informations (p. ex. dans la comptabilité) • Basé sur les concepts de transactions bien formées et de séparation de droits • Plusieurs règles assurent que les transactions soient exécutées de manière à préserver l’intégrité et la cohérence INF 6153 84 • Informations disponibles dans la Toile et
Composition de treillis (Bishop: Computer Security, Sect. 8. 1. 1, figures prises de ce manuel) La composition de treillis ne sera pas sujet de cours pour l’année 2020. Nous verrons s’il y aura temps plus tard. INF 6153 85
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é INF 6153 86
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 INF 6153 87
Comment composer • Observons 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 à INF 6153 88 droite etc,
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}) INF 6153 89
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 INF 6153 90
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 INF 6153 91
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? INF 6153 92
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 INF 6153 93
Extensions et problèmes INF 6153 94
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 INF 6153 95
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 INF 6153 96
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 chera à lire O, il saura si S’ lui a dit ‘oui’ ou ‘non’ INF 6153 97
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 INF 6153 98
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, ‘haute ligne de crue’ INF 6153 99
Exercice (modèle dit de haute ligne de crue - 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 le secret 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 le secret dans le système? Considérer la même idée par rapport à la protection de l’intégrité INF 6153 100
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 INF 6153 101
Limites de MAC-MLS • Les canaux cachés peuvent casser le modèle – Permettant des lectures-écritures qui ne sont pas permises par le modèle • Sinon, MAC-MLS est fiable quand le système est statique – Défendu de créer des nouveaux sujets ou objets – Défendu de changer de niveaux • Ou quand il est administré de manière 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 • Permettre seulement l’augmentation de niveau (high water mark) • Il pourrait être peu pratique de structurer une organisation selon MAC-MLS ‘stricte’ INF 6153 102
Notre simplification … (dans le chapitre Contrôle de flux) • 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 INF 6153 103
Un modèle de sécurité théorique: La non-Interférence INF 6153 104
Non-Interférence • Le modèle de non-interférence représente une définition très stricte du concept de secret • 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 INF 6153 105
Cas concret • Exemple dans lequel le principe de non-interférence est respecté: • 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 public 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 INF 6153 106
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(h 1, … , hm, b 1, …, bn) doit être une fonction de b 1 … bn exclusivement – doit être indépendent des valeurs de h 1 … hn • Tandis que un calcul hj = F’(h 1, … , hm, b 1, …, bn) peut être une fonction de tous les arguments INF 6153 107
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 (le mot de passe), • une publique (le nom d’usager) • et donne comme résultat une donnée publique (accepté ou non) • Mais notez que 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 … INF 6153 108
Prise en compte du chiffrage • L’idée de base du chiffrage est d’utiliser des fonctions F qui permettent de calculer bj = F(h 1, … , hm, b 1, …, bn) de manière que h 1, … , hm soient pratiquement impossibles à récupérer à partir de la valeur de bj , même s’ils ont été utilisés dans le calcul Donc le principe de non-interférence est violé, mais sans conséquences pratiques INF 6153 109
BLP et non-interférence • BLP respecte le critère de noninterférence seulement s’il est statique INF 6153 110
Valeur du modèle de non-interférence • Il paraît donc que le modèle de noninterférence est seulement de valeur théorique, comme exemple de définition « limite » du concept de secret INF 6153 111
Modèle Muraille de Chine Modèle Brewer-Nash INF 6153 112
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 INF 6153 113
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 Bank COI Class Gasoline Company COI Class – Autre exemple: Bank of America Citibank Shell Oil Bank of the West Union ’ 76 Standard Oil ARCO INF 6153 Figure d’un livre de M. Bishop 114
Autre vision Classes de conflit Compagnies Objets Un sujet qui peut lire inf 2 ne peut pas lire inf 4 Il peut cependant lire dans les classes CI 2 ou CI 3 Pour éviter la fuite de données ce sujet ne peut écrire que dans Banque 1 INF 6153 Dessin de Sofiene Boulares 115
Besoins • (secret) 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 – Ni directement ni indirectement O S Banqu e Royale Toronto Domini on Banqu e Royale INF 6153 Toronto Domini on 116
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 … INF 6153 117
Propriété simple (les ovales sont sujets, les rectangles objets, donc les flèches sont des lectures) Banque A Consultant Gaz A Banque B Auto A Suffisante? INF 6153 118
Propriété * (les ovales sont sujets, les rectangles objets, donc les flèches sont des lectures ou écritures) Banque A Consultant e A Auto A Banque B Consultant e 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 INF 6153 119
Contraintes pour une implémentation (définition traditionnelle) • (Propriété simple, lecture) 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é *, écriture) 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 INF 6153 120
Contraintes 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 INF 6153 121
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 Alic e B Roy Shell. Oil B Desj Bob INF 6153 Sinon, les infos de BDesj pourraient se trouver dans Shell 122
Empêcher 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! Alic e B Roy Shell B Desj Bob Honda Carol e INF 6153 Les infos de Banque. Desj peuvent se trouver dans Honda Alice peut lire tant Broy que BDesj 123
Utilisant le modèle de contrôle de flux • Le modèle basé sur les étiquettes permet de résoudre le même problème de manière plus facile • L’étiquette {BRoy, BDesj} est défendue – Scénario 1: Si avant tout Alice obtient le droit de lire de la banque BRoy, son étiquette dira ça. Si Bob et Carole obtiennent les droits qui lui permettent de transférer des données de BRoy à Honda, BRoy sera dans l’étiquette de Honda et Alice ne pourra pas obtenir le droit de lire Honda – Scénario 2: Alice peut lire de BRoy et Honda et puis Bob et Carole obtiennent les droits qui lui permettent de transférer des données de BRoy à Honda; alors Honda va acquérir l’étiquette BDej et Alice perd le droit de lire de Honda • Contrôlez que les contraintes dérivées mentionnées avant ne sont pas obligatoires avec ce mécanisme INF 6153 124
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 données différentes pour aider l’une et nuire à l’autre Alic ? e Banque 1 Banque 2 INF 6153 125
Flux de données • On voit que dans Ch. Wall 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 INF 6153 126
Contrainte excessive! • Il est clair que la propriété * est trop restrictive • Voir le modèle développé dans mes diapos sur le contrôle de flux, qui est moins restrictif – Il s’agit de ‘marquer’ un sujet ou un objet en fonction des données qu’il aurait pu acquérir à cause de ses permissions dans le passé • Cependant dans cette manière on ne respecte pas la ‘contrainte additionnelle’ mentionnée INF 6153 127
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 INF 6153 128
Succès de Ch. Wall • Malgré ses limites, le CW ou des mécanismes semblables sont prescrits dans des lois ou règlements sur la comptabilité et la finance • Sandhu a justement observé que les limitations de CW pourraient être difficiles à appliquer pour des usagers physiques, mais elles peuvent être facilement appliquées aux processus informatiques et bases de données INF 6153 129
Application du modèle treillis • Le modèle treillis peut être appliqué aussi au CW, mais ceci est laissé à vos lectures INF 6153 130
Exercice • Montrer comment le modèle CW peut être utilisé pour empêcher les Chevaux de Troie INF 6153 131
Exercice • Représenter les diagrammes précédents comme matrices de contrôle d’accès INF 6153 132
LBAC: Étiquettes de sécurité méthode qui combine des éléments de DAC et MAC-MLS Myers et Liskov 1997 http: //www. cs. cornell. edu/andru/papers/iflow. Sosp 97/ (les figures sont prises de cet article) INF 6153 133
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) INF 6153 134
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 INF 6153 135
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 INF 6153 136
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 INF 6153 137
Concepts utiles de LBAC • Étiquettent qui disent qui est le propriétaire et qui sont les sujets autorisés à lire (v. DAC et MACMLS) • 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 INF 6153 138 autorisations
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 INF 6153 139
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 … INF 6153 140
Conclusion sur les modèles MAC-MLS 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 INF 6153 141
Quelques champions … David Elliott Bell Len La Padula Barbara Liskov Kenneth Biba INF 6153 Dorothy Denning TCSEC ou Orange Book, 1985 142
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é … • Morale: cherchez à faire tout bien la première fois … – Évidemment une terminologie beaucoup meilleure serait d’appeler • La propriété simple: propriété de lecture • La propriété * : propriété d’écriture INF 6153 143
- Slides: 143