Rappel de la méthode de contrôle d’accès en UNIX-Linux http://w3.uqo.ca/luigi/INF6153/index.html INF6153

Pourquoi on en parle La méthode de contrôle d’accès d’UNIX-Linux est un ‘classique’ Est énormément utilisée Et a inspiré beaucoup d’extensions Malheureusement ces extensions sont restées en grande partie Ou bien dans des implantations de compagnies, et chacune différente Ou bien dans la théorie … INF6153

Catégories d’usagers pour un fichier Owner d’un fichier Membres du Group de l’owner Les groupes sont déterminés par les administrateurs du système Tous les autres Les droits d’un usager sont déterminés par la catégorie à laquelle il appartient L’owner détermine ces droits en assignant des valeurs à un ensemble de trois triplets INF6153

Exemple Usager Jean crée un fichier, il est dans le groupe INF6153, il est automatiquement owner Jean peut se donner des droits sur le fichier P.ex. Read and write, rw Jean peut octroyer des droits à son groupe ou aux autres, p.ex: Les membres de son groupe ont droit read Aucun droit n’est assigné aux Autres Les trois triplets seront donc: rw- r-- --- INF6153

Problèmes … Supposez que Jean veuille imprimer un fichier … Il doit transférer des droits au print spooler Dans le système UNIX de base il n’y a pas de manière de transférer ownership Il faudrait ajouter un mécanisme pour ceci INF6153

Problèmes … Jean veut que Bob puisse lire son fichier Carole puisse y écrire Dave puisse l’exécuter Anne veut donner un droit à ‘tous moins Alice’ Aucun moyen de faire rien de ceci dans UNIX … Plusieurs systèmes cherchent à augmenter le modèle de base de UNIX, mais chacun le fait de sa manière INF6153

Droits d’exécution Les droits d’exécution sont considérés explicitement dans le modèle Unix-Linux mais seulement implicitement dans ce cours comme capacité d’un sujet d’écrire et lire d’un autre sujet Car si un sujet S exécute un Programme S’ on peut considérer que S’ soit un autre sujet et que les actions suivantes aient lieu: S écrit sur S’ quand il lui passe des données pour le faire exécuter À la fin de son exécution, S’ écrit sur S les résultats INF6153

Conclusion … Bien que le système de protection de UNIX-Linux fournisse les concepts de base, il doit être sensiblement étendu pour les besoins réels INF6153

ACM: Access Control Matrices Luigi.Logrippo@uqo.ca INF6153

Modèle fondamental http://www.springerreference.com/docs/html/chapterdbid/317197.html PDF: Policy Decision Function PEF: Policy Enforcement Function INF6153

Matrice de contrôle d’accès Fichier1 Fichier2 Fichier3 Fichier4 Alice R X Bob R, X Jean R, W Khaled W Clairement, cette méthode est très précise Mais une matrice de contrôle d’accès sera normalement Un tableau très grand et très éparpillé Énormément de cases ‘blanches’ = aucun droit Car dans une grande organisation il y aura probablement des milliers d’employés et des milliers d’objets dont la grande majorité n’auront rien à faire les uns avec les autres Presque impossible d’utiliser cette méthodes pour des objets plus spécifiques que des fichiers entiers La gestion de ce tableau présente des problèmes pratiques INF6153

Implémentations: Listes par colonnes ou par lignes ACM est souvent implémenté dans une des deux manières suivantes: Listes de contrôle d’accès: Liste d’objets avec, pour chaque objet, la liste des usagers qui ont des permissions sur les objets Listes de facultés: (capability lists) Liste d’usagers avec, pour chaque usager, la liste des objets sur lequel il a une permission Ou, plus normalement, solutions de compromis INF6153

ACM: Implémentation par listes de contrôle d’accès: ACL Pour chaque objet, on garde une liste d’usagers ayant des droits sur l’objet Fichier1: Alice:R; Jean:R Fichier2: Jean: R,W etc. Au moment où un usager demande d’accéder à un objet, il est contrôlé si l’usager a le droit Ces listes sont faciles à consulter et mettre à jour à partir de l’objet, difficiles à partir de l’usager P.ex. comment peut Alice déterminer rapidement sur quels objets elle a des droits? Faut demander séquentiellement: a-t-elle droit au fichier 1, puis fichier 2, etc. INF6153

