Transcript Access Control Matrices

Rappel de la méthode de contrôle
d’accès en UNIX-Linux
[email protected]
INF6153
Version 2013-09-23
1
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
2
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
3
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
4
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
5
Problèmes …
 Jean veut que



Bob puisse lire son fichier
Carole puisse y écrire
Dave de 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
6
Conclusion …
 Bien que le système de protection de UNIX-Linux
fournisse quelques concepts de base, il doit être
sensiblement étendu pour les besoins réels
INF6153
7
ACM: Access Control
Matrices
INF6153
[email protected]
8
Modèle fondamental
http://www.springerreference.com/docs/html/chapterdbid/317197.html
PDF: Policy Decision Function
PEF: Policy Enforcement Function
INF6153
9
Matrice de contrôle d’accès
Fichier1
Alice
Fichier2
Fichier3
R
Fichier4
X
Bob
R, X
Jean
Khaled
R
R, W
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
La gestion de ce tableau présente des problèmes pratiques
INF6153
10
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:


Listes de facultés: (capability lists)


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
Fichier1
Alice
Fichier2
Fichier3
R
X
Bob
Jean
INF6153
Khaled
Fichier4
R, X
R
R, W
W
11
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.
Fichier1
Alice
Fichier2
Fichier3
R
X
Bob
INF6153
Jean
Khaled
Fichier4
R, X
R
R, W
W
12
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.
Alice
Fichier1
Fichier2
Fichier3
R
X
Bob
Jean
INF6153
Khaled
Fichier4
R, X
R
R, W
W
13
Si on garde les deux listes …
 À noter que, si on garde les deux listes, et on fait une
mise à jour sur une, il est nécessaire de faire la mise à
jour correspondante sur l’autre
INF6153
14
Implementations typiques des listes
Listes enchaînées
Listes de contrôle d’accès
Fichier1
Alice: R
Bob: R
Fichier1: R
Fichier4: E
Fin
Listes de facultés
Alice
INF6153
Fin
15
Solutions compromis
 Étant donné que les deux implémentations ont des
avantages et désavantages, on peut utiliser des
solutions de compromis qui réunissent les
avantages et désavantages des deux

P.ex. tableaux d’hachage

Réfléchissez sur une solution …
INF6153
16
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 d’usager

Nous parlerons plus tard de ‘sujet’
INF6153
17
Extension de la matrice
Fichier1
Alice
Fichier2
Fichier3
R
P1
P2
X
Bob
Jean
Fichier4
R, X
R
Khaled
R, W
W
P1
P2
X, W, R
W
Le processus P1 peut exécuter P2, lui passer des données et en recevoir des
résultats
Le processus P2 peut seulement passer des résultats à P1
INF6153
18
DAC
Contrôle d’accès discretionnaire
[email protected]
INF6153
19
DAC
 DAC fait 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
20
Idée de DAC
Fichier1
Alice
Fichier2
Fichier3
R
X
Bob
Jean
R, X, Owner
R
R, W
Khaled
W
Fichier1
Alice
Fichier2
Fichier3
R
Khaled
Fichier4
X
Bob
Jean
Fichier4
R, X, Owner
R
R, W
W
R
Bob, qui est propriétaire du Fichier 4, a octroyé le droit de lecture à Khaled
INF6153
21
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
INF6153
22
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


Un usager qui a propriété d’un objet peut conférer un droit sur un
objet, autre que la propriété, à un usager


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

Incluant soi-même
INF6153
23
Principe d’atténuation des privilèges
 Peut un usager octroyer des privilèges qu’il n’a pas?
 Principe: Un sujet peut attribuer à 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’attribuer des droits
 Variante: Un sujet peut attribuer à autres seulement
un privilège qu’il a ou qu’il pourrait s’octroyer
INF6153
24
Exemple
 État initial: deux usagers déjà créés
Alice autorise Bob à lire dans F1
F1
Alice
Bob
 Alice crée F1, en devient
propriétaire
Alice
O,W
Bob
R
Bob crée F2, en devient propriétaire
et puis autorise Alice à l’exécuter
F1
Alice
O
Bob
 Alice autorise soi-même à écrire
dans F1
F1
F2
Alice
O, W
X
Bob
R
O
Alice retire l’autorisation de Bob à
lire sur F1
F1
Alice
Bob
INF6153
O, W
Alice
Bob
F1
F2
O,W
X
O
25
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
2 B crée un objet F2
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
26
F1
6
F1
A O
3
A O,W
B R
2
B R
4
3
A
1
F1
F1
A O,W
O
B
B
2
A
B
B
2
F2
1
4
B R
3
O
4
A
O
5
A
O
B
5
INF6153
F2
Etc… la feuille se remplit
rapidement mais nous
voyons que le nombre
d’états possibles est fini.
O,W
B
A
B
O
F1
F2
O
F2
A O
2
F1
A
F1
F1
F2
O
R
Toutes les branches
reviendront enfin à un
état ou à un autre.
O
F2
A
R
B
O
27
Concepts impliqués
 État

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
28
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
donc aucun participant n’aura une vision globale de
l’ensemble des opérations effectuées

Pensez à un système style Facebook
INF6153
29
Décèlement de Canaux 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
d’informations



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 informations 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
30
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

Entre autres, possibilité de Chevaux de Troie

(Cheval de Troie: un programme qui exécute des actions à l’insu
de l’utilisateur)
 La possibilité de modifier les fichiers exécutables crée
des autres possibilités qui sont plus difficiles à déceler
INF6153
31
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 détection de canaux 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
http://www.springerreference.com/docs/html/chapterdbid/317733.html
Lire aussi l’histoire mythique du Cheval de Troie …
32
Source
 L’article:

