Parce que sudo permet des contrôles beaucoup plus fins que "connectez-vous en tant que root puis faites ce que vous voulez". Par exemple, vous pouvez configurer sudo afin que certains utilisateurs ne soient autorisés à exécuter que certaines commandes (comme des scripts wrapper ou des binaires "acceptables"). Vous craignez qu'un cheval de Troie ne compromette l'ordinateur d'un seul utilisateur, mais sudo a été créé pour permettre la journalisation et le contrôle d'accès sur un serveur administré par plusieurs personnes.
Bien sûr, sur un système mono-utilisateur, les fichiers importants sont les fichiers de l'utilisateur, et une fois que vous avez accès au compte de l'utilisateur, vous avez déjà accès à ces fichiers , donc obtenir le mot de passe n'est même plus si important. Même si le mot de passe est votre objectif (par exemple, vous attaquez quelqu'un qui réutilise les mots de passe), il existe de nombreuses façons de l'obtenir sans impliquer sudo; par exemple, j'ai récemment rencontré 2 programmes installés par défaut qui enregistreront les mots de passe ou les erreurs de mot de passe en texte clair.
Et enfin, il est conseillé de ne pas exécuter en tant que root dans la mesure du possible car les conséquences d'une erreur de frappe d'une commande (rm_-rf_._/ est un exemple évident) ne sont pas aussi graves. Nécessite l'étape supplémentaire d'écrire sudo au début d'une commande par opposition à "oublier que vous êtes connecté en tant que root et faire quelque chose de destructeur" peut éviter certaines erreurs simples mais graves.
Il existe des utilisations pratiques valides pour sudo, mais comme elles sont déjà expliquées de manière adéquate dans d'autres articles, je ne les développerai pas beaucoup ici. Je vais cependant vous diriger vers sudoers(5) , qui est le fichier de configuration sudo. Il montre une partie de la configuration étendue possible avec sudo. J'expliquerai quand et pourquoi vous ne devriez pas utiliser sudo pour passer de votre utilisateur normal à root pour des raisons purement de sécurité, côté pratique.
Réponse courte : Il n'y a aucun moyen d'utiliser sudo en toute sécurité si votre utilisateur habituel peut être compromis. Utilisez-le uniquement pour la commodité, pas pour la sécurité. La même chose s'applique à su et à tous les autres programmes qui peuvent être utilisés pour élever votre utilisateur régulier à un utilisateur plus privilégié.
Réponse longue : Il n'est pas vrai que l'utilisation du chemin complet pour sudo vous protégera d'un environnement malveillant. C'est un malentendu courant. Une fonction bash peut même détourner des noms contenant un / au début. Essayez d'exécuter ce qui suit :
$ echo $SHELL
/bin/bash
$ function /usr/bin/sudo { echo "Trust me, now put in your password:"; }
$ /usr/bin/sudo id
Trust me, now put in your password:
Vous devez n'utilisez que l'option 1, c'est-à-dire se connecter avec agetty ou se connecter sur un tty différent (notez que sur certaines distributions, tty1 est l'endroit où Xorg est en cours d'exécution, comme Fedora. Sur la plupart des distributions cependant, tty1 est un tty de rechange et Xorg s'exécute sur tty7) . Cependant , vous devez être conscient que les logiciels malveillants peuvent détourner ctrl +alt +f1 et vous présenter un faux écran, vous devez donc utiliser la combinaison Secure Attention Key (SAK, qui est alt +sysrq +k sur les systèmes Linux), qui tue tous les processus de ce tty. Cela tue tout faux écran de connexion et vous amène uniquement au vrai. S'il n'y a pas de faux écrans de connexion essayant de voler votre mot de passe root (ce qui, espérons-le, est le cas), cela provoque simplement le redémarrage d'agetty, qui devrait apparaître comme rien de plus que l'invite de connexion clignotante. Sur certains systèmes, de nombreuses fonctionnalités SysRq sont désactivées, y compris SAK. Vous pouvez tous les activer temporairement en écrivant l'entier 1 à /proc/sys/kernel/sysrq . La valeur de /proc/sys/kernel/sysrq est un bitmap, alors examinez ce qu'il est actuellement et calculez ce que vous devez convertir pour ajouter le support SAK avant de le rendre permanent dans /etc/sysctl.conf . Le mettre à 1 pour toujours peut être une mauvaise idée (vous ne voulez pas que n'importe qui puisse alt +sysrq +e pour tuer xscreensaver, n'est-ce pas ?).
L'idée que vous pouvez protéger votre utilisateur habituel et utiliser sudo ou su en toute sécurité est une idée très dangereuse. Même si c'était possible, il existe d'innombrables façons de détourner votre session de course, comme LD_PRELOAD , qui est une variable d'environnement qui pointe vers un objet partagé (bibliothèque) qui sera chargé de force par le programme pour modifier son comportement. Bien que cela ne fonctionne pas sur les programmes setuid comme su et sudo, cela fonctionne sur bash et tous les autres shells, qui exécutent su et sudo, et sont ceux qui voient toutes vos frappes. LD_PRELOAD n'est pas la seule variable qui peut pirater des programmes exécutés en tant qu'utilisateur. LD_LIBRARY_PATH peut indiquer à un programme d'utiliser des bibliothèques malveillantes au lieu de vos bibliothèques système. Il existe de nombreuses autres variables d'environnement qui peuvent être utilisées pour modifier le comportement des programmes en cours d'exécution de diverses manières. Fondamentalement, si vos variables d'environnement peuvent être compromises, votre utilisateur et toutes les frappes saisies en tant qu'utilisateur peuvent être compromis.
Si cela ne suffisait pas, sur la plupart des distributions, votre utilisateur peut utiliser ptrace() avec le GETREGS ou PEEKTEXT/PEEKDATA options pour afficher toute la mémoire des processus exécutés sous le même utilisateur (comme le processus bash qui exécute su ou sudo pour vous). Si vous utilisez une distribution qui désactive cela (par exemple en utilisant le Yama LSM), le processus peut toujours être en mesure de lire et d'écrire dans la mémoire de votre processus bash en utilisant process_vm_readv() et process_vm_writev() respectivement. Sur certains noyaux, vous pouvez également écrire directement en mémoire via /proc/pid/mem , tant que le processus qui y écrit est le même utilisateur. Dans le noyau Linux, il existe d'innombrables contrôles de sécurité partout pour s'assurer que les processus ne peuvent pas interférer les uns avec les autres. Cependant, ils impliquent tous inter -protection des utilisateurs, pas intra -protection des utilisateurs. Le noyau Linux suppose que chaque chose faite en tant qu'utilisateur A est approuvée par l'utilisateur A, donc si vous vous connectez à root en tant qu'utilisateur A, alors root doit être tout aussi fiable que cet utilisateur.
Avant même d'aborder Xorg, permettez-moi de commencer par dire que Xorg ne fournit aucune protection contre les enregistreurs de frappe. Cela signifie que, si vous utilisez sudo ou su dans un tty avec Xorg en cours d'exécution, tous les processus exécutés sous le même utilisateur pourront renifler (et injecter) les frappes au clavier. En effet, le modèle de sécurité du protocole X11 suppose que tout ce qui a accès au cookie X11 est fiable et que ce cookie est accessible à tout ce qui s'exécute sous votre utilisateur. Il s'agit d'une limitation fondamentale du protocole X11, enracinée aussi profondément que le concept d'UID sous Linux. Il n'y a pas de paramètre ou de fonctionnalité pour désactiver cela. Cela signifie que tout ce que vous tapez dans une session Xorg, y compris tapé dans su ou sudo (ou des interfaces comme gksu, gksudo, kdesu, kdesudo, pinentry, etc.) peut être reniflé par tout ce qui s'exécute sous le même utilisateur, donc votre navigateur, vos jeux , votre lecteur vidéo, et bien sûr tout ce qui est dérivé de votre .bashrc. Vous pouvez le tester vous-même en exécutant ce qui suit dans un terminal, puis en passant à un autre terminal et en exécutant une commande avec sudo.
$ xinput list
Virtual core pointer id=2 [master pointer (3)]
↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
↳ ETPS/2 Elantech Touchpad id=13 [slave pointer (2)]
Virtual core keyboard id=3 [master keyboard (2)]
↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
↳ Power Button id=8 [slave keyboard (3)]
↳ USB Camera id=10 [slave keyboard (3)]
↳ AT Translated Set 2 keyboard id=12 [slave keyboard (3)]
↳ Video Bus id=7 [slave keyboard (3)]
↳ Sleep Button id=9 [slave keyboard (3)]
↳ Asus WMI hotkeys id=11 [slave keyboard (3)]
↳ Power Button id=6 [slave keyboard (3)]
$ xinput test 12 # replace 12 with the id number of your keyboard
key press 45
key press 44
key release 40
key press 41
key release 45
key release 44
key release 41
key press 31
^C
Notez que si ce test spécifique ne fonctionne pas pour vous, cela signifie que vous n'avez pas le XTEST extension active. Même s'il n'est pas actif, il est toujours possible d'enregistrer des événements de clavier en utilisant XQueryKeymap() . La leçon que vous devriez retenir est qu'il n'y a effectivement aucun moyen pour saisir votre mot de passe en toute sécurité en utilisant su ou sudo via un utilisateur compromis. Vous devez absolument passer à un nouveau tty et utiliser SAK, puis vous connecter directement en tant que root.
Outre ce qui est mentionné par les autres utilisateurs, sudo conserve également l'identité d'origine de l'utilisateur qui exécute la commande. Cela signifie que vous pouvez suivre l'ID utilisateur qui a exécuté la commande. Si vous utilisez root dans un environnement multi-utilisateur, vous ne pourrez pas suivre l'exécution d'une commande pour un seul utilisateur car l'uid sera 0.