gasche a écrit 1151 commentaires

Il me semble intéressant de noter que des trois services "haut profil" que tu cites (LinuxFr, Tumblr, Github), seul Tumblr utilise PHP et encore, ils essaient de s'en débarrasser en utilisant d'autres langages en backend et en limitant PHP au frontend (où ils ont aussi du Ruby sur les bords, je crois). Du coup l'argumentation selon laquelle c'est la disponibilité d'une implémentation PHP qui a fait le succès de Markdown me semble un peu curieuse (d'ailleurs l'implémentation de départ était en Perl). Alors oui les wiki privées, mais n'est-ce pas un usage de plus en plus marginal aujourd'hui, ou au moins réservé aux utilisateurs avertis qui peuvent se trouver un hébergement qui leur permet de choisir le langage serveur ?

PHP est un langage pourri qui a la chance d'être facile à déployer et d'avoir plein de tutoriels douteux qui traînent de l'époque du "web 1.0", et à qui on est ravi de souhaiter une belle mort. Ensuite on pourra se plaindre de Python et Ruby, et ce sera une douleur moins désagréable.

Si des gens trouvent encore amusant de coder des parseurs pour des langages réguliers en utilisant des expressions régulières illisibles dans un langage rétrograde, on leur souhaite bien du plaisir. Et c'est super de faire du logiciel libre, et j'aime bien la GPLv3.

Je trouve que la comparaison avec l'existant est essentielle pour se faire une idée d'un projet.

Quelles sont les similarités et les différences avec les langages Inform (site officiel) ou TADS ?

Il y a eu une discussion sur LinuxFR suite à une dépêche sur la sécurité des applications tierces sous iOS, et cet article parle de ChromeOS, donc je compare les deux. Si tu veux que des gens parlent de la sécurité des applications sous Android, crée un journal ou une dépêche avec des liens qui en disent des choses intéressantes, ça lancera certainement une discussion aussi.

Effectivement on ne s'est pas bien compris. Ce que je veux dire c'est que dans la tradition des systèmes à capacités, les données vont avec leur droit d'accès. Il n'y a plus de donnée "plate" sur laquelle tu fais des actions, tirées d'un ensemble global d'actions possible, en y étant autorisé ou pas par une politique de sécurité, chaque donnée vient avec l'ensemble des opérations qu'elle permet et c'est ce que tu utilises pour agir dessus. Par exemple les "file descriptors" utilisés en mode Capsicum contiennent des masques qui indiquent les droits que la possession du fd donne sur le fichier (ou plus généralement la ressource) correspondant. Donne ce fd à quelqu'un, et tu lui transfères du même coup ces droits. Et tu les as parce qu'à ton démarrage le système te les as fournis.

(Ça c'est dans un mode "tout capacité; capsicum est un système hybride unix/capacités où un processus lancée depuis le shell classique va avoir tous les droits de l'utilisateur, et donc la possibilité de "forger" ces file-descriptor avec les droits un peu qu'elle veut. Ensuite elle demande explicitement à passer en "mode capabilités" et il devient impossible de forger de nouveaux fd, on peut seulement en utiliser des existants ou en obtenir en communiquant avec un autre process)

si je pige bien, ce qui fait la spécificité de capsicum ( qui va aussi séparer les objets manipulé ), c'est le fait que la source primaire de la politique appliqué sur les objets soit le programme lui même ( via son code ), et pas une base de référence externe

Oui, c'est une différence plus concrète et moins philosophique. Ça fait qu'à mon avis les deux sont complémentaires : au développeur de réduire au maximum les droits demandés par son application en utilisant Capsicum ou autre, et l'admin de la machine peut par dessus rajouter des politiques SELinux/AppArmor qui correspondent à des contraintes supplémentaires locales (au risque de rendre inopérantes certaines fonctionnalités de l'appli). Un aspect important de l'approche "la sécurité est dans le code" est qu'en pratique pour ne pas utiliser trop de droits il faut un bon design, et le design il est décidé par le programmeur, donc il vaut mieux qu'il soit impliqué dans le début dans les questions de sécurité plutôt que mettre ça en jeu "après coup" avec un outil qui fonctionne "à l'extérieur".

