En quoi Sudo est-il plus sûr que d'utiliser directement su si l'utilisateur est autorisé à accéder à toutes les commandes?
J'ai donc lu les différences entre su et Sudo, et tout le monde semble être d'accord pour dire que l'approche Sudo est plus sûre que d'autoriser l'accès au compte root lui-même. Ils disent qu'avec le compte root, vous pouvez casser votre système entier avec une seule commande. Je comprends cela. MAIS l'utilisateur initial créé sur le système a également accès à toutes les commandes à l'aide de Sudo. Je peux le savoir en exécutant su -l. Si tel est le cas, je peux simplement exécuter Sudo <game-ending command> pour détruire mon système. Alors, comment cette approche est-elle meilleure ou plus sûre alors me permettant un accès direct au compte super utilisateur? Je peux exécuter toutes les mêmes commandes ...
Est-ce parce que, en utilisant Sudo sur la ligne de commande, je dis explicitement à l'ordinateur que je pense savoir ce que je fais? Est-ce qu'ils pensent que les gens oublieront qu'ils sont sous le compte super utilisateur à moins qu'ils le disent explicitement?
Les gens affirment également que si le système était compromis et entré par une personne étrangère, être sous le compte root leur permettrait de faire des choses terribles pour mon système. Mais il me semble que s'ils ont déjà accès à mon compte et connaissent mon mot de passe, ils peuvent faire la même chose en utilisant Sudo et en entrant mon mot de passe car ils n'ont même pas besoin de connaître le mot de passe du super utilisateur. Qu'est-ce que je n'arrive pas ici?
Personnellement, je ne le considère pas nécessairement comme plus sûr et la plupart des avantages (de Sudo) concernent un système multi-utilisateurs. Sur un système à utilisateur unique, c'est probablement un lavage.
Les avantages sont (sans ordre particulier):
- Sudo a une journalisation supérieure. Sudo enregistre chaque commande.
- Sudo permet un contrôle du grain plus fin. On peut configurer Sudo pour donner à la racine l’accès à certaines commandes, mais pas à toutes.
- Sudo utilise le mot de passe de connexion. Cela évite de devoir donner le mot de passe root (comme vous le feriez avec su) et est lié au point ci-dessus concernant le contrôle/accès plus fin à la racine.
- Dans Ubuntu, par défaut, le compte root est verrouillé. Cela dissuade les crackers de se connecter (via ssh à distance), ils doivent deviner à la fois un nom d'utilisateur et un mot de passe. Si le compte root n'est pas verrouillé, comme c'est le cas avec su, il suffit alors de déchiffrer le mot de passe de root.
Sudo -iest probablement la meilleure méthode pour isoler les variables d'environnement de root de votre utilisateur. Cela revient de temps en temps mais est modérément ésotérique. Voir https://help.ubuntu.com/community/RootSudo#Special_notes_on_Sudo_and_shells- certaines personnes estiment que le fait de taper Sudo avant chaque commande qu'elles souhaitent exécuter en tant qu'utilisateur root ou que le temps mort de Sudo leur permet de s'arrêter et de réfléchir plus clairement et de réduire leurs erreurs ou l'exécution de commandes erronées. Si cela vous aide, ce serait également un avantage.
Il y a probablement plus d'avantages, mais, ce sont les principaux, à mon humble avis.
Voir aussi - https://help.ubuntu.com/community/RootSudo
Pour essayer de répondre à certaines de vos autres pensées:
- Suo ou Sudo ne vous empêche de faire fonctionner du code malveillant tant que vous connaissez le mot de passe. Ni est plus sûr ou mieux.
- Les biscuits peuvent obtenir un accès à Shell via différentes méthodes. Lorsque vous voyez "exécuter du code arbitraire" dans une notification de sécurité - https://usn.ubuntu.com/usn/ - cela signifie qu'un pirate informatique peut exécuter/bin/bash ou tout autre code. Ainsi, un pirate informatique, via divers exploits, peut obtenir un accès à Shell sans connaître votre identifiant ni votre mot de passe. Sudo ou su n'aide à rien.
- Si un cracker a un accès Shell, il peut faire beaucoup de dégâts sans accès root. Par exemple, le ransomware qui chiffre toutes vos données personnelles.
- Si un pirate a un accès Shell à un compte avec un accès root, via su ou Sudo, il peut obtenir un accès root via un certain nombre de méthodes dépassant le cadre de la présente discussion. Sudo ou su n'est pas supérieur à cet égard non plus.
Ainsi, alors que vous avez observé des problèmes ou des failles avec Sudo, su a exactement les mêmes vulnérabilités et qu'il n'est pas supérieur à Sudo dans ces aspects, à mon humble avis,
Imaginez que vous avez 20 minutes pour faire quelque chose de complexe. Vous avez un peu la gueule de bois et vous devez vous précipiter. "Utilisons su" vous dites. "Cela vous fera gagner du temps" est votre raisonnement.
Par accident vous tapez
rm -rf /*
au lieu de
rm -rf ./*
Votre système est maintenant en train de casser et il vous reste 10 minutes avant la date limite.
Si vous choisissez explicitement quand vous avez besoin de root, vous pouvez minimiser les risques que cela se produise. La racine peut ne pas être nécessaire pour rm -r ./* alors pourquoi l'utiliser? Pourquoi prendre le risque?
C’est ce que "sécurité" signifie ici. Minimiser le risque que les utilisateurs (tous les utilisateurs, pas seulement les débutants) commettent une erreur fatale.
Bien sûr, c’est un exemple extrême qui ne devrait pas être autorisé à se produire dans un environnement de production (je garantis que cela s’est passé dans un environnement de production).
Du point de vue de la sécurité, il y a des choses pour lesquelles Sudo est meilleur. Comme @ dit Panther - journalisation, restrictions, mot de passe root est SPOF, etc.)
Je veux ajouter un peu de perspective historique aux autres réponses. Malheureusement, je n'ai aucune source prête, si ce n'est mes propres souvenirs de discussions Usenet et d'articles de magazines.
Il y a quelque temps, dans les années 1990, les distributions facilitaient l'installation de Linux sur votre propre matériel, même avec peu de connaissances en informatique1. Ainsi, Linux a commencé à attirer de plus en plus de personnes qui, étonnamment, n'avaient pas encore été percées comme administrateurs système. certains dialecte UN * X. À la place, beaucoup étaient habitués à des systèmes (utilisateur unique) tels que Windows 95/98. Et ils ont appris que la plupart des tâches d’administration du système Linux obligeaient à travailler sous cet étrange compte "root".
Ainsi, certains utilisateurs viennent de se connecter en tant que root et utilisent ce compte pour tout leur travail quotidien. Pourquoi devraient-ils taper su et le mot de passe root encore et encore ou se connecter à un nouveau tty uniquement pour certaines commandes d'administration? Mais utiliser la racine pour tout n'est évidemment pas une bonne idée, car vous pourriez faire beaucoup plus de tort à votre système avec une commande peu judicieuse au mauvais endroit . Cela a même conduit une distribution (SuSE?) À modifier l’arrière-plan du bureau de l’utilisateur root afin d’afficher un gros avertissement vous invitant à utiliser ce compte uniquement. pour les tâches administratives.
Ainsi, la méthode Ubuntu avec Sudo présente certains avantages (en plus de ceux déjà répertoriés par Panther ).
- Vous ne pouvez pas vous connecter directement au compte root .² :-)
- Le processus d'installation ne vous demandera pas un mot de passe root (supplémentaire), vous n'avez besoin que d'un mot de passe (votre utilisateur).
Sudomet en cache vos informations d'identification. Ainsi, pour plusieurs commandes d'administration en séquence, il vous suffit d'entrer votre mot de passe une fois (contrairement àsu). Cela réduit le besoin d'ouvrir simplement un shell ou un nouveau terminal avec des privilèges root .- Et il est plus facile de dire aux utilisateurs en ligne et dans la documentation quelles commandes ils doivent entrer en tant qu'administrateur et lesquelles non .³
¹ Et pour ceux qui n’osent pas le faire eux-mêmes, il y avait des fêtes d’installation.
² Mais vous pouvez utiliser une commande telle que Sudo -i ou Sudo su - root pour obtenir un shell racine après vous être connecté en tant qu'utilisateur normal.
³ Mais vous savez bien sûr que vous ne devez pas simplement copier-coller des commandes depuis Internet , n'est-ce pas?
Il est possible de désactiver la connexion root via ssh depuis des décennies. Le moyen utilisé par Ubuntu pour désactiver le compte root et faire en sorte que tout le monde soit Sudo n’est rien de plus qu’un gadget. Juste "Sudo -s" et vous avez une racine Shell. Désactivez la connexion root via ssh et laissez-la là.
Selon la configuration, Sudo <game ending command> ne fonctionnera pas nécessairement. Bien sûr, si la configuration sudoersse lit "utilisateur ALL = (ALL) ALL", Sudon'offrira aucune protection supplémentaire. Vous pouvez toutefois spécifier une liste de commandes privilégiées que vous devez exécuter souvent, comme l'installation de nouveaux packages, et omettre des commandes dangereuses telles que rmname__.
De cette façon, vous pouvez exécuter toutes les commandes si vous vous connectez en tant que rootname__, mais comme vous n’en aurez besoin que de temps en temps, le risque d’exécuter <game ending command> sera considérablement réduit.
Que Sudo ne vous permette que de n'autoriser que certaines commandes n'est pas le seul avantage de Sudo sur su.
Dans la plupart des magasins, ce n’est même pas l’avantage le plus important.
Avec Sudo, vous savez qui a exécuté une commande particulière.
Maintenant, peut-être que cela n'a pas d'importance pour vous. Par exemple, vous pourriez être le seul utilisateur de votre ordinateur. Si c'est le cas, alors Sudo n'est peut-être pas mieux que su.
Mais beaucoup d'hôtes ont plus d'un administrateur.
Sudo devient alors très utile car si quelqu'un fait la mauvaise chose, Sudo vous permet de savoir qui l'a fait.
Cela vous permet de comprendre pourquoi des erreurs se sont produites et d’éduquer les utilisateurs afin qu’ils ne se reproduisent plus ou, si nécessaire, de retirer les outils de quelqu'un.
En prime, lorsque les gens savent que leurs actions sont enregistrées, ils sont souvent un peu plus prudents.
Sudo n'est pas parfait.
Si deux personnes font "Sudo sh" en même temps, il peut être difficile d'attribuer des commandes à l'une ou à l'autre.
Et un administrateur malveillant peut toujours supprimer ou modifier les journaux - bien que le faire proprement ne soit pas toujours aussi facile qu'on le pense, en particulier si vous avez une journalisation centralisée.
Sudo n'arrête pas nécessairement une action stupide ou malveillante, pour toutes les raisons identifiées dans la question initiale.
Mais cela vous donne une bien meilleure chance d'éviter une récidive.