Réorganisation des entités spéciales – groupes d’entités

Suite de l’article Réorganisation des entités spéciales – inventaire de départ.

Le regroupement d’entités par rôle correspond à la création d’un groupe d’entités, groupe auquel on va donner le rôle. Il va être possible avec le groupe de définir de nouveaux filtres sociaux de tri des liens. Ces filtres viendront remplacer un filtre historique, restricted, qui a un rôle important mais dont le nom devient ambiguë.
Par exemple, à l’entité maître du code bachue il sera possible d’adjoindre d’autres entités pour valider du code. Cela permet de recréer l’équivalent de l’ajout de plusieurs dépôts logiciels différents. Il est même envisageable pour une entité de désactiver bachue spécifiquement du groupe.

L’entité locale de l’instance va aussi avoir des droits plus étendus. Elle pourra être, via des options, équivalente à toutes les autorités globales, y compris le maître du tout (puppetmaster). Bien sûr ces droits ne seront valables que sur l’instance de serveur qui lui est rattachée… et toute entité qui décidera de l’ajouter dans un groupe de droits.

Réorganisation des entités spéciales – inventaire de départ

L’organisation actuelle des entités spéciales est assez limitée. On a d’un côté les autorités globales imposées par le code et de l’autre quelques autorités locales aux rôles limités.

Le bestiaire

Premier constat fait depuis un moment, l’entité maître unique puppetmaster est par définition un risque même si pour l’instant c’est la seule façon raisonnable d’avoir une cohérence de l’ensemble. Le but serait d’avoir une entité multi-tête à seuil dont le contrôle est réparti entre plusieurs porteurs. Cette entité n’a que pour mission de désigner les autres entités spéciales globales dont la plus utilisée aujourd’hui est l’entité maître du code bachue. L’entité puppetmaster a un rôle d’autorité et sa portée est globale.

L’entité spéciale cerberus permet de gérer les bannissement d’objets. C’est un peu le rôle de police. L’enfer n’ayant pas encore officiellement ouvert, cette entité n’est pas utilisée mais elle pourrait être très rapidement sollicitée fortement pour tout et n’importe quoi.

L’entité spéciale maître du code bachue est aussi désignée autorité mais est subordonnée au puppetmaster. Son rôle est uniquement de gérer le code sous toutes ses formes.

L’entité spéciale kronos n’a qu’un rôle théorique pour l’instant et n’a que brièvement été utilisée dans des expériences. Cette entité va générer des repères temporels fiables. Mais je pressens qu’elle va devenir incontournable à l’avenir, et peut-être critique pour certains usages.

Enfin, l’entité spéciale asabiyya va être utilisée pour relier les gens avec de la confiance. Elle n’est pas encore utilisée non plus.

Les rôles

On peut distinguer plusieurs catégories d’entités. Les autorités désignes des entités sur des rôles. Les administrateurs font des choix de configuration du code et des applications. Les gestionnaires gèrent des objets, des applications, des entités. Et chaque rôle peut avoir une portée locale ou exceptionnellement globale.

Il existe déjà des méthodes d’organisation qui avaient été retranscrites dans l’article Être relié ou ne pas être. Le modèle RBAC est implémentable par les liens de nebule, le modèle OrBAC semble être moins adapté à nebule parce qu’il sous-entend une une organisation, une structure, qui n’est pas portée par nebule.

La liste de grandes catégories de rôles à compléter peut déjà prévoir l’autorité (authority), la police, l’administrateur (administrator), le gestionnaire (manager), l’entité de recouvrement (recovery)…

L’attribution de rôle est additive, les rôles s’ajoutent à une entité mais il n’y a pas de négation de rôle. Pour les rôles locaux, il est possible de supprimer un rôle d’une entité. Il n’y a pas d’inhibiteur de rôle mais juste un une suppression de lien.

La réflexion continue…

Bugg d’affichage des autorités globales dans option

Il y a un petit problème dans l’affichage des autorités globales dans l’application option. Par exemple ici :

https://sylabe.com/?a=21215100000000…0000000212151&view=gauth
shot-2017-06-02_19-51-13

Mais une partie de l’affichage est bon est correspond bien à l’entité bachue qui gère le code. Un petit tour par le bootstrap permet de s’en assurer :

https://sylabe.com/?b
shot-2017-06-02_19-57-13

bootstrap – Désactivation des applications par défaut

Le bootstrap sait maintenant gérer les applications activées. Ça se passe à deux niveaux.

  1. L’application 0 de sélection des applications n’affiche que les applications activées.
  2. Le moteur de sélection de l’application à afficher ne permet pas de sélectionner une application si elle n’est pas activée.

L’activation d’une application se fait sur trois critères :

  1. C’est l’application par défaut définit par l’option defaultApplication, elle est par défaut activée et non désactivable.
  2. C’est une des applications en liste blanche. La liste blanche est une constante définie dans le bootstrap et dans la bibliothèque. Elleet non désactivable.
  3. L’entité instance du serveur a activé explicitement l’application par un lien.

L’entité maître du code bachue ne peut pas activer une application sauf à modifier les constantes dans le code.

Une application peut être activée/désactivée via l’application option, la seule application aujourd’hui en liste blanche. Il faut aller dans la partie des applications et il faut être connecté avec l’instance entité du serveur.

020161127 shot-2016-11-27_18-52-59

