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.
Justement, cette facilité se justifie en ligne de commande car l'utilisateur précise explicitement sudo à chaque fois mais surtout parce que l'administration en ligne de commande consiste généralement en une floppée de commandes successives, toutes éphémères.
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".
C'est là que nos opinions diffèrent. Toutes ces applications sont persistantes, elles effectuent en général toutes les opérations demandées en une fois à la validation, et peuvent être beaucoup facilement lancées en parallèle par l'utilisateur de base. Étant donné qu'en outre, cela ne concerne qu'au plus une quinzaine d'applications, un délai de grâce ne se justifie absolument pas dans ce genre d'environnement.
D'autre part - et c'est son intérêt principal - un clicodrôme propose des options à l'utilisateur à l'inverse d'une ligne de commande à laquelle on doit les passer explicitement (et sans se tromper dans l'orthographe). Si l'on tient compte en plus de fait que bon nombre de foyers (auxquels Ubuntu se destine) utilisent un compte familial, il devient très simple de lancer une application censée être privilégiée comme n'importe quelle autre application du menu.
Il faut donc que :
- le processus ne soit pas rattaché à une console ;
C'est automatiquement le cas de toutes les applications lancées à partir du bureau graphique et non d'une ligne de commande. Et sans cela, il suffit à un processus de faire un setsid() ou un ioctl() avec TIOCNOTTY pour se détacher de sa console.
- l'uid du processus fasse partie du groupe admin ;
C'est forcément le cas aussi puisque tous les programmes sont lancés sous ton identité.
- 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.
Non, il suffit de se mettre en attente et de surveiller l'exécution de gksudo, puis de voir si le même PID sous la même identité (root) correspond à un autre exécutable (suite d'un execve) pour savoir qu'un sudo a réussi et donc que le timestamp est valide pour 5 minutes. Si tu balances la commande à ce moment-là, elle sera toujours associée dans le log avec la précédente. Si tant est, bien sûr, que l'utilisateur lamdba lise le log.
En créant plaçant un sgid sur l'ensemble du système de fichier ?
Encore une drôle d'idée ...
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...
Non, car au moins, seule cette commande pourra être exécutée ! Ça fait quand même toute la différence !
Un sudo même sans délai de grâce permet par défaut de lancer n'importe quelle commande !
Réduire le champ d'action obligatoire de root ne fera pas disparaître la menace d'intégrité du système pour autant.
Encore une fois, il ne faut pas confondre l'utilisation de sudo et le passage vers root. Dans le cas du serveur FTP, tout l'administration peut être faite sous l'identité d'un pseudo-user, et c'est l'identité de celui-ci qu'il faut prendre, pas celle de root.
Il est important de remarquer que, d'une part, le fichier /etc/sudoers permet de spécifier une liste de commande explicitement autorisées, et également de choisir une identité autre que root.
Il est de fait qu'Ubuntu n'exploite pas du tout ces possibilités, pas plus que la plupart des distributions. Le premier utilisateur fraîchement déclaré a donc la possibilité de passer root et de faire n'importe quoi, même lorsqu'il débute sur le système. Et c'est pour moi une grave faille de sécurité.
[^] # Re: Parc linux non homogéne
Posté par Obsidian . En réponse à la dépêche Les virus sous Linux. Évalué à 2.
Justement, cette facilité se justifie en ligne de commande car l'utilisateur précise explicitement sudo à chaque fois mais surtout parce que l'administration en ligne de commande consiste généralement en une floppée de commandes successives, toutes éphémères.
C'est là que nos opinions diffèrent. Toutes ces applications sont persistantes, elles effectuent en général toutes les opérations demandées en une fois à la validation, et peuvent être beaucoup facilement lancées en parallèle par l'utilisateur de base. Étant donné qu'en outre, cela ne concerne qu'au plus une quinzaine d'applications, un délai de grâce ne se justifie absolument pas dans ce genre d'environnement.
D'autre part - et c'est son intérêt principal - un clicodrôme propose des options à l'utilisateur à l'inverse d'une ligne de commande à laquelle on doit les passer explicitement (et sans se tromper dans l'orthographe). Si l'on tient compte en plus de fait que bon nombre de foyers (auxquels Ubuntu se destine) utilisent un compte familial, il devient très simple de lancer une application censée être privilégiée comme n'importe quelle autre application du menu.
C'est automatiquement le cas de toutes les applications lancées à partir du bureau graphique et non d'une ligne de commande. Et sans cela, il suffit à un processus de faire un setsid() ou un ioctl() avec TIOCNOTTY pour se détacher de sa console.
C'est forcément le cas aussi puisque tous les programmes sont lancés sous ton identité.
Non, il suffit de se mettre en attente et de surveiller l'exécution de gksudo, puis de voir si le même PID sous la même identité (root) correspond à un autre exécutable (suite d'un execve) pour savoir qu'un sudo a réussi et donc que le timestamp est valide pour 5 minutes. Si tu balances la commande à ce moment-là, elle sera toujours associée dans le log avec la précédente. Si tant est, bien sûr, que l'utilisateur lamdba lise le log.
Encore une drôle d'idée ...
Non, car au moins, seule cette commande pourra être exécutée ! Ça fait quand même toute la différence !
Un sudo même sans délai de grâce permet par défaut de lancer n'importe quelle commande !
Encore une fois, il ne faut pas confondre l'utilisation de sudo et le passage vers root. Dans le cas du serveur FTP, tout l'administration peut être faite sous l'identité d'un pseudo-user, et c'est l'identité de celui-ci qu'il faut prendre, pas celle de root.
Il est important de remarquer que, d'une part, le fichier /etc/sudoers permet de spécifier une liste de commande explicitement autorisées, et également de choisir une identité autre que root.
Il est de fait qu'Ubuntu n'exploite pas du tout ces possibilités, pas plus que la plupart des distributions. Le premier utilisateur fraîchement déclaré a donc la possibilité de passer root et de faire n'importe quoi, même lorsqu'il débute sur le système. Et c'est pour moi une grave faille de sécurité.