Lampson: Protection and Access Control in Operating
Systems. In: Operating Systems, Infotech State of the Art
Report 14, 1972, 311-326
INF6153
33
Modèle HRU:
Harrison, Ruzzo, Ulmann, 1976
 HRU est une extension du modèle DAC de base
 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


Il donne encore plus de possibilités que le système
précédent, donc il est encore plus dangereux
Et effectivement le but de ce modèle est de montrer que le
problème de détecter les dangers peut être insoluble

Ce qui aujourd’hui est facilement compris
INF6153
34
Syntaxe détaillée des commandes HRU
INF6153
35
Exemples
command CREATE (process, file)
create object file
enter own into (process, file)
end
command CONFER (owner, friend, file)
if own in (owner, file)
then enter r into (friend, file)
end
command REMOVE (owner, exfriend, file)
if own in (owner, file) and r in (exfriend, file)
then delete r from (exfriend, file)
end
Opérations multiples
dans une commande
command REMCONF (owner, newfriend, exfriend, file)
if own in (owner, file) and r in (exfriend, file)
then
delete r from (exfriend, file)
enter r into (newfriend, file)
end
INF6153
36
Ordre d’exécution des opérations
 Le modèle formel de HRU prévoit des préconditions pour
l’exécution des opérations

Elles sont en général évidentes, p.ex. on ne peut pas donner des
droits sur des fichiers qui n’existent pas
 Aussi, chaque opération peut avoir une condition if
 L’exécution n’est pas séquentielle (pas dans l’ordre dans
lequel les opérations sont écrites)
 Une opération peut être exécutée dès que ses
préconditions et conditions sont vraies
INF6153
37
Conditions
 Chaque opération dans HRU peut être
conditionnelle

Par rapport au contenu actuel du tableau
 Exemple:

Usager X pourrait conférer à usager Y le droit D sur
l’objet O seulement si un autre usager A n’a pas le droit
D’ sur l’objet O’
INF6153
38
Multi-opérationnel
 Le système présenté dans l’article de HRU est donc
plus général que le système introduit
précédemment


Ce dernier est uni-operational = chaque commande n’a
qu’une seule opération
HRU est multi-operational
INF6153
39
Sûreté (safety) d’un système HRU
 Définition: Un système HRU a une fuite d’un droit D s’il y a une
manière de mettre D dans une case où il n’était pas avant
 Définition: un système HRU n’est pas sûr pour un droit D si on
peut arriver, exécutant son programme, à une fuite pour D


Un problème avec cette définition est que 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 dans les systèmes multioperational
INF6153
40
Exemple de fuite dangéreuses
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 P1


Elle veut que ce programme soit exécuté par Bob
Mais il ne voudrait pas qu’il soit modifié par lui



Alice: grant_execute (Alice, Bob, P1)
Bob: modify_own_right (Bob, P1)
Maintenant Bob peut modif le programme


P.ex. en faire un Cheval de Troie
Dans ce cas la fuite est immédiatement visible, mais pas toujours …
INF6153
41
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 l’article prouve ce fait en montrant que le
problème de la sûreté d’un tel système peut être reduit au
problème de la décision de l’arrêt d’une machine de Turing

On sait que ce dernier problème est indécidable
INF6153
42
Idée de la preuve de l’indécidabilité
 Un théorème fondamental de l’informatique dit qu’on ne peut pas
construire un algorithme pour déterminer si une machine de Turing
arbitraire s’arrête ou non
 L’article de HRU prouve que, étant donné une configuration d’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ûreté est indécidable comme le problème de
l’arrêt des machines de Turing

Ce résultat n’est pas surprenant …on sait p.ex. qu’on ne peut pas écrire un
programme pour déterminer si un programme arbitraire s’arrête ou non
 Cependant d’autres travaux ont montré que cette indécidabilité est
conséquence de la définition très générale des systèmes HRU

Qui peut être limitée en pratique
INF6153
43
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 D, il est sûr par rapport à
D
 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

Nous avons vu ça
INF6153
44
Variations des systèmes DAC-HRU
 Un grand nombre de variations des systèmes HRU 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
45
Changement de domaine
(ou session)
Fichier1
Dom1
Fichier2 Fichier3 Fichier4 Dom1
R
E
Dom2
Dom3
R
Dom3
Dom4
switch
switch
switch
R, E,
Owner
Dom4

Dom2
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
 p.ex. on peut changer de Dom2 à Dom3
INF6153
46
Droit de recopier

Un usager exécutant dans un domaine ou session peut avoir
le droit de recopier 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
47
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:


Execute, append, copy, delete
Droits d’entrer dans une salle, droit de signer un cheque
>10,000$ etc.
INF6153
48
Implémentation
 Le Modèle DAC, ainsi que les autres modèles reliés,
ont inspiré beaucoup de recherche

mais n’ont jamais été implémentés tels quels
 Ils donnent trop de liberté aux usagers et ils ne les
protègent pas contre leurs propres erreurs
 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’
INF6153
49
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
50
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 discretionnaire, dans
lequel le propriétaire d’un objet peu conférer des droit
sur ces objets
 Modèle DAC de HRU, pour lequel la propriété de
sûreté est indécidable
 Extensions ultérieures …
INF6153
51
Sources utilisées
 http://www.springerreference.com/docs/index.html#Encyclopedia+of+
Cryptography+and+Security+(Computer+Science)-book195
 Article original de Harrison, Ruzzo, Ullman
 Aussi figures du livre: Silberschatz et al. Principes des Systèmes
d’exploitation
INF6153
52