Un petit truc tout bête que j’utilise pour afficher sans souci des applications graphiques lancées via su (genre emacs): un simple
suffit à régler le problème. Cela évite les histoires de xhost + et les manipulations de xauth assez complexes.
J’utilise kdesu, tout simplement (il y a un équivalent sous gnome dont j’ai oublié le nom)
Pour emacs, je l’installe de toutes les manière en -nox, mais on peut toujours le lancer en -nw.
Sinon, c’est toi qui ne veut pas utiliser sudo, et tu préfères prendre le risque de laisser transmettre par keylogger ce que tu tapes en root à un pirate ?
Non, si j’ai bien compris, ça autorise root à utiliser l’affichage X11 de l’utilisateur «francois» mais c’est tout, je me trompe??
Bah si ta session X est compromise par un keylogger, même sans droits root, ce n’est pas parceque le process qui tourne dans ta fenètre est root que ce que tu tapes ne passe pas par ta session X, non ?
M’enfin tu me diras que c’est pareil avec un truc que tu tapes en su dans une console, et que pour keyloguer la session utilisateur, il y a des chances qu’il faille obtenir un rootshell avant.
Mais bon.
Moi c’est ce que j’utilise et c’est comme cela que je l’avais compris.
[quote=“thialme”][quote=“fran.b”]Non, si j’ai bien compris, ça autorise root à utiliser l’affichage X11 de l’utilisateur «francois» mais c’est tout, je me trompe??[/quote]Moi c’est ce que j’utilise et c’est comme cela que je l’avais compris.[/quote]Oui, mais comme je l’ai dit, c’est pas si simple. Tout le serveur X fonctionne sous l’identité fran.b, et c’est ce service X qui fournit les bordures de fenètres, les boutons, et surtout, les inputs X. L’application >cliente< qui tourne dedans, même si elle fonctionne sous l’identité de root, n’est jamais que cliente, et si tu tapes dedans quelquechose de critique et que la session de fran est compromise, ça peut être surveillé. Ou aussi, le seveur X peut simuler ses propres inputs.
Mais c’est comme je disais: que ça se fasse par là ou au travers d’une appli lancée par sudo, c’est pareil.
[quote=“mattotop”]Bah si ta session X est compromise par un keylogger, même sans droits root, ce n’est pas parceque le process qui tourne dans ta fenètre est root que ce que tu tapes ne passe pas par ta session X, non ?[/quote]Exact
[quote]
M’enfin tu me diras que c’est pareil avec un truc que tu tapes en su dans une console, et que pour keyloguer la session utilisateur, il y a des chances qu’il faille obtenir un rootshell avant.
Mais bon.[/quote]
L’intérêt de ma méthode est que si X est bien configuré par ailleurs (en clair xhost - et aucune connexion tcp accepté) seul les utilisateurs ayant le MAGIC-COOKIE peuvent se connecter au serveur X. En faisant ce lien, je donne automatiquement à root la possibilité de se connecter à mon serveur X car il aura la clef d’accès pour la session en cours. Un utilisateur connecté sur ma machine ne pourra pas pour autant y accéder. C’est plus sûr que de faire
$ xhost +localhost
qui permet à un utilisateur local de se connecter au serveur X et donc de faire du keylogging (et de la capture écran).
Théoriquement, xhost +root@localhost devrait faire la même chose mais ça n’a jamais marché chez moi.
T’façon théoriquement, il ne faudrait exécuter du root qu’en console, moi je dis.
C’est pour ça que quitte à ne pas m’inquièter je prends sudo.
Oui mais le sudo… Je n’aime vraiment pas, tu fais une commande sudo et hop, tu peux taper des commandes sudo sans vérifications pendant qques minutes et là il y a une faille. Un bon vieux «su», là au moins tu sais que tu es en root et seul les commandes tapées après le # sont sous root…
Mais j’ai vraiment du mal à changer mes habitudes, je crois que tu t’en es aperçu 
Bah moi aussi j’ai mis des années à passer de lilo à grub. et puis avec un timeout à 0, ça fait le même temps de frappe de taper sudo et su -c , sauf que sudo se configure plus finement que su pour ce qui est du passage d’éléments de l’environnement.
Je me demande s’il n’y a pas un moyen avec sudo de le faire marcher sans mot de passe avec des credentials sur une clé usb. Ca, ça serait sécurisé.
[quote=“mattotop”]Bah moi aussi j’ai mis des années à passer de lilo à grub. et puis avec un timeout à 0, ça fait le même temps de frappe de taper sudo et su -c , sauf que sudo se configure plus finement que su pour ce qui est du passage d’éléments de l’environnement.
Je me demande s’il n’y a pas un moyen avec sudo de le faire marcher sans mot de passe avec des credentials sur une clé usb. Ca, ça serait sécurisé.[/quote]
Pas vraiment: Ce que je redoute, c’est qu’un programme exécuté sous mon compte à mon insu (par une imprudence quelconque de ma part), éxécute des sudo (je te dis, je parie sur des virus sous Ubuntu d’ici peu). Il suffit que je fasse une commande sudo ou que je mette la clef USB pour que ça passe. Il faudrait en fait pouvoir limiter le périphérique d’où est tapé la commande sudo. Quand tu fais su, les commandes ne peuvent être envoyées que d’un seul endroit.
Mais tu peux faire ce genre de choses avec sudo:
[quote="‘man sudoers’"]
(…)
requiretty If set, sudo will only run when the user is logged in to a real tty. This will disallow things like "rsh somehost sudo ls"
since rsh(1) does not allocate a tty. Because it is not possible to turn off echo when there is no tty present, some sites may
wish to set this flag to prevent a user from entering a visible password. This flag is off by default.
(…)
tty_tickets If set, users must authenticate on a per-tty basis. Normally, sudo uses a directory in the ticket dir with the same name as the
user running it. With this flag enabled, sudo will use a file named for the tty the user is logged in on in that directory.
This flag is off by default.
[/quote]Et pui comme l’autentification passe par pam, on peut ajouter des critères dans pam.
[quote=“fran.b”]Un petit truc tout bête que j’utilise pour afficher sans souci des applications graphiques lancées via su (genre emacs): un simple
suffit à régler le problème. Cela évite les histoires de xhost + et les manipulations de xauth assez complexes.[/quote]
J’ai trouvé ça: http://linux-attitude.fr/post/su-X
[quote=“mattotop”]Mais tu peux faire ce genre de choses avec sudo:
Oui, la deuxième option surtout. Il faudrait le mettre comme ça par défaut…
Dimm: Ben oui, mais la première est peu sure, la deuxième nécessite un serveur ssh, la troisième est lourde et nécessite des manips.