Si tu parles du délai de grâce, c'est facile à vérifier. sudo flanque ses timestamps dans /var/run/sudo/loginduuser (problablement avec un touch ou assimilé). Il y crée une entrée qui porte le nom du tty depuis lequel la commande a été lancée, pour que ce délai n'affecte que la console de travail de l'utilisateur et pas une autre. Si tu lances l'affaire depuis X-Window (mais pas depuis un Xterm, rattaché, lui, à un /dev/pts/*), il n'y a pas de console et le timestamp s'applique sur unknown. Moralité : tous les processus qui ne sont pas ou plus rattachés à une console peuvent en profiter.
Si tu veux faire le test, colle l'applet de lancement d'applis en ligne de commande dans ton tableau de bord Gnome, ouvre une des applications du menu Administration d'Ubuntu avec ton mot de passe habituel, puis lance gksudo depuis l'applet avec la commande de ton choix.
Cet exemple n'est pas probant. Je ne trouve pas inconcevable que le fait d'ouvrir un outil qui requiert les droits "root" et donc, te demande une première fois ton mot de passe via gksudo, permette ensuite, dans le délai imparti par sudo, d'en ouvrir une autre qui les requiert également, sans te demander à nouveau le mot de passe. La session X11 est vue comme un seul et même tty. Dans une console, ce comportement est strictement le même. Le délai de grâce de sudo permet justement de taper systématiquement le mot de passe quand on tape plusieurs commandes. S'il fallait que je saisisse mon mot de passe à chaque fois que j'utilise un outil graphique lié à l'administration dans un délai inférieur à 5 minutes, ce serait très lourd et on tomberait dans le second cas que tu décries comme "Mauvais".
Il faut donc que :
- le processus ne soit pas rattaché à une console ;
- l'uid du processus fasse partie du groupe admin ;
- que le mot de passe d'un utilisateur du groupe ait été tapé il y a moins de 5 minutes auparavant.
Cela fait quand même pas mal de conditions à retenir.
En outre, revenons à aptitude : il y aura bien un moment où il va avoir besoin des privilèges de root, ne serait-ce que pour installer durablement les fichiers d'un paquet debian ou exécuter des scripts de post-installation créant un nouvel utilisateur ou appliquant des droits particuliers. Comment veux-tu éviter de demander le mot de passe de (root ou l'utilisateur via sudo) ? En créant plaçant un sgid sur l'ensemble du système de fichier ? sur l'exécutable d'aptitude ? Mais dans ce cas, si le compte de l'utilisateur est compromis, plus besoin de se farcir les failles locales pour escalader les privilèges...
Réduire le champ d'action obligatoire de root ne fera pas disparaître la menace d'intégrité du système pour autant.
[^] # Re: Parc linux non homogéne
Posté par Raphaël SurcouF (site web personnel) . En réponse à la dépêche Les virus sous Linux. Évalué à 1.
Cet exemple n'est pas probant. Je ne trouve pas inconcevable que le fait d'ouvrir un outil qui requiert les droits "root" et donc, te demande une première fois ton mot de passe via gksudo, permette ensuite, dans le délai imparti par sudo, d'en ouvrir une autre qui les requiert également, sans te demander à nouveau le mot de passe. La session X11 est vue comme un seul et même tty. Dans une console, ce comportement est strictement le même. Le délai de grâce de sudo permet justement de taper systématiquement le mot de passe quand on tape plusieurs commandes. S'il fallait que je saisisse mon mot de passe à chaque fois que j'utilise un outil graphique lié à l'administration dans un délai inférieur à 5 minutes, ce serait très lourd et on tomberait dans le second cas que tu décries comme "Mauvais".
Il faut donc que :
- le processus ne soit pas rattaché à une console ;
- l'uid du processus fasse partie du groupe admin ;
- que le mot de passe d'un utilisateur du groupe ait été tapé il y a moins de 5 minutes auparavant.
Cela fait quand même pas mal de conditions à retenir.
En outre, revenons à aptitude : il y aura bien un moment où il va avoir besoin des privilèges de root, ne serait-ce que pour installer durablement les fichiers d'un paquet debian ou exécuter des scripts de post-installation créant un nouvel utilisateur ou appliquant des droits particuliers. Comment veux-tu éviter de demander le mot de passe de (root ou l'utilisateur via sudo) ? En créant plaçant un sgid sur l'ensemble du système de fichier ? sur l'exécutable d'aptitude ? Mais dans ce cas, si le compte de l'utilisateur est compromis, plus besoin de se farcir les failles locales pour escalader les privilèges...
Réduire le champ d'action obligatoire de root ne fera pas disparaître la menace d'intégrité du système pour autant.