Je suis en desaccord fondamentale avec cette approche de devoir "crowdsourcer" la securite a un utilisateur
Pour moi au contraire c'est la seule façon de faire les choses correctement : c'est l'utilisateur qui a les informations pour faire les choix de sécurité concernant ses données. Le modèle Unix est conçu pour protéger le système partagé de tous les utilisateurs, et les utilisateurs les uns des autres; il ne protège pas un utilisateur de ses propres programmes.
qui de toute facon veut juste que ca marche et ne comprend ni la question ni pourquoi on l'embete avec ca, ca va rien donner.
C'est un problème de sécurité. Si l'interface et les choix de sécurité ne sont pas clairs, demander à l'utilisateur de les faire n'est pas efficace. On connaît de bons principes de conceptions pour que l'interface soit claire du point de vue de la sécurité (encore une fois je t'invite à lire mon billet sur la question).
En très grossier plus un modèle de sécurité est fin, plus il est difficile à faire comprendre à l'utilisateur—et donc paradoxalement il peut en être d'autant moins efficace. Pour un niveau de finesse donné il y a des efforts à faire pour obtenir un modèle à l'interface compréhensible. Il n'y a pas de secret, on y arrive en travaillant sur ces questions par itérations successives. Le modèle smartphone actuel de "le programme demande tel genre de capacités grossières, est-ce que ça vous semble raisonnable ?" est déjà un pas en avant. À mon avis on peut faire encore beaucoup plus fin en étant grossièrement aussi clair. Il faut repenser les interfaces pour que les concepts et bordures d'interface qui sont claires à l'utilisateur (par exemple "Mes Documents" et "Documents Partagés") correspondent aux bordures du système de sécurité.
Apple a les moyens d'auditer le code, de le tester
J'en doute fort. Beaucoup de code est proposé pour intégration dans l'Appstore, et auditer du code pour vérifier sa sécurité demande beaucoup d'effort, surtout quand il s'agit d'auteurs en lesquels on n'a aucune confiance, car une faille malicieuse est facile à cacher (cf. le underhanded C contest). Reposer sur l'inspection et l'audit seul ne peuvent pas passer à l'échelle, et il me paraît absolument normal de mettre en place des moyens techniques pour réduire la surface de code critique.
d'agir promptement en cas de probleme et meme de poursuivre le createur du probleme en justice.
Tu marques un bon point : en sécurité on peut jouer aussi sur la réponse après-attaque et pas seulement sur la protection préventive. Mais ça a aussi ses complications importantes et c'est une méthode complémentaire, qui s'ajoute aux protections techniques mises en place dans la couche logicielle.
Je trouve anormal que le logiciel qui sélectionne le fond d'écran de mon bureau puisse lire mon cache Firefox et l'envoyer sur le réseau sans me prévenir; c'est un problème de conception, et la solution n'est pas d'attendre qu'un tel logiciel se serve de cette faille béante pour lui coller un procès.
La difference fondamentale avec le logiciel libre, elle est la. Apple ne peut pas avoir confiance dans les developpeurs de sa plateforme, donc il met une politique en place. […] on peut avoir confiance dans la tres tres grande majorite des developpeurs de logiciel libre
Je ne suis pas du tout d'accord. D'une part vu l'étendue des systèmes techniques on ne peut pas faire confiance à tous les développeurs du libre (cf. les rumeurs sur le fait que tel développeur BSD ait travaillé pour le FBI). D'autre part le problème n'est pas qu'un problème de confiance, une simple erreur peut avoir des conséquences dramatiques : une personne même la plus intentionnée du monde peut laisser dans son code des failles qui permettent une injection de code. Je lis LWN.net et toutes les semaines il y a des failles de ce type rapportées pour des logiciels très utilisés.
On n'a pas attendu de ne "pas faire confiance" aux développeurs logiciels pour mettre en place des protections mémoires entre les différents processus. Vu les technologies utilisées pour le développement (C / C++ en particulier) qui sont extrêmement propices aux failles de tout genre (même chez des développeurs experts), il faut prévoir que n'importe quel logiciel peut être pris sous contrôle d'un attaquant, et donc doit tourner avec juste les droits dont il a besoin pour faire son travail, et pas plus (certainement pas tous les droits utilisateur).
Tant que le logiciel libre passe par des distributions et offre un mecanisme lent de propagation des changements vers les utilisateurs (ce que sont les repository de distribution), alors on reste fortement protégé du problème.
Une version idéaliste qui n'a aucun rapport avec la réalité. On peut prédire sans de grandes chances de se tromper que tous les logiciels de bureau que tu utilises ont des failles d'injection de code, qui n'ont pas encore été trouvées.
Encore une fois les solutions non-techniques (toile de confiance entre les auteurs de logiciel, contre-attaques juridiques, systèmes de mise à jour de sécurité efficaces) sont complémentaires des protections techniques, elles ne les remplacent pas.
Et oui, je fais fondamentalement la difference entre un comportement attendu et l'utilisation d'une faille dans un logiciel existant.
Je ne vois pas trop ce que ça change du point de vue des dégâts causés à l'utilisateur, tu peux développer plus sur ce point ?
[…] On met en place un systeme de review different en fonction des gens qui font les checks de securite et ceux qui ne comprennent pas la question. […]
Encore une fois, ce genre de protections ne passe pas forcément à l'échelle. C'est complémentaire de l'idée toute simple et naturelle qu'une application devrait avoir accès seulement aux droits dont elle a besoin, et pas d'autres, pour mitiger naturellement les problèmes en cas d'attaque.
[^] # Re: La politique de sécurité est bonne
Posté par gasche . En réponse à la dépêche Bref, MPlayerX quitte le Mac App Store. Évalué à 10.
Pour moi au contraire c'est la seule façon de faire les choses correctement : c'est l'utilisateur qui a les informations pour faire les choix de sécurité concernant ses données. Le modèle Unix est conçu pour protéger le système partagé de tous les utilisateurs, et les utilisateurs les uns des autres; il ne protège pas un utilisateur de ses propres programmes.
C'est un problème de sécurité. Si l'interface et les choix de sécurité ne sont pas clairs, demander à l'utilisateur de les faire n'est pas efficace. On connaît de bons principes de conceptions pour que l'interface soit claire du point de vue de la sécurité (encore une fois je t'invite à lire mon billet sur la question).
En très grossier plus un modèle de sécurité est fin, plus il est difficile à faire comprendre à l'utilisateur—et donc paradoxalement il peut en être d'autant moins efficace. Pour un niveau de finesse donné il y a des efforts à faire pour obtenir un modèle à l'interface compréhensible. Il n'y a pas de secret, on y arrive en travaillant sur ces questions par itérations successives. Le modèle smartphone actuel de "le programme demande tel genre de capacités grossières, est-ce que ça vous semble raisonnable ?" est déjà un pas en avant. À mon avis on peut faire encore beaucoup plus fin en étant grossièrement aussi clair. Il faut repenser les interfaces pour que les concepts et bordures d'interface qui sont claires à l'utilisateur (par exemple "Mes Documents" et "Documents Partagés") correspondent aux bordures du système de sécurité.
J'en doute fort. Beaucoup de code est proposé pour intégration dans l'Appstore, et auditer du code pour vérifier sa sécurité demande beaucoup d'effort, surtout quand il s'agit d'auteurs en lesquels on n'a aucune confiance, car une faille malicieuse est facile à cacher (cf. le underhanded C contest). Reposer sur l'inspection et l'audit seul ne peuvent pas passer à l'échelle, et il me paraît absolument normal de mettre en place des moyens techniques pour réduire la surface de code critique.
Tu marques un bon point : en sécurité on peut jouer aussi sur la réponse après-attaque et pas seulement sur la protection préventive. Mais ça a aussi ses complications importantes et c'est une méthode complémentaire, qui s'ajoute aux protections techniques mises en place dans la couche logicielle.
Je trouve anormal que le logiciel qui sélectionne le fond d'écran de mon bureau puisse lire mon cache Firefox et l'envoyer sur le réseau sans me prévenir; c'est un problème de conception, et la solution n'est pas d'attendre qu'un tel logiciel se serve de cette faille béante pour lui coller un procès.
Je ne suis pas du tout d'accord. D'une part vu l'étendue des systèmes techniques on ne peut pas faire confiance à tous les développeurs du libre (cf. les rumeurs sur le fait que tel développeur BSD ait travaillé pour le FBI). D'autre part le problème n'est pas qu'un problème de confiance, une simple erreur peut avoir des conséquences dramatiques : une personne même la plus intentionnée du monde peut laisser dans son code des failles qui permettent une injection de code. Je lis LWN.net et toutes les semaines il y a des failles de ce type rapportées pour des logiciels très utilisés.
On n'a pas attendu de ne "pas faire confiance" aux développeurs logiciels pour mettre en place des protections mémoires entre les différents processus. Vu les technologies utilisées pour le développement (C / C++ en particulier) qui sont extrêmement propices aux failles de tout genre (même chez des développeurs experts), il faut prévoir que n'importe quel logiciel peut être pris sous contrôle d'un attaquant, et donc doit tourner avec juste les droits dont il a besoin pour faire son travail, et pas plus (certainement pas tous les droits utilisateur).
Une version idéaliste qui n'a aucun rapport avec la réalité. On peut prédire sans de grandes chances de se tromper que tous les logiciels de bureau que tu utilises ont des failles d'injection de code, qui n'ont pas encore été trouvées.
Encore une fois les solutions non-techniques (toile de confiance entre les auteurs de logiciel, contre-attaques juridiques, systèmes de mise à jour de sécurité efficaces) sont complémentaires des protections techniques, elles ne les remplacent pas.
Je ne vois pas trop ce que ça change du point de vue des dégâts causés à l'utilisateur, tu peux développer plus sur ce point ?
Encore une fois, ce genre de protections ne passe pas forcément à l'échelle. C'est complémentaire de l'idée toute simple et naturelle qu'une application devrait avoir accès seulement aux droits dont elle a besoin, et pas d'autres, pour mitiger naturellement les problèmes en cas d'attaque.