Il existe des utilisations pratiques valables pour sudo, mais comme elles sont déjà suffisamment expliquées 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 de sécurité purement, par souci de commodité.
Réponse courte: Il n'y a aucun moyen de utilisez sudo en toute sécurité si votre utilisateur régulier peut être compromis. Utilisez-le uniquement pour des raisons de commodité et non pour des raisons de 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: Ce 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 qui contiennent un / au début. Essayez d'exécuter ce qui suit:
$ echo $ SHELL / bin / bash $ function / usr / bin / sudo {echo "Faites-moi confiance, maintenant entrez votre mot de passe:"; } $ / usr / bin / sudo idFaites-moi confiance, maintenant entrez votre mot de passe:
Vous ne devez utiliser que l'option 1, c'est-à-dire se connecter avec agetty ou se connecter sur un autre tty (notez que sur certaines distributions, tty1 est l'endroit où Xorg s'exécute, comme Fedora. Sur la plupart des distributions cependant , tty1 est un tty de rechange et Xorg fonctionne 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 sous Linux systems), qui tue tous les processus de ce tty. Cela tue tout faux écran de connexion et ne vous amène qu'au vrai. S'il n'y a pas de faux écrans de connexion essayant de voler votre mot de passe root (ce qui est, espérons-le, le cas), cela provoque simplement le redémarrage d'agetty, ce qui ne devrait apparaître que comme le clignotement de l'invite de connexion. 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 dans / proc / sys / kernel / sysrq . La valeur de / proc / sys / kernel / sysrq est un bitmap, alors regardez ce qu'il est actuellement et calculez en quoi vous devez le 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 tuer xscreensaver, n'est-ce pas?).
L'idée que vous pouvez protéger votre utilisateur régulier et utiliser sudo ou su en toute sécurité est une idée très dangereuse. Même si cela était possible, il existe d'innombrables façons de détourner votre session en cours, comme LD_PRELOAD , qui est une variable d'environnement qui pointe vers un objet partagé (bibliothèque) qui va être chargé de force par le programme pour changer 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 détourner des programmes exécutés en tant qu'utilisateur. LD_LIBRARY_PATH peut dire à un programme d'utiliser des bibliothèques malveillantes au lieu de vos bibliothèques système. Il existe beaucoup plus de variables d'environnement qui peuvent être utilisées pour changer 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 comme cet utilisateur peuvent être compromis.
Si cela ne suffisait pas, sur la plupart des distributions, votre utilisateur peut utiliser ptrace () avec GETREGS ou PEEKTEXT / PEEKDATA 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 lire et é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 dans la mémoire via / proc / pid / mem , tant que le processus qui y écrit est le même utilisateur. Dans le noyau Linux, il y a 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 une protection inter -utilisateur, pas une protection intra -utilisateur. Le noyau Linux suppose que chaque chose faite en tant qu'utilisateur A est approuvée par l'utilisateur A, donc si vous utilisez root en tant qu'utilisateur A, alors root doit être tout aussi fiable que cet utilisateur.
Avant même de passer à Xorg, permettez-moi de commencer en disant 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) des 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 approuvé et que ce cookie est accessible à tout ce qui s'exécute sous votre utilisateur. C'est une limitation fondamentale du protocole X11, enracinée aussi profondément que le concept d'UID le sont sous Linux. Il n'y a pas de paramètre ou de fonction 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 fonctionne sous le même utilisateur, donc votre navigateur, vos jeux , votre lecteur vidéo, et bien sûr tout ce que vous propose 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 Pointeur de noyau virtuel id = 2 [pointeur principal (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 id du clavier = 5 [clavier esclave (3)] id id du bouton d'alimentation = 8 [clavier esclave (3)] ↳ id caméra USB = 10 [clavier esclave (3)] ↳ jeu de traduction AT 2 id clavier = 12 [clavier esclave ( 3)] ↳ Video Bus id = 7 [slave keyboard (3)] ↳ Sleep Button id = 9 [slave keyboard (3)] ↳ Asus WMI hotkeys id = 11 [slave k eyboard (3)]
↳ Bouton d'alimentation id = 6 [clavier esclave (3)] $ xinput test 12 # remplacez 12 par le numéro d'identification de votre clavier appuyez sur 45 touches 44 touches 40 touches 41 touches 45 touches 44 touches 41 touches 31 ^ C
Notez que si ce test spécifique ne fonctionne pas pour vous, cela signifie que vous n'avez pas l'extension XTEST active. Même sans l'activation, il est toujours possible d'enregistrer les événements du clavier en utilisant XQueryKeymap () . La leçon à tirer est qu'il n'y a en fait aucun moyen de 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.