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 espitall . É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 Marotte ⛧ . É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 espitall . É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 :
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 Martin Peres (site web personnel) . Évalué à 10.
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 espitall . É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 Martin Peres (site web personnel) . Évalué à 10.
Je suis convaincu que c'est le seul choix qui ait un sens.
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.
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 espitall . É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 :
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 Martin Peres (site web personnel) . Évalué à 3.
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 ;)
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 espitall . É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 Martin Peres (site web personnel) . Évalué à 3.
C'est compréhensible, en effet ;)
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 espitall . É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 Martin Peres (site web personnel) . Évalué à 6.
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.
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 espitall . É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 fearan . Évalué à 2.
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 jyes . Évalué à 1. Dernière modification le 20 février 2014 à 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 feth . Évalué à 10. Dernière modification le 20 février 2014 à 08:53.
Qui ne s'est jamais tiré dans les pieds au bazooka ?
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 feth . Évalué à 4.
La vraie source : http://theqz.deviantart.com/art/Rocket-Jump-283517381 et d'autres très drôles sur http://www.deviantart.com/fanart/wallpaper/games/?q=rocket+jump
[^] # Re: Capture d'écran
Posté par reno . Évalué à 5.
Hum, pourquoi commenter avant de lire l'article??
[^] # Re: Capture d'écran
Posté par espitall . É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 Marotte ⛧ . Évalué à 6.
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 espitall . É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 pasBill pasGates . Évalué à 1.
De l'audit de fichier ? Ca existe depuis la prehistoire…
http://support.microsoft.com/kb/310399
[^] # Re: Capture d'écran
Posté par espitall . É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 moi1392 . É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 espitall . Évalué à 1. Dernière modification le 20 février 2014 à 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 Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 2.
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 pasBill pasGates . É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 Marotte ⛧ . Évalué à 6.
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 pasBill pasGates . Évalué à 7. Dernière modification le 20 février 2014 à 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 barmic . Évalué à 3.
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 pasBill pasGates . É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 barmic . É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 Martin Peres (site web personnel) . Évalué à 10.
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.
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 reno . É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 zen . É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 reno . Évalué à 3.
Ça change qu'avec la décoration des fenêtres coté serveur, le serveur peut ajouter des "identifiant visuels" te permettant de distinguer tes applications comme le fait Qubes OS par exemple.
Une capture d'écran:
http://qubes-os.org/trac/raw-attachment/wiki/QubesScreenshots/r2b2-kde-three-domains-at-work.png
[^] # Re: Problematique...
Posté par claudex . É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 Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 1.
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 pepp . É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 Martin Peres (site web personnel) . Évalué à 10.
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 pasBill pasGates . Évalué à 2.
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 Martin Peres (site web personnel) . É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 pasBill pasGates . É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 Martin Peres (site web personnel) . Évalué à 4.
Cool, je savais pas pour Metro!
[^] # Re: Et sur les autres systèmes ?
Posté par xcomcmdr . É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 pasBill pasGates . É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 groumly . Évalué à 7. Dernière modification le 23 février 2014 à 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.
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 pasBill pasGates . Évalué à 0.
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.
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 groumly . Évalué à 4.
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.
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.
Hein? MS mise tout sur une stratégie "no comprise", et on est cense voir des ventes qui baissent?
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.
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 reno . Évalué à 4.
Ton blog est relayé par Phoronix je pense que ça va susciter plein de débats "productifs" ;-)
[^] # Re: Tu en as de la chance
Posté par Martin Peres (site web personnel) . Évalué à 7.
Ah ah, je sais pas si ça va être productif, mais en tout cas ça génère du trafic!
[^] # Re: Tu en as de la chance
Posté par patrick_g (site web personnel) . Évalué à 4.
Et moi j'ai relayé vers LWN ce matin pour que ce soit plus productif ;-)
[^] # Re: Tu en as de la chance
Posté par Martin Peres (site web personnel) . Évalué à 3.
J'ai vu ça, oui, merci ;)
C'est aussi parti sur reddit, si j'en crois analytics.
# Boite de dialogue pour les mots de passe
Posté par glisse . É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 reno . É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 Martin Peres (site web personnel) . É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 cedric . É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 moi1392 . Évalué à 3. Dernière modification le 21 février 2014 à 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 Martin Peres (site web personnel) . Évalué à 2.
Oh yeah, retour des boites de dialogues/boutons qui bougeaient quand on essayait de cliquer dessus!
[^] # Re: Boite de dialogue pour les mots de passe
Posté par claudex . É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 reno . Évalué à 2.
Problème de plein écran --> virer le plein écran sauf pour des applications choisies par l'utilisateur..
[^] # Re: Boite de dialogue pour les mots de passe
Posté par claudex . Évalué à 3.
Comme le navigateur web ?
« 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 reno . Évalué à 2.
Quel est l'autre alternative?
Bloquer le plein écran, sans laisser a l'utilisateur le choix?
Il est fort probable qu'il exerce son libre choix en changeant de distribution..
[^] # Re: Boite de dialogue pour les mots de passe
Posté par claudex . Évalué à 3.
Non, je dis que bloquer le plein écran n'est pas forcément un truc utile.
« 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 Martin Peres (site web personnel) . É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 Littleboy . É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 robin . É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 Martin Peres (site web personnel) . É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 robin . É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 Martin Peres (site web personnel) . Évalué à 2.
Y'a de l'idée!
[^] # Re: Boite de dialogue pour les mots de passe
Posté par espitall . É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 robin . É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 GaMa (site web personnel) . É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 GaMa (site web personnel) . É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 Martin Peres (site web personnel) . É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 jihele . É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 Martin Peres (site web personnel) . É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 jihele . É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.
[^] # Re: Boite de dialogue pour les mots de passe
Posté par Martin Peres (site web personnel) . Évalué à 2.
Si tu lui dit pas, il/elle pourra tomber dans le panneau. Mais l'ordi saura pas que c'est pas toi, donc bon, c'est peu probable que ça arrive.
[^] # Re: Boite de dialogue pour les mots de passe
Posté par jihele . Évalué à 2.
Pas compris…
Tu veux dire que l'attaquant, ne sachant pas que c'est pas toi, ne tentera même pas le coup ? Que la mesure est finalement assez dissuasive ?
Du point de vue de l'attaquant, c'est pas cher de tenter le coup jusqu'à ce que ça passe (cf. phishings et autres…)
[^] # Re: Boite de dialogue pour les mots de passe
Posté par Martin Peres (site web personnel) . Évalué à 2.
C'est pas cher … tant que tu tombes pas sur un mec qui saura virer ton programme malveillant ;)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.