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 ted (site web personnel) . Évalué à 4.
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 Sytoka Modon (site web personnel) . Évalué à 2. Dernière modification le 21 mai 2019 à 08:41.
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 Renault (site web personnel) . Évalué à 5.
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 ninis666 . Évalué à 1. Dernière modification le 21 mai 2019 à 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 minitchoup . Évalué à 1.
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.
[^] # Re: Non
Posté par ted (site web personnel) . Évalué à 2.
En utilisant des DRM?
https://fr.wikipedia.org/wiki/High-bandwidth_Digital_Content_Protection
Un LUG en Lorraine : https://enunclic-cappel.fr
[^] # Re: Non
Posté par arnaudus . Évalué à 2.
Ça marche, ce truc? Je veux dire, je ne doute pas que ça empêche réellement d'afficher quoi que ce soit même quand on a tout acheté légalement, mais je me demande si ça empêche vraiment quelqu'un de motivé d'afficher un truc pour lequel il n'aurait pas le droit?
# appareil photo
Posté par goeb . Évalué à 1.
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 lolop (site web personnel) . Évalué à 3.
Relire la question.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: appareil photo
Posté par hitmanu . Évalué à 3.
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 goeb . Évalué à 0.
Relis-là toi-même.
Pour répondre à la question autrement :
[^] # Re: appareil photo
Posté par lolop (site web personnel) . Évalué à 2.
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 dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
# nope
Posté par fearan . Évalué à 2.
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 minitchoup . Évalué à 5.
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 fearan . Évalué à 4.
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 minitchoup . Évalué à 1.
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 fearan . Évalué à 2.
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 minitchoup . Évalué à 3.
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 :
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 Tarnyko (site web personnel) . Évalué à 3. Dernière modification le 29 mai 2019 à 13:05.
Pour information, c'est également le cas pour d'autres OS connus, tel MS-Windows.
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 minitchoup . Évalué à 2.
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 ;)
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.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.