efficacité de l'économiseur d'écran

Bonjour,
certaines personnes utilisent xscreensaver ou d’autres programmes similaires
pour empêcher l’accès au contenu de leur ordinateur pendant leur absence.

j’aimerais avoir des retours surtout de la part des personnes utilisant des gestionnaires de connections,
les *dm et autres slim, mais aussi de la part de ceux qui utilisent xinit, startx et l’autologin.

Si par exemple, une fois l’économiseur d’écran activé, vous basculez sur le tty qui a servi à lancer X et que vous tapez ctrl-c,
vous retrouvez vous sur un prompt shell ou sur un prompt de login ?

Pour ma part avec xinit, si je n’avais pas un alias alias xinit='xinit && exit'un simple ctrl-c sur tty1 donnerait un shell ouvert à n’importe quel curieux.

Je me demandais ce que les gestionnaires de connection ont prévu dans ce cas de figure.

P.S : je sais qu’un accès physique est suffisant à quelqu’un de déterminé pour faire ce qu’il veut sur la machine,
aujourd’hui je voulais juste parler du curieux qui n’a que ses doigts à dispo.

Plop,

Personnellement, j’utilise gdm, et xscreensaver. Lorsque xscreensaver verrouille l’écran, son verrouillage est fiable : la console qui lance le verrouillage récupère la main juste après, mais est bien sûr lockée par xscreensaver. La fenêtre de reconnexion propose soit d’entrer le mot de passe pour déverrouiller, soit une “nouvelle connexion”.
Un seul défaut : la fenêtre de déverrouillage désactive temporairement l’écran de veille, et n’affiche qu’un (horrible) fenêtre par dessus tout le contenu du bureau. Un petit curieux peut donc voir le bureau précédemment actif.

[quote=“Dunatotatos”]Plop,

Personnellement, j’utilise gdm, et xscreensaver. Lorsque xscreensaver verrouille l’écran, son verrouillage est fiable : la console qui lance le verrouillage récupère la main juste après, mais est bien sûr lockée par xscreensaver.[/quote]Donc, si je t’ai bien compris xscreensaver vérouille aussi les tty ?

[quote=“Dunatotatos”]Plop,

Personnellement, j’utilise gdm, et xscreensaver. Lorsque xscreensaver verrouille l’écran, son verrouillage est fiable : la console qui lance le verrouillage récupère la main juste après, mais est bien sûr lockée par xscreensaver. La fenêtre de reconnexion propose soit d’entrer le mot de passe pour déverrouiller, soit une “nouvelle connexion”.
Un seul défaut : la fenêtre de déverrouillage désactive temporairement l’écran de veille, et n’affiche qu’un (horrible) fenêtre par dessus tout le contenu du bureau. Un petit curieux peut donc voir le bureau précédemment actif.[/quote]
Tu n’a pas bien compris il me semble tu parle de terminal virtuel là où eol parle de console (TTY).

Salut,
Effectivement (et malheureusement) xscreensaver n’empêche pas un CTRL+ALT+FX…

Hum, oui, j’avais mal compris. Les tty ne sont effectivement pas verrouillés par xscreensaver.

Bonjour à tous,
Je ne m’était jamais posé la question du verrouillage des ttys mais effectivement ça pose problème la.

Ta configuration me semble étrange, gdm étant lancé en tant que service si j’accède aux tty j’ai simplement une invite de connexion, je ne suis pas connecté.

Ta configuration me semble étrange, gdm étant lancé en tant que service si j’accède aux tty j’ai simplement une invite de connexion, je ne suis pas connecté.[/quote]Je n’ai pas de gestionnaire de connection donc la question de sa configuration ne se pose pas pour moi :mrgreen: mais ta réponse me renseigne.
Donc quand gdm ( par exemple ) est lancé, il ne monopolise aucun tty , il faut se connecter avant de pouvoir tuer la session graphique depuis un tty ?

[quote=“lol”]Salut,
Effectivement (et malheureusement) xscreensaver n’empêche pas un CTRL+ALT+FX…[/quote]Perso, je préfère pouvoir garder la possibilité d’accès aux tty en toute circonstances.
Tant qu’aucun tty n’est ouvert quand tu laisses ton pc seul avec xscreensaver, les risques sont limités, sauf si , ce dont je cherche vraiment à être sûr, la session X ayant servi à lancer xscreensaver peut-être tuée par un ctrl-c en tty1, auquel cas l’alias alias xinit='xinit && exit' ou n’importe quel autre du genre s’impose.

[quote=“Dunatotatos”]Hum, oui, j’avais mal compris. Les tty ne sont effectivement pas verrouillés par xscreensaver.[/quote]Et chez toi, c’est comme chez gege2061 ?
Quelque soit le tty sur lequel tu bascules pendant qu’une session X est ouverte,
tu te retrouves devant un prompt de login et dans aucun cas devant une console occupée ?

Ah oui, je vois le souci maintenant. Etant donné que je me déconnecte d’une console dès que j’ai fini d’y bosser, je n’ai pas vraiment ce problème.

chez moi le ctrl+alt+Fx fonctionne mais toutes les consoles me demande de me logguer donc c’est bon

Une fois que tu auras trouvé la solution au problème, penses à mettre un mot de passe dans le bios et dans grub, et à désactiver le boot sur cd/usb.

Pas testé, mais il doit y avoir un truc qui s’appelle xlock (paquet xlockmore si je me souviens bien (je suis pas sous debian là)). Il faudrait regarder s’il bloque le Ctrl+Alt+Fx, mais vu que c’est géré par init, je suis sceptique…

[quote=“kna”]Une fois que tu auras trouvé la solution au problème, penses à mettre un mot de passe dans le bios et dans grub, et à désactiver le boot sur cd/usb.[/quote]Je penses pas que j’irais jusque là, pour ma part je n’ai pas de problème, quand X est tué, il ne reste pas de shell ouvert, c’est un post dans support debian qui m’a donné l’idée de cette enquête.
Ne pas laisser de shell ouvert est la limite que je fixe à ma parano, je sais que je pourrais aussi faire tout ce que tu m’as suggéré plus aussi crypter mes partitions mais je n’en vois pas encore l’intéret.

Ben en fait, dans mon idée, le problème des Ctrl+Alt+Fx n’est un problème que dans le cas où l’attaquant a un accès physique. Et je ne voie pas dans le principe pourquoi s’affoler qu’on puisse accéder à une console utilisateur si à côté il suffit de booter sur un live-cd pour avoir les droits root sur la machine…
Sinon, le plus simple est de fermer la salle où se trouve ta machine à clé.

Bon, il y a quand même une nuance : le coup du live-cd ça met plus de temps, et ça se voit.