Skip to content

Linux : les droits, permissions et utilisateurs

Linux est un système assez complet et ayant une gestion des droits via des utilisateurs et des groupes. Cependant, beaucoup de débutants ne comprennent pas exactement ce fonctionnement ou même l’utilité d’avoir plusieurs utilisateurs voir les problèmes que peuvent engendrer le fameux « chmod 777 ».

Cet article aura alors pour but de vulgariser (ou au moins essayer) ces aspects tout en parlant un peu de sécurité.

 

Les utilisateurs

Afin de gérer les droits, Linux utilise les utilisateurs. Ces utilisateurs sont tous définis par 2 choses : Un nom et un User ID tous les deux uniques.

Pour comprendre un peu mieux, jetons un œil au fichier /etc/passwd

Bon… Quand on voit un bloc comme ça on ne comprend peut-être rien. Pas de panique on regarde le man (https://linux.die.net/man/5/passwd) et on analyse.

En prenant une ligne d’exemple (à tout hasard la 2ème), on va essayer de comprendre

driikolu:x:1000:1000:Juste moi:/home/driikolu:/bin/bash

Déjà, il s’agit de 7 champs tous séparés par le caractère « : ». Ces champs sont (dans l’ordre) :

  • Le nom de l’utilisateur
  • Son mot de passe
  • Son ID d’utilisateur
  • Son ID de groupe
  • Une description de l’utilisateur
  • Son dossier « home »
  • Le shell de connexion par défaut

Donc avec notre ligne d’exemple on sait que notre utilisateur s’appelle driikolu, que son ID d’utilisateur est 1000, que son ID de groupe est aussi 1000, on a une description nous disant « Juste moi », on sait que son dossier « home » est /home/driikolu et qu’il utilise de base le shell bash…

Et pour certains, quelques questions ont déjà germées :

  • Pourquoi tous les mots de passes sont « x » ?
  • Ça sert à quoi le dossier « home » ?
  • Pourquoi certains ont un shell en nologin (ou false selon la machine) ?
  • C’est quoi l’ID de groupe ?

 

Pas de panique ! Je vais répondre à tout ça.

 

Les mots de passe

Il faut savoir que le dossier /etc/passwd est autorisé en lecture pour tous les utilisateurs (ou presque). Et les normes Linux voulaient que le mot de passe soit dans /etc/passwd, ou plutôt un hash (https://fr.wikipedia.org/wiki/Fonction_de_hachage) du mot de passe. Le hash n’étant normalement pas réversible (comprendre, qu’on ne peut pas obtenir la chaîne de base à partir de celui-ci), alors en théorie il n’y avait aucun problème.

Seulement, les machines sont devenues plus puissantes et peuvent calculer plus facilement divers hash pour les comparer avec les mots de passe, ceux-ci étaient donc devenus vulnérables.

Une solution était de créer un fichier contenant les hash des mots de passe, le fichier /etc/shadow qui lui n’est pas autorisé à tous en lecture.

 

Le dossier « home »

Ce dossier constituera la variable par défaut $HOME de votre utilisateur. Cette variable défini le dossier « référence » de l’utilisateur, c’est-à-dire celui où il arrive lorsqu’il se connecte, celui auquel il est fait référence avec  la tilde ( ~ ) et celui où on apparaît avec un simple « cd » (sans argument).

Par défaut ce dossier est /home/username (avec username, le nom de votre utiilsateur) sauf pour l’utilisateur root qui a la racine / (ou /root) comme « home »

 

Le /sbin/nologin et le /bin/false

Certains utilisateurs n’ont pas vocation à se connecter, souvent il s’agit d’utilisateurs spéciaux pour certains services. Typiquement l’utilisateur daemon qui doit gérer les démons (applications en arrière-plan pour faire simple) ou l’utilisateur mail qui gère le service de mail.

Puisque le champ du shell ne peut pas être vide, la solution est d’avoir un exécutable qui… Ne fait rien : le nologin ou false.

Ainsi, si vous essayez de vous connecter à un utilisateur ayant l’un de ces « shell », rien ne se passera.

 

L’ID de groupe

En plus des utilisateurs il existe des groupes. Chaque utilisateur est au moins dans 1 groupe (en général un groupe à son nom). On peut aussi voir les différents groupes dans /etc/groups

On retrouve à peu près le même format que pour /etc/passwd, on a donc 4 champs :

  • Le nom du groupe
  • Le mot de passe du groupe
  • L’ID du groupe
  • La liste des utilisateurs de ce groupe (séparés par des virgules)

 

La fonctionnalité du mot de passe est très peu (Qui a dit jamais ?) utilisée. En effet, au niveau de la sécurité avoir un seul mot de passe pour plusieurs personnes n’a jamais été une bonne chose. Malgré tout, il existe ici aussi le /etc/gshadow qui regroupe les hash des mots de passe des groupes (comme le /etc/shadow qui est pour les utilisateurs).

Aussi, les utilisateurs n’apparaissent pas dans la liste de leur groupe principal. C’est pour ça que la plupart des groupes n’ont personne dans leur liste d’utilisateur (sur ma machine).

 

 

Le root

Je pense qu’on ne peut pas présenter les utilisateurs sans faire une légère digression sur le root, même si la majorité des utilisateurs de Linux doit savoir ce que c’est.

La dénomination « root » peut désigner 2 choses :

  • La racine de la machine « / »
  • Un utilisateur spécial

Ici ce qui m’intéresse est l’utilisateur.

En effet, dans la majorité des cas, l’utilisateur à l’ID 0 est nommé « root ». Il s’agit de l’utilisateur avec le plus de droit dans la machine, celui qui théoriquement peut modifier et lire tous les fichiers. Il faut donc éviter un maximum de l’utiliser puisqu’on peut facilement casser son système avec une mauvaise manipulation (qui a parlé du fameux rm –rf /* ?).

 

Il va surtout nous servir à introduire le concept suivant…

 

 

Su & Sudo

On touche là des commandes incontournables lorsqu’on parle d’utilisateurs et de droits. Chacune peut, à sa manière, donner plus de droit à un utilisateur (en théorie, de façon temporaire).

 

Su

Su veut dire « Substitute User », le but  premier de cette commande est d’exécuter une commande en se substituant à un autre utilisateur. C’est-à-dire qu’avec un utilisateur A, je peux exécuter une commande en tant qu’utilisateur B.

Par défaut cette commande va ouvrir un shell avec l’utilisateur root c’est-à-dire que

$ su

et

$ su root –c /bin/bash

Correspondent à la même chose.

En général cette commande est utilisée pour utiliser un autre utilisateur sans avoir à se déconnecter du premier. Et bien sûr elle demande le mot de passe de l’utilisateur ciblé.

C’est-à-dire que l’utilisateur A doit connaître le mot de passe de l’utilisateur B pour exécuter des commandes avec ses droits.

 

Sudo

On commence à toucher à quelque chose d’un peu plus complexe.

Sudo veut dire « Substitue User do » (ou originalement « SuperUser do »).  L’utilité générale de sudo est la même que pour su : Exécuter des commandes avec les droits d’un autre utilisateur.

Seulement il y a une petite différence… Au niveau du mot de passe.

Si un utilisateur A veut exécuter une commande avec les droits de l’utilisateur B en utilisant sudo, il n’aura pas besoin du mot de passe de l’utilisateur B mais de celui de l’utilisateur A… Voir dans certaines configurations il n’aura pas besoin de mot de passe.

C’est donc un outil qui peut s’avérer très dangereux lorsqu’il est mal configuré et c’est d’ailleurs pour ça que je le déconseille (en général).

 

Bien sûr s’il est bien configuré il permet d’autorisé seulement des commandes choisies en tant qu’un utilisateur donné. Par exemple si votre seule utilité à l’utilisation du root est l’installation de nouveaux paquets, il est vrai que ça peut être tentant de configurer sudo pour autoriser votre utilisateur à utiliser le gestionnaire de paquet en tant que root.

Si vous risquez de laisser votre machine à quelqu’un évitez donc de laisser un sudo avec toutes les commandes pour votre utilisateur. Et pour ce qui est de la sécurité le sudo « no password » n’est pas très recommandé non plus.

 

 

Les fichiers et leurs permissions

On arrive au cœur du sujet, ce pourquoi les utilisateurs ne peuvent pas lire, modifier ou exécuter tous les fichiers. Tout d’abord pour illustrer un peu, on va faire un ls –la

On a ici 3 champs différents qui nous intéressent (entourés en Rouge, vert et bleu sur l’image suivante)

Pour commencer, les champs vert et bleu : Ils donnent respectivement le propriétaire du fichier et le groupe  attaché au fichier.

 

Vient ensuite le champ rouge qui correspond aux permissions du fichier.

Dans un premier temps on va considérer les 3 lettres r,w,x. Ces trois lettre correspondent chacune à une permission :

  • r – read (droit de lecture)
  • w – write (droit d’écriture/modification)
  • x – execute (droit d’exécution)

Ces droits de base peuvent apparaitre 3 fois pour le même fichier :

rwx rwx rwx

Chaque « bloc » de droit ne cible pas la même personne :

  • Le premier bloc cible le propriétaire du fichier
  • Le second bloc cible le groupe
  • Le troisième cible tous les autres utilisateurs

C’est-à-dire qu’un fichier avec les droits

rwx r_x ___

Permet au propriétaire de tout faire, au groupe de lire et exécuter le fichier et les autre utilisateurs n’ont aucun droit sur le fichier.

 

S’il ne s’agit pas d’un fichier mais d’un dossier les règles sont globalement les même avec quelques subtilités.

  • r – Vous avez le droit de lister le contenu du dossier
  • w – Vous pouvez ajouter des dossiers/fichier au dossier
  • x – Vous pouvez ouvrir le dossier (aller dedans)

Aussi, si vous avez un dossier, un petit d apparaîtra devant les permissions.

setuid, setgid & sticky bit

Jusque-là on a parlé de 3 droits notés r, w et x. Mais de temps en temps un « s » apparaît à la place du x.

Il s’agit là du setuid ou setgid (on parle aussi de suid et guid). Ce « s » peut apparaître dans les permissions du propriétaire ou du groupe. Il permet à ceux qui exécutent le fichier de le faire avec les droits du propriétaire ou du groupe (selon là où il se trouve).

Par exemple :

Imaginons que je suis l’utilisateur « jacky ».  Ici, on voit jacky peut exécuter les 2 fichiers grâce au x dans la 3ème partie.

Si j’exécute le fichier exemple_1.sh je le ferai avec les droits de driikolu puisqu’à la place du x du propriétaire, il y a un s.

Si j’exécute le fichier exemple_2.sh je le ferai avec les droits du groupe tmptest puisqu’à la place du x du groupe, il y a un s.

 

Pour ce qui est des dossiers et fichier non-exécutables, le setgid a un comportement un brin différent.

  • Pour un dossier, il va déterminer à quel groupe appartiendront les nouveaux fichiers contenus dans le dossier
  • Pour un fichier non-exécutable, il va le verrouiller de façon à ce qu’il ne soit accessible que par 1 processus à la fois (en anglais il s’agit du mandatory locking)

 

En plus de ça il y a le sticky bit.

Le sticky bit est représenté par un t à la place du x des autres utilisateurs (troisième bloc de permission). Tout le monde a au moins 1 dossier avec ce sticky bit : le /tmp/

Le sticky bit ajoute juste ce qu’on appelle une « suppression restreinte » (restricted deletion). C’est-à-dire que les utilisateurs ne pourrons pas supprimer les fichiers qui sont dans ce dossiers s’ils n’en sont pas les propriétaires (du fichier, pas du dossier).

C’est-à-dire que si un utilisateur A créé un fichier dans le /tmp/ , il pourra en faire ce qu’il veut. Et un utilisateur B ne pourra pas supprimer le fichier même si les permissions lui autorise.

 

 

 

J’espère que cet article vous a paru assez clair et vous a appris des choses sur les droits et permissions. Je vous invite à aller voir le travail de Julia Evans qui explique aussi l’utilisation du chmod.

 

 

Published inArticle

2 Comments

  1. Nyarlatothep Nyarlatothep

    Bravo Driikolu et merci pour cette présentation claire. Comptes-tu faire un nouveau billet sur selinux et la façon dont sont étendus les contrôles discrétionnaires ?

    • Merci pour ton retour !
      Pour l’instant ce n’est pas prévu parce que je ne connais pas assez bien SELinux.
      Mais il n’est pas exclus que je travaille dessus pour approfondir mes connaissances. 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *