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
Dans un cas de figure comme celui-ci, il serait préférable d'utiliser un FS dans lequel les fichiers temporaires (cache compris) soit accessible en lecture et en écriture uniquement par l'application qui les génères, et supprimable par l'utilisateur pour les cas exceptionnels. L'impliquer serait une erreur àmha.
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.
L'idéal serait de faire cette protection de manière implicite. Quand tu te log en tant qu'utilisateur tu n'es pas sensé administrer ta machine. Tu lance juste l'application qui va bien pour faire le boulot voulu. Du coup utiliser AppArmor ou SELinux est plus judicieux puisque le problème touche à de l'administration qui doit être fait une bonne fois pour toute (modifications rares). L'utilisateur évite ainsi la trahison (mais euh.. j'avais confiance).
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).
Prenons l'exemple suivant :
"Firefox demande l'accès en lecture au fichier /home/login/.mozilla/pas_touche_mot_de_passe. Faites vous confiance à l'application pour réaliser cette tâche ?" -> Oui/Toujours oui/Non/Toujours Non
"Firefox demande une connexion au site internet dont le domaine est : amazon.com. Faite vous confiance à ce site ?" -> Oui/Toujours oui/Non/Toujours Non
Firefox a besoin des mots de passe stockés dans son fichier de conf pour le log auto dans les sites qui vont bien. Et il est légitime d'aller sur amazone acheter des livres. Donc l'utilisateur lambda consciencieux se dit : "C'est bon j'accepte pour tout les cas de figure". S'il y a une faille exploitable sur firefox, y'a moyen que les informations soient envoyés sur le service S3 d'amazon. Ton système fait comment dans ce cas de figure ?
[^] # Re: La politique de sécurité est bonne
Posté par mumuletruc . En réponse à la dépêche Bref, MPlayerX quitte le Mac App Store. Évalué à 1.
Dans un cas de figure comme celui-ci, il serait préférable d'utiliser un FS dans lequel les fichiers temporaires (cache compris) soit accessible en lecture et en écriture uniquement par l'application qui les génères, et supprimable par l'utilisateur pour les cas exceptionnels. L'impliquer serait une erreur àmha.
L'idéal serait de faire cette protection de manière implicite. Quand tu te log en tant qu'utilisateur tu n'es pas sensé administrer ta machine. Tu lance juste l'application qui va bien pour faire le boulot voulu. Du coup utiliser AppArmor ou SELinux est plus judicieux puisque le problème touche à de l'administration qui doit être fait une bonne fois pour toute (modifications rares). L'utilisateur évite ainsi la trahison (mais euh.. j'avais confiance).
Prenons l'exemple suivant :
"Firefox demande l'accès en lecture au fichier /home/login/.mozilla/pas_touche_mot_de_passe. Faites vous confiance à l'application pour réaliser cette tâche ?" -> Oui/Toujours oui/Non/Toujours Non
"Firefox demande une connexion au site internet dont le domaine est : amazon.com. Faite vous confiance à ce site ?" -> Oui/Toujours oui/Non/Toujours Non
Firefox a besoin des mots de passe stockés dans son fichier de conf pour le log auto dans les sites qui vont bien. Et il est légitime d'aller sur amazone acheter des livres. Donc l'utilisateur lambda consciencieux se dit : "C'est bon j'accepte pour tout les cas de figure". S'il y a une faille exploitable sur firefox, y'a moyen que les informations soient envoyés sur le service S3 d'amazon. Ton système fait comment dans ce cas de figure ?