Journal Un article sur la conception sécurisée des serveurs graphiques (X, Wayland)

Posté par  .
Étiquettes :
26
28
sept.
2012

Dans la lignée de mon journal sur le sandboxing dans Chrome et surtout le troll sur le modèle de sécurité de l'Apple Store, je pense que les lecteurs et lectrices de LinuxFR qui aiment les questions de conception sécurisée des applications seront intéressé-e-s par cet article de Linux Weekly News:

XDC2012: Graphics Stack Security

Martin Peres and Timothée Ravier's session on day one of XDC2012 looked at security in the graphics stack. They considered user expectations around security in the graphical user interface (GUI), reviewed these expectations against the implementations in X11 and Weston (the reference compositing window manager for Wayland), and covered some other ground as well.

Il y a des questions de sécurité très techniques sous-jacentes (par exemple les risques liés à l'accès mémoire sur les cartes graphiques), mais le gros du problème est une question de conception d'application et de leur vision de la sécurité. On retrouve des problématiques très générales telles que le modèle où une application espionne une autre, les tentatives de fishing, les tentatives de compartementalisation, etc. Et ça a l'air assez compliqué de passer à un modèle tel que l'actuel où, en gros, tout est permis, à un modèle plus raisonnable, et ce sans faire râler les gens ayant des besoins spécifiques ou plomber la simplicité du logiciel.

PS: Le modèle "commercial" de LWN est de faire payer le contenu pendant une semaine après sa parution. Ici j'ai créé un "Suscriber Link" qui est une fonctionnalité très sympa permettant de donner l'accès à un article même aux non-abonnés. Si vous êtes intéressé par ce contenu, vous devriez envisager de payer un abonnement pour soutenir le travail des journalistes (qui font à mon avis de l'excellent travail)—ça commence à 3.5€ par mois, soit moins d'un café par numéro (hebdomadaire).

  • # Petite correction

    Posté par  . Évalué à 7.

    Je ne suis pas en mesure de répondre sur le fond, je n'ai pas les compétences nécessaires.

    Il me semble que c'est phishing (hameçonnage) et pas fishing (la pêche). Oui je chipote, fishing est pas mal comme terme également :)

  • # LWN et abo pour boite

    Posté par  (site web personnel) . Évalué à 3.

    Sinon vous pouvez aussi demander à votre entreprise de payer l’accès ( tout comme des gens ont des abos LinuxMag et co au bureau ).

    • [^] # Re: LWN et abo pour boite

      Posté par  (site web personnel) . Évalué à 10.

      J'avoue avoir arrêté tous mes abonnements LinuxMag car manque d'intérêt à la lecture d'une grande partie des magazines (et puis, j'ai envie d'un truc en ligne…). Par contre, je renouvelle chaque année mon abonnement à LWN car franchement, c'est vraiment bien. On sens une vraie coopération avec le développement amont. Et puis, je trouve que libéré les articles au bout de 15 jours, c'est vraiment bien.

      Je ne sais pas pourquoi LinuxMag ne libère pas tout au bout de 6 mois car franchement, j'ai rarement été relire un de mes vieux magazine…

      • [^] # Re: LWN et abo pour boite

        Posté par  . Évalué à 3.

        Tu peux maintenant acheter les anciens numéro en PDF, très utile quand tu vis a l'étranger et les anciens numéro publié sous licence créative common son aussi mis en ligne sur le site. Le choix de la licence dépendant de l'auteur.

      • [^] # Re: LWN et abo pour boite

        Posté par  (site web personnel) . Évalué à 5.

        LinuxMag laisse 3 possibilités de licences aux auteurs (http://www.unixgarden.com/index.php/devenez-auteur). La seconde permet un accès à l'article (Creative Commons BY-NC-ND) au bout de 6 mois. Avec la troisième, l'auteur reste libre de faire ce qu'il veut de son article mais ne sera pas rémunéré.

        Les articles que l'on retrouve sur UnixGarden sont probablement ceux que les auteurs ont choisis de mettre sous le type B (Creative Commons).

        On gagne moins si on publie sous la deuxième licence que la première.
        (Je tiens à préciser que je ne travaille pas pour LinuxMag mais j'ai publié deux articles chez Diamond.)

        • [^] # Re: LWN et abo pour boite

          Posté par  (site web personnel) . Évalué à 4.

          J'ai pas envie d'acheter des PDF, je préfère un abonnement à l'année qui me semble plus prendre la forme d'un soutien aux actions…

          Quand aux choix des licences. Je trouve pas que cela soit une bonne idée. Dans les revues scientifiques, il n'y a pas le droit de choisir sa licence et je trouve que les magazines de Diamond pourraient afficher une politique résolument libre ! Ensuite, si certains auteurs veulent publier ailleurs, c'est leur choix ;-) En plus, si j'ai bien compris leur site, plus ton article est libre, moins ils considèrent qu'il a de la valeur… Encore une fois, c'est un choix de leur part mais je ne le partage plus.

          • [^] # Re: LWN et abo pour boite

            Posté par  (site web personnel) . Évalué à 2.

            La formule A est la classique. La B impose à Diamond la CC au bout d'un certain temps. Mais Diamond peut décider de sortir des articles avant, et il le fait dans unixgarden qui n'a rien à voir avec les formules des auteurs.

            "La première sécurité est la liberté"

      • [^] # Re: LWN et abo pour boite

        Posté par  (site web personnel) . Évalué à 5.

        Ils donnent accès aux articles gratuitement après 7 jours, pas 15 jours. En gros, la newsletter est publiée de manière hebdomadaire, et dès qu'elle sort, les articles de la précédente deviennent en accès gratuit.

  • # noop

    Posté par  . Évalué à 1.

    "Because Wayland/Weston does not (yet) support virtual keyboards it is not (yet) possible to forge input."

    Ah ça c'est sûr.

    "Global keyboard shortcuts present a further problem."

    "Weston does not yet support screen-shot applications"

    De mieux en mieux…

    - J'ai un bug graphique sur Wayland.
    - Envoie-nous un screenshot du problème.
    - ...
    
    
    • [^] # Re: noop

      Posté par  . Évalué à 3.

      Weston does not yet support screen-shot applications

      Je crois que c'est le mot application là qui est important, mais après j'ai du mal avec la doc et Wayland/Weston..

      Il n'y a pas si longtemps j'ai découvert que j'avais fait une erreur grossière concernant Weston: je croyais que déplacer une fenetre était fait par l'application (à chaque déplacement de souris l'application reçoit un évènement et dis à Weston "déplace moi") et bien non, l'application dit à Weston quand elle reçoit un clic sur le titre "je suis en mode déplacement" et ensuite c'est Weston qui fait le boulot..
      Beaucoup mieux au niveau réactivité!

    • [^] # Re: noop

      Posté par  . Évalué à 3.

      Tu n'as pas compris :-)

      Il n'est pas possible dans le protocol Wayland pour une application de prendre un screenshot de l'ecran (ce qui pose de gros probleme de securite sous X). Par contre l'implementation du compositeur Wayland, par exemple Weston, peu tout a fait faire un screen shot de l'ecran sans probleme. D'ailleur elle peut meme te generer une video avec un format qui detecte d'emble les deltas a l'ecran.

      • [^] # Re: noop

        Posté par  . Évalué à 1.

        "ce qui pose de gros probleme de securite sous X"

        Un problème de sécurité ? Moi j'appelle ça (sans rire) une fonctionnalité.

        "Par contre l'implementation du compositeur Wayland, par exemple Weston, peu tout a fait faire un screen shot de l'ecran sans probleme."

        Et ça va servir à quoi si les applications ne peuvent pas exploiter les screenshots comme elles l'entendent ? Faut arrêter de penser que tout est un problème de sécurité, il y a plein d'applications qui peuvent prendre des screenshots et qui sont très utiles.

        • [^] # Re: noop

          Posté par  . É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.

          • [^] # Re: noop

            Posté par  . Évalué à -3. Dernière modification le 02 octobre 2012 à 16:42.

            J'ai hate que la sandbox d'apple qui limite l'accès aux fichiers sélectionnés dans une boite de dialogue arrive sur linux…

            "Par exemple tu peux autoriser les applications à dire "je refuse qu'on me screenshot","

            Des DRMs, rien que ça ! Mais tu cliques sur tout ce qui bouge sans réfléchir pour avoir besoin de ce genre de restriction qui limitera n'importe quelle appli un peu plus avancée qu'une calculatrice ?

            • [^] # Re: noop

              Posté par  . É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.

              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  . Évalué à 3.

          il y a plein d'applications qui peuvent prendre des screenshots et qui sont très utiles.

          Et il y a des applications qui cherchent a récupérer plein d'information qu'elles ne devraient pas pouvoir avoir.

          Tu peux te logger sous root et autoriser tous les droits si tu n'en as rien a faire de la sécurité, le problème c'est que quelqu'un qui lui est concerné par la sécurité ne peut pas vraiment installer une application avec X à moins d'utiliser une usine à gaz genre Qubes OS.

  • # Subscriber Link

    Posté par  (site web personnel) . Évalué à 2.

    Le modèle "commercial" de LWN est de faire payer le contenu pendant une semaine après sa parution. Ici j'ai créé un "Suscriber Link" qui est une fonctionnalité très sympa permettant de donner l'accès à un article même aux non-abonnés.

    Hum, ça me semble pas très sympa de crée un "Subscriber Link". Il suffirait d'attendre une semaine pour écrire ton journal, ou bien d'inviter à les lecteurs à s'abonner.

    Bon, je m'en fous un peu, je paie mon abonnement avec mes propres deniers ;-)

    • [^] # Re: Subscriber Link

      Posté par  . Évalué à 2.

      Justement les "suscriber links" sont une bonne façon de faire connaître le modèle commercial de LWN et d'inciter des gens à payer un abonnement pour faire vivre les journalistes. Si j'attends une semaine pour faire un journal, moins facile de botter en touche pour dire "… et envisagez de vous abonner", et si j'écris un journal "si vous payez tant vous pourrez lire un article très intéressant" personne ne lira l'article.

      Je t'invite à lire la FAQ LWN.net sur les Suscriber Links:

      Where is it appropriate to post a subscriber link?

      Almost anywhere. Private mail, messages to project mailing lists, and blog entries are all appropriate. As long as people do not use subscriber links as a way to defeat our attempts to gain subscribers, we are happy to see them shared.

      Au bout du bout, c'est à chacun de faire ses choix sur la façon dont les Suscriber Links peuvent être utilisés (évidemment ils sont là pour laisser des gens non-abonnés lire les articles payants, donc c'est que la pratique n'est pas uniformément bannie). Je juge que cet usage là est raisonnable. J'ai déjà posté des liens semblables et eu des retours positif de la part de l'équipe LWN.net, qui confirme qu'ils sont là aussi pour ça.

  • # argument de sécurité contre WebGL

    Posté par  (site web personnel) . Évalué à 1.

    Est-ce lié à l'opposition de Microsoft d'intégrer WebGL dans IE pour raisons de sécurité ? Je me demande comment les principaux OS règlent la question

Suivre le flux des commentaires

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