Le lien d’activation d’une application a la forme :

  • action : f
  • source : objet de référence de l’application, par exemple = e5ce3e9938247402722233e4698cda4adb44bb2e01aa0687
  • cible : objet de référence d’activation = e0e9ce893ea87b91f6e276b3839fed99f050168a0eb986354adc63abb3d7335c
  • méta : objet de référence de l’application, par exemple = e5ce3e9938247402722233e4698cda4adb44bb2e01aa0687

La désactivation est un lien de type x.

bootstrap – Avec ou sans pré-chargement des applications

Le pré-chargement des applications par le bootstrap va permettre d’améliorer l’expérience utilisateur lors du premier chargement d’une application. Même si les applications n’ont pas encore été optimisées pour en profiter pleinement, c’est déjà fonctionnel et efficace.

Par contre, comme énoncé dans l’article pré-chargement des applications – indexation, certaines applications n’ont pas forcément un intérêt à être pré-chargées.
C’est le cas de l’application defolt qui se charge très vite et dont la page de pré-chargement n’apporte rien, voir casse un peu le principe de la page par défaut.
Et c’est aussi le cas de l’application upload qui charge vite mais qui peut à l’avenir permettre la synchronisation d’objets et de liens entre serveurs. Hors le passage par une page intermédiaire oblige le serveur distant à gérer le cookie de connexion avant de pouvoir envoyer des données.

La dernière version du bootstrap, qui va être bientôt publiée, reconnaît maintenant un lien pour désactiver le pré-chargement d’une application. Le comportement par défaut reste de pré-charger une application. Chaque application pourra, sur initiative du maître du code bachue ou d’une autorité locale, ne plus être pré-chargée.

Le lien de non pré-chargement a la forme :

  • action : f
  • source : objet de référence de l’application, par exemple = e5ce3e9938247402722233e4698cda4adb44bb2e01aa0687
  • cible : objet de référence de non pré-chargement = 9d019716a5335ee1f3bad59cbb9cc93132b0726129b26b52d6441a66c7c59a8d
  • méta : objet de référence de l’application, par exemple = e5ce3e9938247402722233e4698cda4adb44bb2e01aa0687

De plus, le problème de dépassement de mémoire est résolu. Il vient d’une pré-allocation de mémoire de la fonction file_get_content qui se fait parfois sur la totalité de l’argument $maxlen alors que le contenu réel est dérisoire… et qui ne libère pas cette mémoire en fin de fonction.

Enfin, la métrologie a été aussi grandement renforcée. L’avenir dira si cela a un impact négligeable sur les performances ou pas. En fin de bootstrap, les logs contiennent une trace de la mémoire maximum utilisée ainsi que les objets et liens lus et vérifiés :

Nov 27 12:21:36 bachue bootstrap/81bd1a52600b: 0.64311790466309 Mp=9698504 Lr=2720+4 Lv=355+4 Or=361+0 Ov=8+0

Avancement du bootstrap

Une nouvelle version du code du bootstrap en php procédurale est diffusée :

6c902d8c29b965fde6d576ef04e5405c84b1353d01715c4fb96e561ba76e9114

Comme d’habitude, l’identifiant est sont empreinte sha256. C’est le seul code qui ne peut pas être signé.

Sauf problème de dernière minute lors des tests sur Internet, cette version est fonctionnelle et complète.

Il manque par contre les liens signés du maître du code bachue pour désigner la bibliothèque et les applications. Les différentes applications se lancent sauf sylabe qui coince sur un de ses modules. Lorsque l’ensemble sera à peut près stable, le tout sera mis en ligne.

Du fait des grands changements dans la gestion des arguments en ligne et des applications, les applications actuellement en ligne sur Internet ne sont plus compatibles avec le nouveau bootstrap.

Mode de récupération

Un mode de récupération était déjà plus ou moins bien implémenté. Il a été repris à l’occasion de la ré-écriture du bootstrap et il a notamment été corrigé dans la librairie nebule.

L’activation de ce mode de récupération empêche simplement l’entité instance du serveur et l’entité par défaut de devenir autorités locales. C’est à dire que les options qui leur permettent de devenir autorités locales ne sont plus pris en compte.
Le fait d’être autorité locale permet de générer des liens, qui seront réellement reconnus, pour faire des mises à jours de la librairie et des applications au même titre que le maître du code bachue. C’est comme cela que l’on peut travailler le code signé sans avoir recours en permanence au maître du code. Et c’est aussi comme cela que l’on peut mettre en place sa propre application sans qu’elle soit signée du maître du code.

L’activation peut se faire via les arguments de l’URL en ajoutant rescue si l’option permitOnlineRescue est à true.
En cas de besoin, option modeRescue permet à true d’activer et de forcer le mode de récupération sans tenir compte de l’option permitOnlineRescue.

Ajustement des noms de domaines

Tous les noms de domaines liés aux entités de nebule ont été revus. Le puppetmaster est toujours l’entité autorité racine sous laquelle on trouve maintenant les rôles :

  1. security.master.nebule.org
  2. code.master.nebule.org
  3. directory.master.nebule.org
  4. time.master.nebule.org

Chaque nom de domaine correspondant à un rôle est renvoyé vers une entité déterminée, à savoir aujourd’hui dans l’ordre :

  1. cerberus.nebule.org
  2. bachue.nebule.org
  3. asabiyya.nebule.org
  4. kronos.nebule.org

L’idée, c’est que en cas de problème une entité peut être remplacée par une nouvelle. Et c’est pareil dans le code de la librairie nebule en php.

Les adresses en IPv6 ne sont plus fonctionnelles, mais ça reviendra.

Changement d’identifiant d’entité