ACM: Implémentation par listes de facultés Pour chaque usager, on garde une liste d’objets sur lesquels l’usager a le droit Alice: Fichier1: R; Fichier 4: E Bob: Fichier 4: R,X Ces listes sont faciles à consulter et mettre à jour à partir de l’usager, difficiles à partir de l’objet P.ex.comment déterminer rapidement tous ceux qui ont des droits sur Fichier4? Faut demander séquentiellement: Alice, a-t-elle droit, Bob, etc. INF6153

Si on garde les deux listes … Dans ce cas il est nécessaire d’assurer la cohérence des deux listes dans les mises à jour INF6153

Implementations typiques des listes Listes enchaînées Listes de contrôle d’accès Fichier1 Alice: R Bob: R Fin Listes de facultés Alice Fichier1: R Fichier4: E Fin INF6153

Exercice Quelle de ces deux solutions serait plus normalement utilisée et pourquoi? INF6153

Solutions compromis Étant donné que les deux implémentations ont des avantages et désavantages, on peut utiliser des solutions de compromis Tableaux d’hachage Réfléchissez sur des solutions … Méthode clés-serrures Chaque usager reçoit un ensemble de clés, chaque objet reçoit un ensemble de serrures, l’usager peut faire des accès s’il a la bonne clé pour la bonne serrure Lisez à ce sujet INF6153

Droits d’exécution: Concept étendu d’usager ou ‘sujet’ On peut passer des infos à un processus, p.ex. des paramètres On peut dire qu’on ‘écrit’ dans le processus On peut recevoir des résultats d’un processus, donc On peut dire qu’on ‘lit’ du processus Ces relations peuvent être représentées en généralisant le concept de sujet INF6153

Extension de la matrice Fichier1 Fichier2 Fichier3 Fichier4 P1 P2 Alice R X Bob R, X Jean R, W Khaled W X, W, R Le processus P1 peut exécuter P2 lui passer des données (écrire sur lui) et en recevoir des résultats (lire de lui) Le processus P2 peut seulement passer des résultats à P1 INF6153

Utilisation Malgré leurs limites, les matrices et listes de contrôle d’accès sont encore très utilisées en pratique L’implémentation de méthodes plus sophistiqués commence souvent par l’utilisation de ces informations V. discussion suivante sur Role Mining etc. INF6153

Contrôle d’accès discretionnaire Luigi.Logrippo@uqo.ca INF6153

DAC – Discretionary Access Control DAC est une extension de l’idée de UNIX par laquelle le propriétaire d’un objet peut octroyer des droits sur l’objet à d’autres usagers INF6153

Idée de DAC Fichier1 Fichier2 Fichier3 Fichier4 Alice R X Bob R, X, Owner Jean R, W Khaled W Fichier1 Fichier2 Fichier3 Fichier4 Alice R X Bob R, X, Owner Jean R, W Khaled W Bob, qui est propriétaire du Fichier 4, a octroyé le droit de lecture à Khaled INF6153

Variations de DAC: beaucoup Sur cette idée de base, on a créé un grand nombre de variations Un modèle simple fut décrit dans deux articles de Lampson en 1971 et 1972 Le modèle théorique le plus cité est le modèle de Harrison, Ruzzo et Ullman (HRU), v. leur article de 1976 Nous décrirons ces modèles dans une manière simplifiée Les développements plus compliqués ont seulement une valeur théorique INF6153

Modèle DAC de base (Lampson) Quatre droits possibles d’usagers sur objets: Own, Read, Write, Execute Quatre types d’opérations: Création ou destruction d’un usager Un usager peut créer un objet En assume de ce fait la propriété (own) Un usager qui a propriété d’un objet peut octroyer un droit sur un objet, autre que la propriété, à un usager Incluant soi-même Un usager qui a propriété d’un objet peu retirer des droits d’accès à un autre usager qui a ces droits INF6153

Principe d’atténuation des privilèges Peut un usager octroyer des privilèges qu’il n’a pas? Principe: Un sujet peut octroyer à autres seulement un privilège qu’il a Un des principes fondamentaux en sécurité Cependant on peut le questionner dans des modèles différents de DAC: Surtout dans le cas d’administrateurs qui peuvent n’avoir aucun droit sur les fichiers, excepté le droit d’octroyer des droits Variante: Un sujet peut octroyer à autres seulement un privilège qu’il a ou qu’il pourrait s’octroyer INF6153

Exemple: État initial: deux usagers déjà créés Alice crée F1, en devient propriétaire Alice autorise soi-même à écrire dans F1 Alice autorise Bob à lire dans F1 Bob crée F2, en devient propriétaire et puis autorise Alice à l’exécuter Alice retire l’autorisation de Bob à lire sur F1 F1 Alice O,W Bob R Alice Bob F1 Alice O Bob F1 F2 Alice O, W X Bob R O F1 Alice O, W Bob F1 F2 Alice O,W X Bob O INF6153

