Forum

Reprise du message précédent

http://hassansin.github.io/fun-with-unix-named-pipes

Oui, apparemment la lecture est "aléatoire". Lorsqu'il y a plusieurs processus qui lisent un fichier, on ne sait pas lequel des processus lira le caractère écrit dans le fichier.

OK. Merci! Donc ça éliminerait le mécanisme comme quoi il y aurait un processus qui reçoit les touches (comme Xorg), et puis les rebalance sur une autre sortie (standard ou autre) afin que d'autres processus intéressés viennent s'y "abonner". Ces processus ne recevraient alors pas tous les événements

Du coup, j'ai vérifié pour /dev/console, mais il n'y a rien en sortie standard lorsqu'on tape sur le clavier. Donc l'avertissement de showkey n'a pas l'air très ... pertinent. Idem, personne si je fais un lsof /dev/console lorsque showkey est en marche

Le mystère reste total : qui lui envoie les événements de clavier ?

Édité par choucroot Le 28/04/2020 à 13h56

J'ai regardé le code de showkey.c ... ça me replonge il y a 25 en arrière, à l'époque où on utilisait Motif pour faire des Gui sous Unix

Bon, apparemment, ça utilise des input-output control
if (ioctl(fd, KDGKBMODE, &oldkbmode)) {
perror("KDGKBMODE");
exit(1);
}


des trucs dont j'ignorais l'existence mais qui apparemment "... sont quelquefois utilisés pour donner un accès, depuis l'espace utilisateur, à des fonctions du noyau utilisées uniquement par le cœur du système ou encore en développement. ", dixit Wikipedia

Bref, si tu me confirmeras si c'est ça, mais ça a l'air de pouvoir donner accès au clavier sans utiliser d'entrées sorties, ou de périphérique /dev .

Je relance quand même le challenge du premier qui pourra me dire comment détecter un keylogger sur une machine ! Et intégrer ça dans msec pour Mageia 8.0

Si justement, ça peut confirmer. Il y en a un unique qui écoute et transmet le caractère au processus en avant plan (c'est bien xorg qui orchestre ça non?) Donc il sait à qui transférer le caractère.
D'ailleurs, lorsqu'on joue à des jeux vidéos, un des premiers problèmes pour les français, c'est AZERTY vs QWERTY avec la direction des personnages. Comme quoi l'application ne reçoit pas une touche (touche numéro 56 appuiée) mais un caractère qu'il interprete comme "la touche à tel emplacement est appuiée".
C'est aussi pour ça qu'on redéfini la disposition clavier aux installations.

Il faut ainsi sortir de la couche d'abstraction (d'xorg) et prendre les ressources du noyau.

Tes jeux tournent donc sous Xorg, et en mode "utilisateur" ? Mais pour reprendre ta dernière phrase, prendre les ressouces du noyau quand on n'est pas root, est-ce possible ?

Là on ne peut pas trop savoir car avec mes exemples de keylogger. À chaque fois, c'est root qui l'exécute.
Si on teste showkey en mode utilisateur:

[afb@localhost Bureau]$ su
Mot de passe :
localhost Bureau # chmod o+x /usr/bin/showkey
localhost Bureau # exit
exit
[afb@localhost Bureau]$ showkey
le mode clavier était ?INCONNU?
[ si vous essayez cela sous X Window, cela peut ne pas fonctionner
étant donné que le serveur X utilise également /dev/console ]

showkey: ioctl KDSKBMODE: Opération non permise
[afb@localhost Bureau]$ su
Mot de passe :
localhost Bureau # chmod o-x /usr/bin/showkey
localhost Bureau # exit
exit
[afb@localhost Bureau]$

Ah ah ! Dehors, , ça rentre pas !

Idem, le cat /dev/${périphérique_clavier} n'a pas non plus les droits en mode utilisateur !
[afb@localhost Bureau]$ cat /dev/input/by-id/usb-046a_0023-event-kbd
cat: /dev/input/by-id/usb-046a_0023-event-kbd: Permission non accordée


Donc a priori ça bien foutu ! Alors peut-on dire "Moralité: pour éviter un keylogger, ne jamais exécuter de programmes en root, et pis c'est tout !". Je ne sais pas si c'est suffisant