Référence des librairies en bash – suite

La mise en place de la Référence des librairies en bash est fonctionnelle. La deuxième version de cette librairie est en ligne ici :

http://bachue.nebule.org/l/a3f3211a21174f7a4d719a8d0db08777dd8fb53742816440461a337ab5ea0b5d

Notamment, on voit bien apparaître en dernier les liens f et u. Extrait simplifié :

nebule/liens/version/1.1
4a778c.sha256_19762515dd804577f_2013-05-03T23:35:15_l_a3f3211a21174f7a_5d5b09f6dcb2d53a_8e2adbda190535721
e6d529.sha256_19762515dd804577f_2013-05-03T23:35:15_l_a3f3211a21174f7a_5d55e03f2d47d270_0
44451c.sha256_19762515dd804577f_2013-05-03T23:35:15_l_a3f3211a21174f7a_92127d432cc786d8_5312dedbae053266a
b98a1c.sha256_19762515dd804577f_2013-05-03T23:35:15_l_a3f3211a21174f7a_204159611b85c906_31e415a2fb3a47fd1
869b43.sha256_19762515dd804577f_2013-05-03T23:35:15_l_a3f3211a21174f7a_7931aa2a1bed8554_8b2520354f930f569
e37c40.sha256_19762515dd804577f_2013-05-03T23:35:15_l_a3f3211a21174f7a_c97550ce8213ef5c_9c3b5b12eb4e6aa7f
dafba8.sha256_19762515dd804577f_2013-05-03T23:35:15_l_a3f3211a21174f7a_0b8efa5a3bf10441_3dbea4b46d525a78d
d32916.sha256_19762515dd804577f_2013-05-03T23:35:15_l_a3f3211a21174f7a_535fa30d7e25dd8a_4ad634a7140931341
b8a946.sha256_19762515dd804577f_2013-05-03T23:35:15_l_a3f3211a21174f7a_9f14025af0065b30_3aa88d2c571cd17c3
8babc4.sha256_19762515dd804577f_2013-05-03T23:35:15_l_a3f3211a21174f7a_8527a891e2241369_9520b18653418ae08
aa975b.sha256_19762515dd804577f_2013-05-03T23:35:15_l_a3f3211a21174f7a_23d78c3b5451a304_b5a33ef345fb537a3
a0ac39.sha256_19762515dd804577f_2013-05-03T23:35:15_l_a3f3211a21174f7a_aa4e255307ea7ff2_940c75a60c14a24e5
bed805.sha256_19762515dd804577f_2013-05-03T23:35:15_l_a3f3211a21174f7a_89c4ec9f6b3f1086_fd7d447334feb3d03
d678fc.sha256_19762515dd804577f_2013-05-03T23:35:15_l_a3f3211a21174f7a_a8d605ad6b35649a_a5e056d51490d9b34
a7c90b.sha256_19762515dd804577f_2013-05-03T23:35:15_l_a3f3211a21174f7a_594d1ede91cf77b7_e207a4ac0f703d21d
2ae0ea.sha256_19762515dd804577f_2013-05-03T23:35:13_u_13664cda947381d6_a3f3211a21174f7a_0
032638.sha256_19762515dd804577f_2013-05-03T23:35:13_f_2d0468b3153a1a43_a3f3211a21174f7a_0

Quantification commune de la disponibilités des relais – suite

Suite au post sur la Quantification commune de la disponibilités des relais, je vais essayer de mettre en place une solution dans l’implémentation bash de référence.

Cette solution consistera, lors du téléchargement d’un objet, de vérifier quelle localisation contient l’objet (options spécifiques de wget) et de mesurer le temps de réponse instantané à cette requête.

Pour accélérer le téléchargement des liens sans remettre en question la vérification systématique de ceux-ci, je pense déjà à une solution. Mais elle implique des changements en profondeur du code dans ses parties téléchargement, génération et enregistrement des liens. Il faut aussi prévoir le cas où une entité ne serait pas capable de gérer cette amélioration…

En attendant de pouvoir travailler sur ces améliorations, je dois terminer l’implémentation complète du chiffrement.

Openssl sous Centos

Un des robots tourne sous CentOS release 5.9 (Final).