Analyse d’accessibilité Si le nombre de sujets et objets créés reste fini, il est possible d’explorer toutes les évolutions possibles du système, v. exemple suivant Étant donné un système dans lequel deux usagers, A et B ont déjà été créés, calculer l’automate d’accessibilité global pour les opérations suivantes: 1 A crée un objet F1, il devient propriétaire 2 B crée un objet F2, il devient propriétaire 3 A autorise A à écrire dans F1 4 A autorise B à lire dans F1 5 B autorise A à lire F2 6 Si A a le droit de lire F2, B lui le retire 7 Si B a le droit de lire F1, A lui le retire (Cet automate doit montrer toutes les possibilités d’exécution pour cet ensemble d’opérations) INF6153

Toutes les branches reviendront enfin à un état ou à un autre. O,W B R 3 7 2 4 3 F1 A O,W B F1 F2 A O B R 4 Etc… la feuille se remplit rapidement mais nous voyons que, si le nombre d’usagers et de fichiers est fini, le nombre d’états possibles est fini. Toutes les branches reviendront enfin à un état ou à un autre. F1 A O B 2 1 2 F1 F2 A O B F1 F2 A O,W B O 3 A B 4 2 1 5 F2 A B O F1 F2 A O R B F2 A R B O 5 INF6153

Concepts impliqués État Transition Automate Graphe d’accessibilité Chacun des tableaux que nous avons vu décrit un état du système Transition Exécution d’une opération Automate Consiste d’états et transitions Graphe d’accessibilité Un automate qui décrit tous les états et transitions possibles Analyse d’accessibilité Le processus de créer un graphe d’accessibilité INF6153

Mais en pratique … Cette méthode reste de valeur théorique car dans une organisation de taille il est laborieux de faire cette analyse chaque fois que des droits changent Étant donné aussi que le système pourrait être réparti, aucun participant n’aura une vision globale de l’ensemble des opérations effectuées Pensez à un système style Facebook INF6153

Décèlement de flux indirects S’il est possible de calculer un automate à états finis pour un système, il est aussi possible d’examiner s’il existe la possibilité de transferts indirects de données A donne le droit à B de lire sur F1 B a le droit d’écrire sur un fichier F2 C a le droit de lire F2 Les données que A pourrait écrire sur F1 peuvent être lues par B et recopiées sur F2 C peut les lire a l’insu de A Exercice: étudier plus à fond cette possibilité NB1: Si les sujets ont une mémoire interne, la possibilité montrée existe non seulement si tous les droits nécessaires sont dispo simultanément, mais aussi si un sujet peut lire et puis plus tard écrire NB2: cette méthode est peu pratique car pour prévenir ce type de fuite il est nécessaire de bloquer complètement les échanges entre certains usagers INF6153

Problème fondamental avec DAC Une fois qu’un usager a transféré un droit à un autre usager, il perd tout contrôle sur l’utilisation de ce droit Pis, ce transfert peut être utilisé de manière hostile! Chevaux de Troie Un programme qui exécute des actions hostiles à l’insu de l’utilisateur La possibilité de modifier les fichiers exécutables crée des autres possibilités qui sont encore plus difficiles à déceler INF6153

Cheval de Troie! Vicky crée un fichier appelé Secret, seulement pour elle Jean crée un fichier X et donne à Vicky l’autorisation d’écrire sur ce fichier (à l’insu de Vicky) Jean crée un fichier Programme et donne à Vicky l’autorisation à l’exécuter Ce programme (le cheval de Troie!) fait des choses utiles pour Vicky mais aussi il lit de Secret et écrit sur X Vicky exécute Programme … À noter que cette possibilité peut être décelée par la méthode mentionnée de détection de flux indirects, car Vicky peut écrire sur un fichier dans lequel Jean peut lire Cependant l’algorithme de détection doit être exécuté chaque fois qu’une autorisation quelconque change, ce qui n’est pas pratique dans une grande organisation INF6153

Source L’article: Exercice: Lampson: Protection and Access Control in Operating Systems. In: Operating Systems, Infotech State of the Art Report 14, 1972, 311-326 Exercice: Lire quelques une des nombreuses sources web sur “Cheval de Troie”, “Trojan Horse” INF6153

