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.

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

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

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.

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…

Le maître des poupées et le gardien de l’enfer

1/Le maître des poupées

Le maître des poupées, alias puppetmaster, vient de révoquer son ancienne incarnation :

63864e42204080051f524d5be0171920e0117a0e83d2131ac506ce3cbff7f1f4

Contrairement à ce qui avait été annoncé, c’est un lien de type d qui à été utilisé, et non un lien de type u. Ceci pour un problème de sécurité. Ainsi son ancienne incarnation ne peut pas révoquer ce type de lien… et ressusciter.
Le détail ici : puppetmaster.nebule.org/l/63864e42204080051f524d5be0171920e0117a0e83d2131ac506ce3cbff7f1f4

D’autres anciennes incarnations ont elles aussi été révoquées, à la fois pour la clé publique et la clé privée :
70668497b6a0ad481aa7e0c08131bc0d0be40cd7dde30a7de8613290d7c35543 puppetmaster (priv)
9e85d7d25af97760f8611b85c2765912606c7eec8307dc58c7782e34cc373c18 cerberus (pub)
905296b7070b8e7d601d9509893683d072bb22083006a9e545ceaf0228787c8c cerberus (priv)
d756efe28847a3723639aed49a40f08c22a576ff3f002750a18ad6a192717621 kronos (pub)
5f951d41db3b18001fbc8baf895d84cb4d460a6143b273b4f5b2d0e9b0d5c67b kronos (priv)

Dans le même temps, puppetmaster a reconnu plusieurs nouvelles entités :
01351dd781453092d99377d94990da9bf220c85c43737674a257b525f6566fb4 cerberus cerberus.nebule.org
abdbaa31e404463ecc644f1eecdeb9b5f94428eb140fa5c66a7687ee96ed47aa kronos kronos.nebule.org
975571a8a470a6d975662e284f5ef1bd0396c06b31a2207b81bef2e24c5bf0c5 stéphane stephane.nebule.fr
Voir le détail ici : puppetmaster.nebule.org/l/88848d09edc416e443ce1491753c75d75d7d8790c1253becf9a2191ac369f4ea

2/Le gardien de l’enfer

Le gardien de l’enfer, alias cerberus, vient d’être régénéré en tant que :

01351dd781453092d99377d94990da9bf220c85c43737674a257b525f6566fb4
cerberus.nebule.org

Il est reconnu par puppetmaster. cf Cerberus et la mise en quarantaine d’objets.

Pour son rôle spécifique, il dispose de deux objets spécifiques :
nebule/danger
nebule/warning

Actuellement, les enfers n’ayant pas encore officiellement ouverts, cette entité est au chômage.
Seul le temps nous dira pour combien de temps…

Autorité temporaire : le maître des poupées

Une entité avait été généré en novembre 2012. Elle avait pour rôle de simuler une autorité de haut niveau. Voir l’article Autorité temporaire.

Le bi-clé de cette entité n’ayant pas été généré et manipulé dans des conditions spartiates de sécurité, il était difficile d’avoir pleinement confiance en cette entité.
Il fallait donc régénérer une nouvelle entité de façon plus propre.

Une machine a été installée de façon renforcée, et est prévue pour être manipulée hors réseau.
Tous les systèmes ont leurs faiblesses, et ont donc un besoin récurrent de mise à jour. Le système le moins vulnérable face à l’absence prolongée de mises à jours, c’est OpenBSD. C’est aussi actuellement le système le moins vulnérable par défaut. La non utilisation du réseau réduit très fortement les problèmes potentiels. Il est cependant possible, en cas de nécessité, de réaliser une mise à jour manuelle.
Le disque dur est partiellement chiffré.

Cette machine a donc permit de générer une nouvelle entité racine.
Ce rôle est toujours temporaire. Il ne se justifie que pour coller à un modèle de sécurité actuel, basé sur des autorités racines de confiance. On ne peut faire confiance à une entité que si elle est validée par l’entité racine. Cependant, ce modèle de sécurité n’a pas vocation à subsister en l’état. Soit il y aura d’autres autorités racines, soit elles disparaîtront toutes.

Puppetmaster, le nouveau maître des poupées est identifié comme :

88848d09edc416e443ce1491753c75d75d7d8790c1253becf9a2191ac369f4ea

Et il reprend l’emplacement de l’ancien puppetmaster :

http://puppetmaster.nebule.org/

Pour l’instant, puppetmaster ne reconnaît aucune autre entité. Ce sera fait bientôt. Et le nouveau puppetmaster réformera (lien u) aussi officiellement l’ancien puppetmaster.
Le maître des poupées est mort, vive le maître des poupées!

Grandes migrations

Toutes les entités étaient accessibles via des liens en nebule.org .

Depuis une semaine, certaines entités ont changé de domaine. Les nouvelles localisations des entités concernées :

Les entités à usage publique restent dans le domaine nebule.org, c’est le cas de :

Ces localisations sont des domaines DNS, et de fait des serveurs http derrière. Cependant, la localisation est certes obligatoire pour retrouver une entité, mais elle n’est pas par nature strictement liée aux noms de domaines. Ni liée au réseau d’ailleurs. Certaines machines ne répondent pas à leur localisation (alpha.nebule.fr), et le type de localisation évoluera plus tard vers d’autres formes (ftp, smtp, xmpp, etc…).