TD 7 - LIF12 syst`eme d`exploitation
Transcription
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