séparer ton process en composant ( ie ce que le papier appelle "logical applications" ) reviens plus ou moins à refaire le travail de l'os ( qui sépare tout sous forme de process )

Il y a une légère incompréhension ici: les autres de l'article proposent de changer les applications en les découpant en plein de petits processus pour faciliter le partage des privilèges (par exemple au lieu de faire tourner dans le processus maître le parsing des données utilisateur, on se méfie de cette tâche propices aux buffer overflow et on le fait tourner dans un sous-process forké depuis le maître, à qui on passe juste les file-descriptor des données concernées et aucun autre droit). Ils désignent par "logical application" le groupe de processus qui coopèrent pour faire ce que veut l'utilisateur, correspondant au process monolithique que tu avais avant.

Un exemple de découpage intéressant que j'utilise souvent : aujourd'hui quand tu veux ouvrir un fichier dans ton éditeur de texte, le code appelle la fonction "OpenFile" de l'API que tu utilises (Gtk ou Qt par exemple), qui va te proposer de naviguer dans ton filesystem. Ça veut dire que pour proposer cette fonctionnalité le programme doit avoir le droit de lecture sur tout le filesystem. Si à la place tu appelles un processus privilégié auxiliaire qui prend tes métadonnées en entrée (le type de fichier que tu veux, les droits que tu demandes dessus, tout ça), interagis avec l'utilisateur, et te rends le file_descriptor qui va bien ensuite, le programme lui-même n'a plus besoin de droit de lecture/exploration sur le filesystem, et c'est une grosse catégorie d'exploitations en moins à considérer en cas de faille d'injection de code. Mais pour pouvoir réduire ces privilèges il est crucial d'avoir pensé au découpage de l'application en plusieurs processus selon les bordures des droits nécessaires au fonctionnement des différentes parties.

Évidemment ça conduit à une augmentation des coûts de communication, mais personnellement j'abandonnerais avec plaisir un petit peu de perfs pour beaucoup plus de sécurité. C'est un peu la même chose que le débat {micro,macro}kernel, mais dans un domaine où les découpages restent plus gros et les performances souvent moins contraintes par la communication.

Avec capsicum la gestion des droits est totalement dynamique : ce n'est pas un choix préalable de "labels" qui détermine les autorisation de sécurité, ce sont les données que tu as (par exemple les descripteurs de fichiers ouverts) qui contiennent des restrictions sur l'usage que tu peux en faire, mais que tu peux transférer avec leurs droits à qui tu veux, sous forme de données. C'est un modèle plus flexible mais aussi moins structuré que ce qu'il y a dans les LSM.

Si ça t'intéresse il y a plus d'explications (liens pour approfondir, etc.) dans la dépêche Capsicum.

'_a n'est pas une variable polymorphe, c'est une variable d'inférence encore inconnue, mais son premier usage fixera sa valeur (donc le bout de code que j'ai mis, qui l'utilise à deux types différents, va échouer avec une erreur de typage). Pour plus de détails sur pourquoi le + règle le problème, il faut lire (le début de) l'article sur la "relaxed value restriction".

# Foo.inject [];;
- : '_a list Foo.foo = <abstr>


# Foo.inject [];;
- : 'a list Foo.foo = <abstr>

Tu ne jouais pas au jeu des sept différences quand tu étais petit ?

let li = Foo.inject [];;
List.iter print_int li;;
List.iter print_string li;;

Tu as dû te tromper, chez moi Foo.inject [] ne donne pas le même résultat dans le premier cas.

La covariance est là pour permettre la généralisation polymorphe des expressions de la forme T.cast "foo" (essaie sans et avec le +). J'en parle ici sur reddit. La fonction de cast va renvoyer un terme polymorphe de type 'a T.t, à toi de l'utiliser de la façon qui va bien (je suis d'accord sur le fait que, du coup, l'exemple est un peu bizarre).