On avait déjà vu qu’une entité pouvait être amenée à changer d’identifiant, donc en fait de clé publique et de clé privée. On avait vu que renouveler son entité n’est pas un problème facile à résoudre de façon satisfaisante, c’est à dire vraiment sécurisée et facile pour l’utilisateur.

Du point de vue interface, la nouvelle entité change aussi de couleur propre. Donc on ne peut pas demander à l’utilisateur par ailleurs de se fier à cette couleur propre des objets puisqu’elle va changer complètement à chaque mise à jour de ceux-ci. C’est ici que se fait sentir le besoin d’une référence d’objet stable dans le temps quelque soit les mises à jours, mais cette référence est par nature source de conflit d’une entité à l’autre et surtout elle est impossible à sécuriser.

Le problème est plus simple si l’entité est dépendante d’une autre entité, d’une entité maitresse. A condition que cette entité maitresse soit publiquement déclarée, comme le puppetmaster, il est possible de vérifier de façon sûr qu’une entité à changé de clé privée. CF Entités multiples, gestion, relations et anonymat

Par contre, une entité autonome ou assimilée ne peut pas se reposer sur une entité supérieure. Il faut prévoir un mécanisme qui permette à l’utilisateur d’une entité lambda de valider automatiquement ou manuellement la mise à jour d’une autre entité. Cela ne veut pas dire que l’autre entité ne changera pas d’identifiant, mais que cet identifiant ne sera pas reconnu tant que l’entité lambda n’aura pas validé (pour elle) son changement.

Pour le changement d’une entité qui potentiellement remet gravement en question la sureté de fonctionnement, une acceptation inconditionnelle de la mise à jour serait catastrophique. Il peut être utile dans ce cas particulier de générer un lien d’annulation de l’opération, mais un lien qui n’est pas actif, c’est à dire qui n’est pas diffusé. Ce lien de type x, serait affiché à l’utilisateur et serait donc valide mais pas pris en compte parce que non diffusé avec les autre liens.

Si on prend le cas spécifique de puppetmaster, cette entité valide des entités esclaves ayant des rôles près-définis. On retrouve notamment l’entité bachue qui diffuse les mises à jours logiciels liées au projet nebule. La compromission d’une telle entité poserait de graves problèmes de sécurité pour toutes les entités. Sa mise à jour vers une nouvelle entité serait dans ce cas obligatoire.
Mais ce problème pourrait être plus restreint dans la mesure où une fausse entité bachue serait générée et diffusée à des entités tierces. Si, par un autre moyen, on arrive à convaincre les entités tierces à l’utiliser en place de la vraie entité bachue, ces entités seront à considérer comme compromises. Le lien d’annulation serait alors le seul moyen pour ces entités de pouvoir revenir en arrière, faisant immédiatement un bond en arrière en terme de versions de logiciels, revenant à une version validée par l’entité bachue légitime.
Sauf que cela ne marche que si l’on peut enregistrer le lien de suppression hors du système nébulisé ou hors d’atteinte. Ce qui sera une vraie difficulté sur des systèmes entièrement nébulisés. Aujourd’hui, avec les systèmes d’informations actuels, on s’en sort en régénérant une nouvelle identité à l’utilisateur ou en nettoyant son compte. Peut-être faudra-t-il dans un premier temps garder ce fonctionnement avant d’aller vers quelque chose de plus ouvert…

Les entités et le code

La remise en forme du code de nebule en php orienté objet amène son lot de questions.

Les entités de nebule

Les entités principales de nebule ont actuellement des noms mais ne sont reliées à leurs fonctions respectives que par leur usage dans le code.

Pour que ce soit plus clair dans le code, le nom est un peu trop hermétique. Je le remplace donc par un nom contenant directement le rôle. Ainsi, kronos par exemple s’appellera toujours kronos mais sera mémorisé dans une variable nommée time master. Et il en est ainsi pour toutes les entités qui ont un rôle dans nebule :

  • puppetmaster, ne change pas de nom, c’est l’entité qui chapeaute toutes les autres, le maître ;
  • cerberus, hérite du rôle et du nom security master, le maître de la sécurité ;
  • bachue, hérite du rôle et du nom code master, le maître du code ;
  • asabiyya, hérite du rôle et du nom directory master, le maître de l’annuaire ;
  • kronos, hérite du rôle et du nom time master, le maître du temps.

Les possibilités de gestion pour l’utilisateur

La sécurisation du code amène aussi des questions sur l’organisation de la gestion de certaines parties de la sécurité. Notamment, jusqu’où peut-on permettre l’ajout de droits à une entité normale ?

Cette entité peut vouloir utiliser des extensions externes au code d’origine tel que diffusé par bachue. Cela peux se faire en relation avec la définition d’autorités locales. L’ajout d’une traduction de l’interface en est un bon exemple. L’entité bachue peut aussi diffuser ou permettre la diffusion de plusieurs codes utilisables par une entité.

Plus on donne de droits à un utilisateur, plus il risque de se faire corrompre par un code malveillant. Il faut trouver un juste milieu. Le code et la gestion du bootstrap doit rester la plus saine possible dans tous les cas.

Redéfinition de puppetmaster

L’entité puppetmaster est celle qui contrôle toutes les autres, donc qui contrôle tout. C’est le point fort de la hiérarchie des entités, et aujourd’hui la moins vulnérable. Mais c’est aussi l’entité qui présente le plus grand risque pour l’ensemble puisqu’elle est unique et que sa compromission serait fatale à tout l’ensemble.

