Honnêtement, le sudo, on va dire pour être gentil que c'est un moindre mal. Je suis actuellement sous Ubuntu, et on en fait grand usage, sinon je l'utilise également sur les serveurs de production du travail. Personnellement, je trouve ça dégueulasse quand même.
Les avantages de sudo sont :
- Le traçage des commandes dans le log.
- La possibilité de révocation éventuelle (sans objet sur une machine personnelle).
- La non-divulgation du mot de passe root (nécessaire également en cas de révocation).
- La non-ouverture d'une console, qui en général reste ouverte après usage, ou que l'on confond avec une console utilisateur.
- Pouvoir exécuter des scripts shell en root ou autre (extrêmement sensible, pas souhaitable à mon avis).
Pour le reste, c'est un trou de sécurité béant. 9 fois sur 10, le mot de passe est le même que celui de la session utilisateur, mais surtout, le compte utilisateur peut exécuter n'importe quelle commande, et non pas une liste prédéfinie comme le permet /etc/sudoers.
ce qui revient effectivement à percer root, et permet de court-circuiter l'interdiction de connexion depuis l'extérieur.
Derrière ce cas de figure se cache, à mon humble avis, le véritable problème : les mauvaises configurations et gestions des droits UNIX initiaux. Dès que l'on se retrouve à devoir faire quelque chose qui sort de l'ordinaire, allez hop ! Un petit coup de sudo. Il n'est pas normal, par exemple, de prendre l'habitude de passer super-utilisateur pour lire un log, fût-il de sécurité. Si c'est quelque chose à faire plus d'une fois, alors il faut prendre le temps de passer le log en read-only pour un groupe donné, et de s'inclure dans ce groupe.
Unix, en principe, fait du VFS le point d'articulation de toute entité du système, ce qui devrait permettre de tout gérer de manière uniforme. Malheureusement, la plupart des ressources récentes tendent à s'en éloigner. Ça a commencé avec les IPC SysV, et ça se multiplie avec la tendance à vouloir faire du multiplateforme (qui en général, se traduit par une implémentation sous Windows, et des adaptations du produit sur le reste). Je pense qu'il faut commencer par combattre cela pour conserver un pouvoir d'administration, puis s'occuper de mettre en place un système efficace.
Dans le même esprit, est-ce que l'installation de logiciels via apt-get ou assimilé doit être également une opération super-utilisateur ? Les dépots et les archives étant signés, on sait, en principe, à l'avance ce qui doit être installé. On pourrait alors se contenter de commuter vers un groupe ou un utilisateur installer avec des droits de dépot sur le disque (et rien d'autre), mais pas forcément vers root.
Si on prend le cas d'une distribution personnelle dans lequel les mises à jour sont au minimum hebdomadaires, on passe son temps à saisir son mot de passe pour obtenir les droits d'admin. Il suffit à n'importe quel script de se mettre en écoute sur le serveur X pour briser la sécurité. Je suis sûr qu'en y allant au culot et en ouvrant une boite de dialogue impromptue, même les utilisateurs les plus avertis se feraient avoir, à force de switcher à tout bout de champ.
D'une manière générale, en ramenant toutes les opérations privilégiées à des autorisations UNIX et en plaçant une utilisateur dans tous les groupes, ne recrée-t-on pas un compte omnipotent (comme avec sudo) sans la restriction par mot de passe ? Pas tout-à-fait, car on n'autorise à chaque fois que ce qui a été explicitement prévu. Même les effets de bords que cela risque d'engendrer seront potentiellement moins dangereux que l'acquisition même temporaires des super-privilèges.
Je pense que l'avenir sur les machines personnelles est de :
- Ramener à une gestion UNIX des droits toutes les opérations qui ne sont pas irréversibles, telles qu'installer un .deb/.rpm signé, ou relancer un serveur web par exemple (typiquement, avec un apache graceful).
- Faire un usage plus répandu de suid. On a stigmatisé ce procédé à juste titre pendant un temps parce qu'il pouvait introduire une vulnérabilité si l'exécutable contenait une faille. Le problème est exactement le même avec sudo. On peut aussi envisager mettre tous les exécutables à SUID sur une partition dédiée, spécifiée dans le $PATH, et mettre les autres à nosuid. Enfin, on pourrait auditer l'exécution de ces fichiers, à la manière du /var/log/secure. Je pense que des chown/chgrp/chmod sur les fichiers concernés seraient plus propres qu'une entrée texte supplémentaire dans /etc/sudoers.
- Identifier les tâches privilégiées effectuées régulièrement. Par exemple, changer la résolution de son écran est une tâche qui peut avoir besoin d'être privilégiée, mais qui n'est pas fréquente. Si l'on prend le cas d'un utilisateur débutant, vaut-il mieux mettre en place un sudo exprès pour l'occasion, ou définir un groupe et un setuid, pour permettre à l'utilisateur de faire cette tâche comme on utilise passwd ? La réponse n'est pas évidente.
[^] # Re: Intrusion -> sudo sucks (un peu).
Posté par Obsidian . En réponse au journal Réagir en cas d'intrusion. Évalué à 10.
Les avantages de sudo sont :
- Le traçage des commandes dans le log.
- La possibilité de révocation éventuelle (sans objet sur une machine personnelle).
- La non-divulgation du mot de passe root (nécessaire également en cas de révocation).
- La non-ouverture d'une console, qui en général reste ouverte après usage, ou que l'on confond avec une console utilisateur.
- Pouvoir exécuter des scripts shell en root ou autre (extrêmement sensible, pas souhaitable à mon avis).
Pour le reste, c'est un trou de sécurité béant. 9 fois sur 10, le mot de passe est le même que celui de la session utilisateur, mais surtout, le compte utilisateur peut exécuter n'importe quelle commande, et non pas une liste prédéfinie comme le permet /etc/sudoers.
ce qui revient effectivement à percer root, et permet de court-circuiter l'interdiction de connexion depuis l'extérieur.
Derrière ce cas de figure se cache, à mon humble avis, le véritable problème : les mauvaises configurations et gestions des droits UNIX initiaux. Dès que l'on se retrouve à devoir faire quelque chose qui sort de l'ordinaire, allez hop ! Un petit coup de sudo. Il n'est pas normal, par exemple, de prendre l'habitude de passer super-utilisateur pour lire un log, fût-il de sécurité. Si c'est quelque chose à faire plus d'une fois, alors il faut prendre le temps de passer le log en read-only pour un groupe donné, et de s'inclure dans ce groupe.
Unix, en principe, fait du VFS le point d'articulation de toute entité du système, ce qui devrait permettre de tout gérer de manière uniforme. Malheureusement, la plupart des ressources récentes tendent à s'en éloigner. Ça a commencé avec les IPC SysV, et ça se multiplie avec la tendance à vouloir faire du multiplateforme (qui en général, se traduit par une implémentation sous Windows, et des adaptations du produit sur le reste). Je pense qu'il faut commencer par combattre cela pour conserver un pouvoir d'administration, puis s'occuper de mettre en place un système efficace.
Dans le même esprit, est-ce que l'installation de logiciels via apt-get ou assimilé doit être également une opération super-utilisateur ? Les dépots et les archives étant signés, on sait, en principe, à l'avance ce qui doit être installé. On pourrait alors se contenter de commuter vers un groupe ou un utilisateur installer avec des droits de dépot sur le disque (et rien d'autre), mais pas forcément vers root.
Si on prend le cas d'une distribution personnelle dans lequel les mises à jour sont au minimum hebdomadaires, on passe son temps à saisir son mot de passe pour obtenir les droits d'admin. Il suffit à n'importe quel script de se mettre en écoute sur le serveur X pour briser la sécurité. Je suis sûr qu'en y allant au culot et en ouvrant une boite de dialogue impromptue, même les utilisateurs les plus avertis se feraient avoir, à force de switcher à tout bout de champ.
D'une manière générale, en ramenant toutes les opérations privilégiées à des autorisations UNIX et en plaçant une utilisateur dans tous les groupes, ne recrée-t-on pas un compte omnipotent (comme avec sudo) sans la restriction par mot de passe ? Pas tout-à-fait, car on n'autorise à chaque fois que ce qui a été explicitement prévu. Même les effets de bords que cela risque d'engendrer seront potentiellement moins dangereux que l'acquisition même temporaires des super-privilèges.
Je pense que l'avenir sur les machines personnelles est de :
- Ramener à une gestion UNIX des droits toutes les opérations qui ne sont pas irréversibles, telles qu'installer un .deb/.rpm signé, ou relancer un serveur web par exemple (typiquement, avec un apache graceful).
- Faire un usage plus répandu de suid. On a stigmatisé ce procédé à juste titre pendant un temps parce qu'il pouvait introduire une vulnérabilité si l'exécutable contenait une faille. Le problème est exactement le même avec sudo. On peut aussi envisager mettre tous les exécutables à SUID sur une partition dédiée, spécifiée dans le $PATH, et mettre les autres à nosuid. Enfin, on pourrait auditer l'exécution de ces fichiers, à la manière du /var/log/secure. Je pense que des chown/chgrp/chmod sur les fichiers concernés seraient plus propres qu'une entrée texte supplémentaire dans /etc/sudoers.
- Identifier les tâches privilégiées effectuées régulièrement. Par exemple, changer la résolution de son écran est une tâche qui peut avoir besoin d'être privilégiée, mais qui n'est pas fréquente. Si l'on prend le cas d'un utilisateur débutant, vaut-il mieux mettre en place un sudo exprès pour l'occasion, ou définir un groupe et un setuid, pour permettre à l'utilisateur de faire cette tâche comme on utilise passwd ? La réponse n'est pas évidente.
Enfin, ce n'est que mon avis ... :-)