Rappel de la mthode de contrle daccs en

Rappel de la méthode de contrôle d’accès en UNIX-Linux INF 6153 http: //w 3. uqo. ca/luigi/INF 6153/inde x. html 1

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

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

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

Problèmes … l Supposez que Jean veuille imprimer un fichier … l Il doit transférer des droits au print spooler l Dans le système UNIX de base il n’y a pas de manière de transférer ownership l Il faudrait ajouter un mécanisme pour ceci l Le contrôle de flux de données n’est pas traité On peut créer des Chevaux de Troie, nous en parlerons INF 6153 l 5

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

Droits d’exécution l Les droits d’exécution sont considérés explicitement dans le modèle Unix-Linux mais seulement implicitement dans ce cours l comme capacité d’un sujet d’écrire et lire d’un autre sujet l 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: l l 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 INF 6153 7

Conclusion … l Bien que le système de protection de UNIXLinux fournisse les concepts de base, il doit être sensiblement étendu pour les besoins réels l SE Linux est un système pour permettre d’implémenter des fonctionnalités MAC (Mandatory Access Control) en Unix-Linux l Security-Enhanced Linux INF 6153 8

ACM: Access Control Matrices INF 6153 Luigi. Logrippo@uqo. ca 9

Modèle fondamental http: //www. springerreference. com/docs/html/chapterdbid/31 7197. html Politiques PIF: Policy Information Function PDF: Policy Decision Function PEF: Policy Enforcement Function INF 6153 10

Matrice de contrôle d’accès Fichier 1 Alice Fichier 2 Fichier 3 R X Bob Jean Khaled Fichier 4 R, X R R, W W Pour exprimer les politiques de contrôle d’accès dans le modèle DAC 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 La gestion de ce tableau présente des problèmes pratiques INF 6153 11

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

ACM: Implémentation par listes de contrôle d’accès: ACL l Pour chaque objet, on garde une liste d’usagers ayant des droits sur l’objet l l Fichier 1: Alice: R; Jean: R Fichier 2: Jean: R, W etc. l Au moment où un usager demande d’accéder à un objet, il est contrôlé si l’usager a le droit l Ces listes sont faciles à consulter et mettre à jour à partir de l’objet, difficiles à partir de l’usager l l 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. INF 6153 13

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

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

Implementations typiques des listes Listes enchaînées Listes de contrôle d’accès Fichier 1 Alice: R Bob: R Fin Cette liste peut être stockée avec le fichier, ne peut pas être modif par le ‘propriétaire’ Listes de facultés Alice Fichier 1: R Fichier 4: E Fin Cette liste peut être stockée avec l’usager, qui pourrait auss la modifier INF 6153 16

Contrôle d’accès basé sur les capacités l Capability-based access control l L’usager autorisé a une clé pour accéder aux objets l Dans quelques modèles, cette clé peut être passée à autres INF 6153 17

Point de réfléxion l Quelle de ces deux solutions principales serait plus normalement utilisée et pourquoi? INF 6153 18

Solutions compromis l Étant donné que les deux implémentations ont des avantages et désavantages, on peut utiliser des solutions de compromis l Tableaux d’hachage l l Réfléchissez sur des solutions … Méthode clés-serrures l 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 v INF 6153 Lisez à ce sujet 19

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

Extension de la matrice Fichier 1 Alice Fichier 2 Fichier 3 R P 1 P 2 X Bob Jean Fichier 4 R, X R Khaled R, W W P 1 P 2 Le processus P 1 peut l exécuter P 2 l lui passer des données (écrire sur lui) et l en recevoir des résultats (lire de lui) X, W, R W Le processus P 2 peut seulement passer des résultats à P 1 INF 6153 21

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

DAC Contrôle d’accès discretionnaire Luigi. Logrippo@uqo. ca INF 6153 23

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

Idée de DAC Fichier 1 Alice Fichier 2 Fichier 3 R X Bob Jean R, X, Owner R R, W Khaled W Fichier 1 Alice Fichier 2 R Fichier 3 Fichier 4 X Bob Jean Fichier 4 R, X, Owner R R, W Khaled W R Bob, qui est propriétaire du Fichier 4, a octroyé le droit de lecture à Khaled 25 INF 6153

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