C’est le même problème que le système de certificats présente aujourd’hui. Quoique, c’est pire encore pour le système de certificats puisqu’il existe beaucoup d’autorités de certifications racines et que la compromission d’un seule casse la confiance de tout le système. Dans l’ensemble, ce système de certificats est bien fait à part cette horreur de monstre à têtes multiples. Un vrai trou conceptuel dans la sécurité. Les gouvernements et le grand banditisme l’ont déjà corrompu depuis quelque temps à leur avantage.

Pour l’entité puppetmaster, l’idée est de partir en sens inverse. Au lieu de divulguer cette entité à de multiples personnes et organismes dont l’intégrité et l’honnêteté sont loin d’être garanties, on ne diffuse qu’une partie du pouvoir de l’entité puppetmaster. Une personne seule ne doit pas pouvoir utiliser l’entité. Chaque lien doit être validé, et donc signé, par un corpus de plusieurs clés représentant l’entité. Par exemple, on peut partir sur dix sous-clés de l’entité, associées deux à deux.

On peut implémenter la vérification du quotas de sous-clés ayant signées un même lien. Mais cette façon de faire est un droit faible puisqu’il ne repose que sur du code. On peut, j’espère, trouver une implémentation mathématique permettant de mettre en place une signature unique combinaison de plusieurs clés.

Il faut aussi résoudre un problème organisationnel et non technique. En combien de parties découpe-t-on l’entité ?
Dans notre exemple dix sous-clés associées deux à deux, on a un pouvoir de la clé maître répartie en cinq couples de clés. Chaque clé d’un couple a le pouvoir du couple. Le couple ici fait référence au couple humain. Et le cinq peut faire référence à tout un tas de choses…
Est-ce la meilleur répartition ? Celle-ci doit-elle répondre à une organisation physique ? Philosophique ? Spirituelle ? Mystique ? etc…

Diffusion des mises à jours

L’entité bachue diffuse depuis hier soir les dernières versions de la librairie nebule en php et du bootstrap :

La librairie nebule en bash est en cours de mise à jours vers la version 1.2 .

Parcours restreint de graph de mise à jour

Dans sylabe, la mise en place de la traduction sous forme de modules a apporté son lot de problèmes de sécurité. Les modules peuvent contenir tout un tas de code qui ne sont pas en rapport avec la traduction. Il faut interdire par tous les moyens l’ajout de code malveillant inconnu. Il est très difficile de filtrer finement ces codes pour ne garder au mieux que ce qui concerne les traduction ou au pire rejeter l’objet qui le contient. La solution retenu est de ne reconnaître que les modules signés soit par bachue, soit par l’entité locale.

Les fonctions _l_grx et _l_gr1 de la librairie en php prennent maintenant en compte un paramètre pour restreindre la recherche des liens de mise à jours (résolution du graphe des mises à jours) aux deux entités citées ci-dessus.

Mais, si fonctionnellement c’est suffisant, on va maintenant plus loin. Au lieu de ne reconnaître que deux entités, il est maintenant possible d’en ajouter plus de façon statique. On crée en quelque sorte une liste d’autorités locales. Cette liste n’est valable que sur un serveur et pour une seule instance de sylabe ou tout autre programme similaire.

Ainsi, la variable $nebule_local_authority contient une liste des entités faisant office d’autorité locale. Elle est pré-remplie par défaut avec l’entité bachue. Elle peut être complétée.

Une autre variable $nebule_curentnotauthority permet d’interdire à l’entité courante d’être elle aussi autorité locale. A false par défaut, l’entité locale peut ajouter des modules. C’est notamment pratique pour le développement puisque l’on peut faire soi-même des évolutions de ces modules. A true, l’entité locale ne peut qu’utiliser les modules par défaut présents localement.

Il est bien sûr possible de positionner ces deux variables dans les fichiers de configuration env_nebule.php et env_sylabe.php. Cependant, leur comportement est un tout petit peu différent dans le bootstrap et dans la librairie (via une application comme sylabe).

Quelques explications s’imposent pour comprendre les différences. Schéma de fonctionnement global d’une instance :

1 – Appel du bootstrap (index.php) par le serveur web.
V
2 – Exécution du script php.
3 – Lecture du fichier de configuration env_nebule.php.
4 – Recherche de la librairie nebule valide à charger.
5 – Chargement de la librairie nebule (fonctions et variables).
6 – Recherche de l’application par défaut et valide.
(actuellement, c’est sylabe)
7 – Le bootstrap charge l’application et passe la main.
V
8 – Exécution du script php de l’application.
9 – Lecture du fichier de configuration env_sylabe.php.
10 – Déroulement du script de l’application…

Lors de l’exécution du bootstrap, celui-ci n’utilise pas la session utilisateur gérée par php. Il va cherche si le fichier e existe et si c’est une entité. Il prend cette entité comme étant l’entité propriétaire de l’instance. Si avec la variable $nebule_curentnotauthority on empêche de reconnaître cette entité comme autorité, seule bachue sera autorité et donc seuls ses mises à jours seront prises en compte. Ainsi, il n’est pas possible pour l’entité locale de modifier la librairie ou le programme (sylabe) sauf si ils sont signés par bachue. Une mise à jour régulière est possible.