La version de openssl est la OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008. Elle ne permet pas d’utiliser certaines options de la commande rand pour générer des données aléatoires en hexadécimale. Sauf que je l’utilise intensément… pour générer des IV de chiffrement et pour générer des noms de fichiers temporaires.
Donc, le chiffrement ne marchera pas bien en l’état. Et des buggs sont à prévoir dans certaines fonctions…

Pour info, Debian Linux 6.0.7 dispose d’une version un peu datée aussi, la OpenSSL 0.9.8o 01 Jun 2010. Deux ans de différence, ça se sent… mais c’est suffisant pour mes besoins.
Heureusement, on est en 2013 est openssl est packagé en version 1.0.1e.

Quantification commune de la disponibilités des relais

Les quelques entités robot que je teste sont maintenant tout à fait capable de synchroniser des liens et objets divers. Le problème est souvent de savoir ce que l’on veut synchroniser en fait.

Chaque robot essaye de télécharger un objet sur toutes les autres entités qu’il connaît. Ou plus exactement sur toutes les localisations qu’il connaît, même si ce n’est pas une entité connue. Le téléchargement est actuellement unitaire. L’objet téléchargé doit être complet, on ne prend pas un bout à un endroit et le reste ailleurs comme avec le P2P habituellement. Ce raffinement sera pour plus tard. Et l’ordre des localisations est toujours parcouru de la même façon, c’est à dire dans l’ordre des liens de ces localisations avec l’objet qui les référence.
Évidement, la vérification de l’intégrité des objets et la vérification des signatures des liens associés permet de ne pas se soucier de savoir sur quel entité relais l’objet est téléchargé.

Ce système est assez primaire mais il remplit parfaitement son rôle. Cependant, en terme de performance, on peut faire mieux…

Une des solutions peut être d’enregistrer systématiquement le débit moyen de téléchargement d’un objet sur une localisation particulière. Des statistiques vont commencer à s’accumuler avec le temps et le robot pourra ensuite privilégier certaines localisations en fonctions de leurs statistiques.
Si chaque mesure de débit moyen est lié à la localisation comme étant une statistique, l’ensemble des statistiques des entités peuvent se propager d’une entité à l’autre. Ainsi c’est l’ensemble des robots qui peuvent profiter des statistiques pour affiner le classement des localisations.
Il faut quand même ne pas tout prendre brute quoiqu’il arrive. Des statistiques anciennes n’ont que peu de valeur. De même, comment interpréter les statistiques d’une entité à l’autre bout du monde, et donc qui a des temps de latence différents ? Une moyenne non pondérée entre les statistiques de toutes les entités est-elle suffisante pour gommer des valeurs anormales de débit moyen ?

Priorité des liens à date identique

Comment doivent être interprétés des liens différents et dont la date est identique. Ce peut être le cas d’un lien de type u ayant strictement la même date qu’un lien identique mais de type x.

Est-ce qu’il y a un ordre préférentiel de lecture, et donc inversement de prise en compte ?
Le lien de type x est-il plus important que le lien de type u ou f par exemple?

Aujourd’hui, les implémentations de références doivent traiter les liens dans l’ordre tel que définit dans la documentation de référence. Donc le lien x devient implicitement, par ce que étant le dernier appliqué, celui qui a le plus de poids.

Référence des librairies en bash

L’entité bachue commence sont rôle de diffusion de logiciels signés.

Le tout premier est logiquement la librairie nebule en bash puisque c’est l’implémentation la plus avancée à ce jour.

Déploiement

Un objet dédié contenant « nebule/bachue/reference/bash », de hash 2d0468b3153a1a43861ada08cc0a209df138f581df61b8ebc4cf022ee3d83aef, permet de suivre l’évolution des version successives de la librairie. Pour cela, un lien de type f est fait entre cet objet et les objets successifs contenants les différentes versions de la librairie.
Un autre lien de type u est fait directement entre deux versions successives de la librairie.

Annulation

