Empêcher de lire des fichiers qui n'ont pas été sélectionnés par l'utilisateur est une excellente idée qui permettra de sécuriser les applications. Je comprends que le développeur ne veuille pas fournir les efforts nécessaires (en travail supplémentaire pour adapter son code ou au moins abandonner les features) pour respecter ce critère. Mais alors que la dépêche sous-entend que cette restriction est abusive, je pense qu'elle est au contraire adaptée et utile. Je suis un des premiers à critiquer Apple sur sa fermeture, mais dans la situation telle qu'elle est exposée ici je leur donne totalement raison.
Plus précisément: l'intérêt de cette restriction est de pouvoir interdire aux programmes de lire le système de fichier. Quand ils veulent ouvrir un fichier, ils appellent un widget système (à travers une API système) qui va interagir avec l'utilisateur, lui proposer de naviguer dans ses fichiers et d'en choisir un, ouvrir ce fichier (dans le mode demandé par l'application, lecture seule ou lecture+écriture) et renvoyer le descripteur à l'application. Tout l'intérêt tient dans le fait que le widget système peut être un processus différent qui tourne avec plus de privilèges, et qui est le seul à avoir ces droits sur le système de fichier.
Du coup, même si l'application est malicieuse ou bugguée (faille d'injection de code par exemple), comme elle n'a pas accès au système de fichier sa surface d'attaque du système est considérablement réduite (pas possible d'aller chercher les mots de passe stockés en clair dans ~/.config, d'aller écrire en douce dans le fichier de conf d'une autre application pour dire à la webcam de rediriger son flux vers un site pirate louche, de monter une "access race" sur les fichiers temporaires d'une troisième application, etc.). La quantité de code privilégié (trusted computing base) a fortement réduit, il suffit d'auditer le widget système pour vérifier qu'il est solide, au lieu de toutes les applications qui tournent avec les droits utilisateurs.
De plus, cette façon de forcer les accès privilégiés de l'application à passer par une couche de médiation liée à l'interface utilisateur permet de mettre en place de bonnes pratiques à la frontière entre sécurité et interaction. L'application ne peut pas par exemple mentir à l'utilisateur en lui demandant de lui désigner un fichier pour le lire, alors qu'elle compte en fait écrire dedans (corruption accidentelle ou malicieuse): c'est le widget système qui interagit avec l'utilisateur et a toutes les informations en main pour lui annoncer clairement et honnêtement quels droits on lui demande de fournir à l'application (elle veut le fichier en écriture). Cette façon de s'assurer que les informations montrées à l'utilisateur (donc son image mentale de la sécurité de son système) correspondent bien à la réalité renforce la sécurité.
J'invite les gens intéressés par ces considérations à regarder l'article "User Interaction Design for Secure Systems", de Ka-Ping Yee, 2002, que j'ai présenté dans ce billet. Il donne dix principes fondamentaux de l'interface sécurisée, le plus pertinent ici étant "Explicit Authority": "A user’s authorities must only be provided to other actors as a result of an explicit action that is understood by the user to imply granting."
Alors bien sûr, forcer ces restrictions au niveau d'un système entier restreint les possibilités (c'est la contrepartie à payer pour augmenter la sécurité : si on autorise tout ce qui était possible avant, on autorise toujours les attaques, donc on n'est pas plus sécurisé). Il faut travailler pour mitiger ces problèmes, et c'est là qu'il est peut-être possible de critiquer Apple :
Certaines applications (ici le "widget système de droit de fichier") ont par nature besoin de privilèges supérieurs; on va avoir plusieurs couches de droits, et dans un système libre on veut évidemment pouvoir avoir la possibilité d'exécuter, lire, comprendre et modifier les applications à tous ces niveaux de droit (sachant évidemment qu'exécuter des applications privilégiées va demander plus de droit, des confirmations à l'utilisateur, etc.). Si Apple force tous les app writers à se contenter du niveau le plus bas, et se réserve la possibilité d'écrire des applications privilégiées, et bien on peut faire moins de chose avec la plateforme et c'est dommage. Dans un système libre on voudrait pouvoir soumettre des applications à tous les niveau (mais en comprenant que le coût d'audit est d'autant plus élevé).
Il faut être prêt à faire évoluer des APIs un peu trop restrictives pour permettre des usages plus riches. Par exemple la fonctionnalité de "recherche automatique de sous-titre" pourrait être accommodée en ajoutant un appel système pour sélectionner non pas un fichier, mais un répertoire entier dans lequel le logiciel aurait le droit de lire tous les fichiers, donc les films et les sous-titres associés. Il faut comprendre que cet appel donne un peu plus de droits, et il faut que l'utilisateur le comprenne aussi, mais c'est un bon compromis entre "lire potentiellement tout son $HOME" et devoir choisir fichier-par-fichier. Je n'y connais rien, mais peut-être qu'Apple ne fait pas assez d'efforts pour faire évoluer ses APIs dans ce sens. Mais il faut aussi comprendre que toute modification des APIs donnant accès à ces privilèges demande un effort de conception et d'audit important, peut compliquer l'interface utilisateur ou le modèle de sécurité, etc.
Pour résumer, je ne plains pas trop le développeur et je trouve la démarche technique d'Apple intéressante. J'aimerais bien que ma distribution Linux évolue elle aussi vers des modèles de sécurité plus fins que l'antique user/group/owner, sans être non plus complètement inutilisable. Capsicum va dans la bonne direction, mais il faut un effort des projets/frameworks/etc. entre le kernel et l'utilisateur pour intégrer ces principes de conception sécurisée.
# 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.
Empêcher de lire des fichiers qui n'ont pas été sélectionnés par l'utilisateur est une excellente idée qui permettra de sécuriser les applications. Je comprends que le développeur ne veuille pas fournir les efforts nécessaires (en travail supplémentaire pour adapter son code ou au moins abandonner les features) pour respecter ce critère. Mais alors que la dépêche sous-entend que cette restriction est abusive, je pense qu'elle est au contraire adaptée et utile. Je suis un des premiers à critiquer Apple sur sa fermeture, mais dans la situation telle qu'elle est exposée ici je leur donne totalement raison.
Plus précisément: l'intérêt de cette restriction est de pouvoir interdire aux programmes de lire le système de fichier. Quand ils veulent ouvrir un fichier, ils appellent un widget système (à travers une API système) qui va interagir avec l'utilisateur, lui proposer de naviguer dans ses fichiers et d'en choisir un, ouvrir ce fichier (dans le mode demandé par l'application, lecture seule ou lecture+écriture) et renvoyer le descripteur à l'application. Tout l'intérêt tient dans le fait que le widget système peut être un processus différent qui tourne avec plus de privilèges, et qui est le seul à avoir ces droits sur le système de fichier.
Du coup, même si l'application est malicieuse ou bugguée (faille d'injection de code par exemple), comme elle n'a pas accès au système de fichier sa surface d'attaque du système est considérablement réduite (pas possible d'aller chercher les mots de passe stockés en clair dans
~/.config, d'aller écrire en douce dans le fichier de conf d'une autre application pour dire à la webcam de rediriger son flux vers un site pirate louche, de monter une "access race" sur les fichiers temporaires d'une troisième application, etc.). La quantité de code privilégié (trusted computing base) a fortement réduit, il suffit d'auditer le widget système pour vérifier qu'il est solide, au lieu de toutes les applications qui tournent avec les droits utilisateurs.De plus, cette façon de forcer les accès privilégiés de l'application à passer par une couche de médiation liée à l'interface utilisateur permet de mettre en place de bonnes pratiques à la frontière entre sécurité et interaction. L'application ne peut pas par exemple mentir à l'utilisateur en lui demandant de lui désigner un fichier pour le lire, alors qu'elle compte en fait écrire dedans (corruption accidentelle ou malicieuse): c'est le widget système qui interagit avec l'utilisateur et a toutes les informations en main pour lui annoncer clairement et honnêtement quels droits on lui demande de fournir à l'application (elle veut le fichier en écriture). Cette façon de s'assurer que les informations montrées à l'utilisateur (donc son image mentale de la sécurité de son système) correspondent bien à la réalité renforce la sécurité.
J'invite les gens intéressés par ces considérations à regarder l'article "User Interaction Design for Secure Systems", de Ka-Ping Yee, 2002, que j'ai présenté dans ce billet. Il donne dix principes fondamentaux de l'interface sécurisée, le plus pertinent ici étant "Explicit Authority": "A user’s authorities must only be provided to other actors as a result of an explicit action that is understood by the user to imply granting."
Alors bien sûr, forcer ces restrictions au niveau d'un système entier restreint les possibilités (c'est la contrepartie à payer pour augmenter la sécurité : si on autorise tout ce qui était possible avant, on autorise toujours les attaques, donc on n'est pas plus sécurisé). Il faut travailler pour mitiger ces problèmes, et c'est là qu'il est peut-être possible de critiquer Apple :
Certaines applications (ici le "widget système de droit de fichier") ont par nature besoin de privilèges supérieurs; on va avoir plusieurs couches de droits, et dans un système libre on veut évidemment pouvoir avoir la possibilité d'exécuter, lire, comprendre et modifier les applications à tous ces niveaux de droit (sachant évidemment qu'exécuter des applications privilégiées va demander plus de droit, des confirmations à l'utilisateur, etc.). Si Apple force tous les app writers à se contenter du niveau le plus bas, et se réserve la possibilité d'écrire des applications privilégiées, et bien on peut faire moins de chose avec la plateforme et c'est dommage. Dans un système libre on voudrait pouvoir soumettre des applications à tous les niveau (mais en comprenant que le coût d'audit est d'autant plus élevé).
Il faut être prêt à faire évoluer des APIs un peu trop restrictives pour permettre des usages plus riches. Par exemple la fonctionnalité de "recherche automatique de sous-titre" pourrait être accommodée en ajoutant un appel système pour sélectionner non pas un fichier, mais un répertoire entier dans lequel le logiciel aurait le droit de lire tous les fichiers, donc les films et les sous-titres associés. Il faut comprendre que cet appel donne un peu plus de droits, et il faut que l'utilisateur le comprenne aussi, mais c'est un bon compromis entre "lire potentiellement tout son $HOME" et devoir choisir fichier-par-fichier. Je n'y connais rien, mais peut-être qu'Apple ne fait pas assez d'efforts pour faire évoluer ses APIs dans ce sens. Mais il faut aussi comprendre que toute modification des APIs donnant accès à ces privilèges demande un effort de conception et d'audit important, peut compliquer l'interface utilisateur ou le modèle de sécurité, etc.
Pour résumer, je ne plains pas trop le développeur et je trouve la démarche technique d'Apple intéressante. J'aimerais bien que ma distribution Linux évolue elle aussi vers des modèles de sécurité plus fins que l'antique user/group/owner, sans être non plus complètement inutilisable. Capsicum va dans la bonne direction, mais il faut un effort des projets/frameworks/etc. entre le kernel et l'utilisateur pour intégrer ces principes de conception sécurisée.