Lors de l’exécution de l’application, ici sylabe, l’entité locale n’est pas forcément l’entité courante. Et l’entité courante n’est donc pas forcément propriétaire de l’instance mais juste utilisatrice. Si avec la variable $nebule_curentnotauthority on empêche de reconnaître cette entité comme autorité, seule bachue sera autorité et donc seuls ses modules seront pris en compte. Ainsi, il n’est pas possible pour l’entité courante de modifier les modules. Une mise à jour régulière est possible.

En clair, l’entité locale choisit la librairie nebule et le programme à charger, l’entité courante dans le programme choisit les modules. Si cela ne leur est pas interdit.

Pour ajouter d’autres autorités, il suffit de les ajouter à la variable $nebule_local_authority dans les fichiers de configuration :
$nebule_local_authority[]='88848d09edc416e443ce1491753c75d75d7d8790c1253becf9a2191ac369f4ea';

shot-2014-05-19_12-24-40

Script d’export de la machine hôte de bachue

Voici la suite de l’article Script d’import de la machine hôte de bachue.

C’est un nouvel exemple de manipulation d’un support amovible avec nettoyage par un script. C’est aussi un exemple simple de manipulation de liens.

Le script en bash est disponible sur une page dédiée du wiki : Documentation – Entité bachue – Hôte bachue – Script export
Empreinte SHA256 : 5ffdf679599fedaf9029ad1eafc2bffa459ec8b919363245b9956a725b78ad99

Une version spéciale permet une copie intégrale : Documentation – Entité bachue – Hôte bachue – Script copie
Empreinte SHA256 : 30c5adb8d6582cdc92768575fc1fb42686eefb463ceb0e3445229bd96cc8a43c

Script d’import de la machine hôte de bachue

Voici un exemple de manipulation d’un support amovible avec nettoyage par un script. C’est aussi un exemple simple de manipulation de liens.

Le script en bash est disponible sur une page dédiée du wiki : Documentation – Entité bachue – Hôte bachue – Script import
Empreinte SHA256 : 88e31d4d23271f3e3528842b0d6b71fe36ed9b265e8f0b41202ea87a4e937e73

Une variante de ce script va permettre aussi l’import d’objets et de liens sur le serveur relai bachue. La seule différence, c’est qu’il n’acceptera pas les liens non signés.

La mise en production de bachue progresse…

Migration du bootstrap et de la librairie

Jusque là, le code du bootstrap et de la librairie nebule en php était dépendant du projet sylabe.

Maintenant, ils sont détachés du projet sylabe et sont directement rattachés au projet nebule, ce qui est plus cohérent. Le projet sylabe va cependant continuer à s’appuier sur le bootstrap et la librairie nebule et même à les faire progresser.

Les codes actuellement en ligne, diffusés par l’entité bachue, sont disponibles ici :
bootstrap
librairie

CF : Projet sylabe – Migration du bootstrap et de la librairie

Gestion de bachue

L’entité bachue existe depuis un certain temps en tant que telle. Mais il est difficile de diffuser dans de bonnes conditions les objets et liens qu’elle signe. De bonnes conditions sont ici à interpréter comme conditions de sécurité et facilité d’exploitation.

Cette entité est matérialisée par une clé RSA en deux parties, une publique et une privée. La clé privée doit être manipulée avec précaution dans un environnement strictement contrôlé. La perte ou la divulgation de la clé privée remettrait en question tout ce qui a été diffusée par cette entité, surtout si c’est du code. En terme de sensibilité, elle est en troisième position derrière puppetmaster et cerberus.
Les technologies employées actuellement ont toutes des vulnérabilités en ligne à certains moments. Si ces vulnérabilités peuvent être comblées, il n’en demeure pas moins une petite période de temps pendant lequel elles deviennent à la fois publiques et non encore comblées. Le problème est pire encore avec les vulnérabilités non publiques (0-days) contre lesquelles une machine unique ne peut pas avoir de défense efficace. Donc la machine qui héberge l’entité bachue, la machine hôte, ne peut être laissée connectée sur un réseau externe.
Tout ce qui est manipulé par nebule supporte sans aucun problème les transferts via le réseau ou via des supports amovibles et est manipulable sur des systèmes d’exploitations différents. Il est aisé de travailler avec des stations non connectées et de diffuser simplement l’information via des relais en ligne même plus faiblement protégés.
Chaque machine à un rôle strictement définit avec des règles de gestion en conséquences. Toutes les machines ne sont pas installées avec le même système d’exploitation et toutes les machines ne reposent pas sur la même architecture matériel. Des machines tournent notamment avec un processeur SUN SPARC ou un processeur PowerPC en plus des classiques processeurs Intel/AMD 32bits ou 64bits. Microsoft Windows a été écarté pour sa forte présomption (impossible à démontrer ou à réfuter) de compromission par des entités étatiques.

Voici le schéma de principe retenu actuellement pour la gestion des objets et liens par bachue :

20140301 sync bachue

1 – La station de développement est unique mais pourra s’étendre à plusieurs machines. C’est une machine assez classique et qui sert à bien d’autres choses que nebule. C’est actuellement le principal point de faiblesse, le principal point d’entrée d’une attaque.

1->2 – Depuis la station de développement, on exporte les liens et objets associés sur une clé USB vers la station hôte bachue.