Modèle HRU: Harrison, Ruzzo, Ullmann, 1976 HRU est une extension du modèle DAC de base Il définit un système pour Créer ou détruire des sujets et des objets Octroyer ou retirer des permissions entre sujets et objets Il a des propriétés théoriques intéressantes et il est beaucoup cité Mais il n’a jamais été implémenté tel quel Le but de ce modèle est de montrer que le problème de détecter les dangers dans un système DAC peut être insoluble Ce qui aujourd’hui est facilement compris INF6153

Syntaxe détaillée des commandes HRU INF6153

Généralité Ce langage est très général Il n’empêche rien, toute affectation ou suppression de droits quelconque entre sujets et objets quelconque est admise, selon les conditions spécifiées dans les commandes En pratique il pourrait être utile à un administrateur de système, il est trop général pour un usager normal À noter que les sujets peuvent être dans des lignes ou dans des colonnes pour représenter le fait qu’un processus peut avoir des droits par rapport à un autre processus INF6153

Conditions if Chaque opération dans HRU peut être conditionnelle Par rapport au contenu actuel du tableau Exemple: Le droit D peut être donné à un usager A sur l’objet O seulement si un autre usager B n’a pas le droit D’ sur l’objet O’ INF6153

Exemples – Réseau social? command CREATE (process, file) create object file enter own into (process, file) end command CONFER (Alice, friend, file) if own in (Alice, file) then enter r into (friend, file) end command REMOVE (Alice, exfriend, file) if own in (Alice, file) and r in (exfriend, file) then delete r from (exfriend, file) end command REMCONF (Alice, newfriend, exfriend, file) if own in (Alice, file) and r in (exfriend, file) then delete r from (exfriend, file) enter r into (newfriend, file) end INF6153

Exemples – Réseau social? command CREATE (process, file) create object file enter own into (process, file) end command CONFER (Alice, friend, file) if own in (Alice, file) then enter r into (friend, file) end command REMOVE (Alice, exfriend, file) if own in (Alice, file) and r in (exfriend, file) then delete r from (exfriend, file) end Opérations multiples dans une commande command REMCONF (Alice, newfriend, exfriend, file) if own in (Alice, file) and r in (exfriend, file) then delete r from (exfriend, file) enter r into (newfriend, file) end INF6153

Ordre d’exécution des opérations Il n’y a pas d’ordre séquentiel de commandes Une commande peut être exécutée dès que ses préconditions et conditions sont vraies Les préconditions sont en général évidentes, p.ex. on ne peut pas donner des droits sur des objets qui n’existent pas on ne peut pas effacer des droits qui n’ont pas été donnés Chaque commande peut aussi avoir une condition « if » La commande peut être exécutée seulement si la cond est vraie Le système peut être non-déterministe si à un certain point plusieurs commandes peuvent être exécutées INF6153

Sûreté (safety) d’un système HRU Définition: Un système HRU a une fuite d’un droit r s’il y a une manière de mettre r dans une case où il n’était pas avant Définition: un système HRU n’est pas sûr pour un droit r si on peut arriver, exécutant son programme, à une fuite pour r Plusieurs fuites peuvent être voulues et pas dangereuses… Mais certaines fuites peuvent être dangereuses, donc il serait utile si la sûreté d’un système pouvait être déterminée par inspection du code du système Sachant qu’une fuite est dangereuse, pouvons-nous déterminer si elle est possible? Malheureusement ceci n’est pas possible en général dans les systèmes multi-operational INF6153

Exemple de fuite possiblement dangereuse command grant_execute (s,p,f) if o in (s,f) then enter x into (p,f) end command modify_own_right (s,f) if x in (s,f) then enter w into (s,f) end Alice a développé un programme p Ce programme est offert en exécution à Bob Il se peut qu’Alice ne voudrait pas qu’il soit modifié par lui Mais Bob se donne le droit d’écrire sur le programme dès qu’il a reçu le droit de l’exécuter Alice: grant_execute (Alice, Bob, P1) Bob: modify_own_right (Bob, P1) Cependant on peut aussi avoir une commande qui enlève ce droit à Bob… INF6153

Exercice Comment créer un Cheval de Troie avec ce langage? Facile … INF6153

Ce qui est facile, possible et impossible Facile: déterminer si dans un ensemble de commandes il y a une commande qui peut causer une fuite spécifique Possible: dans beaucoup de cas particuliers, déterminer si ces commandes peuvent arriver à être exécutées Exécuter l’algorithme que nous avons vu Impossible: inventer un algorithme qui peut trouver les fuites dans un ensemble de commandes multi-opérationnel quelconque INF6153

