Introduction

Sudo est un outil extrêmement puissant et complet qui permet de contrôler finement le lancement de commandes avec les privilèges root ou ceux d'un autre utilisateur sur un système GNU/Linux ou *BSD. Beaucoup connaissent l'utilisation sommaire et basique de sudo dans le cadre de systèmes où le compte root est désactivé et que l'utilisateur créé lors de l'installation a besoin d'une élévation des privilèges afin d'utiliser des commandes normalement réservées au superadministrateur.

Mais sudo est beaucoup plus riche que ce que laisse à penser ce fonctionnement standard.

Fonctionnement basique et standard

En effet, lorsque sudo a été implémenté de façon sommaire lors de l'installation d'un système GNU/Linux, le fichier de configuration de sudo : /etc/sudoers ressemble typiquement à ceci :

luke@skywalker:~$ sudo cat /etc/sudoers
# Allow user to execute any command
luke ALL=(ALL:ALL) ALL

Pour faire simple, l'utilisateur luke peut exécuter n'importe quelle commande sur le système en utilisant les privilèges superadministrateurs. La première question qui peut se poser ici est pourquoi utiliser sudo plutôt que su - dans ce contexte classique ? La réponse la plus évidente est tout simplement une meilleure traçabilité des évènements liés aux utilisateurs sur le système.

Limites de la commande su et avantages liés à l'utilisation de sudo

Nous avons trois adminsys sur le serveur : luke, leia et han. Chacun de ces utilisateurs a besoin à certains moments de lancer des commandes qui nécessitent les droits root. Dans le cas de l'absence du logiciel sudo, ils devront utiliser la commande su - qui permet de se connecter sur une session root qui dispose de l'uid 0. Hors si plusieurs de ces admins sont connectés en root en même temps, comment sera-t-il possible de journaliser qui a fait quoi à quels moments puisque tous seront connectés avec l'uid 0. Grâce à sudo, il sera possible de journaliser exactement ce qu'ont lancé luke, leia ou han en utilisant les privilèges root.

Autre argument recevable, le compte root étant un compte générique présent sur tous les systèmes Unix, ce dernier sera ciblé par de potentiels attaquants lors de tentative d'intrusion sur un système de ce type. En désactivant le compte root, on rend la tâche un peu plus complexe aux méchants.

Cas concret dans un cadre pédagogique

Je suis entrain de monter un TP sur DNS pour mes étudiants. Je dispose du nom de domaine lacomte.eriador.fr et je souhaite que chacun des étudiants gère un sous-domaine qui lui est propre (ex: bilbo.lacomte.eriador.fr) avec son serveur DNS et son fichier de zone. Pour cela, il est nécessaire de réaliser une délégation de zone entre le serveur DNS faisant autorité sur le domaine parent lacomte.eriador.fr et le serveur DNS faisant autorité sur le sous-domaine bilbo.lacomte.eriador.fr.

Ainsi, il faut d'une part que l'étudiant installe et paramètre correctement son serveur DNS et la zone qu'il a à gérer puis d'autre part, qu'il déclare son serveur DNS dans le serveur DNS parent ainsi que le glue record associé. Et bien entendu, il était hors de question de laisser à mes apprenants un accès OpenBar à ce serveur en question sous peine de crash et autres maladresses en tout genre (merci la virtualisation et les snapshots <3).

Donc, comme je dispose d'un bel annuaire OpenLDAP et d'un outil merveilleux nommé sudo, j'ai décidé de m'en servir afin de limiter les dégats et d'avoir une journalisation précise de qui a fait quoi. Concernant la partie authentification OpenLDAP sous Debian GNU/Linux, j'ai installé les paquets qui vont bien (libnss-ldap, libpam-ldap, ldap-utils), répondu correctement aux boites de dialogue qui sont apparues et configuré les fichiers /etc/nsswitch.conf et /etc/pam.d/common-* (la configuration de l'authentification LDAP sous Debian Jessie n'est pas le sujet de cet article).

Une fois l'authentification LDAP correctement paramétrée, chaque étudiant dispose d'un compte personnel sur le serveur DNS concerné. C'est déjà une bonne chose. Maintenant, il faut faire en sorte qu'ils aient juste le strict nécessaire pour réaliser l'opération évoquée lors du paragraphe précédent et c'est là que sudo intervient.

Si sudo n'est pas déjà installé sur votre système Debian (ici ns0.lacomte.eriador.fr) :

root@ns0:~# aptitude install sudo

Une fois installé, sudo se configure via le fichier de configuration /etc/sudoers. Attention ! il ne faut pas éditer ce dernier avec un éditeur standard type vi, emacs ou nano mais passer par la command visudo afin de respecter les bonnes pratiques et éviter un drame en cas d'erreur de syntaxe dans ce fichier si sensible :