2 – La station hôte est la seule et unique machine sur laquelle sera déverrouillée l’entité bachue. C’est la machine la plus critique du dispositif. Les seuls vecteurs d’attaque sont la clé USB et un accès physique frauduleux.
Toutes les clés USB insérées sont systématiquement nettoyées. Le nettoyage consiste en la suppression de tout fichier autre que le fichier ‘l’ ou ce qu’il y a dans le dossier ‘o’. Le fichier ‘l’ ne doit contenir que des caractères imprimables. Le dossier ‘o’ ne doit pas contenir de sous dossiers. Les fichiers du dossier ‘o’ doivent avoir une empreinte valide.
Si les liens sont ceux attendus, ils sont signés par l’entité.
Cette station ne se met pas à jour régulièrement des correctifs de sécurité. Ce processus est réalisé à la main si nécessaire. La machine est préparée pour résister aux deux vecteurs d’attaques connus.

2->3 – Les nouveaux liens sont exportés par la même clé USB vers le serveur relais.

3 – Le serveur relais contient une copie de ce que l’entité bachue partage publiquement. Il n’est pas très critique puisqu’une compromission serait facilement détectée dans les liens et objets. La suppression de certains objets ou liens serait facilement réparable. Ce serveur est protégé derrière un pare-feu qui bloque toute tentative de connexion depuis Internet vers le serveur ainsi que toute connexion non référencée depuis le serveur vers Internet.
Toutes les clés USB insérées sont systématiquement nettoyées. Le nettoyage consiste en la suppression de tout fichier autre que le fichier ‘l’ ou ce qu’il y a dans le dossier ‘o’. Le fichier ‘l’ ne doit contenir que des caractères imprimables. Les liens dans le fichier ‘l’ doivent être de bachue uniquement et leurs signatures sont vérifiées. Le dossier ‘o’ ne doit pas contenir de sous dossiers. Les fichiers du dossier ‘o’ doivent avoir une empreinte valide.
Ce serveur se tient automatiquement à jour de correctifs de sécurité directement sur Internet.
Les nouveaux objets sont ajoutés aux objets déjà présents. Les nouveaux liens sont insérés dans les fichiers de liens via la librairie nebule.

3->4 – L’ensemble des objets et liens sont synchronisés vers le serveur miroir public avec rsync encapsulé dans ssh.

4 – Le serveur miroir est un serveur web disponible en permanence sur Internet. Il n’est pas critique dans sont contenu puisque toutes modifications des objets ou liens seront immédiatement rejetées par les autres entités. Il n’est que peut critique en terme de disponibilité puisque les objets et liens peuvent être diffusés par d’autres entités. Il n’est pas critique non plus en terme de sensibilité des données qu’il partage puisque toutes les données sont soit librement publiables soit chiffrées.
Ce serveur se tient automatiquement à jour de correctifs de sécurité directement sur Internet.

4->5 – Chaque entité peut venir consulter les liens et objets sur le serveur miroir public.

5 – La station cliente est autonome. Elle gère ses propres processus et assure sa propre protection.

Librairie de référence php

L’entité bachue diffuse depuis ce soir la librairie php de référence. Elle est disponible ici (liens) :

58f1f8e05b36b567b9b88f3c953de904ac50e92c5fa2b783da2cf08ccdd3b68e

Le contenu n’est pas lisible parce c’est du code php et qu’il est interprété par le serveur web… Il faudra rapidement mettre en place la mécanique de téléchargement neutre d’objets, c’est à dire sans les interpréter et en fournissant le bon type mime.

Cette librairie des fonctions de références de nebule n’est pas encore terminée et est loin d’offrir le minimum pour travailler les objets et liens nebule. C’est surtout un premier pas vers la diffusion automatisé de mises à jour des scripts et codes autour de nebule

Mise à jour – librairie bash de référence

L’entité bachue diffuse depuis ce soir une nouvelle version de la librairie bash de référence. Elle est disponible ici :

0c2bd920ba6efa6fdb72718bd5d606cd56c95956d8e3e8c6e1f8562d56820853 (contenu)

Cette mise à jour apporte la fonction de déchiffrement complète nebObjUnEnc pour extraire un objet en clair d’un autre objet chiffré. Cela tient compte de la clé de session et de l’entité destinataire, c’est à dire celle qui détient la clé privée (et son mot de passe).

Cela donne par exemple (dans une console bash) pour la commande

nebObjUnEnc 7c81a9adf7596b0ea7a7460e1676558a7d2148c0a619f57edff0dc748d744800 /home/steph/temp/

les logs :

