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 ;)
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.
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.
On peut y lire dans les commentaires quelques réserves. Grosso modo, les codes 301 et 302 ont été volontairement "mal" implémentés dans chromium et firefox au niveau du changement de la méthode d'envoi afin de reproduire le fonctionnement de IE qui était en position de force !
Dans HTTP 2.0 le but étant d'écrire un standard ne cassant pas le fonctionnement actuel (et non la norme actuelle, ce qui est bien différent !), le choix a été de dire on fait coller la nouvelle norme au fonctionnement majoritaire actuel des codes 301 et 302 (l'article veut faire croire l'inverse, mais c'est faux) et de repartir sur une base propre avec de nouveaux codes d'erreurs.
Je suis déjà venu deux trois fois au printemps dans l'ancien local… puis j'ai manqué à chaque fois de courage pour aller aux bassins à flots un mardi soir !
Mais Bègles c'est bien plus proche pour moi, demain je viens faire un tour !
J'ai eu il y a peu de temps la même problématique. La solution qui m'a semblé la plus facile/rapide a mettre en place a été d'utiliser haproxy plutôt qu'un jeu de règles avec iptable !
Haproxy rajoute certes un intermédiaire mais est quand même très performant (surtout si on compare avec la solution de mettre node.js derrière apache !)
[^] # Re: Capture d'écran
Posté par espitall . En réponse au journal Compositeurs Wayland - Pourquoi et comment gérer les clients privilégiés?. É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 espitall . En réponse au journal Compositeurs Wayland - Pourquoi et comment gérer les clients privilégiés?. É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 espitall . En réponse au journal Compositeurs Wayland - Pourquoi et comment gérer les clients privilégiés?. É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.
# Capture d'écran
Posté par espitall . En réponse au journal Compositeurs Wayland - Pourquoi et comment gérer les clients privilégiés?. É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 ?
# Nuance
Posté par espitall . En réponse au journal HTTP2, le protocole écrit comme une loi américaine. Évalué à 10.
Le lien vers insanecoding.blogspot.fr a aussi été posté sur HN : https://news.ycombinator.com/item?id=7249193
On peut y lire dans les commentaires quelques réserves. Grosso modo, les codes 301 et 302 ont été volontairement "mal" implémentés dans chromium et firefox au niveau du changement de la méthode d'envoi afin de reproduire le fonctionnement de IE qui était en position de force !
Dans HTTP 2.0 le but étant d'écrire un standard ne cassant pas le fonctionnement actuel (et non la norme actuelle, ce qui est bien différent !), le choix a été de dire on fait coller la nouvelle norme au fonctionnement majoritaire actuel des codes 301 et 302 (l'article veut faire croire l'inverse, mais c'est faux) et de repartir sur une base propre avec de nouveaux codes d'erreurs.
Bonus (trouvé dans les commentaires sur HN), un lien vers le code de chromium sur la gestion des codes 301 et 302 avec un joli commentaire explicatif : https://code.google.com/p/chromium/codesearch#chromium/src/net/url_request/url_request.cc&q=ComputeMethodForRedirect&sq=package:chromium&l=570
# Demain !
Posté par espitall . En réponse à la dépêche Le L@Bx, un hacklab qui déménage !. Évalué à -1.
Je suis déjà venu deux trois fois au printemps dans l'ancien local… puis j'ai manqué à chaque fois de courage pour aller aux bassins à flots un mardi soir !
Mais Bègles c'est bien plus proche pour moi, demain je viens faire un tour !
# Haproxy
Posté par espitall . En réponse au message [iptables] Dérouter vers un autre port les connexions arrivant sur le port 80 via un domaine précis. Évalué à 3.
J'ai eu il y a peu de temps la même problématique. La solution qui m'a semblé la plus facile/rapide a mettre en place a été d'utiliser haproxy plutôt qu'un jeu de règles avec iptable !
Haproxy rajoute certes un intermédiaire mais est quand même très performant (surtout si on compare avec la solution de mettre node.js derrière apache !)