Indécidabilité de la sûreté L’article de HRU prouve que le problème de la sûreté est indécidable pour les systèmes multi-operational Formellement HRU prouvent que le problème de la sûreté dans un tel système peut être réduit au problème de la décision de l’arrêt d’une machine de Turing Si le pb de la sûreté est décidable, alors le pb de l’arrêt de Turing est aussi décidable On sait que ce dernier problème est indécidable INF6153

Idée de la preuve de l’indécidabilité Un théorème fondamental de l’informatique dit qu’on ne peut pas construire une machine de Turing pour déterminer si une machine de Turing arbitraire s’arrête ou non On ne peut pas écrire un programme pour déterminer si un programme arbitraire s’arrête ou non (car: appliquez le programme à lui-même …) Cas particulier: On ne peut pas écrire un programme pour déterminer si un programme arbitraire contient un interblocage (deadlock) L’article de HRU prouve que, étant donné un système HRU multi-operational et une propriété de sûreté, il est possible de construire une machine de Turing telle que la machine s’arrête ssi la propriété de sûreté est décidable Donc le problème de la sécurité des systèmes HRU est indécidable comme le problème de l’arrêt des machines de Turing Clairement cette indécidabilité est conséquence de la définition très générale des systèmes HRU INF6153

Cas décidables Le fait qu’un problème soit indécidable n’exclut pas qu’il pourrait être décidable dans quelques cas P.ex. banalement si un système ne contient aucune instruction concernant un droit r, il est sûr par rapport à r Un cas plus intéressant est si un système a un nombre fini d’état accessibles Dans ce cas on peut construire le diagramme de transitions d’état pour tous les états accessibles, donc voir toutes les situations possibles dans le système L’algorithme vu Malheureusement cette condition (nombre fini) est aussi indécidable et peut être démontrée seulement si on réussit à trouver le diagramme complet INF6153

Variations des systèmes DAC Un grand nombre de variations des systèmes DAC ont été proposées Beaucoup de propriétés de ces systèmes ont été étudiées Les diapos suivantes montrent quelques unes de ces extensions Pour la plupart, encore plus risquées INF6153

Droit de copier Un usager exécutant dans un domaine ou session peut avoir le droit de copier un droit d’accès (signalé par *) p.ex. un usager exécutant dans domaine D2 peut copier son droit d ’accès sur fichier F2 à un autre domaine INF6153

Changement de domaine (ou session) Fichier1 Fichier2 Fichier3 Fichier4 Dom1 Dom2 Dom3 Dom4 R E switch R, E, Owner R, W W Les usagers qui se trouvent dans certains domaines ou sessions peuvent exécuter un switch pour changer et assumer des nouveaux droits (v. Chap 1) p.ex. on peut changer de Dom2 à Dom3, mais pas vice-versa INF6153

Contrôle sur autres types de droits Nous nous sommes concentrés sur les droits de lecture et écriture Les mêmes principes s’appliquent à autres types de droits: Append, copy, delete Droits d’entrer dans une salle, droit de signer un cheque >10,000$ etc. À noter que le modèle HRU ne spécifie pas de quels droits on parle INF6153

Implémentation Le Modèle DAC, ainsi que les autres modèles reliés, ont inspiré beaucoup de recherche Ils donnent trop de liberté aux usagers et ils ne les protègent pas contre leurs propres erreurs Les droits d’accès peuvent se propager de manière arbitraire Aussi souvent en pratique le propriétaire d’un objet n’est pas un usager comme les autres Pourrait être l’entreprise, p.ex. Conduisant aux modèles ‘non-discretionnaires’=‘obligatoires, mandatory’ INF6153

Réseaux sociaux Les faiblesses des modèles DAC sont préoccupantes, car les réseaux sociaux utilisent des modèles DAC! Attention donc … INF6153

Dans ce chapitre … Modèle ACM des matrices de contrôle d’accès, qui peut être considéré comme le modèle de base du CdA Il montre explicitement qui peut faire quoi Modèle DAC de contrôle d’accès discrétionnaire, dans lequel le propriétaire d’un objet peu conférer des droit sur ces objets Modèle HRU, qui est un modèle DAC pour lequel la propriété de sûreté est indécidable Variations de ces modèles … INF6153

Sources utilisées https://link.springer.com/referenceworkentry/10.1007/978-1-4419-5906-5_179 Article original de Harrison, Ruzzo, Ullman: Protection in operating systems (1976) Facile à trouver Aussi figures du livre: Silberschatz et al.: Principes des Systèmes d’exploitation INF6153