Il y a parfois un compromis à faire entre les "fonctionnalités" et la sécurité. Donner à n'importe quelle application le droit de prendre un screenshot de tout l'écran est aberrant d'un point de vue sécurité, si tu pars du principe que l'utilisateur va exécuter du code tiers dans lequel il n'a pas forcément confiance (sujet de la discussion sur les modèles de sécurité des applications mobiles, par exemple). Imagine par exemple un démon qui est lancé par l'utilisateur plus ou moins à son insu, qui périodiquement prend des captures de l'écran, dans le but de repérer les pages webs correspondant à des paiement en ligne (c'est facile, on cherche les icônes visa / carte bleue) et utilisant de la reconnaissance de caractères pour extraire ton numéro de carte bleue.
Ça s'appelle une "attaque par canaux cachés" : même si tu as sécurisé ton navigateur web en le faisant tourner avec des privilèges différent, en chiffrant les fichiers qu'il stocke en mémoire et en empêchant les programmes non-privilégier de prétendre le débugguer, tu te retrouves à avoir une fuite d'information potentiellement critique parce que n'importe qui peut prendre des screenshot de l'écran. C'est l'équivalent visuel d'un keylogger.
L'important est de trouver un moyen de concilier cette "fonctionnalité" et la sécurité, en la modifiant pour éviter ces fuites d'information indésirables. Par exemple tu peux autoriser les applications à dire "je refuse qu'on me screenshot", et le compositeur va envoyer une image vide à la place qu'elles occupent à l'écran. Ou alors tu peux autoriser chaque application à prendre un screenshot de sa propre zone mémoire, mettre en place un système de tokens de sécurité que les applications peuvent partager (une application screenshot ne verra la zone graphique que des applications dont elle a fourni le token, donc c'est un design général qui subsume les deux précédents), etc… Il y a de nombreux moyens de raffiner cette fonctionnalité pour la sécuriser, mais ça demande de la réflexion et du travail sur les applications; oui, c'est moins simple que le "tout est permis" existant, mais l'existant est une bouse du point de vue sécurité, et c'est quand même quelque chose d'assez critique.
Ce genre de compromis délicats entre fonctionnalités et sécurité est justement le sujet de l'article et des discussions précédentes que j'ai cité-e-s dans mon billet.
Je suis pour ma part qu'on peut concilier sécurité et utilisabilité, et même que la "bonne conception" pour la sécurité coïncide avec la "bonne conception" pour l'interface utilisateur et la sémantique, et qu'on a donc tout à gagner en poussant cet aspect.
[^] # 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.
Il y a parfois un compromis à faire entre les "fonctionnalités" et la sécurité. Donner à n'importe quelle application le droit de prendre un screenshot de tout l'écran est aberrant d'un point de vue sécurité, si tu pars du principe que l'utilisateur va exécuter du code tiers dans lequel il n'a pas forcément confiance (sujet de la discussion sur les modèles de sécurité des applications mobiles, par exemple). Imagine par exemple un démon qui est lancé par l'utilisateur plus ou moins à son insu, qui périodiquement prend des captures de l'écran, dans le but de repérer les pages webs correspondant à des paiement en ligne (c'est facile, on cherche les icônes visa / carte bleue) et utilisant de la reconnaissance de caractères pour extraire ton numéro de carte bleue.
Ça s'appelle une "attaque par canaux cachés" : même si tu as sécurisé ton navigateur web en le faisant tourner avec des privilèges différent, en chiffrant les fichiers qu'il stocke en mémoire et en empêchant les programmes non-privilégier de prétendre le débugguer, tu te retrouves à avoir une fuite d'information potentiellement critique parce que n'importe qui peut prendre des screenshot de l'écran. C'est l'équivalent visuel d'un keylogger.
L'important est de trouver un moyen de concilier cette "fonctionnalité" et la sécurité, en la modifiant pour éviter ces fuites d'information indésirables. Par exemple tu peux autoriser les applications à dire "je refuse qu'on me screenshot", et le compositeur va envoyer une image vide à la place qu'elles occupent à l'écran. Ou alors tu peux autoriser chaque application à prendre un screenshot de sa propre zone mémoire, mettre en place un système de tokens de sécurité que les applications peuvent partager (une application screenshot ne verra la zone graphique que des applications dont elle a fourni le token, donc c'est un design général qui subsume les deux précédents), etc… Il y a de nombreux moyens de raffiner cette fonctionnalité pour la sécuriser, mais ça demande de la réflexion et du travail sur les applications; oui, c'est moins simple que le "tout est permis" existant, mais l'existant est une bouse du point de vue sécurité, et c'est quand même quelque chose d'assez critique.
Ce genre de compromis délicats entre fonctionnalités et sécurité est justement le sujet de l'article et des discussions précédentes que j'ai cité-e-s dans mon billet.
Je suis pour ma part qu'on peut concilier sécurité et utilisabilité, et même que la "bonne conception" pour la sécurité coïncide avec la "bonne conception" pour l'interface utilisateur et la sémantique, et qu'on a donc tout à gagner en poussant cet aspect.