J'ai toujours un pincement au cœur quand j'entends une personne de plus qui utilisait une couche logicielle quasi-entièrement libre passer définitivement à une couche logicielle majoritairement propriétaire, mais je suis bien conscient que c'est causé par des manques réels et qu'il n'y a pas grand chose à faire d'autre que d'essayer de contribuer à l'amélioration de la couche libre—en particulier, il n'y a pas grand chose à gagner à critiquer les gens qui migrent.

Donc oui tu es déçu de GNU/Linux et de sa communauté, en plus tu apprécies les qualités techniques (véritables) du logiciel Apple, c'est ton droit le plus strict et tant mieux si tu as trouvé ton bonheur. Tu parles beaucoup des qualités de OSX pour les bidouilleurs, est-ce que tu as des exemples de logiciels libres intéressant qui les exploitent, de gens qui ont fait la migration comme toi et qui ont ensuite créé des choses sympa ? Ça pourrait être une bonne idée de journal. Je demande ça parce que j'ai souvent l'impression que les gens qui migrent vers OSX pour "arrêter de se prendre la tête" arrêtent aussi en même temps de bidouiller leur système, et utilisent donc surtout des logiciels upstream au final assez classiques; ce qui est tant mieux si ça correspond au besoin (je suis sûr que plein de bidouille dont on est fier n'a pas au final un effet si important sur la productivité), mais diminue un peu l'utilité des aspects "scriptables et bien documentés".

Si le design et les brevets d'Apple étaient si triviaux, pourquoi personne n'a sorti un équivalent de l'iPhone avant ?

Je suis un peu choqué par cet argument au milieu d'un post qui me semble globalement de bonne foi. Je n'ai rien à dire sur les "design d'Apple" (je n'y connais rien), mais les brevets utilisés dans les procès dans le monde mobile, oui, sont généralement triviaux. Sachant que les brevets logiciels sont par nature insensés et de fait triviaux, mais que les procès pour violation de brevet continuent pourtant à "fonctionner" dans le domaine, la liste des procès lancés par Apple, avec une bonne moitié de perdu, suffit à se convaincre que les brevets mis en jeux étaient triviaux.

Je remarquerai moi-même que, d'une part, une partie de ces procès ont été intenté en "contre-attaque" vis-à-vis de concurrents (pas de jugement négatif sur Apple méchant loup dans ce cas), et qu'il est possible que certains de ces brevets reposent en fait sur l'aspect matériel et soient donc dans ce cas digne de considération; mais j'ai regardé vite fait les sources sur ces procès et c'est surtout du logiciel: regardez par exemple cette liste de brevets contre HTC, avec de belles pépites comme "Object-Oriented Graphic System", qui d'ailleurs est effectivement une innovation de NextSTEP mais paraît difficilement brevetable.

Bref, oui l'iPhone a provoqué un changement des usages dans le milieu de la téléphonie mobile (comme l'iPod pour la musique) et ce sont des produits innovants, et par ailleurs tu as tout à fait le droit de te sentir de la loyauté vis-à-vis d'une entreprise remarquée pour son excellence technique, mais ça ne légitime en aucun cas les brevets logiciels qui sont toujours nocifs, à l'industrie mobile (mais les autres sont tout autant des chacals, en particulier Microsoft qui fait un racket abject), mais surtout à l'informatique en général.

Défends Apple si tu veux. Mais pas ses brevets.

Mais bon, le mépris envers l'extérieur va avec le nombrilisme…

Le mépris se signale par les remarques désagréables comme celle-là. Alors oui tu as raison de signaler qu'il y a des gens désagréables dans le monde du libre, mais ça n'est en aucun cas une excuse pour reproduire ce comportement.

