Forum Linux.général X11 et le vol par capture d'images

Posté par . Licence CC by-sa.
1
20
mai
2019

Hi,

J'aimerai pouvoir être rassuré sur le fait qu'il existe un moyen d’empêcher la capture d'écran pour toutes applications non explicitement autorisées à en réaliser, et/ou pour pouvoir interdire l'accès à l'affichage d'une application (toutes ses fenêtres) ainsi qu'au fond d'écran.

Possible ou pas ?

  • # Non

    Posté par (page perso) . Évalué à 4 (+3/-0).

    Non, ce n'est pas possible sous X11. D'ailleurs ce n'est pas un bug, c'est une fonctionnalité!

    Les nouveaux serveurs d'affichage doivent normalement régler ce point (Wayland).

    Un LUG en Lorraine : https://enunclic-cappel.fr

    • [^] # Re: Non

      Posté par (page perso) . Évalué à 2 (+0/-0). Dernière modification le 21/05/19 à 08:41.

      pouvoir interdire l'accès à l'affichage d'une application

      unset DISPLAY

      Si la variable DISPLAY n'est pas définit ou si tu la définit à une valeur débile (genre :156) alors ton application ne va pas pouvoir afficher quoi que ce soit.

      C'est l'avantage de l'ancien monde où tout passait par des variables d'environnement, il était "facile" de se créer des environnements parallèles…

      • [^] # Re: Non

        Posté par (page perso) . Évalué à 5 (+2/-0).

        Oui enfin niveau sécurité ce genre d'astuces c'est zéro pointé aussi. C'est bien pour bidouiller mais pas pour garantir un minimum de sécurité ou que cela fonctionnera en toute circonstance.

      • [^] # Re: Non

        Posté par . Évalué à 1 (+0/-0). Dernière modification le 21/05/19 à 16:57.

        mouais, ton appli peut aussi essayer toutes les valeurs possibles de display jusqu'à en trouver une qui peut être ouverte … Donc non, ça ne protège pas grand chose non plus …

      • [^] # Re: Non

        Posté par . Évalué à 1 (+0/-0).

        Quand je parle d'interdire l'accès à l'affichage d'une application, je me suis mal exprimé, je voulais dire empêcher toute autre application d'accéder au contenu des fenêtres de cette application.

  • # appareil photo

    Posté par . Évalué à 2 (+1/-0).

    Dès lors qu'une application affiche quelque chose à l'écran, tu ne peux pas empêcher quelqu'un de le prendre en photo.

    • [^] # Re: appareil photo

      Posté par (page perso) . Évalué à 3 (+1/-0).

      Relire la question.

      Python 3 - Apprendre à programmer en Python avec PyZo et Jupyter Notebook → https://www.dunod.com/sciences-techniques/python-3

      • [^] # Re: appareil photo

        Posté par . Évalué à 3 (+2/-0).

        Tu ne peux pas empêcher quelqu’un de poser l’écran sur un scan pour faire une copie d’écran,
        je vais relire la question ==>>[]

        Merci aux personnes qui mon aidé a trouvé des solutions pour essayer d’écrire sans faute d’orthographe.

      • [^] # Re: appareil photo

        Posté par . Évalué à 1 (+0/-0).

        Relis-là toi-même.

        Pour répondre à la question autrement :

        • si l'application affiche quelque chose à l'écran, la réponse est non, il ne peut pas être rassuré.
        • si l'application n'affiche rien à l'écran, alors je crois qu'on n'est plus dans la question…
        • [^] # Re: appareil photo

          Posté par (page perso) . Évalué à 2 (+0/-0).

          Prendre en photo, potentiellement avec un appareil en face de l'ecran, n'est pas du meme niveau que faire une capture via un logiciel sur l'appareil qui affiche l'image.

          Python 3 - Apprendre à programmer en Python avec PyZo et Jupyter Notebook → https://www.dunod.com/sciences-techniques/python-3

  • # nope

    Posté par . Évalué à 2 (+0/-0).

    Comme dit plus haut, sous X11, il n'est pas possible d'empêcher la capture d'écran sur une application y ayant accès.

    Si tu n'as pas confiance dans un logiciel, et qu'il n'a pas besoin d'accéder à l'affichage graphique, tu peux lancer ce logiciel avec un autre utilisateur
    su autreUtilisateur
    commande

    si tu fais ça assure toi que tu n'as pas de forward automatique des autorisation d'usage du serveur X
    (echo $DISPLAY doit renvoyer rien, et le unset est insuffisant, il vaut mieux faire un rm ~/.Xauthority pour autreUtilisateur, ou ne pas forwarder les autorisations )

    Il ne faut pas décorner les boeufs avant d'avoir semé le vent

    • [^] # Re: nope

      Posté par . Évalué à 4 (+3/-0).

      Donc si je comprends bien, n'importe quel logiciel GUI en cours d'exécution, a la possibilité de faire la capture de tout l'écran sans qu'il en ait à répondre à personne ?

      Alors avec Wayland, sais-tu, savez-vous, si des mécanismes d'autorisations ont été prévu ? Quels en sont les principes ?
      Par exemple, est-il possible d'indiquer que les ressources graphiques (fenêtres) de tel processus ou groupe de processus sont accessibles ou non pour d'autres processus du système ?
      Par exemple, me serait-il possible de configurer le système, pour que par défaut, tout processus ne puisse utiliser uniquement SES ressources visuelles ?

      Quand je lance mon trousseau KeepassX je serais vachement plus serein si j'avais la certitude qu'au moment où je visualise un mot de passe généré, en clair, celui-ci n'ait pas été capturé par je ne sais quelle autre application malveillante.

      C'est moi, ou cette absence de sécurité sur les contenus visuels semble préoccuper personne ? Dit autrement, je m'inquiète pour rien ?

      PS : je vais regarder cette histoire de DRM…

      Merci à tous pour vos réponses.

      • [^] # Re: nope

        Posté par . Évalué à 4 (+2/-0).

        C'est moi, ou cette absence de sécurité sur les contenus visuels semble préoccuper personne ?

        Cela préoccupe des gens, mais peu de systèmes bloquent réellement la capture d'écran ou de zone d'écrans. Par ailleurs si tu as un processus résident qui 'regarde' ton écran, qu'en est il du clavier? Du presse papier? du disque dur? du réseau? Si tes mots de passes sont stocké sur disque, il est plus simple d'écouter le clavier lorsque tu tape ton master password; si c'est sur le réseau un processus résident de l'utilisateur peu aussi regarder sa mémoire ou le remplacer…

        Et je ne parle pas du risque d'élévation de privilège, qui même si elle est plus compliqué, peu se faire (mais nécessite une connaissance plus précise du système. )

        Il ne faut pas décorner les boeufs avant d'avoir semé le vent

        • [^] # Re: nope

          Posté par . Évalué à 1 (+0/-0).

          Tout cela semble bien exact. Et inquiétant. Le "système" semble tellement contenir de failles que je me demande si on n'est pas dans l'erreur. Ce doit être plus compliqué que ça… Car si faille il y a, alors elle est sans doute exploitées.

          • [^] # Re: nope

            Posté par . Évalué à 2 (+0/-0).

            Ce doit être plus compliqué que ça…

            • keylogger ( par exemple https://www.macrorecorder.com/ ou sous Linux yum install xev (ou dnf install xev , ou urpmi xev selon la distrib ), puis xev -id fenêtre )
            • pour le presse papier, sous windows tu as quick atlas qui te traduit le contenu du presse papier, ou office qui te conserve jusqu’à un certain nombre de copier, sous Linux klipper sous kde, fait la même chose qu'office (depuis plus longtemps ;) )
            • lecture/écriture sur disque, n'importe quelle appli le permet, suffit de modifier la conf pour s'en rendre compte ;)

            Car si faille il y a, alors elle est sans doute exploitées.

            Ce ne sont pas des failles, pas en tant que telle, normalement ce qui tourne sur ton poste est contrôlé, c'est toi qui est maitre de ce qui tourne, et avant html5, ce que permettait un navigateur était assez limité, d'où la présence de flash/java qui permettaient de faire plus, le premier étant plus limitant que le second.

            Avec l'arrivé du html5, ces deux dinosaures finiront par tomber dans l'oubli, mais la maitrise de ce qui tourne est plus compliqué, si on pouvait activer/désactive ces deux antiquités, html5, lui, n'est pas désactivable.

            Il ne faut pas décorner les boeufs avant d'avoir semé le vent

            • [^] # Re: nope

              Posté par . Évalué à 2 (+1/-0).

              Tu parles des accès disques. Les systèmes de fichiers offrent des protections pour les sécuriser.

              Pourquoi rien n'existe avec X ?

              J'ai trouvé aussi ça, qui va dans le sens de tout ce que vous dites : wayland-vs-xorg
              Un passage intéressant :

              Issues with the Xorg

              As discussed above, the design of the Xorg doesn't allow the applications to have GUI-Level isolation. This implies that if the system has multiple GUI applications running, like Word Office, any of your favourite editor, or something else, then there is no isolation among them. It is easy to log keystrokes of all processes of the same user using the command xinput.
              The command generates the log of all key-presses. Any kind of isolation is not possible, even using SELinux since any keystrokes passed to the X Server are available for any arbitrary program.

              La démonstration qui est faite dans la suite de l'article, avec xinput et sudo (mais ça marche évidemment avec tout) est saisissante, vertigineuse. xev fait aussi le job.

              Et après on nous bassine sur l'utilité de choisir de bons mots de passe, sur la performance de tel ou tel technologie de cryptage, sur l'isolation par conteneur… mais que valent tout ça quand le système est pourri à la base ?

              Il reste plusieurs solutions, que vous avez suggérées, en agissant, non pas sur la capture d'informations périphériques E/S, mais en agissant sur la capacité que peut avoir une application à communiquer avec le monde extérieur "malveillant" partant du principe, maintenant, qu'elle a accès à tout, en tout cas à l'essentiel :
              - se déconnecter du monde
              - isoler du réseau toutes les applications qui ne devraient pas en avoir usage; là SELinux ou AppArmor restent encore efficaces.
              - passer en mode console, en changeant d'utilisateur (=> avec des droits restreints), pour surfer, télécharger, jouer,… :(

              Bref, c'est mission impossible !

              Heureusement, on peut quand même compter sur l'accès au code source, sur les très mauvaises retombées médiatiques qui frapperaient tous concepteurs d'applications malicieux s’adonnant à l'espionnage mais découverts… ;)

      • [^] # Re: nope

        Posté par (page perso) . Évalué à 2 (+1/-0). Dernière modification le 29/05/19 à 13:05.

        n'importe quel logiciel GUI en cours d'exécution, a la possibilité de faire la capture de tout l'écran sans qu'il en ait à répondre à personne ?

        Pour information, c'est également le cas pour d'autres OS connus, tel MS-Windows.

        Alors avec Wayland, sais-tu, savez-vous, si des mécanismes d'autorisations ont été prévu ? Quels en sont les principes ?

        Avec Wayland, c'est simple, c'est exactement l'inverse :

        Le protocole n'expose ni le bureau, ni les fenêtres des autres applications.
        Pour prendre une capture, il faut le demander explicitement en passant par l'interface D-Bus dédiée du compositeur (p.ex. org.kde.kwin.Screenshot - org.kde.kwin.Screenshot) qui pourra, si besoin, demander une identification.
        L'implémentation technique dépend donc du DE utilisé (GNOME, KDE…) ; une application générique va concrètement essayer ces différentes interfaces avec un regex.

        • [^] # Re: nope

          Posté par . Évalué à 1 (+0/-0).

          Pour information, c'est également le cas pour d'autres OS connus, tel MS-Windows.

          MS-Windows n'est pas mon problème. Je laisse le SI de ma boîte se débrouiller avec ça. Chez moi, c'est Linux le problème ;)

          Avec Wayland, c'est simple, c'est exactement l'inverse…

          Super ! Bon je vais bien me rencarder sur le sujet. Même si cela semble poser des problèmes au fonctionnement de Steam… Tiens donc…
          Anecdote au passage : je fais tourner Steam dans un conteneur Lxc. Dans ce conteneur j'avais également Firefox installé. Saviez-vous que celui-ci démarre en mode "Remote" par défaut ? Cela donne accès à tout ce qui est vu de processus Firefox parent, celui là même qui est lancé depuis la machine hôte (en dehors du conteneur). Ben voyons ! C'est open bar !

          Merci à tous pour les infos.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.