Pourquoi utiliser sudo?
La plupart des articles Linux modernes conseillent d'utiliser Sudo plutôt que de se connecter à root. Ce conseil est tellement ancré que certaines distributions ne permettent pas automatiquement la connexion root. En effet, ils sont préconfigurés avec Sudo en utilisant le mot de passe des utilisateurs pour exécuter des commandes arbitraires en tant que root.
Qu'est-ce qui peut mal tourner?
En réalité, si l'on exécute la commande ci-dessus, il pourrait presque aussi bien fonctionner que root !!
Que font les logiciels malveillants?
modifier .bashrc pour inclure
export PATH=/home/user/.hack:$PATH
et déposez un script dans ~/.hack qui:
- imiter Sudo
- envoyer le mot de passe au serveur C&C
- se supprimer
Le pirate obtient le mot de passe (utilisateur et root).
Le même problème existe avec le su simple, et la seule façon d'éviter est:
- Alt-Ctrl-F1 et connectez-vous en tant que root
- Toujours exécuter Sudo ou su en tant que/usr/bin/Sudo ou/usr/bin/su
La première option semble beaucoup plus sûre, mais semble aller à l'encontre de la pratique moderne. Pourquoi?
Il existe des utilisations de commodité valides pour Sudo, mais comme elles sont déjà suffisamment expliquées dans d'autres articles, je ne les expliquerai pas beaucoup ici. Je vous indiquerai cependant sudoers(5) , qui est le fichier de configuration de Sudo. Il montre une partie de la configuration étendue possible avec Sudo. Je vais vous expliquer quand et pourquoi vous ne devriez pas utiliser Sudo pour passer de votre utilisateur normal à root pour des raisons purement sécuritaires, mise à part la commodité.
Réponse courte: Il n'y a aucun moyen d'utiliser en toute sécurité Sudo si votre utilisateur régulier peut être compromis. Utilisez-le uniquement pour des raisons de commodité, pas 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 normal à 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 les noms qui contiennent 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 utiliser uniquement l'option 1, alias vous connecter avec agetty ou logind sur un autre tty (notez que sur certaines distributions, tty1 est l'endroit où Xorg est exécuté, 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 sur les systèmes Linux), qui tue tous les processus de ce tty. Cela tue tout faux écran de connexion et vous amène au vrai uniquement. 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, qui ne devrait apparaître que comme une invite de connexion clignotante. Sur certains systèmes, de nombreuses fonctionnalités SysRq sont désactivées, y compris SAK. Vous pouvez temporairement tous les activer 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 ce dont vous avez besoin pour le convertir pour ajouter le support SAK avant de le rendre permanent dans /etc/sysctl.conf. Le définir sur 1 pour toujours peut être une mauvaise idée (vous ne voulez pas que n'importe qui puisse alt+sysrq+e pour tuer xscreensaver, pensez-vous?).
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 en cours, comme LD_PRELOAD , qui est une variable d'environnement qui pointe vers un objet partagé (bibliothèque) qui sera forcé chargé par le programme pour changer son comportement. Bien qu'il ne fonctionne pas sur les programmes setuid comme su et Sudo, il 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 indiquer à un programme d'utiliser des bibliothèques malveillantes au lieu de vos bibliothèques système. Il existe beaucoup plus variables d'environnement qui peuvent être utilisées pour modifier le comportement des programmes en cours d'exécution de différentes 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 les options GETREGS ou PEEKTEXT/PEEKDATA Pour afficher toute la mémoire des processus s'exécutant sous le même utilisateur (comme le processus bash qui exécute su ou Sudo pour vous). Si vous utilisez une distribution qui la désactive (par exemple en utilisant 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 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 - la protection des utilisateurs, pas intra - la protection des utilisateurs. Le noyau Linux suppose que chaque opération effectuée en tant qu'utilisateur A est approuvée par l'utilisateur A, donc si vous utilisez root pour l'utilisateur A, root doit être tout aussi fiable que cet utilisateur.
Avant même de passer à Xorg, permettez-moi de commencer en disant que Xorg fournit pas de 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 en tant que ce même utilisateur pourront renifler (et injecter) les frappes. 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. Il s'agit d'une limitation fondamentale du protocole X11, ancrée aussi profondément que le concept des UID sur Linux. Il n'y a aucun paramètre ou 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 frontends 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 qui est généré par votre .bashrc. Vous pouvez le tester vous-même en exécutant ce qui suit dans un terminal, puis en vous déplaçant vers 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 l'extension XTEST active. Même sans l'activer, il est toujours possible d'enregistrer des événements de clavier en utilisant XQueryKeymap() . La leçon que vous devez suivre est qu'il n'y a effectivement aucun moyen d'entrer en toute sécurité votre mot de passe 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.
Parce que Sudo permet beaucoup contrôles plus fins que "se connecter en tant que root puis faire ce que l'on veut". Par exemple, vous pouvez configurer Sudo afin que certains utilisateurs ne soient autorisés à exécuter que certaines commandes (comme les scripts d'encapsulage ou les 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, le 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 aussi important. Même si le mot de passe est votre objectif (par exemple, vous attaquez quelqu'un qui réutilise des 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.
Enfin, il est conseillé de ne pas s'exécuter en tant que root dans la mesure du possible, car les conséquences d'une mauvaise saisie d'une commande (rm_-rf_._/ est un exemple évident) ne sont pas aussi graves. Exiger l'étape supplémentaire d'écriture de 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 des erreurs simples mais graves.
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 quel ID utilisateur 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 à un seul utilisateur car l'uid sera 0.
Pour moi, l'une des principales raisons d'utiliser Sudo (par opposition à su) est d'éviter de devoir suivre "le mot de passe root" pour chaque serveur que j'administre et le changer chaque fois que quelqu'un qui le sait quitte l'entreprise.
Au lieu de cela, il s'agit simplement de gérer les membres du groupe wheel, qui peuvent aller et venir sans se forcer à changer les mots de passe les uns des autres plus souvent qu'ils ne le sont déjà.
Ceci n'est probablement pas considéré comme la réponse entière en soi, mais devrait être inclus dans la réponse acceptée pour être complet.
La raison de ne pas s'exécuter en tant que root est qu'en utilisant Sudo, vous prenez la décision consciente d'exécuter une commande particulière en tant que root.
L'exécution en tant que root permet à une faute de frappe négligente de gâcher votre journée.