Si une version de la librairie doit être annulée, il y a plusieurs méthodes possibles qui aboutissent à ce résultat :

  1. La première méthode est de déployer une nouvelle version de la librairie et de faire un lien de type u entre la version à annuler et la nouvelle version. Normalement, toutes les entités devraient ainsi mettre à jour leur copie de la librairie avec la nouvelle version, ce depuis la version à annuler ou depuis une version antérieur.
  2. La seconde méthode est d’annuler le lien de mise à jour (type u) avec un lien de type x. Dans ce cas, toutes les entités avec la version de librairie à annuler devraient ainsi mettre à jour leur copie de la librairie vers la version précédente en attendant une nouvelle version. Les entités avec une version antérieur de la librairie s’arrêteront naturellement à la version précédent la version à annuler, en attendant aussi une nouvelle version.
  3. Une troisième solution pourrait être d’ajouter un lien de type u en sens inverse, c’est à dire entre la version de la librairie à annuler et la version précédente. Cependant, cela crée une boucle dans les liens de mises à jour d’un objet avec tous les risques de boucles infinies à gérer que cela entraîne. C’est une solution similaire à la deuxième solution.

dans tous les cas, par sécurité on peut demander la suppression de l’objet contenant la librairie à annuler avec un lien de type d.

La seconde méthode me paraît plus hasardeuse dans le sens où elle nécessite une régression dans la mise en application des versions de la librairie. Cependant elle à le mérite de pouvoir répondre immédiatement à un problème sans attendre la mise en place rapide d’une nouvelle version.

Attention, la version actuelle de la librairie ne tient pas encore compte des liens de type u, x et d. Ce développement devrait arriver assez rapidement pour couvrir ce besoin de gestion des références de logiciels.

Ralentissement des échanges à débit constant

Je commence à voir ressortir un problème que je ne pensais pas avoir à régler si tôt.

Le nombre d’objets augmente, et avec, les liens associés aussi. Or lorsqu’un robot par exemple synchronise les liens d’un objet pivot, que l’on peut plutôt appeler un nÅ“ud, il télécharge systématiquement l’intégralité des liens… et vérifie leurs signatures.
Tant qu’il n’y en avait pas beaucoup, ça ne se sentait pas trop sur le temps de synchronisation. Mais ça commence à se voir aujourd’hui sur certains objets.

Une des solutions serait de voir si le lien est déjà connu. Cela oblige à parcourir l’intégralité des liens d’un objet qui justement peut en contenir beaucoup. On va gagner à court terme sur le traitement des liens. Mais on continue à télécharger des liens inutilement.
Et que ce passera-t-il lorsque la recherche de la présence du lien sera plus longue que la vérification de sa signature?
Bref, cela ne fait que reporter le problème à plus tard…

Il faut résoudre ce problème de façon plus élégante. Cela peut être fait en demandant les liens après un lien particulier, le dernier que l’on connaît déjà.
Cela oblige à implémenter la fonction côté entité, mais aussi côté serveur. Or la façon dont les serveurs web délivrent les liens et objets ne se pas prête à ça. Il faut leur ajouter un peu plus d’intelligence.

D’un autre côté, la vérification si le lien est déjà présent est réalisée juste avant de l’ajouter à un objet… On aura aussi un problème à résoudre à cette étape là…

Auto-vérification automatique périodique – 2

Suite à la mise en application automatique de la vérification des objets et liens, il y avait eu des pertes.

Je n’ai pas essayé de restaurer les objets qui n’ont pas d’importance ici. Mais j’ai restauré les liens depuis une autre entité. La restauration répare en grande partie les liens.

Le résultat est visible :

Auto-vérification automatique périodique

Une des expériences en cours est la vérification automatisée et à intervalle régulier de tous les objets et de tous les liens des objets.

Les objets sont faciles à vérifier, on calcule leur empreinte et on vérifie qu’elle correspond à leur nom. Si elle diffère, on le supprime. Si l’objet n’a pas de liens, il est jugé comme une pièce rapportée, on le supprime aussi.

Les liens sont assez faciles à vérifier aussi. Il faut procéder objet par objet, prendre les liens un par un et vérifier que la signature est valide pour l’entité qui l’a générée. Si la signature diffère, on supprime le lien. Si l’entité est inconnue, la signature ne pourra être vérifiée, le lien est donc supprimé aussi.

