Sous Linux, le compte root, également appelé superutilisateur, est le compte le plus puissant, il peut tout faire sur la machine.
♫ I've got the POWER ♫
Travailler avec le compte root présente des avantages mais aussi des risques, dont celui de compromettre la machine. La commande sudo
peut aider à limiter ce risque, mais dans certains cas, elle peut au contraire l'augmenter.
Qu'est ce que sudo ?
sudo
(abréviation de substitute user do, que l'on pourrait traduire en français par « faire en se substituant à l'utilisateur ») est une commande qui permet, à un utilisateur non root préalablement autorisé, d'exécuter des commandes en tant que root, ou en tant qu'un autre utilisateur, tout en conservant une trace des commandes saisies et des arguments 1.
Par défaut, sudo
n'est pas présent sur Debian mais peut être installé avec un accès root à la machine. La configuration se trouve dans le fichier /etc/sudoers
qui doit être édité à l'aide de la commande visudo
exécutée en root.
Pour un utilisateur du groupe sudo, il suffit simplement de taper le préfix sudo
devant chaque commande qui nécéssite des droits administrateur.
Par exemple, pour mettre à jour le système :
sudo apt-get update
sudo apt-get upgrade
Le mot de passe de l'utilisateur est demandé. Il sera conservé en mémoire pendant 15 minutes. Pendant ce délai, il sera possible à l'utilisateur de tapez d'autres commandes avec sudo
sans que le mot de passe soit demandé à nouveau.
toto@debian:$ sudo apt-get update
[sudo] Mot de passe de toto :
Sudo est paramétrable selon ses besoins, il est notamment possible :
- d'accorder des droits à toutes les commandes, à une ou plusieurs commandes seulement, ou encore à des scripts ;
- de demander le mot de passe root au lieu du mot de passe utilisateur, ou ne pas demander de mot de passe ;
- de personnaliser le délai de conservation du mot de passe ;
- ...
Les avantages de sudo
Si vous avez déjà un accès root à votre serveur, vous pouvez vous demander l'intérêt d'utiliser sudo. En fait que vous soyez seul sur votre machine ou que vous la partagiez, plusieurs raisons tendent à considérer, en théorie, sudo
comme meilleur / plus sûr que d'ouvrir une session en tant que superutilisateur :
Personne n'a à connaitre le mot de passe du superutilisateur (
sudo
demande par défaut le mot de passe de l'utilisateur courant) : On peut donc accorder temporairement des droits supplémentaires à des utilisateurs puis les retirer sans avoir à changer de mot de passe, ou divulguer le mot de passe root.Il est possible de n'exécuter que les commandes qui nécessitent des droits spéciaux avec
sudo
et le reste du temps, on travaille en tant qu'utilisateur non-privilégié, ce qui réduit les dommages que l'on peut commettre par erreur. Détruire sa machine avec une commande foireuse est vite arrivé (sirm -rf
à la racine est le graal des commandes foireuses, unchmod
récursif exécuté par erreur sur/etc
est déjà un bon début, pour parler de vécu , merci les backups!)Contrôler et enregistrer : quand une commande sudo est exécutée, le nom de l'utilisateur et la commande sont enregistrés. Sur Debian, on retrouve des messages dans
auth.log
, en voici un exemple :Aug 27 19:06:16 REMOVED sudo: toto : TTY=pts/0 ; PWD=/home/toto ; USER=root ; COMMAND=/usr/bin/apt-get update
Et si l'utilisateur toto avait lancé la même commande avec
sudo
alors qu'il est pas déclaré dans le fichiersudoers
, le message d'erreur serait le suivant :Aug 28 10:15:49 REMOVED sudo: toto : user NOT in sudoers ; TTY=pts/0 ; PWD=/home/toto ; USER=root ; COMMAND=/usr/bin/apt-get update
Quels sont les risques avec sudo ?
Dans le paragraphe précédent et dans la plupart des tutoriels sur le net, sudo
est mis en avant comme étant une bonne pratique. Mais rappelons que sudo
est un programme. Il s'agit donc d'une couche logicielle supplémentaire sujette, par nature, à des bugs et/ou des failles de sécurité.
Dans les faits, sudo
a été déjà été, et sera encore, victime de failles de sécurité. Je n'ai pas l'historique, mais taper CVE sudo dans un moteur de recherche n'est pas sans résultats...
Et dans certains cas de figure (usecase), il peut être détourné de son contexte pour obtenir plus de permissions que prévu. Pour ce qui est des nombreux biais de sécurité avec sudo
, présents au moment ou vous lisez cet article, je vous invite à regarder cette vidéo de Christophe Casalegno 2.
Pour résumé, selon lui, sudo
n'est au contraire pas recommandé dans la plupart des cas. L'idée est que si un compte utilisateur est compromis et que ce compte est dans le groupe sudo
, c'est le jackpot ! Une élevagation de privilèges (passer en root ou exécuter des commandes non désirées en tant que root) peut être réalisée de plusieurs manières.
Le problème est dans la méconnaissance des commandes auxquelles on donne accès : de nombreuses commandes peuvent être détournées, en raison du fonctionnement même de sudo, et/ou grâce à des options méconnues que ces commandes contiennent.
J'ose imaginer que personne ne prétend connaître toutes les options de chaque commande et comment elles se comportent lorsqu'on leur passe des arguments foireux. Et qu'est ce qu'il se passe lorsqu'on donne des arguments innapropriés à une commande lancée avec sudo
?
La commande
date
est une commande en apparence inoffensive. Elle peut prendre un fichier en paramètre, mais s'attend à trouver quelque chose ressemblant à une date dans chaque ligne du fichier. Qu'est ce qu'il se passe si on la lance avec le fichier/etc/shadow
en paramètre ?date -f /etc/shadow sudo date -f /etc/shadow
Avec un compte utilisateur classique, on obtient un message d'erreur de type permission refusée.
Mais avec
sudo
, on obtient un message d'erreur, pour chaque ligne du fichier, du type :date: date « ... » incorrecte
avec à la place des
...
la ligne du fichier/etc/shadow
. En gros vous venez de lire le fichier !Penseriez-vous que la commande
man
est dangereuse ? Tapez :sudo man man
Dans la partie qui permet une entrée utilisateur (
Manual page man(1) line 1 (press h for help or q to quit
), tapez :!/bin/bash
Entrer et HOP, vous venez de lancer un shell root !, tapez
id
pour vous en convaincre.Imaginez pour X raisons que vous ayez donné un accès à la commande
mysql
à un compte sudo. Saviez-vous quemysql
peut exécuter des commandes ? Celle-ci donne encore une fois un shell root :sudo mysql -e '\! /bin/bash'
Il n'y a généralement pas lieu de donner l'accès à la commande
mysql
, mais un utilisateur qui demande la permission d'utiliser la commandeservice
pour redémarrer les services, cela peut paraître légitime. Pourtant ... :sudo service ../../../../../bin/bash
... Encore une fois, un shell root. La liste est longue.
Conclusion : sudo ou pas sudo ?
La conclusion est que, comme souvent, cela dépend de chaque usecase et que la notion de bonne pratique est relative (qui la décrété et pourquoi ??).
Que vous soyez seul ou pas sur votre machine, créer un compte sudo dédié à l'administration est légitime, mais pour être safe, ce compte ne doit pas pouvoir se connecter directement en ssh
et son utilisation devrait être limitée aux seules tâches d'administration.
Et si vous devez donner l'accès à des commandes d'administration à d'autres utilisateurs via sudo
, limitez les permissions que vous donnez à des scripts que vous maitrisez et non directement à des commandes, en apparence non dangereuses, mais en pratique potentiellement détournables de leur contexte.
Comment sécuriser ses scripts ?
La première chose est de considérer TOUTE donnée venant d'un utilisateur (argument de scripts, données de formulaire, ... ) comme potentiellement foireuse. Parce que l'utilisateur est un vilain pirate qui vous veux du mal, ou tout simplement distrait. Et ceci est valable quelque soit le language.
Un utilisateur a besoin de redémarrer un service ? Donnez lui l'accès à un script avec la commande de redémarage codée en dur. Il doit pouvoir en redémarrer plusieurs ? Codez en dur dans le script une liste de services à passer en paramètre, ou codez quelque chose pour vérifier le nom du service en paramètre avec une Regex par exemple.