Un droit c'est quoi ?
Un droit c'est une information supplémentaire associée à un fichier ou un répertoire qui va permettre de dire qui a la permission d'effectuer ou non certaines actions. Sur un système de fichier Unix, chaque fichier en plus son contenu, possède des informations qui lui sont propres comme son nom, sa taille, son propriétaire... et ses droits d'accès. Toutes ces informations sont décrites dans la norme POSIX. Tout système de fichier qui se veut conforme à cette norme doit donc impérativement posséder ce type d'information.Les systèmes de fichiers conformes à cette norme sont par exemple : ext2, ext3, reseirfs, xfs... Le système de fichier FAT (système de fichier encore utilisé couramment avec Windows) par exemple n'est pas conforme à la norme POSIX.
Droits : les bases
Les droits sur les systèmes Linux sont relatifs à 3 classes d'utilisateurs :- L'utilisateur propriétaire du fichier ou du répertoire qui est appelé u pour user
- Le groupe propriétaire du fichier ou du répertoire qui est appelé g pour group
- Tout utilisateur qui n'appartient pas aux deux premières catégories qui est appelé o pour other.
Pour chacune de ces trois classes, il existe trois droits possibles (en réalité un peu plus comme nous le verrons par la suite) :
- Le droit de lecture appelé r pour read
- Le droit d'écriture appelé w pour write
- Le droit d'exécution appelé x pour exécution
Il est possible d'afficher ces droits grâce à la commande ls suivie de l'option -l :
$ ls -l /bin/bash -rwxr-xr-x 1 root root 678832 Dec 7 2007 bash
Comme on peut le voir dans cet exemple, le fichier bash appartient à l'utilisateur root (premier root affiché par la commande), au groupe root (deuxième root affiché par la commande) et possède les droits en lecture/écriture/exécution pour son propriétaire (rwx), les droits en lecture/exécution pour son groupe propriétaire (premier r-x) et les droits en lecture/exécution pour les autres utilisateurs (deuxième r-x).
Impact de chaque droit
C'est bien joli d'avoir des droits sur des fichiers et des répertoires mais encore faut il précisément savoir à quoi cela peut bien servir.Droit en lecture
Le droit en lecture noté r est très facile à comprendre. Pour un fichier il permet d'autoriser ou non la lecture du fichier et pour un répertoire la possibilité de lister son contenu.Même si nous n'avons pas les droits en lecture sur un répertoire il nous est tout à fait possible d'accéder aux fichiers ou répertoires contenus à l'intérieur (si bien entendu les droits sur ces fichiers/répertoires nous le permettent). En revanche, il faut absolument connaître leur nom (ou le deviner en brute force par exemple mais ceci est un autre sujet).
$ id uid=1001(time0ut) gid=1001(time0ut) groupes=1001(time0ut) $ ls -l total 1 drwx--x--x 1 root root 4096 Dec 1 directory_not_readable $ ls directory_not_readable ls: cannot open directory_not_readable: Permission denied $ cat directory_not_readable/file_readable Je peux lire le contenu !
Droit en écriture
Le droit en écriture noté w permet pour un fichier et pour un répertoire d'autoriser ou non la modification de leur contenu. Il est important ici de bien comprendre ce que l'on entend par modification de contenu d'un répertoire. La présence ainsi que le nom d'un fichier dans un répertoire fait parti du contenu du répertoire et non du contenu du fichier. Ce qui implique les éléments suivants :- On peut modifier le nom d'un fichier si on a les droits en écriture sur le répertoire sur lequel il est contenu, même si nous n'avons pas les droits en écriture sur ce fichier. Inversement, nous ne pouvons pas modifier le nom d'un fichier sur lequel nous avons les droits en écriture, si nous ne possédons pas les droits d'écriture sur le répertoire.
- On peut supprimer un fichier si on a les droits en écriture sur le répertoire sur lequel il est contenu, même si nous n'avons pas les droits en écriture sur le fichier. Inversement, il ne sera pas possible de supprimer un fichier sur lequel nous avons les droits en écriture, si nous n'avons pas les droits en écriture sur le répertoire. Tout au plus nous pourrons vider le fichier, mais nous ne pourrons pas le supprimer.
$ id uid=1001(time0ut) gid=1001(time0ut) groupes=1001(time0ut) $ ls -l total 1 drwxrwxrwx 1 root root 4096 Dec 1 directory_writable $ ls -l directory_writable total 1 -rwxr-xr-x 1 root root 5 Dec 1 file_not_writable $ echo "Je vais pas pouvoir ecrire !!!" >> directory_writable/file_not_writable directory_writable/file_not_writable: Permission denied $ rm directory_writable/file_not_writable $ ls -l directory_writable total 0
Comme on peut le voir dans cet exemple, nous avons les droits en écriture sur directory_writable mais pas sur le fichier contenu dans ce répertoire. Il nous est donc impossible de modifier le contenu de ce fichier, mais rien ne nous empêche de le supprimer. Par la suite il sera alors possible de le recréer avec un contenu différent (on a donc réussi à éviter la protection du fichier). Attention donc quand vous configurez les droits d'accès à ne pas oublier de placer les bons droits sur les répertoires.
Droit en exécution
Le droit en exécution sur un fichier permet comme son nom l'indique d'autoriser ou non l'exécution de ce fichier. Le droit en exécution sur un répertoire permet d'autoriser ou non l'accès au répertoire. Sans les droits en exécution il est donc impossible de se placer à l'intérieur d'un répertoire ou de le traverser pour aller dans sa sous arborescence. Il est tout à fait possible d'autoriser le droit en exécution sur un répertoire sans autoriser le droit en lecture, on pourra donc se placer dans ce répertoire, le traverser mais pas lister son contenu. Le droit d'exécution n'est pas nécessaire pour lister le contenu d'un répertoire (même si la commande ls bien qu'elle affiche le résultat fasse une erreur).$ id uid=1001(time0ut) gid=1001(time0ut) groupes=1001(time0ut) $ ls -l total 1 drwxr-xr-- 1 root root 4096 Dec 1 directory_readable $ cd directory_readable cd: directory_readable: Permission denied $ ls directory_readable ls: cannot access directory_readable: Permission denied file $ for i in directory_readable/*; do echo $i; done directory_readable/file
Droits Avancés
La grande majorité des personnes qui ont déjà utilisé deux ou trois fois une machine Linux connaissent les droits que je viens de décrire. Le problème de ces droits est qu'ils sont trop simplistes et que bien souvent dans certains cas on se trouve dans l'incapacité de faire précisément ce que l'on souhaite. Pour cela il existe des droits supplémentaires assez particulier que je vais décrire ici.Setuid bit
Dans un système Unix quand un utilisateur x exécute un programme, ce dernier possède les droits de l'utilisateur x. Par exemple quand l'utilisateur time0ut exécute le programme bashce dernier aura les droits de l'utilisateur time0ut. Jusque là tout est normal.Comment faire quand on vient d'écrire un programme qui nécessite de faire une minuscule tâche qui a besoin de droits que ne devraient pas avoir l'utilisateur qui utilisera ce programme ? Doit on lui donner l'ensemble des droits pour effectuer cette minuscule tâche ? Bien sûr que non ! Alors comment faire ? La solution est le setuid bit.
Ce bit quand il est positionné sur un programme qui a les droits en exécution a pour conséquence que le programme n'aura plus les droits de l'utilisateur qui a lancé le programme (uid), mais les droits du propriétaire du programme (euid). Si on reprend l'exemple du programme bash, si ce dernier avait le setuid bit activé et que notre utilisateur time0ut l'exécute alors bash aurait les droits du propriétaire du programme c'est à dire les droits du root.
On voit ici le danger que le setuid bit peut engendrer. Le simple fait de positionner ce bit sur un programme comme bash donnerait l'ensemble des droits à tous les utilisateurs du système. Toute application possédant le setuid bit est donc relativement critique car la moindre vulnérabilité trouvée dans cette application peut entraîner une élévation de privilège. Dans la mesure du possible il est donc très important d'éviter le recours à cette configuration.
Le programme ping que tout le monde connaît possède habituellement le setuid bit. Il nécessite les droits du root pour forger les paquets ICMP. Sans ce setuid bit, il ne serait pas possible à un utilisateur non root d'utiliser cette commande. Un autre exemple de programme est passwd.
Le setuid bit sur un répertoire est ignoré par le système Linux (les systèmes BSD peuvent l'interpréter d'une façon similaire au setgid bit qui sera développé plus tard).
$ ls -l /usr/bin/passwd -rwsr-xr-x 1 root root 32988 Nov 13 07:54 /usr/bin/passwd
Remarques
Il ne sert à rien de mettre un setuid bit sur un script (shell, perl, python...) car ce dernier est interprété.
Le setuid bit (tout comme le setgid bit) peut aussi apparaître avec un S majuscule. Dans ce cas cela veut dire que le fichier ne possède pas le droit en exécution. Si c'est un s minuscule comme dans l'exemple ci dessus, le fichier possède le droit en exécution. Le setuid sans le droit en exécution n'a à priori aucune caractéristique particulière et est donc ignoré (j'ai lu je ne sais plus où que certains Unix le setuid bit sur un fichier n'ayant pas les droits en exécution pouvait permettre de lock pour éviter les accès multiples notamment avec des systèmes de fichier réseau comme NFS).
Si vous souhaitez avoir plus d'information sur la gestion du setuid bit et que les termes de uid et effective uid ne vous sont pas étrangers, n'hésitez pas à jeter un coup d'oeil à ce lien qui décrit la gestion de ce cas.
Setgid bit
Le setgid bit suit le même principe que le setuid bit. Lorsqu'un programme possédant ce droit est exécuté, il ne possède plus les droits du groupe de l'utilisateur qui l'a appelé mais les droits du groupe auquel appartient le programme. Ce droit n'a pas de sens sur un fichier ne possédant pas les droits en exécution pour le groupe.Par contre lorsque ce droit est appliqué à un répertoire il signifie que chaque fichier et répertoire créé à l'intérieur possédera le même groupe que le répertoire et non pas le groupe de l'utilisateur qui a créé le fichier/répertoire, comme c'est le cas par défaut. De plus chaque répertoire créé possèdera en plus le droit setgid qu'il héritera de son parent.
$ id uid=1001(time0ut) gid=1001(time0ut) groupes=1001(time0ut) $ ls -l drwxr-xr-x 1 time0ut time0ut_group 4096 2008-12-02 22:18 directory_without_sgid drwxr-sr-x 1 time0ut time0ut_group 4096 2008-12-02 22:18 directory_with_sgid $ touch directory_without_sgid/file $ ls -l directory_without_sgid/file -rw-r--r-- 1 time0ut time0ut 0 2008-12-02 22:18 directory_without_sgid/file $ touch directory_with_sgid/file $ mkdir directory_with_sgid/directory $ ls -l directory_with_sgid drwxr-sr-x 2 time0ut time0ut_group 4096 2008-12-02 22:23 directory -rw-r--r-- 1 time0ut time0ut_group 0 2008-12-02 22:18 file
Comme on peut le voir dans l'exemple ci-dessus qui illustre mes précédents propos, le fichier créé dans le répertoire sans setgid possède le groupe de l'utilisateur qui a créé le fichier, alors que le fichier créé dans le répertoire avec setgid possède le même groupe que le groupe du répertoire. On peut remarquer aussi le droit setgid activé par défaut sur le répertoire créé.
Sticky bit
Le dernier droit que l'on verra dans ce billet est le sticky bit qui apparaît en lieu et place du droit en exécution pour la classe d'utilisateur other sous forme d'un t ou d'un T. Comme pour le setuid et le setgid la majuscule signifie que le droit en exécution n'est pas positionné alors que la minuscule signifie qu'il l'est.Le sticky bit sur un fichier n'est plus utilisé dans la majorité des systèmes Unix et ne l'a même jamais été sur Linux. Le positionnement de ce bit permettait à un exécutable d'avoir son code placé directement en swap quand celui ci n'est pas utilisé. De cette façon le lancement du programme se fait plus rapidement. Il était souvent positionné sur les programmes utilisés fréquemment comme les éditeurs de texte.
Le sticky bit positionné sur les répertoires est par contre toujours utilisé de nos jours sur le répertoire /tmp par exemple.
$ ls -ld /tmp drwxrwxrwt 8 root root 4096 Nov 6 /tmp
Comme je l'ai dit précédemment avoir les droits en écriture sur un répertoire nous permet de modifier le contenu de ce répertoire (ajout de fichier, suppression de fichier, modification du nom de fichier...). Cela veut dire qu'il serait possible de supprimer n'importe quel fichier du répertoire /tmp, même ceux qui ne nous appartiennent pas. Le sticky bit est utilisé pour éviter cela. Quand le sticky bit est positionné sur un répertoire, seul le possesseur du répertoire, le possesseur du fichier et l'utilisateur root peuvent renommer ou supprimer ce fichier, même si le droit en écriture est positionné sur ce répertoire.
Quelques commandes utiles
Je finis ce billet par quelques commandes se rapportant aux droits ou au propriétaire/groupe propriétaire sur les fichiers et répertoires.Modification du propriétaire/groupe propriétaire
La commande chown permet de changer le propriétaire d'un fichier et la commande chgrp permet de changer le groupe propriétaire d'un fichier. Je vous renvoie aux man de ces commandes pour de plus amples informations.chown [OPTION] user[:group] file chgrp [OPTION] group file
Il est possible de changer le user ET le groupe avec la commande chown d'un fichier ou d'un répertoire. Les deux commandes acceptent l'option -R qui permet d'appliquer la modification à toute une sous arborescence ce qui peut s'avérer très utile.
Modification des droits
La modification des droits sur les fichiers se fait avec la commande chmod. Cette commande permet de configurer les droits de plusieurs façons différentes. Il est possible de le faire avec une notation symbolique que j'ai développée avant ou avec une notation octale.chmod [OPTION] permissions file
La notation littérale prend la forme de : classe_d'utilisateur opérateur permission.
classe_d'utilisateur peut être égal à u pour le propriétaire, g pour le groupe, o pour les autres et a pour tout le monde.
operateur peut être égal à + pour ajouter des droits, - pour les enlever ou = pour mettre des droits stricts.
permission peut être égal à r pour lecture, w pour écriture, x pour exécution, s pour le setuid/setgid bit et t pour le sctiky bit.
Voilà quelques exemples de commandes :
# Suppression du droit en écriture pour toutes les classes d'utilisateur chmod a-w file # Ajout du droit en exécution pour le propriétaire chmod u+x file # Ajout du droit en lecture pour le groupe et suppression de ce même droit pour other chmod g+r,o-r file # Positionnement des droits lecture/écriture pour le propriétaire, du droit de lecture pour le groupe et suppression de tous les droits pour other chmod u=rw, g=r, o= file
La notation octale ne permet pas d'enlever des droits ou d'en ajouter. Elle permet juste de mettre des droits stricts. Le fonctionnement est décrit dans le tableau suivant.
| Classe user | Classe group | Classe other | |
|---|---|---|---|
| Classe d'utilisateur | u | g | o |
| Droits | rwx | rw- | r-- |
| Binaire | 111 | 110 | 100 |
| Octal | 7 (1x2^2 + 1x2^1 + 1x2^0) | 6 (1x2^2 + 1x2^1 + 0x2^0) | 4 (1x2^2 + 0x2^1 + 0x2^0) |
$ ls -l total 0 -rwxrwxrwx 1 time0ut time0ut 0 2008-12-02 23:47 file $ chmod 750 file $ ls -l file -rwxr-x--- 1 time0ut time0ut 0 2008-12-02 23:47 file
Si l'on souhaite mettre les droits spéciaux, il suffit de rajouter un chiffre au début : 1 pour le sticky bit, 2 pour le setgid bit et 4 pour le setuid bit (les combinaisons sont possibles).
$ ls -l file -rwxr-x--- 1 time0ut time0ut 0 2008-12-02 23:47 file $ chmod 1750 file $ ls -l file -rwxr-x--T 1 time0ut time0ut 0 2008-12-02 23:47 file $ chmod 5750 file $ ls -l file -rwsr-x--T 1 time0ut time0ut 0 2008-12-02 23:47 file $ chmod 6750 file $ ls -l file -rwsr-s--- 1 time0ut time0ut 0 2008-12-02 23:47 file
Droits par défaut lors de la création d'un fichier/répertoire
Lorsqu'un fichier est créé sur le disque il a des droits par défaut qui sont fonctions d'un masque. Les droits qui en résultent sont le résultat de l'opération suivante : droits_demandés & !masque. La modification du masque se fait grâce à la commande umask.Si l'on souhaite enlever par défaut les droits en écriture/exécution pour le groupe et tous les droits pour les autres donc aboutir à des droits du style rwxr----- qui en binaire se traduit par 111 100 000. Il suffit de prendre l'inverse en binaire, donc 000 011 111 qui se traduit en octal par 037.
$ umask 0000 $ touch file1 $ ls -l total 0 -rw-rw-rw- 1 time0ut time0ut 0 2008-12-02 23:43 file1 $ umask 037 $ touch file2 $ ls -l total 0 -rw-rw-rw- 1 time0ut time0ut 0 2008-12-02 23:43 file1 -rw-r----- 1 time0ut time0ut 0 2008-12-02 23:43 file2
Ici le droit en exécution n'est pas mis tout simplement car la commande touch ne le positionne pas. Comme on peut le voir il est aussi possible de spécifier des droits spéciaux.
Recherche de fichiers en fonction de leurs droits
Voilà quelques commandes qui peuvent être très utiles lors de l'audit d'un système Unix par exemple. Elles sont basées sur la commande find associé à l'option -perm.L'option -perm en fonction de comment est marqué les permissions qui suivent ne se comporte pas de la même façon. Si les permissions qui suivent ne sont précédées d'aucun opérateur alors cela signifie que l'on cherchera l'ensemble des fichiers/répertoires possédant exactement les droits demandés. Ces droits pouvant être précisés en octal ou en symbolique.
Si l'opérateur - précède les droits, alors find cherchera les fichiers/répertoires possédant tous les droits précisés (le fichier peut en avoir plus, il faut juste qu'il ait les droits demandés par l'option).
Si l'opérateur / précède les droits, alors find cherchera les fichiers/répertoires possédant au moins un de ces droits.
Voilà quelques exemples de commandes de recherche utile :
# Recherche des répertoires possédant les droits en écriture pour tout le monde find / -type d -perm -o=w -print find / -type d -perm -002 -print # Même chose avec les fichiers find / -type f -perm -o=w -print find / -type f -perm -002 -print # Recherche de fichiers possédant le setuid bit ou le setgidbit find / -type f -perm /u=s,g=s -print find / -type f -perm /6000 -print
Pour plus d'informations sur la commande find reportez vous à son manuel (man find).
Ce billet se termine. Il sera certainement suivi dans le futur par d'autres sur des sujets proches comme par exemple les ACL ou sur les attributs que l'on peut mettre sur les fichiers/répertoires sur le système de fichier ext2/3 (lsattr, chattr...).
merci beaucoup pour cette article
RépondreSupprimer