Tout d'abord, merci pour ta réponse intéressante et argumentée.
un certain nombre d'individu se comporte de maniere particulierement idiote sur la route […] On fait aveuglement confiance a son banquier […] j'ai d'ailleurs souvent vu des gens qui oubliaient de fermer la porte
Certes il y a des gens qui font des erreurs graves de sécurité, il y en aura toujours. Mon point est qu'avec des interfaces bien faites tu peux obtenir que la majorité des utilisateurs puissent faire le bon choix sans que ça les gêne dans leur travail.
enfin la grande majorite des applications, celle qui etende le contexte des informations deja acquise. En gros, c'est application accede a des donnees privees, de maniere plutot automatise pour faciliter la vie de l'utilisateur, en extrait de l'information et en rajoute pour proposer des choix a l'utilisateur qui lui facilite la vie
Je connais et j'admire MagicInk, mais je ne pense pas que ces applications soient aussi prépondérantes aujourd'hui que tu le dis. Dans les logiciels que j'utilise tous les jours aucune ne fait vraiment ça, à part le logiciel distant hébergé par Google (spécialisation des résultats de recherche, qui d'ailleurs me gonfle pas mal, et publicité personnalisée). Je ne crois pas qu'on puisse dire aujourd'hui que ça constitue la "grandes majorité des applications", en tout cas sur des distributions GNU/Linux classiques.
J'ai donc très peu d'expérience sur la conception et la structure de ces "applications contextuelles" et je peux difficilement en dire plus sur comment les intégrer à ces modèles de sécurité. Je suis cependant confiant du fait qu'on pourra le faire quand elles se développeront (l'idée est d'isoler le composant qui construit le contexte pour le faire tourner dans un processus à part ayant des droits spécialiser, et de travailler sur son interface avec les autres composants pour qu'elle ne transmette pas trop d'information).
Quand je regarde les applications que j'utilise aujourd'hui (un navigateur web, un éditeur de textes/programmes, des programmes pour lire des images/musiques/vidéos, un client mail, un lecteur PDF, quelques jeux, plus tout le userland invisible qui fait tourner tout ça), elles sont toutes simples à sécuriser par une restriction de droits (approximative au début, puis de plus en plus fine quand les modèles de sécurité s'améliorent), sauf peut-être le navigateur web qui a en plus le problème d'être devenu un sous-monde à part au sein duquel les problématiques de sécurité/compartementalisation se re-posent. Mais je reste confiant qu'un modèle même relativement simple permettrait de réduire de plusieurs ordres de grandeur la surface de la Trusted Computing Base.
Maintenant imagine une application de calendrier qui va indexer et parcourir tous tes mails a la recherche de possible evenement en piece jointe ou directement dans le contexte du mail.
Pour moi ce n'est pas au calendrier d'indexer mes mails mais plutôt au client mail de prévenir le calendrier s'il détecte un événement; ou alors à un démon externe de faire la médiation entre les deux. Dans tous les cas le processus calendrier n'a pas besoin des droits sur mes mails.
maintenant quelle question doit-on poser à l'utilisateur ? Tu connais déjà mon point de vue, aucune :-) L'application fait ce qu'elle est censée faire, pas la peine d'ennuyer l'utilisateur avec un comportement normal.
Je trouverais normal de poser la question une fois, au moment de l'installation du module qui gère ça. Je voudrais que mon système me prévienne par défaut si une application tierce que je télécharge et exécute demande à lire tous mes mails.
(Après on peut imaginer des systèmes de chaînes de confiance où le binaire est signé par ma distribution (ou l'administrateur local ou un site d'audit indépendant ou…), et j'ai dit quelque part que "je fais confiance à ma distribution pour tous les (ou telle famille de) choix de sécurité", et donc on ne pose des questions de ce genre que pour les binaires non-signés. Il y a un compromis à trouver.)
Alors dans le cas de mplayer, le systeme pourrait etre tres intelligent et donner les droits d'acces a des fichiers lie comme les sous-titre. Mais le probleme se posera a chaque fois qu'une fonction automatique sera ajoute pour simplifier la vie de l'utilisateur…
Pour moi dans un bon design il y a des cycles de conception avec une discussion entre les concepteurs du modèle de sécurité et les concepteurs des applications. On commence avec un modèle de sécurité robuste et qui couvre une majorité des cas; si une application ne rentre pas dans le modèle, on doit la mettre à un niveau de privilèges un peu supérieur à ce dont elle aurait eu besoin (dans un système idéal). Ensuite on regarde toutes les applications pour lesquelles le problème s'est posé et on essaie de comprendre comment satisfaire leur besoin, c'est-à-dire comment adapter le modèle de sécurité pour lui faire comprendre que justement, leur besoin ne nécessite pas vraiment autant de privilèges. On modifie le tout, et on recommence.
L'idée spécifique d'aller chercher des sous-titres est bien trop particulière pour être raisonnablement implémentée dans le système de sécurité (ça revient à y mettre des bouts d'application, et donc à le rendre plus complexe est moins sûr), mais il y a sans doute des sur-approximations raisonnables qui capturent ce besoin et d'autres en même temps. J'avais proposé le droit de lire dans un répertoire entré, et un autre commentaire parlait d'autorisations de lecture de certains MIME types seulement.
Pour mplayer on semble être dans le cas "modèle trop simple, besoin de privilèges supérieurs" : il faudrait décomposer mplayer en un processus qui tourne au niveau de privilège bas, et un processus auxiliaire qui est appelé quand l'utilisateur a choisit un fichier pour aller lire dans le répertoire correspondant et chercher des sous-titres. Le processus auxiliaire doit tourner à un niveau de privilège supérieur (accès au système de fichier) mais il est isolé, simple, et donc plus facile à auditer.
Maintenant si Apple a une approche trop rigide et refuse de mettre ces processus un peu trop demandeurs à un niveau de privilège supérieur, ça ne m'étonne pas tellement et ça explique le problème mentionné par la dépêche. Ça n'invalide en aucun cas l'approche globale de permettre aux applications de restreindre au minimum leurs droits.
[^] # 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é à 2.
Tout d'abord, merci pour ta réponse intéressante et argumentée.
Certes il y a des gens qui font des erreurs graves de sécurité, il y en aura toujours. Mon point est qu'avec des interfaces bien faites tu peux obtenir que la majorité des utilisateurs puissent faire le bon choix sans que ça les gêne dans leur travail.
Je connais et j'admire MagicInk, mais je ne pense pas que ces applications soient aussi prépondérantes aujourd'hui que tu le dis. Dans les logiciels que j'utilise tous les jours aucune ne fait vraiment ça, à part le logiciel distant hébergé par Google (spécialisation des résultats de recherche, qui d'ailleurs me gonfle pas mal, et publicité personnalisée). Je ne crois pas qu'on puisse dire aujourd'hui que ça constitue la "grandes majorité des applications", en tout cas sur des distributions GNU/Linux classiques.
J'ai donc très peu d'expérience sur la conception et la structure de ces "applications contextuelles" et je peux difficilement en dire plus sur comment les intégrer à ces modèles de sécurité. Je suis cependant confiant du fait qu'on pourra le faire quand elles se développeront (l'idée est d'isoler le composant qui construit le contexte pour le faire tourner dans un processus à part ayant des droits spécialiser, et de travailler sur son interface avec les autres composants pour qu'elle ne transmette pas trop d'information).
Quand je regarde les applications que j'utilise aujourd'hui (un navigateur web, un éditeur de textes/programmes, des programmes pour lire des images/musiques/vidéos, un client mail, un lecteur PDF, quelques jeux, plus tout le userland invisible qui fait tourner tout ça), elles sont toutes simples à sécuriser par une restriction de droits (approximative au début, puis de plus en plus fine quand les modèles de sécurité s'améliorent), sauf peut-être le navigateur web qui a en plus le problème d'être devenu un sous-monde à part au sein duquel les problématiques de sécurité/compartementalisation se re-posent. Mais je reste confiant qu'un modèle même relativement simple permettrait de réduire de plusieurs ordres de grandeur la surface de la Trusted Computing Base.
Pour moi ce n'est pas au calendrier d'indexer mes mails mais plutôt au client mail de prévenir le calendrier s'il détecte un événement; ou alors à un démon externe de faire la médiation entre les deux. Dans tous les cas le processus calendrier n'a pas besoin des droits sur mes mails.
Je trouverais normal de poser la question une fois, au moment de l'installation du module qui gère ça. Je voudrais que mon système me prévienne par défaut si une application tierce que je télécharge et exécute demande à lire tous mes mails.
(Après on peut imaginer des systèmes de chaînes de confiance où le binaire est signé par ma distribution (ou l'administrateur local ou un site d'audit indépendant ou…), et j'ai dit quelque part que "je fais confiance à ma distribution pour tous les (ou telle famille de) choix de sécurité", et donc on ne pose des questions de ce genre que pour les binaires non-signés. Il y a un compromis à trouver.)
Pour moi dans un bon design il y a des cycles de conception avec une discussion entre les concepteurs du modèle de sécurité et les concepteurs des applications. On commence avec un modèle de sécurité robuste et qui couvre une majorité des cas; si une application ne rentre pas dans le modèle, on doit la mettre à un niveau de privilèges un peu supérieur à ce dont elle aurait eu besoin (dans un système idéal). Ensuite on regarde toutes les applications pour lesquelles le problème s'est posé et on essaie de comprendre comment satisfaire leur besoin, c'est-à-dire comment adapter le modèle de sécurité pour lui faire comprendre que justement, leur besoin ne nécessite pas vraiment autant de privilèges. On modifie le tout, et on recommence.
L'idée spécifique d'aller chercher des sous-titres est bien trop particulière pour être raisonnablement implémentée dans le système de sécurité (ça revient à y mettre des bouts d'application, et donc à le rendre plus complexe est moins sûr), mais il y a sans doute des sur-approximations raisonnables qui capturent ce besoin et d'autres en même temps. J'avais proposé le droit de lire dans un répertoire entré, et un autre commentaire parlait d'autorisations de lecture de certains MIME types seulement.
Pour mplayer on semble être dans le cas "modèle trop simple, besoin de privilèges supérieurs" : il faudrait décomposer mplayer en un processus qui tourne au niveau de privilège bas, et un processus auxiliaire qui est appelé quand l'utilisateur a choisit un fichier pour aller lire dans le répertoire correspondant et chercher des sous-titres. Le processus auxiliaire doit tourner à un niveau de privilège supérieur (accès au système de fichier) mais il est isolé, simple, et donc plus facile à auditer.
Maintenant si Apple a une approche trop rigide et refuse de mettre ces processus un peu trop demandeurs à un niveau de privilège supérieur, ça ne m'étonne pas tellement et ça explique le problème mentionné par la dépêche. Ça n'invalide en aucun cas l'approche globale de permettre aux applications de restreindre au minimum leurs droits.