C'était pareil dans le cas précédent (si j'ai bien interprété la question sur l'agenda): si ton client de messagerie invoque un processus fils agenda, il doit bien choisir quel agenda invoquer (un logiciel en dur ou un choix système) et surtout lui fournir les données ou requêtes à traiter (donc il faut un accord sur le protocole de communication).

Il faudra donc aussi contrôler quelles applications sont exécutables par d’autres ?

Oui bien sûr, si tu fais tourner des processus avec des droits restreint, il faut que leur propres processus fils aient eux aussi ces droits restreints et pas d'autres. Si une application qui tourne sans les droits sur le fichier essaie de lancer grep dessus, ça va échouer, puisqu'il tournera dans un environnement sans les droits.

Sinon, comme mon client de messagerie pourra lancer mon agenda ?

Il ne va sans doute pas créer un processus fils pour l'agenda, mais plutôt envoyer à l'agenda déjà présent un message pour lui transmettre des données, sur un canal système. À charge du système de démarrer le processus s'il n'est pas encore lancé, avec les bons droits pour l'utilisateur (et le mode choisi, etc.).

Encore une fois, il est facile de remédier à ce problème :

• Tu peux tout simplement faire tourner la partie de "grep" qui parcours récursivement le répertoire à un niveau de droits supérieur (je l'ai dit dans mon premier message); on va évidemment avoir besoin de faire ça pour un certain nombre d'outils de base

• Tu peux redistribuer les responsabilités : au shell d'ouvrir les fichier en lecture ou écriture ou (pour les répertoires) parcours (récursif ou non), et les utilitaires reçoivent seulement les (listes ou arbres de) descripteurs de fichiers et travaillent dessus sans savoir d'où ils viennent.

Ces solutions sont bien connues. Le deuxième design est par exemple discuté (brièvement, section 3.2) dans la thèse de 2006 de Mark Miller: "Robust Composition, Towards a Unified Approach to Access Control and Concurrency Control".

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.

Mouais. Je ne suis pas surpris par ton histoire, je connais pas mal d'utilisateurs Mac qui ont exactement le même parcours. Fatigue d'administrer son système (au début c'est fun mais on s'en lasse), "ça marche, etc.".

En même temps, je pense qu'il est aussi facile d'utiliser un système GNU/Linux avec peu d'administration. L'idée est que au lieu de mettre à jour tous les quatre matins, on utilise des versions de distribution qui changent peu souvent (Debian stable, Ubuntu LTS, what have you), en utilisant un petit nombre de versions indépendantes pour les logiciels qu'on veut vraiment avoir à jour (le navigateur web). C'est un choix conscient à faire, "je veux trouver la méthode qui minimise les efforts d'administration", qui n'est pas forcément ce qu'on fait naturellement quand on découvre un système ultra-bidouillable.

Il reste potentiellement du boulot au moment des mises à jour, moi je me prévois toujours une journée d'administration, mais si on fait pas plus souvent que tous les 6 mois, ou même tous les 3 ans, ça me semble très rentable comme "prix" à payer pour la satisfaction d'utiliser un système libre.

Les qualités techniques d'OSX et le degré de finition de leur interface graphique, ça n'est (j'espère) une nouvelle pour personne. Il n'empêche qu'à mon avis on peut aussi utiliser un système libre "sans se prendre la tête", et c'est de plus en plus facile (à une époque on avait des difficultés de cartes graphiques, pour la 2D au moins c'est fini, ensuite il y a eu des difficultés avec les cartes Wifi c'est un lointain souvenir, etc.).

J'avais envie de répondre "rien à cirer des daltoniens :)" juste pour déprimer au prochain commentateur degré zéro qui me fait une longue tirade sur l'importance de l'accessibilité blabla. Il est clair que rouge/vert est juste une façon de désigner la distinction et ne dit rien de l'implémentation, la façon dont ce sera présenté à l'utilisateur (parce que s'il fallait comprendre qu'on aura vraiment des icônes teintées en rouge et d'autres en vert, pas besoin de l'argument daltonien, disons juste qu'une interface qui fait vomir peut nuire à la sécurité).

Tu me montres un exemple où l'expressivité du modèle de sécurité est insuffisante, et aboutit à un choix non-optimal pour la sécurité. Soit, il est évident que de tels exemples existent (quel que soit le modèle de sécurité). Je n'ai pas dit qu'on devait prendre le modèle tel quel sans raffinement, et que les modèles à prendre permettraient de résoudre tous les problèmes, mais seulement qu'ils représentaient des améliorations importantes par rapport à l'existant (où tout est dans la zone rouge si on veut), et qu'ils permettaient de rendre une majorité de situations sûres. Il y aura toujours des cas à part à traiter à part.

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 ?

Là c'est un problème d'architecture du browser, si c'est un processus monolithique qui gère à la fois des informations sensibles (mots de passe) et la communication avec des sites potentiellement hostiles il y a un problème.

On pourrait imaginer réorganiser le système de la façon suivante : le navigateur ne stocke aucun mot de passe, il communique avec un "démon d'authentification internet" qui le gère. Plus précisément quand le navigateur reçoit un formulaire qui demande des données sensibles, il le donne au démon avec l'adresse de validation. Le démon s'occupe de regarder s'il a les données dans sa base (le mot de passe du site mais pourquoi pas le numéro de téléphone de l'utilisateur si le site fait partie de ceux pour lequel l'utilisateur a dit qu'il faisait confiance pour accéder au numéro), interagit avec l'utilisateur pour les données qui lui manquent, envoie la requête au site web et redirige vers le browser la réponse du site web.

