TD 7 - LIF12 syst`eme d`exploitation

Département d’Informatique
TD 7 - LIF12 système d’exploitation
Divers
5 janvier 2010
I
Droits unix
Sur le système considéré, il y a trois utilisateurs :
– gmw qui fait partie du groupe utilisateurs ;
– asw qui fait partie des groupes utilisateurs et developpeurs ;
– scw qui ne fait partie d’aucun de ces deux groupes.
Q.I.1) - Représentez dans une matrice les possibilités d’accès des fichiers suivants pour chaque
utilisateur.
-rw-r-----.
-rw-r--r--.
-rwxr-sr-x.
-rw-rw----.
-rw-r-----.
gsw
asw
scw
1
1
1
1
1
gmw
gmw
asw
asw
asw
developpeurs
27 janv.
utilisateurs
24 janv.
developpeurs 152392 janv.
utilisateurs 164488 janv.
developpeurs 118581 janv.
donnees.txt
rw
r
-
PPP-Notes
rw
r
r
prog1
rwx
rx
rx
2
2
2
2
2
project.t
rw
rw
-
11:06
10:46
10:47
10:55
10:49
donnees.txt
PPP-Notes
prog1
projetc.t
splash.png
splash.png
rw
-
Q.I.2) - Que signifie le bit s du fichier prog1, à quoi cela peut-il servir ? donnez un exemple
d’utilisation.
C’est le bit setgid : la commande est exécutée avec le gid du fichier et pas celui
du lanceur. Cela permet d’acquérir temporairement les droits correspondants. Ici par
exemple, quel que soit l’utilisateur lançant le programme prog1, prog1 pourra lire le
fichier splash.png (pour afficher l’icone alors que ce fichier est protégé par exemple). La
commande sudo, qui appartient à root, fonctionne selon un principe similaire, mais avec
un bit setsuid.
II
II.1
Acces Control List (ACL) dans openldap
Principe général des ACL openldap
Un annuaire électronique est une base de données spécialisée, dont la fonction première
est de retourner un ou plusieurs attributs d’un objet grâce à des fonctions de recherche multicritères. Aujourd’hui, on utilise souvent les annuaires basés sur LDAP (Lightweight Directory
Université Claude Bernard Lyon I
1
Département d’Informatique
dc=fr
dc=SpiR
ou=People
ou=RessourcesHumaines
ou=Group
ou=Informatique
ou=Computers
ou=Production
Fig. 1 – Organisation de l’annuaire LDAP dans notre exemple.
Access Protocol). Un annuaire LDAP contient des objets, organisés de façon hiérarchique
(arborescente), comme cela est illustré par la figure 1. Chaque objet peut posséder un certain
nombre d’attributs, dont certains sont normalisés, comme par exemple :
– dc pour domain component : identifie une composante de l’annuaire ;
– dn pour distinguished name : nom distingué, utilisé par d’autres attributs par héritage ;
– cn pour common name : nom commun de l’objet ;
– o pour organisation : nom de l’organisation ;
– ou pour organisation unit : branche de l’organisation ;
– ...
Un annuaire LDAP permet à certains de s’authentifier et de manipuler les informations.
Ces manipulations sont limitées par la définition des accès par des ACL. Pour définir une
directive d’accès vous devez utiliser :
access to <what> [ by <who> [ <access> ] [ <control> ] ]+
Cela donne l’accès spécifié par <access> sur un ensemble d’objets ou d’attributs spécifiés
par <what> à certains objets de l’annuaire <who>.
Pour tester si un objet a accès à une certaine cible, la liste est évaluée par ordre d’écriture.
Si une clause <what> correspond à la cible demandée, les champs <who> sont évalués. Lorsqu’un
des champs correspond à l’objet authentifié, le droit obtenu est celui qui est spécifié par
<access>. Le test s’arrête alors, sauf si cela est spécifié par <control>
On considère que chaque directive est terminée implicitement par un by * none stop refusant l’accès aux objets qui ne sont pas nommés dans la directive. De même, la liste des ACL
est supposée se terminer par
access to *
by * none
Université Claude Bernard Lyon I
2
Département d’Informatique
II.1.1
what
Le champ <what> spécifie à quel objet cible la directive s’applique. La manière dont les
objets sont identifiés est la suivante :
dn [. < dnstyle >]= < dnpattern >
attrs = < attrlist >
avec
< dnstyle >={ exact | regex | sub | c h i l d r e n}
< attrlist >={ < attr >|[{!| @ }] < objectClass >}[ , < attrlist >]
Par exemple,
– si le champ what est composé de
dn.exact="uid=root,ou=Informatique,ou=People,dc=chezmoi,dc=fr"
attrs=cn,telephonenumber
cela identifie « les attributs cn et telephonenumber de l’objet dont le distinguish name
est exactement uid=root,ou=Informatique,ou=People,dc=chezmoi,dc=fr ».
– dn.children="ou=Informatique,ou=People,dc=chezmoi,dc=fr" définit « tous les attributs des descendants de ou=Informatique,ou=People,dc=chezmoi,dc=fr ».
Attention, il y a 2 pseudo-attributs (attrs) entry et children. entry correspond à l’objet cible
lui même (par exemple, on ne veut pas afficher un attribut d’un objet sans avoir le droit de
voir l’objet). children correspond aux descendants de l’objet (pour ajouter des objets, il faut
avoir le droit write sur l’attribut children de l’ancêtre).
II.1.2
who
Le champ <who> indique à qui est attribué l’accès. Il peut être défini par un dn comme le
champ <what> mais aussi par
– * qui s’applique à tous ;
– anonymous qui s’applique à toute requête sans authentification (ce qui se passe si on n’a
pas encore donné de mot de passe) ;
– users à tout objet authentifié ;
– self à l’objet cible lui même ;
– ...
II.1.3
access
Les droits que l’on peut donner sont les suivant : none|auth|compare|search|read|write|manage.
Ces droits sont ordonnés (un droit donne obligatoirement les droits précédants).
– none signifie ne donner aucun droit ;
– auth permet seulement de s’authentifier (envoyer le dn et le mot de passe, et obtenir
l’accès ou un refus) ;
– compare, search permettent de comparer ou d’utiliser la valeur comme filtre de recherche ;
– ...
II.1.4
control
Le dernier champs <control> permet de définir le comportement une fois qu’une Acces
Control Entry (ACE) à été choisie :
Université Claude Bernard Lyon I
3
Département d’Informatique
– stop est le comportement par défaut qui arrête l’évaluation ;
– continue permet de tester aussi les autres clauses <who> de la même directive et les
directives suivantes ;
– break permet de passer à l’évaluation des autres directives.
II.2
Un exemple : une petite entreprise
Une entreprise a trois filiales à Paris, Lyon et Marseille. Les informations des employés
sont stockées dans un annuaire openldap dont vous devez définir les ACL. L’organisation de
l’annuaire est celle de la figure 1. Le but est de sécuriser les information de manière à les
distribuer le moins possible. Vous devez définir les ACL de manière à ce que :
– Par défaut toutes les informations sont lisibles sauf celles correspondant aux utilisateurs.
– Vis à vis de l’extérieur, seul les noms et numéros de téléphones sont disponibles (attributs displayName et telephoneNumber).
– Vis à vis des autres employés, seul les informations personnelles sont cachées (userPassword)
– Les machines (descendant de ou=Computers,dc=SpiR,dc=fr) doivent avoir le droit de lire
les mots de passe pour assurer l’authentification.
– Les membres des Ressources Humaines doivent pouvoir lire et modifier les données de
tous, sauf le mot de passe.
– Un utilisateur doit être capable de lire et de modifier ses propres informations.
– L’administrateur de la base (uid=root,ou=Informatique,ou=People,dc=chezmoi,dc=fr
doit pouvoir tout lire et modifier.
Q.II.1) - Proposer une ACL permettant cela.
Université Claude Bernard Lyon I
4
Département d’Informatique
# ACL 1 : qui assure qu ’ on peut m o d i f i e r ses infos et que root aussi
# la d e r n i è r e ligne est n é c e s s a i r e pour p e r m e t t r e aux autres ACE d ’ ^
e tre
# lues car celle si c o n c e r n e tout ( et une acl se finit i m p l i c i t e m e n t
#
par by * none )
access to *
by dn . exact = " uid = root , ou = Informatique , ou = People , dc = SpiR , dc = fr "
write
by self write
by * break
# ACL 2 : qui permet la g e s t i o n du mot de passe
# on s u p p o s e déjà que les cas de root et de self sont fait par l ’ ace1
access to attrs = u s e r P a s s w o r d
by dn . c h i l d r e n= " ou = Computer , dc = SpiR , dc = fr " read
by a n o n y m o u s auth
by * none
# ACL 3 : pour p e r m e t t r e à tout le monde de lire et voir le nom ( cn ) et
# le t e l e p h o n e. Attention , entry est n e c e s s a i r e pour au moins voir la
# donnée elle m^
e me
access to dn . c h i l d r e n= " ou = People , dc = SpiR , dc = fr "
attrs = cn , t e l e p h o n e numb er , entry , c h i l d r e n
by dn . c h i l d r e n= " ou = R e s s o u r c e s H um ai ne s , ou = People , dc = SpiR , dc = fr "
write
by * read
# ACL 4 : pour p r o t é g e r l ’ a d r e s s e perso ( street )
access to dn . c h i l d r e n= " ou = People , dc = SpiR , dc = fr " attrs = street
by dn . c h i l d r e n= " ou = R e s s o u r c e s H um ai ne s , ou = People , dc = SpiR , dc = fr "
write
by * none
# ACL 5 : d o n n é e s u t i l i s a t e u r qui ne sont d i s p o n i b l e s qu ’ aux
# u t i l i s a t e u r s . On permet qu ’ en m^
e me le search aux autres , ce qui
# n ’ est pas s p é c i f i é mais f a c i l i t e les tests
access to dn . c h i l d r e n= " ou = People , dc = SpiR , dc = fr "
by dn . c h i l d r e n= " ou = R e s s o u r c e s H um ai ne s , ou = People , dc = SpiR , dc = fr "
write
by dn . c h i l d r e n= " ou = People , dc = SpiR , dc = fr " read
by * search
# ACL 6 : tout ce qui n ’ est pas traité avant est l i s i b l e
access to *
by * read
Université Claude Bernard Lyon I
5
Département d’Informatique
III
Débordement de mémoire
Un grand nombre de trous de sécurité viennent des débordements mémoire. Il y a débordement
mémoire lorsqu’un programme utilise un tableau trop petit pour stocker des données. Dans
ce cas, insérer les données dans le tableau modifie d’autres variables du programme.
Par exemple, un utilisateur malveillant remplace le nom de fichier qu’il doit entrer par
une chaı̂ne de caractères trop longue et calculée de manière à modifier les bonnes variables
afin de changer le comportement du programme.
Q.III.1) - Expliquez pourquoi l’utilisation des packages et de la mémoire virtuelle peut accentuer
ce phénomène.
A cause de la mémoire virtuelle, les données sont toujours au même endroit, comme
toutes les variables. On peut assez facilement faire du reverse engineering : c’est encore
plus facile quand on utilise des logiciels open-source.
Lorsqu’on utilise des packages, le programme que le hacker réussit à faire planter sur
sa propre machine est exactement le même que celui de la machine qu’il veut attaquer
à l’autre bout du monde. Cela permet même à des apprentis hackers d’utiliser des
programmes tout fait sans rien savoir de leur fonctionnement.
Q.III.2) - Est-il possible d’utiliser les capacités de la MMU pour assurer une protection ? Sinon
pourquoi ; si oui comment et à quel coût ?
Non, car ce serait trop coûteux. Il faut bien comprendre que la MMU sert à chaque
accès mémoire. De plus, la MMU obtient l’adresse virtuelle sans autre info (pour les
variables qui ne risquent rien par exemple). Insérer du code permettant de détecter les
dépassements de tableaux signifierait exécuter ce code à chaque accès mémoire (sinon,
celui qui trouve un moyen peut devenir très riche).
Q.III.3) - Même question pour la possibilité d’utiliser le compilateur pour cela ?
Oui c’est possible car le compilateur sait comment on utilise un tableau. Le code inséré
est utilisé moins souvent donc cela est moins coûteux. Mais le surcoût reste tout de
même important. En plus c’est assez difficile car, par exemple en C, il est tout à fait
légal d’utiliser des pointeurs (tableaux de taille 1) à la place de tableaux.
Q.III.4) - Quel langage est le plus approprié entre JAVA, C et C++ pour éviter cela ? En C quelles
techniques permettent d’éviter ce phénomène ?
Les langages objet permettent justement une meilleure gestion des tableaux avec des
sécurités. Voir par exemple la lecture d’une string en JAVA ou C++ par rapport à gets.
Un bon moyen est de faire toujours attention à la taille des tableaux surtout lorsque
cela vient des utilisateurs (utilisation systématique des fonctions de la librairie string qui
imposent des limites (strncpy, snscanf, fgets) ça ne coûte pas plus cher et ça empêche
les problèmes.
Université Claude Bernard Lyon I
6