Ce petit bout de script reste assez simple et doit être testé soigneusement pour éviter des dommages collatéraux. Il m’avait semblé l’avoir testé suffisamment… mais visiblement il y a eu des dégâts pour certaines entités.

Voici notamment le résultat sur les sauvegardes de la machine zulu (à comparer à ce graphe ci) :

On peut encore allez plus loin. Non dans les dégâts collatéraux mais dans une forme plus poussée d’immunisation. L’entité peut entretenir une liste d’objets jugés dangereux, et donc à supprimer. Elle peut et surtout doit aussi se référencer à une entité dédiée au marquage d’objets dangereux, c’est le rôle justement de cerberus

Continuer la lecture de Auto-vérification automatique périodique

Chiffrement fonctionnel vers une entité tierce

Le chiffrement est fonctionnel vers une entité tierce. Toujours sans pré-compression des données.

Cela donne ce type de graphe pour le chiffrement de multiples objets vers une entité :

CF :
Chiffrement fonctionnel
Chiffrement et type mime
Chiffrement et vecteur initial
Chiffrement et compression
Introduction à la cryptographie

Localisation de fichiers

Une étape importante dans l’utilisation de nebule, c’est d’importer des données. Ces données sont typiquement des fichiers existants. Cette opération d’importation de fichiers, c’est la nébulisation de fichiers.

La nébulisation de fichiers ne présente pas à priori de difficultés. On calcule son empreinte et on lui associe tout un tas d’informations telles que son type mime, sa taille, etc…

Il y a cependant une propriété des fichiers qui pose un problème.
Un fichier est classiquement reconnu par son nom. ce nom est une propriété du fichier au même titre que sa taille par exemple. L’extension de fichier n’est qu’un indicateur, peu fiable, de son type. L’extension de fichier est repris comme suffixe du nom.
Il peut y avoir plusieurs fichiers qui portent le même nom (et même suffixe) et qui ont ou non le même contenu. Ils doivent dans ce cas être disposés dans des emplacements différents. Cet emplacement peut être repris comme préfixe. L’emplacement est la traduction textuelle de l’arborescence de répertoires dans lequel se trouve un fichier. Et l’emplacement peut être soit relatif (à un autre emplacement), soit absolu. Dans tous les cas, il fait implicitement ou explicitement référence au disque, la distinction entre les deux dépendant de la notation faite par les différents systèmes d’exploitations. Nous ne prendrons ici que l’emplacement absolu, seul à pouvoir discriminer de façon certaine deux fichiers au même nom.
On peut aussi avoir deux fichiers de même nom/suffixe dans le même répertoire, mais sur deux machines différentes. Dans les différentes notations, il est donc préférable de se restreindre à l’utilisation de notations impliquant le nom de machine. Sinon on risque de pouvoir restaurer correctement un fichier en cas de besoin (si c’est le but).

Le problème de la notation des noms de fichiers peut se poser aussi dans le cas de deux fichiers identiques au même emplacement sur deux machines différentes. Si un des fichiers est modifié, cela va entraîner la création d’un lien u pour l’objet correspondant. Si rien ne distingue les deux fichiers, cela implique que l’autre fichier non modifié sera marqué comme lui aussi modifié…

Références :
Nebule blog – Empreinte d’objets et URI
Nebule blog – Fiches perforées
Nebule blog – Fichiers et chemins
Nebule blog – Système de fichiers
Nebule wiki – Réflexion – analyse des applications – Système de fichiers

Chiffrement et type mime

Suite de la réflexion sur l’Introduction à la cryptographie.

Il n’existe pas de type mime généralistes pour des fichiers chiffrés. Comme les objets chiffrés ne sont liés à aucune application en particulier, je gratte un peu ce qui se rapproche le plus de mon besoin.

Il se trouve qu’il existe le type mime application/octet-stream un peu fourre tout pour les contenus… binaires. Mais il est standardisé en l’état.
Il faut aussi un moyen de préciser l’algorithme de chiffrement derrière. Une application aura besoin de connaître cet algorithme pour déchiffrer le flux d’octets.
Bref, en suivant la rfc2046, il reste la possibilité de créer quelque chose en application/x-