2013-05-24T23:23:48+0200 2  -nebObjUnEnc REQ 7c81a9adf7596b0ea7a7460e1676558a7d2148c0a619f57edff0dc748d744800 /home/steph/temp/
2013-05-24T23:23:48+0200 2  -nebObjUnEnc PATH /home/steph/temp/
2013-05-24T23:23:48+0200 3  -nebReadObjLinks REQ 7c81a9adf7596b0ea7a7460e1676558a7d2148c0a619f57edff0dc748d744800
2013-05-24T23:23:48+0200 4  _l_lsx REQ 7c81a9adf7596b0ea7a7460e1676558a7d2148c0a619f57edff0dc748d744800
2013-05-24T23:23:48+0200 5  _l_ls1 REQ 7c81a9adf7596b0ea7a7460e1676558a7d2148c0a619f57edff0dc748d744800
2013-05-24T23:23:48+0200 2  -nebObjUnEnc FOUND 2919ec018c34e16115b6edccd6cd8f5ba4fc43b2f81a74b05a6a6b2b7b10c1203495bc16302448e0f765f996b20dcfdaa603d498ca3677d1c4edc89d00ff78ee0b08afea86599b9dd7d3b906eabd03e95fcedb6a061a845880734dbd96ce
2013-05-24T23:23:48+0200 2  -nebObjUnEnc SESSION KEY fd375403d263355facc8bfe0393c3182358675ee24826f11911a3e6a6040e9a0
2013-05-24T23:23:48+0200 3  -nebReadObjLinks REQ fd375403d263355facc8bfe0393c3182358675ee24826f11911a3e6a6040e9a0
2013-05-24T23:23:48+0200 4  _l_lsx REQ fd375403d263355facc8bfe0393c3182358675ee24826f11911a3e6a6040e9a0
2013-05-24T23:23:48+0200 5  _l_ls1 REQ fd375403d263355facc8bfe0393c3182358675ee24826f11911a3e6a6040e9a0
2013-05-24T23:23:48+0200 2  -nebObjUnEnc FOUND 8081c51cffa6f2e56f0f2b087cfaf0cf58eb04470e232d3051153d12e536b803a17dbb2d2d32d1816abfe405beac973193ce3ec4116a5588a03fe7a120170cf19160ccb6a2d131711c30d18eb120326972b147baddbd008837f271c401f5
2013-05-24T23:23:48+0200 2  -nebObjUnEnc SESSION KEY ENC cf3ba5ec5c63e3fa3f2aaa4e4005f11134afe1bf1c10cf0b349c303adb3a0a4c
2013-05-24T23:23:48+0200 3  -nebAsymUnEnc REQ cf3ba5ec5c63e3fa3f2aaa4e4005f11134afe1bf1c10cf0b349c303adb3a0a4c
2013-05-24T23:23:48+0200 4  -nebReadObjTypeMime REQ cf3ba5ec5c63e3fa3f2aaa4e4005f11134afe1bf1c10cf0b349c303adb3a0a4c
2013-05-24T23:23:48+0200 5  -nebFindObjType REQ cf3ba5ec5c63e3fa3f2aaa4e4005f11134afe1bf1c10cf0b349c303adb3a0a4c nebule/objet/type
2013-05-24T23:23:48+0200 6  _l_lsx REQ cf3ba5ec5c63e3fa3f2aaa4e4005f11134afe1bf1c10cf0b349c303adb3a0a4c
2013-05-24T23:23:48+0200 7  _l_ls1 REQ cf3ba5ec5c63e3fa3f2aaa4e4005f11134afe1bf1c10cf0b349c303adb3a0a4c
2013-05-24T23:23:48+0200 5  -nebFindObjType TYPE f0fff2e398c34a5cde5006bd1d964226ddee18a7550e552a4e49536607792d7a
2013-05-24T23:23:48+0200 4  -nebReadObjTypeMime FIND application/x-encrypted/rsa
2013-05-24T23:23:48+0200 3  -nebAsymUnEnc OBJ TYPE application/x-encrypted/rsa
2013-05-24T23:23:48+0200 3  -nebAsymUnEnc DECODE cf3ba5ec5c63e3fa3f2aaa4e4005f11134afe1bf1c10cf0b349c303adb3a0a4c 6a4b7f1100b87044b21f0300eb5c8b627e440e6c239b7dc64767dc16fab38719
2013-05-24T23:23:48+0200 3  -nebAsymUnEnc DECODED cf3ba5ec5c63e3fa3f2aaa4e4005f11134afe1bf1c10cf0b349c303adb3a0a4c -> fd375403d263355facc8bfe0393c3182358675ee24826f11911a3e6a6040e9a0
2013-05-24T23:23:48+0200 3  -nebObjUnEnc DECODED KEY
2013-05-24T23:23:48+0200 4  -nebSymUnEnc REQ 7c81a9adf7596b0ea7a7460e1676558a7d2148c0a619f57edff0dc748d744800 fd375403d263355facc8bfe0393c3182358675ee24826f11911a3e6a6040e9a0
2013-05-24T23:23:48+0200 5  -nebReadObjTypeMime REQ 7c81a9adf7596b0ea7a7460e1676558a7d2148c0a619f57edff0dc748d744800
2013-05-24T23:23:48+0200 6  -nebFindObjType REQ 7c81a9adf7596b0ea7a7460e1676558a7d2148c0a619f57edff0dc748d744800 nebule/objet/type
2013-05-24T23:23:48+0200 7  _l_lsx REQ 7c81a9adf7596b0ea7a7460e1676558a7d2148c0a619f57edff0dc748d744800
2013-05-24T23:23:48+0200 8  _l_ls1 REQ 7c81a9adf7596b0ea7a7460e1676558a7d2148c0a619f57edff0dc748d744800
2013-05-24T23:23:48+0200 6  -nebFindObjType TYPE f67ae5bf11f82e1037ee44aa79fab49dd4d7c4f66e6efb3f9a157193b1e20f9a
2013-05-24T23:23:48+0200 5  -nebReadObjTypeMime FIND application/x-encrypted/aes-256-cbc
2013-05-24T23:23:48+0200 4  -nebSymUnEnc OBJ TYPE application/x-encrypted/aes-256-cbc
2013-05-24T23:23:48+0200 4  -nebSymUnEnc ALGO aes-256-cbc
2013-05-24T23:23:48+0200 5  -nebFindObjType REQ 7c81a9adf7596b0ea7a7460e1676558a7d2148c0a619f57edff0dc748d744800 nebule/objet/encode/InitialVector
2013-05-24T23:23:48+0200 6  _l_lsx REQ 7c81a9adf7596b0ea7a7460e1676558a7d2148c0a619f57edff0dc748d744800
2013-05-24T23:23:48+0200 7  _l_ls1 REQ 7c81a9adf7596b0ea7a7460e1676558a7d2148c0a619f57edff0dc748d744800
2013-05-24T23:23:48+0200 5  -nebFindObjType TYPE 4dcabd9342f9d1da7703e050a8887c4d87b06dcea7426d9c0d099bacf763656e
2013-05-24T23:23:48+0200 4  -nebSymUnEnc IV 4dcabd9342f9d1da7703e050a8887c4d87b06dcea7426d9c0d099bacf763656e
2013-05-24T23:23:48+0200 4  -nebSymUnEnc DECODE aes-256-cbc 7c81a9adf7596b0ea7a7460e1676558a7d2148c0a619f57edff0dc748d744800 fd375403d263355facc8bfe0393c3182358675ee24826f11911a3e6a6040e9a0 IV=739c43201f51033e5826db9572bde317
2013-05-24T23:23:48+0200 4  -nebSymUnEnc DECODED IN 0af75abec49fb5769b2431464657f419a2e9e28859b584a3c662c89ae87f1f1e
2013-05-24T23:23:48+0200 4  -nebSymUnEnc MOVED TO PRIV
2013-05-24T23:23:48+0200 4  -nebObjUnEnc DECODED OBJ
2013-05-24T23:23:48+0200 5  -nebReadEntityFName REQ 0af75abec49fb5769b2431464657f419a2e9e28859b584a3c662c89ae87f1f1e
2013-05-24T23:23:48+0200 6  -nebFindObjType REQ 0af75abec49fb5769b2431464657f419a2e9e28859b584a3c662c89ae87f1f1e nebule/objet/nom
2013-05-24T23:23:48+0200 7  _l_lsx REQ 0af75abec49fb5769b2431464657f419a2e9e28859b584a3c662c89ae87f1f1e
2013-05-24T23:23:48+0200 8  _l_ls1 REQ 0af75abec49fb5769b2431464657f419a2e9e28859b584a3c662c89ae87f1f1e
2013-05-24T23:23:49+0200 6  -nebFindObjType TYPE f3ca40a0f58333a71523ebe390a71240432eaa5572f4a466d4ed8030b91f0e20
2013-05-24T23:23:49+0200 5  -nebReadEntityFName FIND 201305201327.e837349285b6a040f41bc5371d58c0a7.www.tar
2013-05-24T23:23:49+0200 5  -nebReadEntitySName REQ 0af75abec49fb5769b2431464657f419a2e9e28859b584a3c662c89ae87f1f1e
2013-05-24T23:23:49+0200 6  -nebFindObjType REQ 0af75abec49fb5769b2431464657f419a2e9e28859b584a3c662c89ae87f1f1e nebule/objet/suffix
2013-05-24T23:23:49+0200 7  _l_lsx REQ 0af75abec49fb5769b2431464657f419a2e9e28859b584a3c662c89ae87f1f1e
2013-05-24T23:23:49+0200 8  _l_ls1 REQ 0af75abec49fb5769b2431464657f419a2e9e28859b584a3c662c89ae87f1f1e
2013-05-24T23:23:49+0200 6  -nebFindObjType TYPE b06912c7bb9360d220e0a7a25449b9012b35f891f4d748cc0f3f0615c1ec48d7
2013-05-24T23:23:49+0200 5  -nebReadEntitySName FIND bz2
2013-05-24T23:23:49+0200 4  -nebObjUnEnc FILENAME 201305201327.e837349285b6a040f41bc5371d58c0a7.www.tar.bz2
2013-05-24T23:23:49+0200 4  -nebObjUnEnc MOVED TO /home/steph/temp/

