Author: bleny Date: 2010-07-26 17:02:18 +0200 (Mon, 26 Jul 2010) New Revision: 112 Url: http://nuiton.org/repositories/revision/diswork/112 Log: r?\195?\169flexion sur la s?\195?\169cu dans diswork Modified: trunk/src/site/rst/diswork-fs/devel.rst Modified: trunk/src/site/rst/diswork-fs/devel.rst =================================================================== --- trunk/src/site/rst/diswork-fs/devel.rst 2010-07-26 09:32:54 UTC (rev 111) +++ trunk/src/site/rst/diswork-fs/devel.rst 2010-07-26 15:02:18 UTC (rev 112) @@ -208,4 +208,203 @@ since it can be replaced by a malicious node. Public keys for each nodes should be made available by another means. It may -be a read-only public key store available through HTTP for example. \ No newline at end of file +be a read-only public key store available through HTTP for example. + +Sécurité dans Diswork (French only) +----------------------------------- + +Les systèmes distribués en général et P2P en particulier comme Diswork sont +réputés pour être difficiles à concevoir de façon sûre. + +Commençons la réflexion par un rappel des faits : + +* Diswork daemon est un petit logiciel qui tourne sur une machine et qui propose + à Isis de lui soumettre des jobs. + +* Diswork File System est un système de fichiers utilisé comme sous-couche du + démon. Le truc, c'est que tous les daemon utilisent tous le même système de + fichiers : c'est ce qui les relie entre eux. Lorsqu'un démon reçoit une + soumission de job, en fait, il écrit le job sur le FS, et comme tous les + démons ont accès au FS, il suffit d'aller lire ce qui se trouve sur le FS + pour trouver de jobs. + +* Pour assurer la distribution du système de fichiers sur tous les noeuds. + Diswork FS écrit toutes les données du système dans une seule Map (telle que + java.util.Map). C'est cette Map qui est distribuée entre toutes les machines, + et comme toutes les machines ont accès à la même Map, le système de fichier se + trouve être distribué. Cette Map distribuée, c'est la fameuse DHT, c'est sur + elle que repose tout le système. + +Jusqu'ici tout va bien, le système global fonctionne à mon avis si on omet +l'implémentation de la DHT qui est erratique. + +Le problème qui se pose qui nous intéresse ici est le suivant : que se passe-t-il +si on imagine qu'un individu mal intentionné (au hasard, appelons-le Juan) +décide de nuire au système. + +Juan a de nombreuses possibilités : + +* au niveau du démon on peut déjà soumettre toutes les seconds des jobs qui ne + finissent jamais. Des jobs qui, en fait, envoient du spam ou font crasher la + machine qui les lances (fork bombs) ou encore envoyer des tas de requêtes HTTP + vers un serveur cible ce qui aurait pour effet (en soumettant ce job plusieurs) + de faire participer tous les noeuds diswork à un DDoS. On peut modifier le + code du démon pour réserver un job comme si on allait le faire, puis, en fait, + ne jamais le faire. + +* au niveau du File System, c'est simple, les droits ne sont pas gérés + (et pour cause, voir la suite). Tout est accessible en lecture/écriture. + Juan peut donc faire un petit « rm -rf / ». + +* au niveau de la DHT, nous avons vu que c'est une Map. C'est donc une mémoire + partagée entre tous les nœuds du réseau : et ça, c'est bon pour Juan. Les DHT + ont pour particularité de ne pas permettre, contrairement à toutes les Map + habituelles, de pouvoir parcourir l'ensemble des clés (espace trop grand). + Toutefois, en se documentant un peu (oui, j'ai fait de la doc.) Juan pourra + vite trouver un moyen de trouver tout un tas de clés utilisées dans la Map et + pourra, à loisirs, faire des map.remove() dessus. Je vais pas m'attarder + m'attarde pas sur les attaques possibles qui sont intrinsèques à l'algorithme + et/ou à l'implémentation de la DHT utilisée mais si on parle de l'algo + Kademlia, on peut parler d'attaque Sybil (ou Spartacus) + +Comme on peut le voir, il y a trop de problèmes à trop de niveaux pour espérer +tout réglé mais on va quand même essayé. + +Tentons de régler les problèmes, niveaux par niveaux : + +Commençons par le démon. Envisageons de filtrer les jobs pour ne faire que des +jobs qui sont "gentils" : sur quel critère se baser pour dire que tel ou tel de +job est mauvais ? + +* L'application utilisée ? On peut créer des jobs qui dépendent de Isis (isis + sera téléchargé) mais préciser une ligne de commande pour ce job qui n'a rien + à voir (fork bomb) + +* Le nœud qui a soumis le job ou les résultats d'un job ? Comment savoir quel + nœud a posé ce job sur le FS. Vu que le FS est accessible en écriture pour + Juan, Juan pourrait changer les informations concernant le propriétaire du job + et donc poser un job vicieux et dire qu'il est à Éric (qui est un ange, comme + chacun sait). Même si ce n'était pas le cas, comme savoir que Éric est gentil + et Juan méchant ? Pas moyen. Pour s'assurer de l'origine d'un job, on pense + tout de suite à signer les jobs avec un système de clés asymétriques. Ça ne + change rien, Juan peut signer des jobs et des résultats aussi. Vient alors + encore une idée, on a qu'à faire faire le job par 4 machines différentes, + comparer les quatre résultats et voir si les résultats sont différent. Si un + résultat diffère des trois autres, on considère qu'il a été mal fait par une + machine contrôlée par Juan et on exclue ce résultat pour se baser sur les + trois restants, supposés fiables. Sauf que, comme dit, les jobs ne sont pas + poussés vers ceux qui les font mais posés sur le file-system, d'autres nœud, + en parcourant le FS les trouve. Du coup, Juan peut facilement lancer quatre + nœud (voire un seul nœud), réserver les quatre jobs, calculer (une fois) de + faux résultats, les signer avec des clés différentes et les publier 4 fois + comme 4 résultats faits par des machines différentes (avec un pti délai entre + chaque dépôt pour pas qu'on voit que tout a été fait en même temps...). Juan + est vraiment vicieux. En plus, ça impliquerait de mettre en place un système + pour échanger les clés publiques, il ne faut surtout pas les mettre sur le FS, + Juan pourrait remplacer celle d'Éric par la sienne. On peut imaginer les + mettre toutes sur un serveur à côté, où les clés sont publiées une fois pour + toutes mais comment éviter que Juan y publie ses propres clés ? + +Passons au système de fichier. Pour résoudre les problèmes évoqués ci dessus, on +pourrait souhaiter des droits de le forme UNIX pour le FS distribué (des +utilisateurs, des groupes et des droits lectures/écritures par fichier pour le +propriétaire, le groupe et les autres). Il faudrait stocker ces nouvelles +données dans la Map, c'est pas un problème. Cependant, comme, de toute façon, +c'est Juan qui choisit d'interpréter les données qu'il peut lire dans la Map, +il pourra lire les droits, les ignorer, et lire le fichier quand même : il +suffit de faire des get(). + +Et si on crypte ? Et bien Juan n'arrivera pas à lire les données, c'est déjà ça +de pris. Encore faut-il savoir avec quelle clé crypter. Celle du propriétaire ? +Non, le membres du groupe ne pourrait pas lire. Celle du groupe alors ? Oui, +c'est déjà mieux. En fait, il faut choisir le clé en fonction des droits. Quand +on écrit le fichier, il faut crypter avec la clé du groupe si le groupe a accès +en lecture, celle du proprio si le groupe n'a pas accès en lecture et ne pas +crypter si tout le monde a accès en écriture. Ça suppose que le proprio +appartienne au groupe (c'est pas absurde). Encore faut-il ne distribuer la clé +du groupe qu'à ceux qui sont dans le groupe et ne pas la divulguer. Ça peut +s'imaginer disons, en déposant dans le home d'un utilisateur un fichier qui +contient la clé du groupe cryptée avec la clé publique de l'utilisateur qu'on +veut ajouter au groupe. On retombe sur le problème des clés publiques parce +que si je la mets sur le FS, elle doit être en clair pour que tout le monde +puisse m'ajouter à un groupe et donc, Juan peut m'usurper. Du coup, il faut +distribuer les clés publiques par l'extérieur du FS (via HTTP par exemple) et +là, on peut croire qu'on est bon. Encore faut-il supposer qu'on ne peut pas +changer les proprio et groupe d'un fichier (parce qu'on ne peut pas re-crypter +sans la clé privée) et qu'ils sont donc fixés à la création et immuables. Ne +parlons pas du cas où on souhaiterait exclure un utilisateur d'un groupe : la +clé lui a déjà été divulguée et donc, il faudrait ré-encoder tous les fichiers +(plusieurs Go ?) de ce groupe avec une nouvelle clé... + +On a donc réussi à faire un système qui permet à un utilisateur d'écrire ses +fichiers et de les lire sans que personnes d'autres ne puissent les lire. C'est +intéressant mais parfaitement inutile dans le cas de Diswork vu que tous les +fichiers doivent être partagés. Autre possibilité, y'a qu'à les mettre dans le +groupe "diswork", sauf qu'il faudrait savoir comment un noeud honnête peut +rejoindre se groupe ou pourquoi Juan, lui, ne pourrait pas en se faisant passer +pour honnête (voire faire quelques jobs bien), puis trahir plus tard. Donc le +groupe, ça marche pas vraiment, donc autant tout mettre en clair. Donc retour +à la case départ. + +Mais, y'a pire ! Là, au niveau du FS, on a vu qu'on pouvait embêter Juan s'il +voulait faire un get() en lui rendant la valeur lue incompréhensible. Peut-être, +mais ça n'empêchera pas Juan de faire un remove() d'une clé, ou un put() avec +des données vides voire des grossièretés. Donc de toute façon, on peut peut-être +l'empêcher de lire, il reste toujours à Juan la possibilité de supprimer nos +données. + +C'est ce qui m'amène à penser que, finalement, le problème, c'est soit la DHT +soit son utilisation. + +Suivons la première hypothèse, la seule échappatoire que je vois, c'est +d'utiliser une DHT qui gère les droits au niveaux des clés. +Je ne connais aucune DHT qui permet cela. + +Maintenant, faisons un peu d'histoire. +Rappelez vous l'époque où il était très facile d'écrire des malwares. +Il suffisait de faire un peu de C ou de tout langage bas niveau, on pouvait +aller taper tout simplement dans la mémoire vive, faire un malloc sur un tableau +et écrire au delà de l'espace alloué et, du coup, écrire sur le reste dans la +mémoire : en allant assez loin, on écrit sur la mémoire utilisée par les autres +processus voire sur celle utilisée par l'OS. Pareil pour détruire des système +de fichiers, on court-circuite le système de droit ou la possibilité de +parcourir le FS en écrivant direct des I/O sur le disque dur, on arrivera bien à +abîmer quelque-chose... + +Ce temps est aujourd'hui révolu. Aujourd'hui les programmes n'ont accès qu'à la +mémoire qui leur est allouée par l'OS. Ça clos le problème. + +J'y vois une analogie avec notre DHT. Notre DHT, c'est notre mémoire partagée et +on en est au même point. N'importe qui peut écrire n'importe-quoi. Qu'il s'agisse +de la gestion de la RAM (mémoire partagée entre différents processus locaux), +ou d'une DHT (mémoire partagée entre des processus distants), on a la même +problématique, peut-être que la solution de l'une peut solutionner l'autre. +C'est la réflexion que je suis en train de mener et j'ai une piste. + +Seconde hypothèse, on a pas compris le principe (et on est pas les seuls à +s'être planté, Pastis est un exemple) et pour faire un système de fichier P2P, +on a pas la bonne approche. Peut-être qu'il faut utiliser la DHT autrement, +voire ne pas utiliser une DHT mais pour l'instant je ne vois pas de meilleure +solution que l'actuelle, étant donné le CdC. + +Finalement, utiliser de la cryptographie asymétrique, que ce soit pour crypter +ou signer, ça fera joli mais c'est jamais que répondre à côté de notre +problématique. Y'a un côté pavlovien "sécurité = crypto". + +Le problème est intrinsèque à la DHT qui ne gère pas les droits. Je ne connais +pas de DHT qui le fasse mais j'ai, pendant mes insomnies régulières, des idées +qui surgissent sur la question, j'en ferai part si je sens que ça peut aboutir, +encore quelques nuits... + +Tel que je vois la conception actuelle de Diswork, je pense que le plus sage +pour l'instant est la solution de placer la sécurité à la périphérie, et de +veiller à ce que seuls des nœuds de confiance se connectent au système global. +Ainsi, on cloisonne le système, c'est pas absurde si les noeuds peuvent se +trouver dans un même labo comme c'est le cas pour Isis. + +Ou alors... il faut tout remettre à plat, et envisager pour une prochaine +version de Diswork, de s'y prendre autrement, avec une DHT utilisée autrement +ou sans DHT. Mais là, je sèche parce que vu les contraintes exprimées, il y +avait pas tellement possibilité de faire autrement... + +26/07/2010 \ No newline at end of file