Voici donc comment seront définis les objets chiffrés dans nebule :
application/x-encrypted/aes-256-ctr
application/x-encrypted/aes-256-cbc
application/x-encrypted/rsa
Etc…

En fonction de l’algorithme invoqué, on sait si c’est du chiffrement symétrique ou asymétrique, et donc en principe si c’est pour une clé de session ou pas.

Gestion de programmes – création

Suite à la précédente réflexion sur la gestion des programmes, l’entité correspondante a été créée.

Cette entité s’appelle bachue, dérivé de Bachué. Son empreinte :

19762515dd804577f9fd8c005a7803ddee413f264319748e30aa2aedf318ca57
http://bachue.nebule.org

bachue

Tuer l’ordinateur pour le sauver – 2

Il est encore aujourd’hui difficile de dire quel est le principal problème dans l’architecture de nos systèmes d’information. Il est d’ailleurs fort probable que ce soit un cumul de plusieurs causes qui rendre l’ensemble du SI si difficile à sécuriser. La conséquence, c’est que nous avons bien du mal à endiguer des attaques toujours plus complexes et nombreuses malgré les moyens considérables que nous déployons. Ces moyens sont de plusieurs ordres : financiers, organisationnels, humains et technologiques.

Est-ce la façon qu’on nos machines de communiquer sur l’internet qui est à revoir ?
A cette question, il est très tentant de répondre oui. Il faut filtrer, segmenter. Si l’on bloque l’internet mondial en le fermant au niveau des frontières, on résoudra une grande partie des problèmes. Mais on ne résoudra pas vraiment les vraies causes de nos problèmes. Cela ne fera que réduire la portée des conséquences. Et, en faisant cet enclavement, je pense que l’on ne fait que repousser à plus tard la résolution de ces problèmes.
Il faut peut-être plus simplement revoir comment nos machines communiquent et modifier la pile réseau. Mais cela ne tient pas compte des autres moyens de communication comme les périphériques de stockage amovibles.

Est-ce l’architecture de nos machines qui est vulnérable ?
Les attaques sur le SI ont de multiples formes parce qu’elles ont autant de buts différents. Le réseau est rarement la cible d’une attaque, alors qu’un serveur est une cible de choix. Et le serveur est une cible exposée si il veut remplir son rôle : servir. Les attaques sur les serveurs sont toujours passées par les interfaces, les entrées/sorties. Mes ces attaques n’ont de raison d’être que parce que le serveur est un objet actif, interactif. Et cette activité siège avant tout dans le processeur.
Le processeur permet l’exécution du code des programmes et notamment le système d’exploitation. Tous les systèmes d’exploitations actuels ont un (ou plusieurs) compte ou pseudo compte super-administrateur, qu’il s’appelle root ou SYSTEM. Or, le processeur ne sait pas reconnaître un compte. Il se contente d’exécuter le système d’exploitation qui, lui, contient toute la logique d’exploitation des comptes et de séparation des privilèges. Qu’est ce qui garantie aujourd’hui l’intégrité de cette logique ? Pas grand chose. Les élévations de privilèges sont courantes suite à des attaques.
D’un autre côté, le système d’exploitation repose sur un ordonnanceur. Celui-ci permet de répartir le temps de calcul du processeur entre les différents programmes, et donc de faire du multitâches entre les applications. Mais le processeur lui-même est fondamentalement monotâche. Le processeur dispose aussi d’un mécanisme, le RING, mais les systèmes d’exploitation ne l’exploitent qu’à moitié. La séparation entre les différents programmes est de fait artificielle parce que logiciel, et donc faible.
On en arrive à une aberration conceptuelle. Le super-utilisateur a plus de pouvoir sur le système que l’utilisateur qui manipule ses données, ce qui est normal. Mais ce qui l’est moins, c’est qu’il a aussi plus de pouvoir sur les données de l’utilisateur que ce dernier. En l’état de la technologie actuelle, le problème de confidentialité est insoluble sauf à considérer que l’utilisateur est le super-utilisateur. Et c’est sans compter les élévations de privilèges.
Et dire qu’un utilisateur est super-utilisateur de son système est aujourd’hui reconnu comme une aberration. La boucle est bouclée.

