Utilisateurs, permissions et sudo

Linux a été conçu dès l'origine comme un système où plusieurs personnes partagent la même machine, sans se marcher sur les pieds. Pour cela, chaque fichier appartient à quelqu'un et précise ce que chacun a le droit d'en faire. Ce modèle de permissions est au cœur de la sécurité du système : la plupart des erreurs de configuration, et beaucoup d'attaques, jouent sur lui.

Dans la leçon précédente, vous avez affiché des fichiers avec ls -la sans vous préoccuper des colonnes de gauche. Il est temps de les déchiffrer : elles contiennent l'information de sécurité la plus importante.

Utilisateurs et groupes

Chaque personne (ou service) qui utilise le système a un compte utilisateur, identifié par un nom et un numéro, l'UID. L'administrateur, root, a toujours l'UID 0 et peut tout faire. Les utilisateurs sont réunis en groupes (identifiés par un GID), ce qui permet d'accorder des droits à un ensemble de personnes. Les commandes pour interroger l'identité :

whoami          # mon nom d'utilisateur
id              # mon UID, mon GID et mes groupes
groups          # la liste de mes groupes
who             # qui est connecté

Où sont stockées ces informations ? Dans deux fichiers que vous croiserez souvent :

• /etc/passwd : la liste des comptes, un par ligne, avec sept champs séparés par des deux-points (nom, un champ historique pour le mot de passe, UID, GID, description, répertoire personnel, interpréteur de commandes). Le fichier est lisible par tous.
• /etc/shadow : les empreintes des mots de passe (jamais les mots de passe eux-mêmes). Il n'est lisible que par root, précisément pour qu'un utilisateur ordinaire ne puisse pas les récupérer. Vous comprendrez au chapitre 6 pourquoi ces empreintes sont protégées.

Les comptes « de service » (par exemple celui qui fait tourner un serveur web) ont généralement un interpréteur /usr/sbin/nologin : personne ne peut s'y connecter en interactif. C'est une bonne pratique de sécurité.

Lire les permissions

Affichez un fichier avec ls -l :

-rwxr-xr-- 1 antoine equipe 2048 janv. 12 10:30 script.sh

Décomposons : le premier caractère est le type (- fichier, d répertoire, l lien). Viennent ensuite trois groupes de trois lettres, pour trois catégories de personnes :

Position	Pour qui ?	Dans l'exemple
caractères 2 à 4	Le propriétaire (antoine)	rwx : lire, écrire, exécuter
caractères 5 à 7	Le groupe propriétaire (equipe)	r-x : lire, exécuter
caractères 8 à 10	Tous les autres	r-- : lire seulement

Les trois droits sont r (read, lecture), w (write, écriture) et x (execute, exécution). Sur un répertoire, r permet de lister son contenu, w d'y créer ou supprimer des fichiers, et x d'y entrer et de traverser son chemin.

Modifier les droits : chmod et chown

Pour changer les permissions, on utilise chmod, de deux façons. La notation symbolique est la plus lisible :

chmod u+x script.sh        # ajoute l'exécution pour le propriétaire (user)
chmod g-w fichier.txt      # retire l'écriture au groupe
chmod o-rwx secret.txt     # retire tous les droits aux autres
chmod a+r public.txt       # ajoute la lecture pour tous (all)

La notation octale est plus compacte : chaque droit vaut un nombre (r = 4, w = 2, x = 1) et on les additionne par catégorie.

chmod 755 script.sh    # rwx r-x r-x  (7 = 4+2+1 ; 5 = 4+1)
chmod 644 notes.txt    # rw- r-- r--
chmod 600 cle.pem      # rw- --- ---  : réservé au propriétaire

Pour changer le propriétaire ou le groupe, on utilise chown (en général réservé à root) : sudo chown antoine:equipe fichier.txt.

Un autre paramètre intervient à la création d'un fichier : le umask, qui définit les droits retirés par défaut. Un umask de 022 donne des fichiers en 644 et des répertoires en 755.

Les droits spéciaux (notions)

Vous croiserez trois droits spéciaux. Retenez simplement leur existence :

