sudo
est aussi sûr, ou non, que ses alternatives populaires telles que su
.
L'alternative la plus populaire à sudo
est de permettre à certains ou à tous les utilisateurs d'élever leurs privilèges avec su
. Le plus souvent, tous les utilisateurs sont autorisés à le faire, tant qu'ils connaissent le mot de passe de l'utilisateur cible . Contrairement à sudo
, qui est presque toujours configuré pour exiger le mot de passe d'un utilisateur (et est limité uniquement aux utilisateurs de confiance), su
nécessite le mot de passe de l'utilisateur cible .
Certaines personnes supposent que cela rend su
plus sûr que sudo
, mais ce n'est pas le cas. su
est soumis aux mêmes types d'attaques que sudo
. Supposons que vous soyez un utilisateur qui exécute parfois su
pour devenir root. Supposons en outre qu'un attaquant qui ne connaît pas le mot de passe root et ne peut pas encore effectuer des actions en tant qu'utilisateur root parvient néanmoins à exécuter du code arbitraire en tant que compte non root. Tout comme cet attaquant peut faire en sorte que lorsque vous exécutez sudo
vous exécutez sa commande malveillante, cet attaquant peut également faire en sorte que lorsque vous exécutez su
vous ' exécutez leur commande malveillante.
Autrement dit, la technique de la réponse de reed fonctionne aussi bien pour introduire une fausse commande su
qui capture le mot de passe de l'utilisateur cible (qui, lorsque su
est utilisé pour administrer le système, est généralement root).
Mais il est possible de faire mieux que l'un ou l'autre, ou pour atténuer le risque.
Une fois que quelqu'un peut exécuter n'importe quelle commande comme vous, il peut généralement apporter des modifications arbitraires au comportement de votre shell, et ainsi créer de faux sudo
, su
, doas
ou toute autre commande d'élévation de privilèges.
Cependant, tant que vous pouvez éviter d'interagir avec un faux écran de connexion , vous pouvez atténuer ce problème en ayant des comptes d'utilisateurs administratifs et non administratifs séparés. Cela ne semble pas être une nouvelle idée, et bien sûr que non, mais il est surprenant de constater à quel point cela est vraiment fait rarement.
Votre compte administratif pourrait soit juste le compte root. Mais si vous voulez les avantages de ne pas vous connecter en tant que root, qui incluent la journalisation (afin de déterminer ce qui n'a pas fonctionné en cas d'erreurs non malveillantes) et la possibilité d'exécuter des programmes qui ne sont pas censés fonctionner en tant que root (la plupart interfaces graphiques), alors vous pouvez avoir deux comptes non root, dont l'un est utilisé pour l'administration (dans lequel vous exécutez sudo
ou su
si nécessaire), et l'autre dont ce n'est pas le cas.
Ce compte devrait si bien sûr pas partager les identifiants d'accès avec le compte non administratif. Ils ne doivent pas avoir de mots de passe identiques ou similaires, et ils doivent avoir des paires de clés distinctes. De plus, vous ne devez pas passer du compte non administratif au compte administratif, pour la même raison, vous ne devez pas passer du compte non administratif à root.
Si vous faites cela, il y a même un argument pour sudo
sur ses alternatives.
Dans cette configuration, il y a un avantage de sudo
sur su
, bien que ce ne soit pas un avantage décisif. Vous pouvez éviter d'utiliser accidentellement le mauvais compte - celui qui est utilisé pour toutes sortes d'autres choses non administratives qui peuvent l'exposer à un plus grand risque - pour administrer le système, en faisant en sorte qu'il ne s'agisse que d'un compte d'utilisateur limité régulier qui n'est pas répertorié et n'est membre d'aucun groupe répertorié dans le fichier / etc / sudoers
.
Mais vous pouvez également atteindre cet objectif avec su
soit en exerçant une autodiscipline appropriée et en vous assurant de ne jamais su
-ing à partir du compte que vous avez conçu comme non-administratifs, ou en empêchant les comptes désignés comme non-administratifs d'élever des privilèges avec su
. (Un moyen d'y parvenir, sur un système GNU / Linux, est avec AppArmor, qui est la façon dont Ubuntu a empêché le compte invité d'utiliser su
avec succès - de retour dans les versions d'Ubuntu qui étaient livrées avec comptes invités activés.)
Le risque d'utiliser sudo
ou su
de la manière habituelle peut être acceptable pour vous.
Cela dit, je ne dis pas que vous devez nécessairement le faire. Cela dépend de vous ou, le cas échéant, de vous et des autres parties prenantes.
Pour de nombreuses personnes, les risques associés à l'utilisation du même compte en (a) passent à la racine avec sudo
(ou des mécanismes similaires comme Polkit) ou su
(ou des mécanismes similaires tels que doas
) comme il est utilisé pour (b) des tâches non administratives telles que l'exécution d'un navigateur Web peuvent être un compromis acceptable pour plus de commodité.