Et le fichier /home/steph/temp/201305201327.e837349285b6a040f41bc5371d58c0a7.www.tar.bz2 est bien créé.

Mise à jour – librairie bash de référence

L’entité bachue diffuse depuis ce soir une nouvelle version de la librairie bash de référence. Elle est disponible ici :

e7694b8923bfd02d601ddf8235463ceecc0d6913b7d046157107864d0944feb8 (contenu)

C’est une correction de bugg mineur pour la fonction de chiffrement nebAsymEnc . Le bugg entraînait la génération de liens ayant une signature valide mais ayant manifestement une syntaxe invalide.
Les liens invalides, validés jusqu’à présent par l’entité émettrice ainsi que par toutes les autres entités les ayant téléchargés, n’ont pas été nettoyés. Le nettoyage aura lieu lorsque la fonction nebCheckAll sera complète.

IPv6 et nebule

Il est parfois bien difficile de se préparer à l’avenir et d’abandonner les choses au passé.

Il est une chose qui devrait déjà appartenir au passé, ou du moins être en voie d’extinction, voir entretenu par quelques antiquaires : IPv4 !!!

IPv6, c’est le futur.
Ce devrait même être le présent en fait… mais c’est encore considéré comme le futur. Même en France beaucoup de gens n’ont pas nativement accès à l’Internet en IPv6, leur FAI (ou ISP) ne l’implémente pas. Cela ne veut pas dire forcément de systématiquement l’utiliser, mais juste de pouvoir le faire.

Et pour nebule ?
Bonne nouvelle, l’implémentation en bash fonctionnement indifféremment en IPv4 et IPv6. En fait, c’est parce que cela ne dépend que de l’hôte. Si celui-ci a un accès IPv6, les programmes savent l’utiliser. D’ailleurs, on peut aller plus loin. Si l’hôte n’a que IPv6, ça marche aussi !

Donc, depuis hier soir, toutes les entités importantes de nebule sont accessibles aussi en IPv6 :