sudo et droits minimaux

Module 3: Utilisateurs, droits et sudo · Temps de lecture : 11 minutes

Objectif pédagogique : À l'issue de cette leçon, vous saurez travailler en tant qu'utilisateur normal avec sudo, ajouter un administrateur en toute sécurité, modifier les réglages de sudo sans vous enfermer dehors, et expliquer pourquoi les droits minimaux protègent votre serveur.

Notions clés : sudo, groupe sudo, groupe wheel, /etc/sudoers, /etc/sudoers.d, visudo, NOPASSWD, sudo -l, verrouiller root, journal de sudo, droits minimaux (least privilege), utilisateur de service

Pourquoi ne pas simplement travailler en root ?

Après l'installation, vous vous connectez souvent en root. C'est pratique : tout est permis. Mais c'est justement là le problème :

• Une seule faute de frappe suffit. rm -rf / home/anna/oud (notez l'espace après la première barre oblique) efface tout votre serveur en root. En tant qu'utilisateur normal, vous obtenez un message d'erreur.
• Tout tourne en root. Un script copié depuis Internet, un programme que vous testez : tout reçoit les pleins droits.
• Aucune trace. Si trois personnes travaillent en root, personne ne sait après coup qui a fait quoi.
• Root est le nom que tout attaquant essaie. Il vaut mieux désactiver complètement la connexion en root (leçon 2.2), mais ce n'est possible qu'une fois que vous disposez d'un autre accès aux droits d'administration.

Cet autre accès, c'est sudo : vous vous connectez sous votre propre nom et vous placez sudo uniquement devant une commande qui nécessite des droits d'administration.

anna@web1:~$ apt update
E: Could not open lock file /var/lib/apt/lists/lock - open (13: Permission denied)
anna@web1:~$ sudo apt update
[sudo] password for anna:
Hit:1 http://deb.debian.org/debian trixie InRelease
...

(Depuis la version 25.10, Ubuntu utilise par défaut sudo-rs, une nouvelle implémentation de sudo. Pour tout ce qui est abordé dans cette leçon, elle fonctionne de la même manière.)

sudo demande votre mot de passe, pas celui de root. Ensuite, il s'en souvient par défaut pendant un quart d'heure, pour que vous n'ayez pas à le saisir à chaque commande. Chaque commande exécutée avec sudo est inscrite dans le journal.

Créer un administrateur

Sur Debian et Ubuntu, tous les membres du groupe sudo peuvent tout faire via sudo. C'est défini dans /etc/sudoers :

%sudo   ALL=(ALL:ALL) ALL

Lisez cela ainsi : les membres du groupe sudo (%) peuvent, sur toutes les machines (ALL), en tant que n'importe quel utilisateur et groupe ((ALL:ALL)), exécuter n'importe quelle commande (ALL).

Ajouter un administrateur se fait donc en deux étapes, en tant que root :

root@web1:~# adduser anna
root@web1:~# adduser anna sudo

Placez ensuite la clé publique d'Anna dans /home/anna/.ssh/authorized_keys avec le bon propriétaire et les bons droits :

root@web1:~# mkdir -p /home/anna/.ssh
root@web1:~# cp /root/.ssh/authorized_keys /home/anna/.ssh/
root@web1:~# chown -R anna:anna /home/anna/.ssh
root@web1:~# chmod 700 /home/anna/.ssh
root@web1:~# chmod 600 /home/anna/.ssh/authorized_keys

N'oubliez pas le chown : copié par root, le fichier appartient à root, et Anna ne peut alors pas se connecter avec sa clé.

Testez maintenant dans une deuxième fenêtre, en gardant votre session root ouverte :

anna@laptop:~$ ssh anna@192.0.2.10
anna@web1:~$ sudo -l
[sudo] password for anna:
User anna may run the following commands on web1:
    (ALL : ALL) ALL
anna@web1:~$ sudo whoami
root

Ce n'est qu'une fois que cela fonctionne que vous définissez PermitRootLogin no dans vos réglages SSH (leçon 2.2). À partir de là, vous vous connectez toujours en tant qu'Anna.

Un point à retenir : Anna a maintenant besoin d'un mot de passe pour sudo. Conservez-le dans votre gestionnaire de mots de passe. La connexion se fait avec la clé, sudo avec le mot de passe : deux éléments distincts qu'un intrus doit posséder tous les deux.

Modifier les réglages de sudo : toujours avec visudo

Une erreur dans /etc/sudoers peut signifier que sudo ne fonctionne plus du tout. Si root ne peut pas non plus se connecter, vous êtes bloqué. C'est pourquoi vous ne modifiez jamais les réglages de sudo avec un éditeur ordinaire, mais avec visudo. Celui-ci ouvre une copie temporaire et vérifie le contenu avant d'enregistrer :

root@web1:~# visudo -f /etc/sudoers.d/backup

Comme pour SSH, préférez un fichier à vous dans /etc/sudoers.d/ plutôt que le fichier principal. Attention à deux règles propres à ce dossier :

• Les fichiers dont le nom contient un point ou se termine par ~ sont ignorés. backup.conf ne fonctionne donc pas, backup si. Le but est d'ignorer les copies créées par les éditeurs, mais cela surprend beaucoup de monde.
• Le fichier doit appartenir à root et ne pas être modifiable par les autres (440 est la valeur habituelle ; visudo s'en charge).

Pour vérifier un fichier existant sans le modifier : visudo -c contrôle l'ensemble.

NOPASSWD : pratique, mais sachez ce que vous faites

Avec NOPASSWD, sudo ne demande plus de mot de passe :

anna ALL=(ALL:ALL) NOPASSWD: ALL

Certaines images de VPS l'activent pour l'utilisateur par défaut, afin que vous soyez administrateur dès la connexion avec une clé. Vérifiez avec sudo -l ce qui s'applique chez vous. La conséquence : quiconque possède la clé d'Anna est immédiatement root. Il n'y a plus de second verrou. Pour un serveur personnel, vous pouvez faire ce choix, mais faites-le en connaissance de cause.

Il est bien préférable de limiter NOPASSWD à une seule commande précise, par exemple un script de sauvegarde qui doit pouvoir s'exécuter automatiquement :

backup ALL=(root) NOPASSWD: /usr/local/bin/maak-backup

L'utilisateur backup peut alors exécuter ce seul script en tant que root, sans mot de passe, et rien d'autre. Deux pièges :

• Utilisez toujours le chemin complet. Avec seulement maak-backup, quelqu'un peut placer son propre programme portant ce nom en tête de son chemin.
• Le script lui-même ne doit pas être modifiable par cet utilisateur. Sinon, il le modifie et exécute alors des commandes arbitraires en tant que root. Il en va de même pour les commandes capables d'ouvrir elles-mêmes un shell, comme un éditeur (vim, nano) ou less : quiconque peut les lancer via sudo peut ouvrir un shell root depuis le programme. N'autorisez jamais ce type de commandes isolément via sudo.

Ce qui est journalisé

Chaque fois que quelqu'un utilise sudo, une ligne est ajoutée au journal (et, sur les systèmes avec rsyslog, également dans /var/log/auth.log) :

anna@web1:~$ sudo journalctl _COMM=sudo --since today
Nov 09 10:31:02 web1 sudo[2214]:     anna : TTY=pts/0 ; PWD=/home/anna ; USER=root ; COMMAND=/usr/bin/apt update

Vous voyez qui, où, en tant que qui et quelle commande. C'est l'une des raisons de ne pas travailler à plusieurs en root. Des tentatives sudo échouées ("incorrect password attempts") provenant d'un compte qui n'est pas le vôtre sont un signal d'alarme.

Les droits minimaux à grande échelle

sudo n'est qu'une application d'un principe général : les droits minimaux (least privilege). Chaque utilisateur et chaque service reçoit exactement les droits nécessaires, et pas davantage. Sur un serveur, cela signifie entre autres :

• vous travaillez en tant qu'utilisateur normal et n'utilisez sudo que lorsque c'est nécessaire ;
• chaque service tourne sous son propre utilisateur sans shell (leçon 3.1), pas en root ;
• une application web reçoit un utilisateur de base de données qui ne peut utiliser que sa propre base, pas l'administrateur du serveur de bases de données ;
• un script de sauvegarde n'a droit qu'à la seule commande dont il a besoin (NOPASSWD avec chemin complet) ;
• un collègue qui se contente de mettre à jour le site reçoit un droit d'écriture sur /var/www/example.com via un groupe, pas sudo.

L'idée : si quelque chose tourne mal (une faille dans une extension, une clé volée), les dégâts restent limités à cet utilisateur ou à ce service. Ce principe revient sans cesse dans les principes CIS et dans la leçon sur le durcissement (10.1).

Sur AlmaLinux et Rocky Linux

Le groupe des administrateurs s'y appelle wheel au lieu de sudo : usermod -aG wheel anna. La règle dans /etc/sudoers est %wheel ALL=(ALL) ALL. visudo et /etc/sudoers.d fonctionnent de la même manière. Les messages de sudo s'y trouvent également dans /var/log/secure.

Résumé

• Travaillez en tant qu'utilisateur normal et utilisez sudo pour l'administration ; sudo demande votre propre mot de passe et journalise chaque commande.
• Créer un administrateur : adduser anna, adduser anna sudo (wheel sur les systèmes de type RHEL), clé avec le bon propriétaire et les bons droits, test dans une deuxième fenêtre, et seulement ensuite désactivation de la connexion root.
• Ne modifiez les règles sudo qu'avec visudo, de préférence dans un fichier à vous dans /etc/sudoers.d/ sans point dans le nom.
• NOPASSWD pour tout supprime un verrou ; réservez-le plutôt à une seule commande avec chemin complet que l'utilisateur ne peut pas modifier.
• Droits minimaux : chaque utilisateur et service reçoit exactement ce qui est nécessaire, pour qu'une erreur ou une faille reste limitée.

Quiz

Exercice

Exercice O3.2 : Un administrateur avec sudo. Créez sur votre serveur un administrateur normal (par exemple anna), installez correctement votre clé, testez la connexion et sudo -l dans une deuxième fenêtre, puis désactivez la connexion root via SSH (PermitRootLogin no). Cochez les étapes, collez la sortie de id (uniquement le nom et les groupes) et répondez aux questions : quelle règle donne ses droits à votre administrateur, NOPASSWD figure-t-il quelque part, et comment entrez-vous si vous oubliez votre mot de passe ?

Pour aller plus loin

Les étapes de ces articles s'appliquent aux VPS de WebOké ; chez d'autres fournisseurs, le fonctionnement est comparable.

• Sécuriser votre VPS : les cinq premières minutes
• Plus d'accès à votre VPS : que faire ?
• Guide DirectAdmin 12.2: Utilisateurs de base de données, droits et mots de passe
• Ubuntu Server : User management : https://ubuntu.com/server/docs/how-to/security/user-management/
• Manuel Debian sudoers : https://manpages.debian.org/trixie/sudo/sudoers.5.en.html