Utiliser sudo (ou pas ?? 🤔) pour administrer son serveur Debian

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.

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Ă© (si rm -rf Ă  la racine est le graal des commandes foireuses, un chmod 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 fichier sudoers, 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 décrit comme tout beau, tout rose et 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.

Dans les faits, il a été, est, et sera la source de failles de sécurité. Je n'ai pas l'historique des failles dont sudo a déja eté victime, mais taper CVE sudo dans un moteur de recherche n'est pas sans résultats...

Et dans certains cas de figure (use case), 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.

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, ou grâce à des options méconnues qu'elles 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 fichier. Qu'est ce qu'il se passe si on la lance avec en paramètre le fichier /etc/shadow ?

    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 que mysql 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 commande service 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 ?

Après avoir fait quelques recherches sur sudo et l'avoir installé sur ma machine, j'avais l'impression de bien faire, suivre les bonnes pratiques. Quelques semaines plus tard, après avoir regardé la vidéo citée plus haut 2, je vois les choses autrement et j'ai changé de stratégie.

La conclusion est que, comme souvent, cela dépend de chaque use case 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 ?

Un concept majeur en développement pour écrire du code safe 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 hacker qui vous veux du mal, ou 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.


Partager