• setuid (un s à la place du x du propriétaire) : le programme s'exécute avec les droits de son propriétaire, et non de celui qui le lance. C'est ainsi que passwd peut modifier /etc/shadow à la demande d'un utilisateur ordinaire.
• setgid : même principe, avec le groupe ; sur un répertoire, les nouveaux fichiers héritent de son groupe.
• sticky bit (un t) : sur un répertoire comme /tmp, chacun peut y créer des fichiers mais ne peut supprimer que les siens.

Les programmes setuid sont puissants et donc délicats : un programme setuid mal écrit ou mal configuré est un classique des chemins d'élévation de privilèges. Les administrateurs les inventorient régulièrement ; vous verrez comment au cours d'hacking éthique. Pour l'instant, sachez simplement les reconnaître avec ls -l.

sudo : des droits d'administrateur, à la demande

Travailler en permanence en root est dangereux : une faute de frappe ou un logiciel malveillant peut tout détruire. La bonne pratique est de travailler en utilisateur ordinaire et d'élever ses droits ponctuellement, pour une seule commande, avec sudo :

apt update                 # échoue : droits insuffisants
sudo apt update            # réussit après saisie de votre mot de passe
sudo -l                    # liste ce que vous avez le droit de faire avec sudo

sudo a plusieurs avantages : il demande votre mot de passe (preuve que c'est bien vous), il journalise chaque commande exécutée (qui, quand, quoi), et il permet un contrôle fin : on peut autoriser un utilisateur à lancer certaines commandes seulement. Les règles sont dans le fichier /etc/sudoers, qu'on modifie uniquement avec la commande visudo, qui vérifie la syntaxe avant d'enregistrer : une erreur dans ce fichier pourrait vous priver de tout accès administrateur.

Un utilisateur du groupe sudo (sous Debian et Kali) peut utiliser sudo. On ajoute un utilisateur à un groupe avec sudo usermod -aG sudo nom (l'option -a est essentielle : sans elle, on remplacerait tous les groupes existants).

Gérer les comptes

sudo adduser invite                 # créer un utilisateur (interactif)
sudo passwd invite                  # changer son mot de passe
sudo usermod -L invite              # verrouiller le compte
sudo deluser --remove-home invite   # supprimer le compte et son répertoire

Dans un contexte professionnel, on désactive les comptes inutilisés, on supprime les comptes des personnes qui ont quitté l'organisation, et on évite les comptes partagés : si plusieurs personnes utilisent le même compte, impossible de savoir qui a fait quoi.

À vous de jouer

Dans votre VM de laboratoire :

1. Créez un utilisateur stagiaire avec sudo adduser stagiaire.
2. Créez un fichier ~/secret.txt contenant une phrase, puis rendez-le illisible pour tous sauf vous (chmod 600).
3. Ouvrez un second terminal et connectez-vous en tant que stagiaire avec su - stagiaire. Essayez de lire /home/votre-nom/secret.txt. Que se passe-t-il ?
4. Revenez à votre compte (exit), passez le fichier en 644. Le stagiaire peut-il maintenant le lire ? Peut-il le modifier ?
5. Vérifiez que stagiaire ne peut pas utiliser sudo, puis supprimez le compte.

Voir une solution

Étape 3. Vous obtenez « Permission denied » : le fichier est en rw------- et le stagiaire fait partie de la catégorie « autres ». Il est possible que même l'accès à votre répertoire personnel soit refusé, selon les droits de celui-ci.

Étape 4. Avec 644 (rw-r--r--), les autres ont le droit de lire (r) mais pas d'écrire. Le stagiaire peut afficher le contenu avec cat, mais pas le modifier (« Permission denied »). Si la lecture est refusée, c'est le répertoire parent qui manque du droit x pour les autres.

Étape 5. sudo -l affiche pour stagiaire un message du type « user stagiaire is not allowed to run sudo » ; la suppression se fait avec sudo deluser --remove-home stagiaire.

Les fichiers et les droits n'ont plus de secrets pour vous. Reste à comprendre ce qui est en train de tourner sur votre machine, et où retrouver la trace de ce qui s'y passe : processus, services et journaux.