Avec cette organisation la partie de code à auditer/analyser/faire tourner à un niveau de privilège supérieur est beaucoup plus réduite, c'est ce démon plus simple à coder et ayant moins de fonctionnalités, peu d'interaction avec l'extérieur (en particulier aucun parsing de formats sophistiqués, grosse cause de failles), pas de plug-ins etc., et le navigateur n'a plus besoin du droit de gestion du mot de passe. Du côté de l'utilisateur l'ergonomie est toujours la même, on ne lui demande pas plus souvent son avis qu'avant.

(Il reste un soucis potentiel: le navigateur peut envoyer des requêtes au démon qui ne correspondent pas à une action réelle de l'utilisateur. C'est un problème non-critique puisque, comme c'est le démon qui décide d'envoyer les infos sensibles au site, il a son adresse, il peut vérifier qu'il n'envoie pas l'information à n'importe qui (pas besoin de faire confiance au navigateur sur l'identité du destinataire). Mais il peut toujours envoyer des informations qui n'ont pas été demandées. On pourrait imaginer que les sites webs qui demandent des informations sensibles signent leurs formulaires avec leur clé publique pour que le démon puisse vérifier que ça correspond à une demande réelle, mais c'est un raffinement plus coûteux à mettre en place puisqu'il demande des efforts de la part des autre aussi.)

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).

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.

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 erreur¹.

¹: 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.

l'utilisateur ne peut pas forcément faire le lien entre les autorisations et leurs implications.

C'est justement le rôle des concepteurs de l'interface utilisateur que de faire le maximum pour que le lien soit clair et concret.

Mais que propose-tu qui lui permette de choisir une option qui protège ses données en connaissance de cause.

Je ne suis pas un spécialiste du domaine donc je ne suis pas au courant de toutes les propositions. Une idée simple pour commencer est de mettre en place une séparation (des données, personnes, programmes etc.) en deux niveaux, "je fais confiance" (zone verte : données bancaires, documents de travail, documents administratifs…) et "je ne fais pas confiance" (zone rouge : tout le reste). Les deux systèmes fonctionnent en isolation, avec impossibilité de transférer des données de l'un à l'autre, ou au moins besoin d'une autorisation forte de l'utilisateur. Les pièces jointes des mails envoyés vont par défaut dans la zone rouge, sauf celles de certains contacts que l'utilisateur a explicitement marqués "verts", etc. C'est un système assez basique d'un point de vue de l'expressivité, mais déjà très utilisable et clair pour l'utilisateur (zone rouge, zone verte, c'est clair).

