L'utilisateur, il cliques sur Ok pour que son application marche. Il ne cherche tres rapidement plus a comprendre pourquoi une application lui demande quelque chose. Il veut que ca marche et qu'on ne l'ennuie pas avec des questions superflues ! En ergonomie, chaque cliques augmentent de 50% les chances de perdrent l'utilisateur. Donc toutes questions de securite resulte en une mauvaise ergonomie. Ce n'est pas une solution !
En utilisant la même logique :
l'utilisateur dans sa voiture il prend les tournants comme il veut, il ne cherche pas à comprendre ce qu'est le code de la route et pas le resepcter
l'utilisateur qui veut stocker son argent il le donne au premier type venu qui promet de le lui rendre, il ne cherche pas à comprendre si le type est de confiance
l'utilisateur qui sort de chez lui laisse la porte ouverte, lui demander de fermer sa porte à clé augmente de 50% les chance de le voir déménager
Encore une fois dans la vraie vie les gens font ce genre de choix de sécurité en permanence. Ils sont en train d'apprendre à les faire sur internet (réglages de vie privée, etc.). Il n'y a pas de raison de croire qu'ils sont incapable de les faire, tant que les décisions à prendre sont compréhensibles et pas obscures, et qu'on ne lui pose pas la question trop souvent (auquel cas oui, un automatisme "tout accepter" peut s'installer, tout comme tu ne fermerais pas à clé chacune des porte que tu traverses même si on te le demandait). Et pour éviter de poser les questions trop souvent, il faut un bon modèle de sécurité :
par défaut les applications ne créent pas de danger, elles sont conçues de façon à ne pas avoir besoin de privilèges (donc pas besoin d'avertir); cf. l'exemple de départ où c'est un démon externe qui accède à l'arborescence de fichier
les choix de sécurité sont le plus possible combinés à une action utilisateur qui fait avancer son travail. C'est tout l'intérêt de dire qu'on donne accès à l'application aux fichiers que les utilisateurs a explicitement ouvert : ça permet d'avoir une seule action "choisir un fichier et donner les droits à l'application" qui est utile, et pas un popup indépendant "l'application veut lire tel fichier, oui/non" qui se met en travers de l'utilisation.
Pour le proteger des failles de securite, c'est une problematique technique et un arsenal technique va clairement aider. Noyau et linker permettant de faire de l'adressage memoire aleatoire, canarie, analyse statique du code, privilege super fin de l'application (definit par le developpeur) et definition des sorties (en gros, quand il y a des donnees privees dans un fichier que l'application cree, le systeme en est informe et prend les mesures necessaires), virtualisation, secure boot et trusted computing. Avec ca le potentiel d'une attaque sur un systeme aillant une faille devient tres difficile et a aucun moment l'intervention de l'utilisateur a ete necessaire. Donc aucune problematique d'ergonomie.
La plupart des techniques que tu cites ("privilèges super fins", "définitions des sorties", "virtualisation"…) sont aussi utiles dans le cas d'une faille que dans le cas d'une application malicieuse, puisqu'elles reviennent à restreindre au maximum les droits d'une application et la forcer à être explicite sur ses besoins. Pour moi elles sont liées à des questions d'ergonomies pour deux raisons :
pour avoir un découpage assez fin il faut parfois poser des questions à l'utilisateur (tu ne peux pas deviner à l'avance quels fichiers il va vouloir ouvrir avec son éditeur de texte), et surtout il faut savoir interpréter les actions de l'utilisateur comme apportant des privilèges supplémentaires : ce n'est pas parce que l'application a une aide en ligne qu'il faut lui donner le droit de faire des requêtes sur le réseau, par contre quand l'utilisateur clique sur "aide en ligne" ça veut dire qu'il demande implicitement à visiter le site web de l'application (à ton système de faire la médiation en décidant soit de donner à l'application les droits sur le réseau et alors comment les restreindre raisonnablement, ou alors en appelant un service système pour faire la navigation en dehors de l'application, etc.)
si l'ergonomie n'est pas bonne la sécurité est en danger puisque l'utilisateur qui ne comprend pas ce qui se passe va faire des mauvais choix de sécurité (typiquement donner tous les droits à l'application pour qu'on arrête de le faire chier).
Ceci dit je suis tout à fait d'accord pour dire qu'il ne s'agit pas que de questions d'ergonomies, il y a des questions techniques dessous (essentiellement quel modèle de sécurité utiliser et comment reconcevoir les applications pour pouvoir vérifier facilement (automatiquement ou au moins déjà manuellement) qu'elles le respectent) qui sont intéressantes et importantes et non directement liées à l'interface utilisateur.
Après tu cites une autre série de mesure (heap randomization, canaries) qui sont là pour rendre plus difficiles l'exploitation des failles, et donc augmenter la distance entre "application bugguée" et "application malicieuse" (ou équivalente via injection de code). On peut ajouter l'analyse statique, l'utilisation de langages memory-safe, les données non-exécutables, tout ce qui est Software Fault Isolation, etc. C'est aussi une ligne de recherche intéressante et importante mais complémentaire, il faut se défendre à tous les niveaux.
Pour moi la partie "réduire les privilèges au maximum" est primordiale puisqu'elle a l'effet de réduire la zone d'attaque (TCB, trusted computing base) de plusieurs ordres de grandeur, en nous permettant de concentrer les efforts les plus coûteux (analyse statique, méthodes formelles de preuve de correction, etc.) seulement sur la partie critique tout en donnant de bonnes garanties de "pire cas" sur le reste. Et cette partie passe par des choix de conception qui mettent en jeu l'interface utilisateur.
Dans un cas, tu as une tracabilite, avec la possibilite juridique d'intervenir dans l'autre tu es dans un cas anonyme et il faut des recherches plus ou moins pousser pour trouver un coupable. […] Comme c'est un probleme different, il demande des reponses differentes.
Encore une fois la plupart des mesures que tu as citées sont applicables dans les deux cas, et le principe directeur "privilèges les plus fins possibles" est valide partout. Après tu as raison de signaler qu'il y a d'autres méchanismes de sécurité complémentaire (jugements de confiance pré-installation, audit post-attaque, etc.) qui se passent différemment, mais ce n'est pas eux que je prenais en compte, et il me semble évident qu'ils sont à ajouter par dessus les techniques de restriction des privilèges, et pas à la place—puisqu'eux aussi ne sont pas infaillibles et qu'il faut donc savoir minimiser les dégats s'ils échouent. D'ailleurs ces techniques sont déjà largement en place aujourd'hui (sites de téléchargement centralisés avec notes, répertoire de paquets signés, etc.) et pourtant on a de gros problèmes de sécurité, preuve qu'ils ne sont pas suffisants à eux seuls.
Et a aucun moment, on peut compter sur l'utilisateur pour prendre la bonne solution surtout sur une question complique.
Encore une fois, pour moi l'interaction avec l'utilisateur ça ne veut pas dire lui casser les pieds en permanence pour lui poser des questions de sécurité qui le distraient de son travail, mais plutôt savoir interpréter ses actions pour pouvoir gérer la sécurité de façon non-intrusive (il choisit un fichier dans le dialogue "ouvrir un fichier", donc il veut bien donner les droits dessus à l'application), tout en s'assurant que ces droits qu'il donne sont explicites et que l'application ne peut pas l'induire malicieusement en erreur1.
1: un exemple est une forme de "fishing" au niveau de l'interface graphique; je suis un petit démon malicieux qui tourne en background et, quand je devine que l'utilisateur s'apprête à se connecter à un serveur par Putty, je fais apparaître une fenêtre popup qui ressemble comme deux gouttes d'eau à celle de Putty, en espérant que l'utilisateur mette le mot de passe du serveur dans ma fenêtre. On peut s'en protéger en forçant au niveau du systèmes de fenêtre que la provenance de chaque popup est claire pour l'utilisateur et ne peut pas être "camouflée" par les applications.
[^] # 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é à 7.
En utilisant la même logique :
Encore une fois dans la vraie vie les gens font ce genre de choix de sécurité en permanence. Ils sont en train d'apprendre à les faire sur internet (réglages de vie privée, etc.). Il n'y a pas de raison de croire qu'ils sont incapable de les faire, tant que les décisions à prendre sont compréhensibles et pas obscures, et qu'on ne lui pose pas la question trop souvent (auquel cas oui, un automatisme "tout accepter" peut s'installer, tout comme tu ne fermerais pas à clé chacune des porte que tu traverses même si on te le demandait). Et pour éviter de poser les questions trop souvent, il faut un bon modèle de sécurité :
La plupart des techniques que tu cites ("privilèges super fins", "définitions des sorties", "virtualisation"…) sont aussi utiles dans le cas d'une faille que dans le cas d'une application malicieuse, puisqu'elles reviennent à restreindre au maximum les droits d'une application et la forcer à être explicite sur ses besoins. Pour moi elles sont liées à des questions d'ergonomies pour deux raisons :
Encore une fois, il faut lire l'article User Interaction Design for Secure Systems (PDF) qui explique tout ça très bien, donne des exemples, et ne fait que 16 pages.
Ceci dit je suis tout à fait d'accord pour dire qu'il ne s'agit pas que de questions d'ergonomies, il y a des questions techniques dessous (essentiellement quel modèle de sécurité utiliser et comment reconcevoir les applications pour pouvoir vérifier facilement (automatiquement ou au moins déjà manuellement) qu'elles le respectent) qui sont intéressantes et importantes et non directement liées à l'interface utilisateur.
Après tu cites une autre série de mesure (heap randomization, canaries) qui sont là pour rendre plus difficiles l'exploitation des failles, et donc augmenter la distance entre "application bugguée" et "application malicieuse" (ou équivalente via injection de code). On peut ajouter l'analyse statique, l'utilisation de langages memory-safe, les données non-exécutables, tout ce qui est Software Fault Isolation, etc. C'est aussi une ligne de recherche intéressante et importante mais complémentaire, il faut se défendre à tous les niveaux.
Pour moi la partie "réduire les privilèges au maximum" est primordiale puisqu'elle a l'effet de réduire la zone d'attaque (TCB, trusted computing base) de plusieurs ordres de grandeur, en nous permettant de concentrer les efforts les plus coûteux (analyse statique, méthodes formelles de preuve de correction, etc.) seulement sur la partie critique tout en donnant de bonnes garanties de "pire cas" sur le reste. Et cette partie passe par des choix de conception qui mettent en jeu l'interface utilisateur.
Encore une fois la plupart des mesures que tu as citées sont applicables dans les deux cas, et le principe directeur "privilèges les plus fins possibles" est valide partout. Après tu as raison de signaler qu'il y a d'autres méchanismes de sécurité complémentaire (jugements de confiance pré-installation, audit post-attaque, etc.) qui se passent différemment, mais ce n'est pas eux que je prenais en compte, et il me semble évident qu'ils sont à ajouter par dessus les techniques de restriction des privilèges, et pas à la place—puisqu'eux aussi ne sont pas infaillibles et qu'il faut donc savoir minimiser les dégats s'ils échouent. D'ailleurs ces techniques sont déjà largement en place aujourd'hui (sites de téléchargement centralisés avec notes, répertoire de paquets signés, etc.) et pourtant on a de gros problèmes de sécurité, preuve qu'ils ne sont pas suffisants à eux seuls.
Encore une fois, pour moi l'interaction avec l'utilisateur ça ne veut pas dire lui casser les pieds en permanence pour lui poser des questions de sécurité qui le distraient de son travail, mais plutôt savoir interpréter ses actions pour pouvoir gérer la sécurité de façon non-intrusive (il choisit un fichier dans le dialogue "ouvrir un fichier", donc il veut bien donner les droits dessus à l'application), tout en s'assurant que ces droits qu'il donne sont explicites et que l'application ne peut pas l'induire malicieusement en erreur1.
1: un exemple est une forme de "fishing" au niveau de l'interface graphique; je suis un petit démon malicieux qui tourne en background et, quand je devine que l'utilisateur s'apprête à se connecter à un serveur par Putty, je fais apparaître une fenêtre popup qui ressemble comme deux gouttes d'eau à celle de Putty, en espérant que l'utilisateur mette le mot de passe du serveur dans ma fenêtre. On peut s'en protéger en forçant au niveau du systèmes de fenêtre que la provenance de chaque popup est claire pour l'utilisateur et ne peut pas être "camouflée" par les applications.