gandalf@ns0:~$ sudo visudo

Voilà ce que j'ai ajouté dans le fichier de configuration afin d'avoir une bonne traçabilité des évènements liés à sudo et limiter les droits des étudiants :

# Journalisation des évènements
Defaults     log_output
Defaults!/usr/bin/sudoreplay !log_output
Defaults!/sbin/reboot !log_output

# Le professeur est un utilisateur ayant la possibilité d'exécuter
# n'importe quelles commandes avec les privilèges root
gandalf      ALL=(ALL:ALL) ALL

# Définition du strict minimum permettant aux étudiants de mettre en oeuvre une délégation de zone effective pour la gestion de leur sous-domaine
%hobbits     ns0= sudoedit /etc/bind/db.lacomte.eriador.fr,  /usr/sbin/named-checkconf -z, /bin/systemctl start bind9,  
    /bin/systemctl stop bind9, /bin/systemctl restart bind9, /bin/systemctl status bind9

Mise à jour du 28/07/2020 ! Un commentaire récent m'a fait remarquer à fort juste titre que l'utilisation d'un éditeur tel que nano ou vim était à proscrire avec sudo. En effet, cela permet à un utilisateur restreint, une fois l'éditeur lancé avec les droits superadministrateur, d'éditer et de modifier n'importe quel fichier pour lequel il n'a, à la base, aucune autorisation y compris dans /etc/sudoers.

Cf :

Merci encore pour ce retour !

Tous mes étudiants, qui font partie du groupe hobbits (groupe créé et présent dans l'annuaire OpenLDAP), ont le droit, sur le serveur DNS ns0, d'éditer le fichier de zone db.lacomte.eriador.fr (que j'aurai pu ou du définir dans /var/cache/bind/), de vérifier la configuration et la syntaxe des différentes zones déclarées ainsi que d'arrêter | démarrer | redémarrer et vérifier le statut du service DNS Bind (oui j'utilise cette daube de systemd, je sais c'est pas terrible mais je suis dans un contexte de formation...).

Pour que la journalisation fonctionne correctement, il est nécessaire de créer le répertoire sudo-io dans /var/log/ :

gandalf@ns0:~$ sudo mkdir /var/log/sudo-io

Lorsqu'un étudiant se connectera au serveur via SSH avec son compte personnel, il ne pourra utiliser avec sudo que les commandes citées précédemment et aucune autre nécessitant des privilèges plus importants.

frodon@ns0:~$ sudo -l
[sudo] password for frodon:
User frodon may run the following commands on ns0:
        (root) /usr/bin/nano /etc/bind/db.lacomte.eriador.fr,
        /usr/sbin/named-checkconf -z, /bin/systemctl start bind9,
        /bin/systemctl stop bind9, /bin/systemctl restart bind9, /bin/systemctl
        status bind9

Concernant la journalisation, il existe une commande magique nommée sudoreplay qui permet de savoir qui a fait quoi en détail à l'aide de la commande sudo.

gandalf@ns0:~$ sudo sudoreplay -l
juin 30 10:53:02 2017 : frodon : TTY=/dev/pts/1 ; CWD=/home/frodon ; USER=root ; TSID=000001 ; COMMAND=/bin/systemctl restart bind9
juin 30 16:42:37 2017 : sam : TTY=/dev/pts/1 ; CWD=/home/sam ; USER=root ; TSID=000002 ; COMMAND=/bin/systemctl status bind9
juil.  3 01:42:12 2017 : merry : TTY=/dev/pts/0 ; CWD=/home/merry ; USER=root ; TSID=000003 ; COMMAND=/usr/bin/nano /etc/bind/db.lacomte.eriador.fr

Conclusion

Sudo est un outil ultra-puissant et souvent sous-exploité. Voici un exemple d'utilisation simple qui met en avant ce qu'il est possible de faire avec ce logiciel. On peut bien entendu aller beaucoup plus loin (centralisation et utilisation d'un fichier sudoers global pour un ensemble de machines, intégration avec OpenLDAP etc). J'ai potassé avec énormément d'intérêt l'excellent ouvrage de Michael W Lucas, Sudo Mastery, qui m'a permis d'obtenir toutes les informations dont j'avais besoin. Donc merci à lui pour la qualité de sa documentation.

Si vous souhaitez savoir tout ce qu'il est possible de faire avec sudo et avoir un bouquin de référence sur le sujet, je vous conseille vivement d'acheter Sudo Mastery (ouvrage en anglais) au format papier ou numérique.

Enjoy ;)

Références

Concernant l'authentification LDAP sous Debian Jessie : https://wiki.debian.org/LDAP/PAM

Concernant sudo : Sudo Mastery, by Michael W Lucas aux éditions Tilted Windmill Press