Merci de brancher ton cerveau la prochaine fois que tu écris un commentaire. Je me fatigue à expliquer les problématiques de sécurité qui entourent le fait de capturer les informations graphiques produites par une application à son insu, et toi tu me matraques avec des conclusions hâtives sur une citation sortie de son contexte. J'ai réfléchi à la question, il y a de vraies problématiques intéressantes qui demandent de la réflexion, j'aimerais que tu fasses un effort pour comprendre ce que je dis avant de tirer dessus au bazooka.
Dire qu'une application sans privilège n'a pas le droit de prendre un screenshot n'a pas, en soit, les effets négatifs des DRMs (ou alors l'interdiction pour les process userspace d'accéder à la mémoire du kernel est aussi un DRM dans ton esprit ?). Dans tous les systèmes de sécurité il y a plusieurs niveaux de privilège et il faut aller vers un niveau plus élevé pour avoir certains droits. Là on est juste en train de dire "la capture du rendu graphique d'une appli étant sensible du point de vue de la sécurité, il faut pouvoir interdire certains niveaux bas de privilèges de le faire". Évidemment ça veut dire qu'on envisage aussi un niveau de privilège plus élevé qui a ces droits; qui est dans ce niveau dépend de la politique de sécurité (ça peut être seulement le processus dont on veut prendre le screenshot, ou alors seulement le window manager (solution mentionnée dans l'article LWN), ou alors toutes les applis à tel niveau de droit, etc.).
Le problème des DRMs n'est pas de faire une distinction entre qui a certain droits et qui ne l'a pas (empêcher le compte SSH anonyme sans droits sur ta machine de lire ta collection de films, ce n'est pas mettre un DRM). Le problème est quand une entreprise grande ou riche ou puissant force l'utilisateur à ne pas avoir accès à ce niveau de droit plus élevé, en le sortant de son contrôle et en le donnant seulement à certains programmes propriétaires fournis par la boîte et sur lesquels il n'a aucun droit.
On peut créer des frameworks de sécurité plus fins sans restreindre les libertés des utilisateurs; c'est les gens qui essaient de te priver du droit, toi administrateur de la machine, d'avoir accès à l'ensemble des niveaux de droits qui restreignent ta liberté. Alors oui, tu pourrais dire qu'avoir le framework de sécurité en place facilite pour les grosses boîtes d'imposer les DRMs (par exemple l'interdiction du clic droit est d'autant plus facile dans un navigateur web qui a les technos prévues pour ça, et on n'est pas trop pressé d'avoir les fonctionnalités de boot sécurisé vu les risques que les vendeurs s'en servent pour bloquer certains OS). Mais il rend aussi la vie plus difficile aux attaquants qui veulent utiliser ces droits à ton insu, ce qui peut aussi avoir des conséquences graves. Je n'utilise pas su ma machine de logiciel propriétaire susceptible d'essayer de m'interdire des captures d'écran d'un contenu protégé; et je ne veux pas que ce cas de figure empêche les développeurs de mon système de me protéger des virus espions siphonant les numéros de carte bleue.
Mais tu cliques sur tout ce qui bouge sans réfléchir pour avoir besoin de ce genre de restriction [..] ?
Je fais tourner du code tiers en lequel je n'ai pas confiance en permanence, oui. J'utilise un navigateur web, des logiciels de lecture/rendu de fichiers multimédias, des utilitaires de compression, un noyau de système d'exploitation, et je suis convaincu que dans tous ces logiciels il existe des failles d'exécution de code qui permettraient à un attaquant disposant d'une faille zero-day de faire tourner le code qu'il veut sur ma machine avec mes droits utilisateurs (puisque chaque mois on trouve et corrige au moins une faille de ce genre dans un logiciel qui tourne sur ma machine).
Ces failles rendent mon système troué d'un point de vue de sécurité. Je suppose qu'il n'est pas infecté par un programme malicieux caché tournant en mode utilisateur, parce que je ne suis pas une cible particulièrement intéressante et que je n'ai pas encore entendu parler d'attaques à grande échelle visant les systèmes que j'utilise, mais c'est plus un hasard des circonstances qu'une sécurité technique. Techniquement, la "trusted code base", la quantité de code auquel je devrais faire confiance pour supposer que personne ne peux exécuter de programmes malicieux avec mes droits utilisateurs (je ne parle pas des droits root de ma machine) est gigantesque. Et la conception même du système fait que, sans une révolution du point de vue de la conception (sandboxing généralisé et ré-architecture des applications pour minimiser les privilèges requis), ça restera le cas dans le futur.
[^] # Re: noop
Posté par gasche . En réponse au journal Un article sur la conception sécurisée des serveurs graphiques (X, Wayland). Évalué à 7. Dernière modification le 02 octobre 2012 à 17:07.
Merci de brancher ton cerveau la prochaine fois que tu écris un commentaire. Je me fatigue à expliquer les problématiques de sécurité qui entourent le fait de capturer les informations graphiques produites par une application à son insu, et toi tu me matraques avec des conclusions hâtives sur une citation sortie de son contexte. J'ai réfléchi à la question, il y a de vraies problématiques intéressantes qui demandent de la réflexion, j'aimerais que tu fasses un effort pour comprendre ce que je dis avant de tirer dessus au bazooka.
Dire qu'une application sans privilège n'a pas le droit de prendre un screenshot n'a pas, en soit, les effets négatifs des DRMs (ou alors l'interdiction pour les process userspace d'accéder à la mémoire du kernel est aussi un DRM dans ton esprit ?). Dans tous les systèmes de sécurité il y a plusieurs niveaux de privilège et il faut aller vers un niveau plus élevé pour avoir certains droits. Là on est juste en train de dire "la capture du rendu graphique d'une appli étant sensible du point de vue de la sécurité, il faut pouvoir interdire certains niveaux bas de privilèges de le faire". Évidemment ça veut dire qu'on envisage aussi un niveau de privilège plus élevé qui a ces droits; qui est dans ce niveau dépend de la politique de sécurité (ça peut être seulement le processus dont on veut prendre le screenshot, ou alors seulement le window manager (solution mentionnée dans l'article LWN), ou alors toutes les applis à tel niveau de droit, etc.).
Le problème des DRMs n'est pas de faire une distinction entre qui a certain droits et qui ne l'a pas (empêcher le compte SSH anonyme sans droits sur ta machine de lire ta collection de films, ce n'est pas mettre un DRM). Le problème est quand une entreprise grande ou riche ou puissant force l'utilisateur à ne pas avoir accès à ce niveau de droit plus élevé, en le sortant de son contrôle et en le donnant seulement à certains programmes propriétaires fournis par la boîte et sur lesquels il n'a aucun droit.
On peut créer des frameworks de sécurité plus fins sans restreindre les libertés des utilisateurs; c'est les gens qui essaient de te priver du droit, toi administrateur de la machine, d'avoir accès à l'ensemble des niveaux de droits qui restreignent ta liberté. Alors oui, tu pourrais dire qu'avoir le framework de sécurité en place facilite pour les grosses boîtes d'imposer les DRMs (par exemple l'interdiction du clic droit est d'autant plus facile dans un navigateur web qui a les technos prévues pour ça, et on n'est pas trop pressé d'avoir les fonctionnalités de boot sécurisé vu les risques que les vendeurs s'en servent pour bloquer certains OS). Mais il rend aussi la vie plus difficile aux attaquants qui veulent utiliser ces droits à ton insu, ce qui peut aussi avoir des conséquences graves. Je n'utilise pas su ma machine de logiciel propriétaire susceptible d'essayer de m'interdire des captures d'écran d'un contenu protégé; et je ne veux pas que ce cas de figure empêche les développeurs de mon système de me protéger des virus espions siphonant les numéros de carte bleue.
Je fais tourner du code tiers en lequel je n'ai pas confiance en permanence, oui. J'utilise un navigateur web, des logiciels de lecture/rendu de fichiers multimédias, des utilitaires de compression, un noyau de système d'exploitation, et je suis convaincu que dans tous ces logiciels il existe des failles d'exécution de code qui permettraient à un attaquant disposant d'une faille zero-day de faire tourner le code qu'il veut sur ma machine avec mes droits utilisateurs (puisque chaque mois on trouve et corrige au moins une faille de ce genre dans un logiciel qui tourne sur ma machine).
Ces failles rendent mon système troué d'un point de vue de sécurité. Je suppose qu'il n'est pas infecté par un programme malicieux caché tournant en mode utilisateur, parce que je ne suis pas une cible particulièrement intéressante et que je n'ai pas encore entendu parler d'attaques à grande échelle visant les systèmes que j'utilise, mais c'est plus un hasard des circonstances qu'une sécurité technique. Techniquement, la "trusted code base", la quantité de code auquel je devrais faire confiance pour supposer que personne ne peux exécuter de programmes malicieux avec mes droits utilisateurs (je ne parle pas des droits root de ma machine) est gigantesque. Et la conception même du système fait que, sans une révolution du point de vue de la conception (sandboxing généralisé et ré-architecture des applications pour minimiser les privilèges requis), ça restera le cas dans le futur.