Re,
On se demande même pourquoi ils ont jugé bon de créer cette option timeout 
sudo donne à un utilisateurs normal des droits root, donc à quelqu’un dont le compte est exposé des droits root. Le timeout est effectivement une aberration à ce stade mais a été mis pour une question de confort. su bascule sur le compte root, à un moment précis: Un processus bash root est lancé. Pour le reste, dans un cas comme dans l’autre les entrées sorties se font sur un DISPLAY possédé par l’utilisateur et accessible uniquement par lui (excepté si on fait xhost + ce qui est une erreur). Les cas d’IO trappés sont donc les mêmes avec sans doute un bémol pour sudo, il est plus facile de corrompre un compte standard que le compte root, mais dans ce cas il est tout aussi facile d’intercepter le mot de passe root avec un faux «su» (je l’ai fait).
Personnellement, je préfère la logique su, je comprends la logique sudo avec un timeout 0 mais aurait du mal à supporter de taper 100 fois le mot de passe et ferais rapidement un «sudo su». Donc je n’installe pas sudo.
de toute manière, à priori, lorsque l’on lance une commande en tant que root, elle n’est pas active pendant des heures. Donc les malwares ne peuvent pas faire beaucoup de mal.
Cependant, en vous lisant, je me demande comment le mot de passe administrateur est stocké? Car même s’il y a encryption, il y a forcément moyen de le décrypter…
[quote=“ggoodluck47”]Re,
Et pendant tout le temps que durera la connexion, la relation client/serveur seras accessible à tous les malwares 
/etc/sudoers
Default: timestamp_timeout=0 ==> brise la relation dès le lancement de la commande
ALL-(ALL) ALL ==> donne à tous les droits mais au coup par coup[/quote]
Tu peux détailler stp ?
Je vois pas comment un utilisateur normal pourrai voir ce qui passe par la boucle locale…
[quote=“thuban”]de toute manière, à priori, lorsque l’on lance une commande en tant que root, elle n’est pas active pendant des heures. Donc les malwares ne peuvent pas faire beaucoup de mal.
Cependant, en vous lisant, je me demande comment le mot de passe administrateur est stocké? Car même s’il y a encryption, il y a forcément moyen de le décrypter…[/quote]
Non, le codage n’est pas injectif donc il n’y a pas de fonction d’inversion et on ne sait pas encore construire un antécédent à la fonction d’encodage du mot de passe. C’est un paradoxe apparent mais fréquent: le fait même qu’il y ait plusieurs solutions possibles (comprendre plusieurs mots de passe fonctionnant) rend le calcul de l’un d’entre eux très dur: c’est une situation classique en Maths: plus un pbm a de solutions, plus en trouver une est compliqué.
@fran.b
Sauf si les mots de passe sont mauvais,
auquel cas on peut tenter une attaque par dictionnaire
(ou d’autres méthodes essayant de réduire le nombre de possibilités
en faisant des hypothèses sur les utilisateurs)
@thuban
Les mots de passes sont tous stockés (cryptés) au même endroit :
/etc/shadow
Et même si en théorie il est possible de les craquer,
ça prend tellement de temps en brute force qu’on peut se permettre de dire “c’est pas possible”
[quote=“BBT1”]@fran.b
Sauf si les mots de passe sont mauvais,
auquel cas on peut tenter une attaque par dictionnaire
(ou d’autres méthodes essayant de réduire le nombre de possibilités
en faisant des hypothèses sur les utilisateurs)
@thuban
Les mots de passes sont tous stockés (cryptés) au même endroit :
/etc/shadow
Et même si en théorie il est possible de les craquer,
ça prend tellement de temps en brute force qu’on peut se permettre de dire “c’est pas possible”[/quote]
Oui, à titre indicatifs, je fais ça sur les mots de passe des 300 utilisateurs d’un de mes serveurs: 60% des mots de passe sont craqués en 2 heures…
question idiote : est-ce possible de changer le mot de passe root? ainsi que les mots de passe utilisateurs?
edit :
réponse idiote :
oui, facilement avec kuser par exemple.
je crois bien que mon /root n’est pas complet…
quelqu’un aurait-il l’aimabilité de me donner le contenu de son dossier /root avec un ls -a svp?
Je ne crois pas que ça pose le moindre problème que ton /root soit vide.
En fait, je pense que si ce /root se met à gonfler,
c’est qu’il y a un problème dans l’administration de la machine…
Par contre, je finis toujours par coller un .bashrc et un .emacs,
mais ça reste du domaine des préférences personnelles…