Modèle DAC de base (Lampson) l Quatre droits possibles d’usagers sur objets: l Own, Read, Write, Execute l Quatre types d’opérations: l l Création ou destruction d’un usager Un usager peut créer un objet l l Un usager qui a propriété d’un objet peut octroyer un droit sur un objet, autre que la propriété, à un usager l l En assume de ce fait la propriété (own) 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 l Incluant soi-même INF 6153 27

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

Exemple: l 1) État initial: deux usagers déjà créés Alice 4) Alice autorise Bob à lire dans F 1 Alice O, W Bob l 2) Alice crée F 1, en devient propriétaire F 1 Alice O Bob R 5) Bob crée F 2, en devient propriétaire et puis autorise Alice F 2 à l’exécuter. F 1 Alice O, W X Bob R O l 4) Alice autorise soi-même à écrire dans F 1 F 1 Alice Bob O, W 6) Alice retire l’autorisation de F 1 F 2 Bob à lire sur F 1 Alice O, W X Bob INF 6153 O 29

Analyse d’accessibilité l Si le nombre de sujets et objets créés reste fini, il est possible d’explorer toutes les évolutions possibles du système, p. ex. l É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 F 1, il devient propriétaire 2 B crée un objet F 2, il devient propriétaire 3 A autorise A à écrire dans F 1 4 A autorise B à lire dans F 1 5 B autorise A à lire F 2 6 Si A a le droit de lire F 2, B lui le retire 7 Si B a le droit de lire F 1, A lui le retire l (Cet automate doit montrer toutes les possibilités d’exécution pour cet ensemble d’opérations) INF 6153 30

F 1 7 A O 3 A O, W B R 2 B R 4 3 A 1 F 1 A O, W O B B 2 A A B 2 F 2 B 1 F 1 4 F 2 O O 5 B R O 3 4 A 5 INF 6153 A R B O B F 2 O, W B A F 2 O F 1 A B F 2 A O 2 F 1 Cherchant à montrer toutes les possibilités d’évolution F 1 O F 1 F 2 O R O Etc… la feuille se remplit rapidement mais, 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. 31

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

Mais en pratique … l L’analyse d’accessibilité reste théorique car dans une organisation de taille il est laborieux de la faire chaque fois que des droits changent l É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 l Pensez à un système style Facebook, comment le réprésenter? INF 6153 33

Décèlement de flux indirects l 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 l l l A donne le droit à B de lire sur F 1 B a le droit d’écrire sur un fichier F 2 C a le droit de lire F 2 l l Les données que A pourrait écrire sur F 1 peuvent être lues par B et recopiées sur F 2 C peut les lire a l’insu de A l Exercice: étudier plus à fond cette possibilité NB 1: 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 l NB 2: 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 INF 6153 l 34

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

Cheval de Troie! l Vicky crée un fichier appelé Secret, seulement pour elle l Pirate crée un fichier X et donne à Vicky l’autorisation d’écrire sur ce fichier (à l’insu de Vicky) l Pirate crée un fichier Programme et donne à Vicky l’autorisation à l’exécuter l Ce programme (le cheval de Troie!) fait des choses utiles pour Vicky mais aussi il lit de Secret et écrit sur X l Vicky exécute Programme … l À 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 Pirate peut lire l 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 l Contrôler que les chevaux de Troie peuvent être facilement INF 6153 créés dans le modèle Lampson 36

Cheval de Troie schéma Vicky Secret Pirate Programme (Cheval de Troie) X INF 6153 37

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

Modèle HRU: Harrison, Ruzzo, Ullmann, 1976 l HRU est une extension du modèle DAC de base l Il définit un système pour l l Créer ou détruire des sujets et des objets Octroyer ou retirer des permissions entre sujets et objets l Il a des propriétés théoriques intéressantes et il est beaucoup cité l Mais il n’a jamais été implémenté tel quel l 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 l Ce qui aujourd’hui est facilement compris INF 6153 39