Le projet nebule est un premier pas vers une solution. Il est encore trop tôt pour savoir si c’est le début de la bonne solution. On permet à l’utilisateur de se réapproprier ses données. Malheureusement, l’architecture actuelle des machines ne permet pas de protéger efficacement l’identité d’une entité une fois déverrouillée, c’est à dire une fois la clé privée chargée en mémoire. Le super-utilisateur peut directement lire cette clé en mémoire. Aucune protection de prévaut dans ce cas, quelque soit sa complexité. Certes, il faut corrompre ce super-utilisateur… mais c’est justement ce qui est fait lors de la plupart des attaques informatiques actuelles.

CF : Tuer l’ordinateur pour le sauver

Gestion de programmes – suite

La précédente réflexion sur la gestion de programmes peut être complétée.

Les programmes doivent être validés par des entités. Il faut des entités dédiées à cette tâche. La validation et les mises à jours se font par les liens de ces entités.

Une des propriété qui va rapidement ressortir, c’est qu’une entité peut, sans grand risque de refus, demander à toutes les entités qu’elle connaît les objets et liens signés par une entité de gestion de programmes. En fait, il y a de grandes chances que toutes les entités partagent la même source de programmes. Cela rend la diffusion de mises à jours particulièrement rapides. On a un peu un effet virus sur la diffusion des objets.
Évidemment, comme cela se passe aujourd’hui, nous risquons d’avoir une hégémonie de certains programmes. C’est pour cela qu’il faut aussi être capable d’accepter simultanément plusieurs entités de gestion de programmes… et de strictement respecter la diffusion des liens et objets tel que définit par le projet nebule.

L’entité cerberus n’a pas vocation à diffuser des programmes, mais elle peut être amenée à interdire l’utilisation de certains programmes si ceux-ci sont reconnus malveillants. Cela ne bloque pas les mises à jours du-dit programmes mais oblige à le mettre à jour.

Il me faut donc maintenant créer la première entité de gestion des programmes, et il faut commencer par lui trouver un nom.

Objets privés et fonctionnement interne

Il existe des informations que l’on ne peut gérer par les liens nebule sous peine de fortement complexifier son fonctionnement, et donc la compréhension que l’on en a dans son ensemble.

Par exemple, c’est le cas pour mettre un poids à un objet. C’est à dire lui attribuer une méta information qui décrit son importance relative aux autres objets. C’est une notation en quelque sorte.
Un poids peut être fixé arbitrairement. Ce n’est pas le meilleur cas même si c’est réalisable en pratique. Le poids d’un objet a surtout de forte chance de refléter l’importance que l’on donne à cet objet. A cet objet pondéré sont liés d’autres objets. Ces autres objets, si leurs poids ne sont peut-être pas explicitement définis, vont hériter d’une moyenne des poids des objets autour. Ainsi, un objet va gagner de l’importance si il est lié à un objet jugé (donc pondéré) très important.
De ce poids peut en découler des conséquences concrètes. Par exemple si l’on permet l’oublie et l’effacement d’objets anciens de façon calculé et contrôlé, la pondération permet de conserver très longtemps un objet important.

Cette pondération des objets qu’une entité va réaliser est un travail ‘personnel’. Le fruit de ce travail peut avoir un intérêt public. Et une autre entité ayant fait le même travail ne donnera pas les mêmes pondérations.
Cependant, une partie de ce travail de pondération peut être jugé privé. Si le partage d’une pondération d’objets peut être réalisée simplement par des liens, comment protéger les pondérations privées ?

Une des possibilités est d’exploiter les objets stockants des liens.

Hash et type des objets – suite

Suite à la décision de modifier deux objets de base niveau, hash function et mime-type, les premières répercussions ont été faites sur puppetmaster, cerberus et kronos.

De fait, les premiers liens de type x ont été générés. C’est à dire que ce sont les premiers liens qui permettent la suppression d’autres liens précédemment créés.

Cela se voit sur le graph de l’objet entité de puppetmaster :

C’est un peu fouillis parce que le précédent lien supprimé est remplacé par un nouveau lien dont l’objet meta est différent. Il faudra améliorer le tracé de ces liens…