Butler Lampson avait fait un exposé sur le sujet au collège de France l'année dernière, tu peux regarder les slides qui contiennent des détails techniques supplémentaires (un peu saugrenus à mon avis mais bon).

Bien sûr seulement deux niveaux c'est un peu grossier, on veut raffiner le modèle pour traiter des cas plus avancés, mais c'est le genre d'idées à explorer (que ce soit le design qu'on choisisse d'adopter finalement ou non) si on veut quelque chose d'à la fois utilisable et sécurisé.

Et LLVM ça compte pour du beurre ?

Personne ne peut deviner à la place de l'utilisateur si le fichier texte qui contient les prénoms de ses chats est sensible (parce que c'est sa question secrète sur GMail) ou non. Plus généralement, tu ne pourras jamais avoir de système sécurisé de façon satisfaisante si l'utilisateur n'est pas impliqué dans les décisions de sécurité (encore une fois je ne parle pas de protéger l'intégrité du système contre les utilisateurs, mais de protéger leurs données).

L'utilisateur a du mal à utiliser les mauvaises interfaces utilisateurs, et c'est la faute du développeur, pas de l'utilisateur. Les gens font des choix de sécurité tous les jours dans la vraie vie, ils seraient certainement capable de le faire sur leur ordinateur.

Par ailleurs je trouve votre approche de "de toute façon l'utilisateur ne comprend pas" assez douteuse. Lu hors de contexte, ça peut paraître hautain et méprisant (je ne pense pas que ça corresponde à ton opinion, mais c'est ce qu'il en paraît). L'idée de "l'utilisateur ne comprend pas" en informatique n'est pas là pour nous convaincre que les utilisateurs sont des débiles, mais pour critiquer les interfaces utilisateurs trop compliquées qui forcent l'utilisateur à prendre des décisions qui n'ont aucun rapport avec sa vision de son activité (par exemple lui demander de choisir le mode de chiffrement WPA quand il veut juste se connecter à un réseau wifi). Ici il s'agit de tout autre chose, puisqu'on lui pose des questions sur des concepts liés à son usage de l'ordinateur et qu'il comprend (acceptes-tu de donner telle information/capacité aux auteurs du logiciel que tu es en train d'installer ?), sur lequel il peut donc faire des choix et est même parfois le seul adapté pour cela.

Et donc le développeur il doit fournir des règles SELinux, et des règles AppArmor, et Tomoyo, et Akari, et whatever other Linux Security Module incompatible avec tous les autres les gens du milieu de la sécurité décident de distribuer ?

À côté le packaging c'est rigolo.

(Je veux dire qu'un système donné ne peut faire tourner qu'un seul LSM à la fois, et que donc ce sont les distributions ou administrateurs qui font le choix duquel utiliser, le développeur peut difficilement anticiper ces choix.)

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.

Et d'ailleurs pour les lecteurs qui voudraient plus de détails croustillant, il y a une dépêche sur l'histoire du développement de ce seccomp 2.0.

Je ne comprends pas ta réaction en proverbes, citations et platitudes. Oui, il y a toujours des gens qui cherchent (et trouvent) des failles dans un système suffisamment complexe, mais ce n'est pas une raison pour faire des choix de conception qui leur facilitent la tâche. On sait construire des systèmes plus robustes que ce qu'on a aujourd'hui, mais il est difficile d'obtenir l'effort demandé.

Et non, on ne doit pas abandonner sa liberté pour avoir la sécurité, moi je veux un système à la fois libre et sécurisé (et oui, et c'est possible). Par ailleurs si des personnes ont choisi d'utiliser du logiciel Apple, leur liberté (sur ce plan) est mal barrée, et elles n'étaient sans doute motivées ni par la liberté, ni la sécurité… Ce n'est pas une raison pour se mettre la tête dans le sable et refuser de reconnaître au moins que l'idée, techniquement, a du mérite.