Journal Compositeurs Wayland - Pourquoi et comment gérer les clients privilégiés?

50
19
fév.
2014

Après de multiples heures de discussion sur la liste de diffusion de Wayland et avec des amis ayant la même formation que moi en sécurité système, j'ai décidé de compiler en un article un maximum d'observations et de propositions sur comment gérer les problèmes de sécurité que posent certaines fonctionnalités classiques des serveurs graphiques. Le focus a bien évidement été mis particulièrement sur Wayland car il est actuellement en développement et que c'est le meilleur moment pour influencer l'élaboration des protocoles pour les rendre plus sécurisés dès le début :)

Ce travail fait suite à la présentation intitulée Recap, Vulnerabilities, Attacks and Discussions on the Linux Graphic Stack's Security que j'avais donné en compagnie de Timothée Ravier à la X.org Developer Conference 2012 (LWN, LinuxFR).

Voilà le résultat, un article appelé Wayland Compositors - Why and How to Handle Privileged Clients! qui j'espère va susciter quelques débats productifs dans les commentaires ;) Bonne lecture!

  • # Capture d'écran

    Posté par . Évalué à 3.

    Autant je peux comprendre qu'un niveau de sécurité est nécessaire pour le rendu à l'écran, autant je comprend moins ce qui concerne la capture.

    Est ce vraiment le rôle de la couche graphique de s'assurer qu'un programme malicieux n'est pas en train d'espionner l'écran et le clavier ?

    • [^] # Re: Capture d'écran

      Posté par . Évalué à 8.

      Comme X c'est non seulement une couche graphique mais aussi une couche d'entrées utilisateur.

      Ces deux couches forment ce qu'on pourrait regrouper comme étant l'interface homme-machine/système. C'est donc plus ou moins nécessairement lié. Surtout du point de vue de la sécurité…

      • [^] # Re: Capture d'écran

        Posté par . Évalué à 1.

        Il est évidement que ce composant doit être pensé pour la sécurité mais dans l'article le passage parlant des solutions pour la capture :

        Waiting for a user to press the key with a clear semantic before launching the associated         application (for instance, PrintScreen launching the screen-shot application)
        Prompting the user whenever an application tries to access a restricted interface
        Creating secure widgets that are drawn and managed by the compositor but can be imported in applications (UDAC)
        Any other way?
        

        Cela me semble pas du ressort de ce composant système. Autant permettre l'identification des programmes utilisant une fonctionnalité de capture est quelque chose de bénéfique pouvant servir a détecter des programmes malicieux, autant en contrôler directement l'accès me semble être un pas trop loin.

        Pour faire un parallèle avec le réseau, ce n'est pas la couche réseau qui s'occupe de savoir si le service est légitime ou non. Le parallèle n'est super car l'un est un composant du noyau, l'autre plus un serveur mais c'est pour donné un idée plus claire de ma pensée.

        • [^] # Re: Capture d'écran

          Posté par (page perso) . Évalué à 10.

          Cela me semble pas du ressort de ce composant système. Autant permettre l'identification des programmes utilisant une fonctionnalité de capture est quelque chose de bénéfique pouvant servir a détecter des programmes malicieux, autant en contrôler directement l'accès me semble être un pas trop loin.

          Si un service ne fait pas de contrôle d'accès avant de fournir son service, qui doit le faire? Un "parefeu" système? Faut pas confondre un hack avec une solution.

          Il y a un seul process sur la machine qui a autant de vision sur la volonté de l'utilisateur, ne pas faire le contrôle d'accès dans ce process (qui est en plus le producteur du service), c'est se tirer dans les pieds à coup de bazooka!

          • [^] # Re: Capture d'écran

            Posté par . Évalué à 3.

            Je suis d'accord sur le fait qu'il y a un problème et que c'est une solution. Je me demande juste si c'est la meilleure façon de faire.

            Ce qu'il me semble important c'est que ce processus donne des outils pour détecter les utilisations avec risque pour la sécurité.

            Tout ce qui est keylogger et capture d'écran malicieuse, je le rentre dans la même catégorie que les programme ouvrant une connexion non-désirée vers un serveur distant offrant un accès à mon ordinateur qui le veut. Je serais plus a l'aise avec une solution détectant ce genre d'utilisation (type 'anti-virus') qui repose sur des informations fourni par les processus producteurs de services (graphique/input/réseau/etc).

            Pour information, je suis un vrai néophyte dans ces domaines (server graphique/sécurité) donc c'est un point de vue naïf que j'ai. Mes remarques sont faite dans le but de m'instruire, non de critiquer gratuitement le travail de réflexion que vous avez fait ;)

            • [^] # Re: Capture d'écran

              Posté par (page perso) . Évalué à 10.

              Je suis d'accord sur le fait qu'il y a un problème et que c'est une solution. Je me demande juste si c'est la meilleure façon de faire.

              Je suis convaincu que c'est le seul choix qui ait un sens.

              Ce qu'il me semble important c'est que ce processus donne des outils pour détecter les utilisations avec risque pour la sécurité.

              Détecter, c'est bien. Prévenir, c'est mieux. Comme je le disais plus haut, les anti virus et pare feu sont plus des rustines que des solutions de sécurité. Bon, c'est surtout les AV qui sont par natures pratiquement inutile, les pare feu sont très justifiables aussi dans pas mal de cas.

              Ce que je veux dire, c'est que c'est au programme qui exporte un service de faire le contrôle d'accès, pas à quiconque d'autre. Oui, ça demande à réfléchir quand on fait le service mais bon, c'est la vie.

              Pour information, je suis un vrai néophyte dans ces domaines (server graphique/sécurité) donc c'est un point de vue naïf que j'ai. Mes remarques sont faite dans le but de m'instruire, non de critiquer gratuitement le travail de réflexion que vous avez fait ;)

              Fait une analogie à une organisation qui fourni un service, genre demande de passeport. Ce que tu proposes, c'est qu'on donne un passeport à chaque personne qui le demande, sans contrôle d'identité, puis d'avoir la douane juste derrière pour vérifier. Si tout va bien, la personne arrivera pas à faire sortir le passeport par une voie cachée, mais rien n'est garanti à partir du moment où tu le lui donne. Si tu fais les vérifications avant de lui donner, il y aura accès uniquement si il y a droit et y'a moins de risques de fraude.

              • [^] # Re: Capture d'écran

                Posté par . Évalué à 2.

                Effectivement il faut prévenir. Mais je ne suis pas sur que ça justifie que wayland doit être le module décisionnaire la dedans.

                Je prend un passage de l'article :

                Most users run their computers without Mandatory Access Control (MAC), it is thus important to provide the best security possible by default. The POSIX security backend shouldn’t depend on any decision engine or MAC system (such as SELinux, Tomoyo, AppArmor, …) and should be easy to configure.
                

                Est que l'on est pas en train de dire que comme les utilisateurs n'installent pas tous un système de sécurité avancé alors on en impose un dans le processus pour leur propre bien ?

                Question un peu à part : l'article indique comme façon de gérer la sécurité de se baser sur le "fullpath" du binaire. Comment cela se passerait-il pour des langages interprétés ?

                • [^] # Re: Capture d'écran

                  Posté par (page perso) . Évalué à 3.

                  Effectivement il faut prévenir. Mais je ne suis pas sur que ça justifie que wayland doit être le module décisionnaire la dedans.

                  Oh, tu as mal lu la fin de l'article. L'idée, c'est de déléguer la prise de décision à une bibliothèque qui permettra d'abstraire le moteur de décision. Comme ça, tous les compositeurs devront juste demander à la bibliothèque quelle décision prendre ce qui devrait pas impacter les compositeurs en terme de volume de code. De plus, si un nouveau modèle de prise de décision apparaît, pas besoin de modifier tous les compositeurs ;)

                  Est que l'on est pas en train de dire que comme les utilisateurs n'installent pas tous un système de sécurité avancé alors on en impose un dans le processus pour leur propre bien ?

                  Non. Ces systèmes avancés couvrent d'autres choses et complètent la sécurité nécessaire dans Wayland (notamment pour contrer les attaques proposées par pasBillpasGate). Aucun de ces outils ne sait contrôler les actions utilisateur directement, c'est au compositeur de remonter ces informations.

                  • [^] # Re: Capture d'écran

                    Posté par . Évalué à 2.

                    Ok, mon incompréhension vient peut être tout simplement de la, l'article étant long j'ai du mal comprendre une partie.

                    Pour mieux comprendre, dans l'article il est proposé des fichiers de configuration pour le module de sécurité (comme /etc/wayland/…). Qui se chargerait d'évaluer et interpréter ces fichiers ?

                    • [^] # Re: Capture d'écran

                      Posté par (page perso) . Évalué à 3.

                      Ok, mon incompréhension vient peut être tout simplement de la, l'article étant long j'ai du mal comprendre une partie.

                      C'est compréhensible, en effet ;)

                      Pour mieux comprendre, dans l'article il est proposé des fichiers de configuration pour le module de sécurité (comme /etc/wayland/…). Qui se chargerait d'évaluer et interpréter ces fichiers ?

                      Ce cas là, c'est quand on utilise aucun moteur de décision externe. Du coup, ça sera simplement un .so référencé par la bibliothèque d'abstraction de prise de décision.

                      • [^] # Re: Capture d'écran

                        Posté par . Évalué à 1.

                        Ok ! Ça commence à devenir plus clair dans ma tête. C'est de la que venait mon commentaire : "Est que l'on est pas en train de dire que comme les utilisateurs n'installent pas tous un système de sécurité avancé alors on en impose un dans le processus pour leur propre bien".

                        Je pensais que c'était un module forcé par défaut dans le système alors que ça serait plus un exemple d'implémentation.

                        • [^] # Re: Capture d'écran

                          Posté par (page perso) . Évalué à 6.

                          Ok ! Ça commence à devenir plus clair dans ma tête. C'est de la que venait mon commentaire : "Est que l'on est pas en train de dire que comme les utilisateurs n'installent pas tous un système de sécurité avancé alors on en impose un dans le processus pour leur propre bien".

                          Non, tu avais raison, ce sera la politique par défaut des compositeurs Wayland et elle sera paramétrable automatiquement par les packageurs des distros.

                          Je pensais que c'était un module forcé par défaut dans le système alors que ça serait plus un exemple d'implémentation.

                          Non, c'est pas une politique d'exemple non et oui, ça sera vraisemblablement forcé sur le système de la même façon que X a sa/ses politique(s) de sécurité forcée. Tu devrais être content car la politique que je propose est bien plus configurable que celle de X qui est compilée dans le binaire et qui n'est pas paramétrable.

                          La dernière chose que je veux, c'est une politique open bar par défaut pour les utilisateurs qui ne veulent pas accepter qu'ils sont différents des autres et qui ne veulent pas prendre 2 secondes pour cliquer sur "j'accepte" ou 2 minutes pour "écrire la politique de 5 lignes" si la distro ne lui a pas fourni.

                          Je prend la sécurité du serveur graphique très au sérieux car c'est le point le plus délicat pour sécuriser un OS avec interaction utilisateur. Pour te donner une petite idée, j'ai commencé à bosser sur ce sujet il y a 5 ans, avec une équipe de recherche à l'ENSI de Bourges et ça a donné ces résultats (PIGA-SYSTRANS et PIGA-OS).

                          • [^] # Re: Capture d'écran

                            Posté par . Évalué à 1.

                            Je suis content de voir des réflexion et des solutions pour la problématique de la sécurité du serveur graphique. Ce qui est expliqué sur l'amélioration de la sécurité avec DMA_BUF par exemple a l'air vraiment cool (je ne maitrise pas du tout ces notions, mais l'article explique suffisamment clairement pour comprendre). Difficile de trouver à redire.

                            Publier un API pour gérer finement la sécurité est aussi une très bonne chose. Le point qui me gène vient donc plus de l'obligation d'avoir l'implémentation par défaut.
                            Que ce passerait t'il si on implémente un deuxième module décisionnaire, qui aurait le dernier mot le nouveau module ou le module intégré au système ?

                            Qu'une implémentation existe c'est une très bonne chose, mais forcer son usage j'ai du mal. Ce que je veux bien admettre c'est que je chipote pour les quelques utilisateurs qui se font tout à la main et que les distributions feront quoi qu'il arrive une dépendance entre wayland et cette implémentation (et je ne me place pas dans ces utilisateurs, n'étant pas expert je me fis aux recommandations quant à la configuration de mon système sans chercher à faire le malin).

              • [^] # Re: Capture d'écran

                Posté par . Évalué à 2.

                Ce que je veux dire, c'est que c'est au programme qui exporte un service de faire le contrôle d'accès,

                Surement pas!!!! Si le programme refuse la capture d'écran je serai bien emmerdé lorsque moi je voudrai la faire. A la rigueur, c'est au serveur qui doit demander à l'utilisateur (via un équivalent à l'UAC) si tel programme à le droit d'espionner tel fenêtre, mais surement pas au programme.

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

                • [^] # Re: Capture d'écran

                  Posté par (page perso) . Évalué à 1. Dernière modification le 20/02/14 à 19:34.

                  En l’occurence, ici, le programme qui exporte un service est le compositeur Wayland. Ce n’est bien sûr pas chaque application qui implémente ses propres règles de sécurité.

          • [^] # Re: Capture d'écran

            Posté par (page perso) . Évalué à 10. Dernière modification le 20/02/14 à 08:53.

            Qui ne s'est jamais tiré dans les pieds au bazooka ?
            When the distance is worth the damage!

            Edit: oh on voit pas l'URL source : http://fc01.deviantart.net/fs71/i/2012/036/f/6/rocket_jump_by_theqz-d4osret.jpg

    • [^] # Re: Capture d'écran

      Posté par . Évalué à 5.

      Hum, pourquoi commenter avant de lire l'article??

      • [^] # Re: Capture d'écran

        Posté par . Évalué à 2.

        Je lis un article décrivant des solutions de sécurité et comment mettre en place. Je m'interroge simplement si certaines de ces fonctionnalités sont vraiment du ressors de Xorg/Wayland ou plutôt d'"autre chose".

        L'article donne des exemples prouvant qu'un risque existe, mais pas qu'implémenter des restrictions dans Wayland soit la seule solution.

        Pour faire un autre parallèle, je ne veux pas que le gestionnaire du système de fichiers surveille les applications qui feraient une modification frauduleuse de mon fichier .ssh/know_hosts en vue de me cacher une attaque. C'est pourtant un risque de sécurité, mais c'est de "mon" ressort de vérifier ou faire surveiller par une routine quelconque que je n'ai pas de programme non désiré sur mon système.

        • [^] # Re: Capture d'écran

          Posté par . Évalué à 6.

          Pour faire un autre parallèle, je ne veux pas que le gestionnaire du système de fichiers surveille les applications qui feraient une modification frauduleuse de mon fichier .ssh/know_hosts en vue de me cacher une attaque. C'est pourtant un risque de sécurité, mais c'est de "mon" ressort de vérifier ou faire surveiller par une routine quelconque que je n'ai pas de programme non désiré sur mon système.

          Un système de fichiers intégrant une surveillance automatique de l'horodatage et l'intégrité des fichiers est quelque chose d'envisageable qui pourrait avoir certainement une utilité et qui a peut-être déjà été tenté :)

          • [^] # Re: Capture d'écran

            Posté par . Évalué à 2.

            Je n'en ai jamais entendu parlé, mais effectivement il n'est pas dit que ça n'a jamais été envisagé ;)

            Si jamais quelqu'un trouve une source évoquant le sujet, je serais assez curieux de lire ça !

            • [^] # Re: Capture d'écran

              Posté par . Évalué à 1.

              De l'audit de fichier ? Ca existe depuis la prehistoire…

              http://support.microsoft.com/kb/310399

              • [^] # Re: Capture d'écran

                Posté par . Évalué à 1.

                Oui effectivement, merci !

                Le fait est que l'on est dans la surveillance, on intègre pas un système bloquant l'accès au fichier à certaines applications directement dans le système de fichier.

                Mais bon, mon analogie entre le service proposé par le serveur graphique et celui par le système de fichier était visiblement un peu bancale

        • [^] # Re: Capture d'écran

          Posté par . Évalué à 6.

          Le soucis c'est que tu compares avec ce qui t'arrange pour dire que cela ne te conviens pas.

          Je pourrais aussi dire que je souhaites un système qui contrôle l'accès à mes fichiers en fonction de l'utilisateur et des droits du fichier.

          Lequel des deux énoncés est plus proche du cas compositeur wayland ?

          Moi je trouve l'article très intéressant.
          Et je trouve cela correcte qu'à partir du moment où le rendu à l'écran soit du ressort du compositeur, et que l'on décide d'en restrindre l'accès à l'application, et bien que cette restriction soit complètement gerée par le compositeur.

          Pour l'analogie avec l'accès à un fichier, je dirais aussi que les cas d'utilisation sont très différents !
          L'utilisation de ton système étant très dépendante de l'accès à des fichiers, il est difficile d'en restreindre l'accès arbitrairement sans remettre en cause énormément de choses.
          Pourtant, c'est bien ce qui est en train de se faire avec les exécutions dans des bac à sable sur les systèmes mobiles entre autre qui n'ont pas ce lourd historique applicatif à gerer !
          Et du coup ça n'est peut-être pas une si mauvaise idée que cela, juste qu'elle est vraiment trop difficilement applicable à l'existant.
          Mais vu que wayland et ses compositeur sont nouveaux (rien à voir avec le driver nvidia…), autant essayer d'améliorer les choses là où c'est possible sans remettre en cause trop d'applications et de cas d'utilisation existants.

          • [^] # Re: Capture d'écran

            Posté par . Évalué à 1. Dernière modification le 20/02/14 à 16:39.

            Juste deux petites précisions : je trouve aussi l'article très intéressant et je ne dis pas que ça me conviens pas ;)

            Si je me porte en faux c'est plus parce que par intuition je ne n'aurais pas fait ça et que je voudrais comprendre pourquoi la solution de l'article est mieux. Il est sur qu'entre un auteur expert dans la couche graphique et moi-même n'ayant pas tout à fait une formation en informatique (je fais de l'électronique) il y a peu de chance que j'ai raison et j'en suis bien conscient :p

            De plus entre ce commentaire et mon dernier, j'ai un peu mieux compris et la discution a un peu dévié par rapport à ma question initiale

    • [^] # Re: Capture d'écran

      Posté par (page perso) . Évalué à 2.

      Je pense notamment a l'exemple que tu donnes d'une appli qui lance Firefox et fait un redirect. L'appli lanceuse n'a pas besoin de passer par Wayland ou X pour voir ce qu'il se passe, il lui suffit de charger une librairie dans Firefox qui se chargera de tout faire de l'interieur meme du processus.

      En fait, justement, l'application ne fait pas de redirect, mais modifie seulement l'affichage de la barre d'adresse. C'est donc bien un problème d'affichage et non pas un problème de protocole réseau ou HTTP.

      Après, elle peut évidemment utiliser d'autres failles, mais je pense qu'il est bien d'en éviter au maximum surtout que l'on a rarement l'occasion de recommencer de zéro un protocole graphique et donc de pouvoir traiter directement ces failles sans faire de hacks douteux.

  • # Problematique...

    Posté par . Évalué à 3.

    Le probleme avec tout ca, c'est que tant que j'ai la possibilite d'injecter du code dans un processus, je pourrais lire ses entrees clavier/souris et voir ce qu'il affiche.

    Ajouter tous ces trucs a Wayland c'est sympa, mais tant qu'il n'y a pas d'isolation complete de processus a processus, ca revient a fermer une fenetre dans une maison qui a 5 fenetres ouvertes…

    Je pense notamment a l'exemple que tu donnes d'une appli qui lance Firefox et fait un redirect. L'appli lanceuse n'a pas besoin de passer par Wayland ou X pour voir ce qu'il se passe, il lui suffit de charger une librairie dans Firefox qui se chargera de tout faire de l'interieur meme du processus.

    • [^] # Re: Problematique...

      Posté par . Évalué à 6.

      Le probleme avec tout ca, c'est que tant que j'ai la possibilite d'injecter du code dans un processus, je pourrais lire ses entrees clavier/souris et voir ce qu'il affiche.

      Sauf que là actuellement, si j'ai bien compris, c'est qu'il est possible d'utiliser du code légitime pour récupérer de l'information d'un processus à l'autre, sans injection. Donc bon, tu as l'air de dire que Wayland n'apporte absolument rien par rapport à X…

      • [^] # Re: Problematique...

        Posté par . Évalué à 7. Dernière modification le 20/02/14 à 00:17.

        Je ne dis pas que Wayland n'apporte rien, je dis que les objectifs cites dans ce papier sont un peu illusoire car leur realisation depend de bcp plus que Wayland.

        Qu'on se comprenne, l'objectif est louable et serrer les boulons est tres bien, mais il faut etre realiste quand a ce qui est possible. Bloquer les methodes courantes c'est bien, mais ca ne changera absolument rien si je peux toujours mettre ma librairie dans LD_PRELOAD et lancer Firefox, injecter mon code a travers ptrace, …

        L'IPC a travers X / Wayland c'est juste un type d'IPC, il faut une isolation de tous les IPCs pour que ce soit viable. Bref, une sandbox quoi…

        • [^] # Re: Problematique...

          Posté par . Évalué à 3.

          L'IPC a travers X / Wayland c'est juste un type d'IPC, il faut une isolation de tous les IPCs pour que ce soit viable.

          Donc soit il faut le faire pour tout soit pour rien ?

          Le sandboxing sous linux me semble s'orienter vers un ensemble de dispositif plutôt que vers un seul et pour rendre l'ensemble un peu facilement utilisable on utilise des outils qui simplifie le travail. Finalement on appel ça lxc ou libvirt.

          Tu parle de fenêtre plus haut, à mon avis c'est pas parce que les murs sont mal isolés qu'il faut bâcler le montage de la fenêtre ou la laisser ouverte.

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: Problematique...

            Posté par . Évalué à 4.

            Du tout, comme je l'ai dit, serrer les boulons est louable. Mais il faut rester realiste sur le resultat final tant que le reste de la maison reste ouvert. Wayland ne pourra jamais clamer qu'il amene une isolation entre processus tant que les autres IPCs ne sont pas isoles.

            • [^] # Re: Problematique...

              Posté par . Évalué à 10.

              Je dois avoir raté quelque chose. Le document parle de la sécurité du protocole. Il ne vient pas promettre la lune. Qu'est ce qui te fait dire que l'auteur rêve ?

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: Problematique...

          Posté par (page perso) . Évalué à 10.

          Je ne dis pas que Wayland n'apporte rien, je dis que les objectifs cites dans ce papier sont un peu illusoire car leur realisation depend de bcp plus que Wayland.

          Tu as totalement raison, mais je ne parle ici QUE de la sécurité liée à Wayland. Tant qu'on pourra injected du code dans les applis à coup de LD_PRELOAD, la sécurité des desktops sera nulle. Cependant, avec du contrôle d'accès mandataire, tu peux limiter un processus au chargement de bibliothèques depuis /usr/lib/. Ça suffirait pour fixer la majorité des cas. Il reste ensuite le fait que tous les fichiers sont visibles par tous les processes et il faudra un daemon brocker pour résoudre ce problème là et on sera bon.

          Qu'on se comprenne, l'objectif est louable et serrer les boulons est tres bien, mais il faut etre realiste quand a ce qui est possible. Bloquer les methodes courantes c'est bien, mais ca ne changera absolument rien si je peux toujours mettre ma librairie dans LD_PRELOAD et lancer Firefox, injecter mon code a travers ptrace, …

          Comme dit un autre commentaire, on ne fait que fermer une fenêtre, les autres sont toujours ouvertes par défaut … pour l'instant (le MAC suffit à les résoudre). Ne rien faire, c'est recommencer les conneries de X et c'est pas acceptable. Un pas après l'autre, on peut pas révolutionner le desktop tout d'un coup.

    • [^] # Re: Problematique...

      Posté par . Évalué à 3.

      Donc tu es en train de dire que puisqu'il y a autre problème, ça ne sert à rien de corriger les erreurs de conception d'X11?

      Sauf que je te ferais remarquer qu'on ne peut pas corriger X11 sans casser les applications existantes, donc il FAUT profiter de la rupture de compatibilité de Wayland pour corriger les erreurs de conceptions d'X, autrement le jour où on arrive a corriger les autres problèmes, on a les mêmes problème qu'X.

      Soit-dit en passant les concepteurs de Wayland poussent pour une gestion des décorations de la fenêtre coté client, ce qui est potentiellement un trou de sécurité: une application peut plus facilement essayer de se faire passer pour une autre quand elle a la maitrise totale de la fenêtre; bon ceci dit Wayland n'est pas incompatible avec une gestion des décorations coté serveur d'affichage, alors ça n'est pas un vrai problème juste un n-ième choix (difficile) à faire entre la sécurité et les performance..

      • [^] # Re: Problematique...

        Posté par . Évalué à 3.

        Que la décoration des fenêtres soit coté client ou serveur je ne voit pas ce que ça change. Dans les 2 cas il me semble aussi simple pour une application de se faire passer par une autre.Je vois pas comment les décorations coté serveur empêcherait ça. Pour ma culture personnelle je suis preneur de plus de détail …

    • [^] # Re: Problematique...

      Posté par (page perso) . Évalué à 8.

      L'injection de bibliothèque peut se prévenir avec SELinux il me semble. Il y a dont déjà la couche qui permet d'éviter ce genre de problème.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: Problematique...

      Posté par (page perso) . Évalué à 1.

      Je pense notamment a l'exemple que tu donnes d'une appli qui lance Firefox et fait un redirect. L'appli lanceuse n'a pas besoin de passer par Wayland ou X pour voir ce qu'il se passe, il lui suffit de charger une librairie dans Firefox qui se chargera de tout faire de l'interieur meme du processus.

      En fait, justement, l'application ne fait pas de redirect, mais modifie seulement l'affichage de la barre d'adresse. C'est donc bien un problème d'affichage et non pas un problème de protocole réseau ou HTTP.

      Après, elle peut évidemment utiliser d'autres failles, mais je pense qu'il est bien d'en éviter au maximum surtout que l'on a rarement l'occasion de recommencer de zéro un protocole graphique et donc de pouvoir traiter directement ces failles sans faire de hacks douteux.

      PS : désolé pour le doublon, j'avais répondu au mauvais poste –_–

  • # Et sur les autres systèmes ?

    Posté par . Évalué à 5.

    Avez-vous regardé ce qui se fait sur Windows ou MacOS par ex ?

    Je ne sais pas si c'est sécurisé chez eux, mais ils se sont peut-être déjà posé les mêmes questions.

    • [^] # Re: Et sur les autres systèmes ?

      Posté par (page perso) . Évalué à 10.

      Avez-vous regardé ce qui se fait sur Windows ou MacOS par ex ?
      Je ne sais pas si c'est sécurisé chez eux, mais ils se sont peut-être déjà posé les mêmes questions.

      C'est en effet une bonne suggestion et c'est pas super beau à voir non plus ;)

      Input

      Confidentialité

      Mac OS X

      Clavier: Ça a l'air bloqué, sauf si on active un passe droit: https://github.com/dannvix/keylogger-osx/blob/master/keylogger.c
      Souris: Pas de sécu. http://stackoverflow.com/questions/2262516/getting-global-mouse-position-in-mac-os-x

      Windows

      Clavier/Souris: J'ai pas trouvé de keylogger qui utilise la pile graphique (SetWindowsHookEx ou pilote noyau)

      Intégrité

      Mac OS X

      Clavier: À priori, c'est pas possible avec Quartz direct
      Souris: Pas de sécu: https://developer.apple.com/library/mac/documentation/GraphicsImaging/Reference/Quartz_Services_Ref/Reference/reference.html#//apple_ref/c/func/CGDisplayMoveCursorToPoint

      Windows

      Clavier/Souris: Pas d'intégrité: http://michaelsync.net/2006/07/04/sendmessage-c

      Output

      Confidentialité

      Mac OS X

      Capture d'écran possible: https://developer.apple.com/library/mac/samplecode/ScreenSnapshot/Introduction/Intro.html

      Windows

      Capture d'écran possible: http://stackoverflow.com/questions/4751750/automatically-taking-screenshots-of-program-window

      Intégrité

      Mac OS X

      Pas de modification de fenêtre possible autre que la sienne possible. Du moins, je trouve rien.

      Windows

      C'est possible, dans certains cas: http://stackoverflow.com/questions/15440710/win32-how-to-post-message-to-a-process-run-by-a-different-user-in-windows

      • [^] # Re: Et sur les autres systèmes ?

        Posté par . Évalué à 2.

        Clavier/Souris: Pas d'intégrité: http://michaelsync.net/2006/07/04/sendmessage-c

        Si, il y a UIP depuis Vista qui amene une isolation par niveaux (low/medium/high). Un processus en low IL ne peut pas envoyer de messages a des processus en medium/high --> pas d'entree souris/clavier

        • [^] # Re: Et sur les autres systèmes ?

          Posté par (page perso) . Évalué à 7.

          J'ai vu ça, oui, mais dans les faits, tu as un exemple utile à part pour empêcher qu'une appli contrôle les inputs de la fenêtre de l'UAC?

          Un programme est lancé par défaut en IL medium (si je me souviens bien) avec possibilité de le descendre (ce que fait IE, adobe reader et chrome). Du coup, un programme non privilégié classique a le droit de modifier les autres applications non privilégiées. Donc, au final, c'est maigre comme sécurité.

          • [^] # Re: Et sur les autres systèmes ?

            Posté par . Évalué à 7.

            Ben oui, mais l'objectif est bien ca : les softs qui font des trucs risques reduisent leurs privileges. C'est un compromis entre compatibilite et securite car il faut bien vivre avec l'existant.

            Si tu veux vraiment une isolation complete, tu prends le mode Metro, la l'application est totalement sandboxee(en utilisant UIPI notamment pour la partie graphique). L'avantage d'avoir un nouveau modele d'app c'est justement qu'il n'y a pas de compatibilite a gerer, on a pu mettre un mur sans rien casser.

            • [^] # Re: Et sur les autres systèmes ?

              Posté par (page perso) . Évalué à 4.

              Cool, je savais pas pour Metro!

            • [^] # Re: Et sur les autres systèmes ?

              Posté par . Évalué à 0.

              Dommage qu'il n'y ait pas d'applications Metro (quand au nombre de Windows 8 en circulation, il est ridiculement faible. Or, je ne crois pas qu'une application Metro soit compatible Windows 7).

              "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

              • [^] # Re: Et sur les autres systèmes ?

                Posté par . Évalué à -3.

                Il y a 150'000 apps Metro, dont quasiment tous les gros (Twitter, FB, Instagram, Angry Birds, etc…), faudrait penser a revenir sur terre…

                Idem pour Windows 8, 200 millions de licences en 2 ans 1/2, c'est a peu pres le nombre d'iPads vendu pendant la meme periode.

                • [^] # Re: Et sur les autres systèmes ?

                  Posté par . Évalué à 7. Dernière modification le 23/02/14 à 07:18.

                  Drinkin' the kool aid…

                  Sur tes 150,000 applis metro, combien ont ete payee par ms et ne sont plus maintenues? Je sais que c'est le cas pour nous, on a eu notre appli ecrite par ms, et on a aucune intention d'y toucher.

                  Idem pour Windows 8, 200 millions de licences en 2 ans 1/2, c'est a peu pres le nombre d'iPads vendu pendant la meme periode.

                  Dur de passer de domination totale a moins de 50% du marche, non? http://ben-evans.com/benedictevans/2014/2/12/apple-passes-microsoft
                  T'oublies aussi de preciser que les ventes de licences 8 sont en baisse par rapport a celle de windows 7 sur une period comparable (et pas qu'un peu), la ou l'ipad est en croissance constante.
                  Et dans ce domaine, ne pas croitre, c'est un peu mourir.

                  Linuxfr, le portail francais du logiciel libre et du neo nazisme.

                  • [^] # Re: Et sur les autres systèmes ?

                    Posté par . Évalué à 0.

                    Sur tes 150,000 applis metro, combien ont ete payee par ms et ne sont plus maintenues? Je sais que c'est le cas pour nous, on a eu notre appli ecrite par ms, et on a aucune intention d'y toucher.

                    Bah il y en a evidemment, et combien d'applis pourries / malware / … sur Android par exemple ?

                    Les app stores sont tous remplis de softs non maintenus et l'enorme majorite des softs dans tous les stores sont de la merde. Ce qui compte, et ce qui a fait mal a MS pendant longtemps c'etaient les 'grosses' applis genre Instagram, Twitter, Path etc… et quasiment tous ceux la sont maintenant presents, en version updatees regulierement. C'est pas encore parfait, mais quasiment tout est la maintenant.

                    Dur de passer de domination totale a moins de 50% du marche, non? http://ben-evans.com/benedictevans/2014/2/12/apple-passes-microsoft
                    T'oublies aussi de preciser que les ventes de licences 8 sont en baisse par rapport a celle de windows 7 sur une period comparable (et pas qu'un peu), la ou l'ipad est en croissance constante.

                    N'importe qui qui revait de voir des ventes similaires a Windows 7 clairement a fume. Windows 7 c'est l'OS qui a convaincu enormement de gens d'upgrader depuis XP. Ces gens la pour la plupart clairement n'allaient pas upgrader de nouveau apres 2 ans.
                    Windows 7 s'est vendu a une vitesse fulgurante, fallait pas esperer que MS fasse ca tous les 2 ans hein…
                    L'iPad qui croit, bien pour Apple, mais de nouveau, faut voir a quoi tu compares et a quoi ressemble la courbe future, je la vois pas si rose que ca pour Apple perso, contrairement a Google.

                    • [^] # Re: Et sur les autres systèmes ?

                      Posté par . Évalué à 4.

                      Bah il y en a evidemment, et combien d'applis pourries / malware / … sur Android par exemple ?

                      C'est pas trop la question. Le truc c'est que:
                      - 150k, c'est au final plutôt faible de nos jours. iOS et android ont passe le million.
                      - une certaine partie de ces 150k ont été au final paye par MS. Ca veut dire que si MS n'avait pas finance le dev a 100% de la plateforme, t'aurais un nombre bien plus bas. En clair, les developeurs ne veulent pas aller sur la plateforme, et MS est oblige de faire leur boulot a leur place pour avoir des applis sur le store. C'est pas exactement une stratégie qui est tenable sur le long terme.

                      Ce qui compte, et ce qui a fait mal a MS pendant longtemps c'etaient les 'grosses' applis genre Instagram, Twitter, Path etc… et quasiment tous ceux la sont maintenant presents, en version updatees regulierement. C'est pas encore parfait, mais quasiment tout est la maintenant.

                      Mouais, alors. Vine a 2 versions de retard sur la version ios. Twitter 6 versions de retard, et pas touche depuis novembre. Path et Instagram ont l'air a jour, mais avec un gros BETA dans le nom de l'appli. Pinterest est grave a la bourre. Evernote parait un peu a la bourre aussi.
                      La tu parles de startups qui sont plus vraiment des startups, et dont la philosophie est d'être PARTOUT. Le fait que ca prenne autant de temps pour eux de considerer la plateforme, et qu'il faille les pousser pour qu'ils y viennent est un très mauvais signe.

                      Maintenant, quid des petites startup qui montent très vite? Snapchat, par exemple, secret.ly qui monte vite. uber/lyft sont absents.
                      Alors vous avez angry birds, cool. Welcome to 2010!

                      On peut dire beaucoup de choses sur ballmer, mais il avait clairement raison avec son "developers! developers! developers!", et force est de constater qu'ils sont absents sur windows 8.

                      N'importe qui qui revait de voir des ventes similaires a Windows 7 clairement a fume.

                      Hein? MS mise tout sur une stratégie "no comprise", et on est cense voir des ventes qui baissent?

                      Ces gens la pour la plupart clairement n'allaient pas upgrader de nouveau apres 2 ans.
                      Windows 7 s'est vendu a une vitesse fulgurante, fallait pas esperer que MS fasse ca tous les 2 ans hein…

                      Pourquoi pas? Apple fait ca tous les ans depuis 7 ans. Google/Samsung font ca tous les ans depuis 3-4 ans.
                      MS a fait 2 fours monstrueux avec Surface, les pc tactiles ne se vendent pas, en clair la stratégie de MS "le meme OS pour tablette et laptop" fait un bide complet. Les consommateurs n'en veulent pas, la stratégie "no compromise" se fait revisiter a chaque update et les ventes sont mauvaises. Oui, les ventes sont mauvaises, tu pourrais potentiellement attribuer ca au marche pc qui se casse la gueule, mais quand tu prends en compte le four de surface, et des OEM comme HP qui en arrivent a faire la pub du retour de windows 7, t'as plus vraiment d'excuses, windows 8 est un four. C'est un tel échec sur toute la ligne que le head of windows et le CEO se sont fait virer.

                      L'iPad qui croit, bien pour Apple, mais de nouveau, faut voir a quoi tu compares et a quoi ressemble la courbe future, je la vois pas si rose que ca pour Apple perso, contrairement a Google.

                      On en reparle ici meme l'année prochaine? Autant tu peux argumenter qu'android bouffe une part certaine sur smartphone, via le low end/middle range, et offre une certaine concurrence sur le high end, autant sur le marche des tablettes, c'est sans appel, l'ipad ecrase tout sur le segment "tablette".

                      Linuxfr, le portail francais du logiciel libre et du neo nazisme.

  • # Tu en as de la chance

    Posté par . Évalué à 4.

    Ton blog est relayé par Phoronix je pense que ça va susciter plein de débats "productifs" ;-)

  • # Boite de dialogue pour les mots de passe

    Posté par . Évalué à 4.

    Que faire pour les boites de dialogues pour les mots de passes. Tu peux imaginer une application, ou même un site web, qui reproduit le design du screenlocker et qui demande d'entrer le mot de passe pour dévérouiller. Le pauvre utilisateur rentre alors son mot de passe sans se douter de rien et si le tout est bien fait sans jamais savoir qu'il vient de perdre son mot de passe.

    Je m'étais dis il y a longtemps qu'il suffirait que le compositeur affiche une petite icone dans un coin pour que l'utilisateur sache que la boite de dialogue qui a le focus de l'input a les privilèges qu'il faut. Le problème reste qu'une application en plein écran peut afficher la même icone et tromper l'utilisateur. La seul solution est à mon avis de périodiquement (et aléatoirement) vérifier le contenue de des buffers plein écrans, si le compositeur vois que l'application plein écran affiche la même icone au même endroit alors il récupère la main et bloque l'application.

    Bref mon idée c'est un peux comme le feedback https et certificat de confiance dans la bar d'adresse des navigateurs mais il implique en plus que le compositeur vérifie constamment les applications qui sont en plein écran.

    Il y a d'autre idées ?

    • [^] # Re: Boite de dialogue pour les mots de passe

      Posté par . Évalué à 2.

      Ça rejoins un peu mes postes sur qubeOS/l'interet d'avoir la gestion des décorations côté serveur, non?

      • [^] # Re: Boite de dialogue pour les mots de passe

        Posté par (page perso) . Évalué à 2.

        Oui, c'est la même idée car faire du pattern-matching entre deux images pour vérifier qu'une appli est pas en train de se faire passer pour la fenêtre de mot de passe, c'est pas facile ;)

        Une autre possibilité, c'est d'animer la fenêtre différemment. Avec Wayland, les applications peuvent pas se bouger seules si je me souviens bien (elles disent juste au compositeur "à partir de maintenant, tout mouvement de souris et jusqu'à ce que le clic soit laché, tu bougeras ma fenêtre"). Du coup, on peut faire apparaitre la fenêtre différemment tant qu'on tape pas son mot de passe.

        En tout cas, c'est encore clairement un problème ouvert!

        • [^] # Re: Boite de dialogue pour les mots de passe

          Posté par . Évalué à 7.

          Et pourquoi ne pas faire faire cela directement par le compositeur en rajoutant un protocol ask-pass ? Cela permettrait de clairement identifier qui fait la demande en donnant un bon controle au gestionnaire de fenetre pour renforce une police de securite. Etant donnee que tous les compositeurs viennent avec un toolkit graphique, avoir une gestion de la demande du mot de passe directement dans le compositeur n'est clairement pas un probleme technique.

        • [^] # Re: Boite de dialogue pour les mots de passe

          Posté par . Évalué à 3. Dernière modification le 21/02/14 à 11:45.

          J'ai la solution !!
          Il suffit de faire une boite de dialogue de mot de passes qui esquive quand on veut y entrer son mot de passe :D
          Du coup, quand ce sera trop facile pour les autres, l'utilisateur se doutera forcément de quelque chose !

          Faut penser à activer les webcam pour filmer la tête des utilisateurs au passage :D

        • [^] # Re: Boite de dialogue pour les mots de passe

          Posté par (page perso) . Évalué à 4.

          Ces deux solutions ne résolvent pas le problème de la fenêtre en plein écran qui imiterait ce comportement.

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: Boite de dialogue pour les mots de passe

      Posté par (page perso) . Évalué à 5.

      Bon, je crois avoir trouvé ce qu'il faut faire …. et la réponse me vient de ….. Windows.

      Ce qu'il faut faire, c'est créer une interface pour faire qu'une application soit au premier plan et soit la seule à pouvoir avoir accès aux inputs. Ensuite, il faut que l'appli soit centrée et le reste de l'écran (autour de l'appli) devienne noir transparent.

      Cette interface serait donc privilégiée et seule les applications qui ont le droit de faire du plein écran pourrait copier ça si on leur laisse rendre en ARGB!

      Quoi que vous n'en pensez?

      • [^] # Re: Boite de dialogue pour les mots de passe

        Posté par . Évalué à 4.

        Plus d'infos sur comment Windows gere les desktop 'securises':
        http://security.stackexchange.com/a/3762

      • [^] # Re: Boite de dialogue pour les mots de passe

        Posté par . Évalué à 1.

        Si je ne me trompe pas, les applications dans Wayland n'ont aucun moyen de connaitre le fond d'écran de l'utilisateur et les autres fenêtres.
        Donc pour les applications en mode fenêtré, pas de problème avec la solution de Martin Peres, et pour les applications en plein écran, lors d'une demande d’authentification, Wayland afficherai le fond d'écran au lieu de l'application plein écran. Du coup, le fond sera dans tout les cas modifié, et un utilisateur attentif risquera beaucoup moins de se faire avoir.

        bépo powered

        • [^] # Re: Boite de dialogue pour les mots de passe

          Posté par (page perso) . Évalué à 2.

          En fait, ça marche pas. Une application "fenetrée" peut se mettre en maximisé, et comme le rendu des décorations peut être fait coté client, il pourra se faire passer pour une appli plein écran sans problèmes. À moins de désactiver le rendu ARGB pour toutes les applications (ce qui ne serait pas choquant!), je vois pas ce qu'on peut faire!

          Si on désactivais le canal alpha des applications, alors ça marcherait uniquement si on ne masque pas les autres applications. Le fond d'écran, c'est récupérable depuis le fichier de configuration du compositeur.

          • [^] # Re: Boite de dialogue pour les mots de passe

            Posté par . Évalué à 1.

            Et en ajoutant un effet sur les fenêtres en arrière plan (ou le fond d'écran) , tel qu'une déformation en spirale des autres fenêtres, un programme mal intentionné ne pourrait plus se faire passer pour un autre, ou il y a encore un détail qui m'échappe ?

            bépo powered

            • [^] # Re: Boite de dialogue pour les mots de passe

              Posté par (page perso) . Évalué à 2.

              Y'a de l'idée!

              • [^] # Re: Boite de dialogue pour les mots de passe

                Posté par . Évalué à 1.

                Si j'ai bien suivi le fil, on parle ici du "screen locker".

                Je ne pense pas que ce soit une bonne idée qu'il laisse apparaître le contenu fenêtres ouvertes lorsque l'écran est verrouillé.

                Donc si un effet doit être fait il doit brouiller suffisamment le contenu pour qu'il devienne illisible. Effet pervers, une application voulant se faire passer un "screen locker" aura juste à simuler un effet de fenêtres brouillées pour faire illusion.

                • [^] # Re: Boite de dialogue pour les mots de passe

                  Posté par . Évalué à 1.

                  Non, c'est pour les applications demandant un mot de passe, et un moyen sécurisé de le donner. Le problème étant qu'une application mal intentionnée pourrait se faire passer pour le gestionnaire de mot de passe.

                  bépo powered

              • [^] # Re: Boite de dialogue pour les mots de passe

                Posté par (page perso) . Évalué à 7.

                Bon, j'ai un peu de retard, mais quand même (merci au résumé des meilleurs articles qui ma permit de ne pas louper les derniers commentaires)

                Ça demande un peu de réflexion et probablement de l'ajustement mais l'idée est d'avoir un identifiant visuel qui permettrait aux applications autorisées de s’authentifier auprès des utilisateurs.

                À la création d'un compte, l'utilisateur choisi un "certificat visuel" (plus ou moins en même temps qu'il renseigne son mdp). Ce certificat visuel (CV) serait par exemple une image de 100x100 en RGB, ça peut être une photo, un schéma dessiné à la souris ou un mot stocké sous forme d'image. Le CV est stocké de manière sécurisé et accessible par le compositeur seulement. Lorsqu'une application autorisé veut demander un mdp à l'utilisateur, elle doit demander ce CV et l'afficher à l'utilisateur. L'utilisateur à la garantie que c'est bien une appli autorisée car il voit le CV qu'il a choisi.

                Une appli mal intentionnée ne peut pas accéder au CV et ne peut donc pas s'authentifier auprès de l'utilisateur. Ça reste à l'utilisateur de vérifier qu'il voit son CV avant de rentré le mdp, mais ça reste une vérification pas trop contraignante, facile et rapide à effectuer.

                Matthieu Gautier|irc:starmad

                • [^] # Re: Boite de dialogue pour les mots de passe

                  Posté par (page perso) . Évalué à 2.

                  En fait, il est même pas nécessaire que l'appli affiche le certificat visuel.

                  Le compositeur peut le faire de lui-même. L'important est que l'utilisateur le choisisse pour qu'il ne puisse pas être connu par une appli malveillante.

                  Matthieu Gautier|irc:starmad

                  • [^] # Re: Boite de dialogue pour les mots de passe

                    Posté par (page perso) . Évalué à 2.

                    Très bonne idée GaMa. On en a discuté sur #wayland-secu, y'a du potentiel! La difficulté est de faire que seul le compositeur connaisse cette info. Avec du contrôle d'accès mandataire, c'est facile, mais pour faire sans, on a quelques pistes avec les cgroups/systemd.

                    • [^] # Re: Boite de dialogue pour les mots de passe

                      Posté par . Évalué à 2.

                      La même idée peut être reprise avec un mot clé pré-choisi. Ça revient au même, un mot-clé ou un chemin vers un fichier image.

                      C'est l'interface de saisie de mot de passe qui s'identifie auprès de l'utilisateur avec le mot que l'utilisateur lui a confié au préalable.

                      • [^] # Re: Boite de dialogue pour les mots de passe

                        Posté par (page perso) . Évalué à 2.

                        Dans l'idée, c'est pareil, mais l'image est beaucoup plus rapide à vérifier. Notre architecture est faite comme ça ;)

                        Une image est aussi beaucoup moins facile à deviner qu'un mot / phrase, surtout si les gens mettent des mots de passe. Aussi, tu pourrais savoir que j'ai mis une photo de ma famille, tu aurais toujours du mal à trouver la photo en particulier avec le même re-cadrage!

                        • [^] # Re: Boite de dialogue pour les mots de passe

                          Posté par . Évalué à 2.

                          Un inconvénient de cette méthode : si je prête mon ordi à qqn en lui donnant le MdP (je sais, çaymal), il faut aussi (que je lui donne le mot de vérif ou) que je lui décrive l'image de vérif ? Sinon, il va tomber dans le panneau.

Suivre le flux des commentaires

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