Idée du langage HRU l La lettre « r » représente un droit quelconque l Exemples: droits de lecture, écriture, exécution mais aussi autres selon les besoins d’un système quelconque l Chaque commande: l l If: Conditionnel à des droits déjà affectés à des sujets et objets Then: Peut l l ajouter ou enlever des droits « r » à autres sujets ou objets créer ou détruire des sujets ou des objet Exemple: Si if un usager A a le droit r sur l’objet O l Alors then le droit r’ peut être donné à un usager B INF 6153 sur l’objet O’ seulement 40 l

Syntaxe détaillée des commandes HRU INF 6153 41

Généralité l Ce langage est très général l 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 if l En pratique il pourrait être utile à un administrateur de système, il est trop général pour un usager normal l À 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 l Aussi, les conditions peuvent être seulement positives l On ne peut pas dire: si A n’a pas le droit r sur O INF 6153 42

Exemples – Réseau social? command CREATE (process, file) create object file enter own into (process, file) end command CONFER (Alice, Sam, file) if own in (Alice, file) then enter r into (Sam, file) end command REMOVE (Alice, Abdel, file) if own in (Alice, file) and r in (Abdel, file) then delete r from (Abdel, 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. INF 6153 Aucun changement si un droit entré était déjà là 43

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. INF 6153 Opérations multiples dans une commande 44

Ordre d’exécution des opérations l Il n’y a pas d’ordre séquentiel de commandes l Une commande peut être exécutée dès que ses préconditions et conditions sont vraies l Les préconditions sont en général évidentes, p. ex. l l 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 l Chaque commande peut aussi avoir une condition « if » l La commande peut être exécutée seulement si la INF 6153 cond est vraie 45

Sûreté (safety) d’un système HRU l 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 l 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 l l 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 l l 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 INF 6153 46

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 l Alice a développé un programme p l Ce programme est offert en exécution à Bob l l 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 l l l Alice: grant_execute (Alice, Bob, P 1) Bob: modify_own_right (Bob, P 1) Évidemment on peut aussi avoir une commande qui enlève ce droit à Bob… INF 6153 47

Exercice l Comment créer un Cheval de Troie avec ce langage? l Facile … INF 6153 48

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

Indécidabilité de la sûreté l Rappel: 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 l L’article mentionné prouve que le problème de la sûreté est indécidable pour les systèmes multi-operational l Formellement il prouve 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 INF 6153 de Turing est aussi décidable l 50

Idée de la preuve de l’indécidabilité l 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 l l 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 L’article 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 l 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 l Clairement cette indécidabilité est conséquence de la définition très générale des systèmes HRU INF 6153 51

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

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

Droit de copier n Un usager exécutant dans un domaine ou session peut avoir le droit de copier un droit d’accès (signalé par *) u p. ex. un usager exécutant dans domaine D 2 peut copier son droit d ’accès sur fichier F 2 à un autre domaine INF 6153 54

Changement de domaine (ou session) Fichier 1 Fichie r 2 Fichie r 3 Fichie r 4 Dom 1 R E Dom 2 R, E, Owner Dom 3 R Dom 4 n Dom 1 Dom 2 Dom 3 Dom 4 switch R, W W switch 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) u p. ex. on peut changer de Dom 2 à Dom 3, mais pas viceversa INF 6153 55

Contrôle sur autres types de droits l Nous nous sommes concentrés sur les droits de lecture et écriture l Les mêmes principes s’appliquent à autres types de droits: l l l 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 INF 6153 56

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

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

Dans ce chapitre … l Modèle ACM des matrices de contrôle d’accès, qui peut être considéré comme le modèle de base du Cd. A l Il montre explicitement qui peut faire quoi l 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 l Modèle HRU, qui est un modèle DAC pour lequel la propriété de sûreté est indécidable l Variations de ces modèles … l Enfin nous avons montré que les modèles DAC sont puissants et généraux, mais aussi ils ont des problèmes importants, notamment: l l Difficultés d’administration Difficulté de vérification: l De quels droits un sujet est titulaire à un moment donné? l Quelles données peuvent arriver à qui? Donnent tout le contrôle à la personne qui a créé les données, chose qui n’est pas désirable dans la plupart des organisations INF 6153 l 59

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