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

sudo

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é (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 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 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 ?

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.


Partager cet article ...OU NE PAS.?
Commentaires 0


    Laisser un commentaire
    Le commentaire sera publié sur le site après modération. Entrez votre adresse email pour être notifié lorsque le commentaire est publié ou reçoit une réponse.
    captcha
    captcha