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…

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.

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…

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.

Multi-entité et suppression d’objet

A l’origine, le projet nebule s’appliquait à des entités autonomes. C’est à dire que les entités fonctionnaient localement dans un environnement réservé et ne dépendaient pas d’une entité maître.
Cependant, ces deux points ne sont plus assurés. Le cas du projet sylabe montre que de multiples entités peuvent coexister sur un serveur et surtout dans le même environnement. Ce pourrait être le cas aussi dans une famille qui utilise le même ordinateur, et donc le même environnement. La sûreté de fonctionnement veut que les objets publiques soient partagés pour économiser des ressources, et que les objets protégés ne soient à aucun moment disponibles aux entités qui n’ont pas la clé de déchiffrement.
De plus, pour assurer des transferts anonymisés, il est nécessaire de créer des entités dédiées à ce rôle. Ces entités ne doivent pas avoir de lien avec la véritable entité d’un utilisateur. Mais cet utilisateur doit pouvoir gérer ces entités esclaves et notamment détenir les mots de passe de celles-ci. Il se crée donc une petite hiérarchie d’entités. Il reste à assurer la non-liaison entre l’entité maître et les entités esclaves. Il faut penser que ce lien peut être remonté par les liens de type l, f, u, k, et e… sauf à les chiffrer…
A voir.

Suite à la réflexion sur le nettoyage des liens, et suite, l’expérience de sylabe montre que la suppression des objets en environnement partagé n’est pas évident. En effet, si je décide de supprimer un objet et un certain nombre de liens affairant, que ce passe-t-il ?
Pour les liens, ce n’est pas grave puisque ce sont mes liens. Les autres entités sont sensées disposer de leurs propres liens.
Pour l’objet, peut-être qu’une autre entité s’en sert aussi. Le supprimer sans concertation n’est pas la bonne méthode. Demander une concertation est inimaginable, surtout si certaines entités effectivement disponibles sur un serveur ne sont en fait plus utilisées.
Il se pose une question sur l’appartenance de l’objet. On pourrait très bien supprimer un objet du serveur, si une autre entité en a besoin elle le synchronisera simplement ailleurs et du coup il réapparaîtra sur le serveur. C’est aussi potentiellement un déni de disponibilité si cet objet n’est présent que sur ce serveur ou si on arrive à demander simultanément la suppression sur tous les serveurs hébergeant cet objet. D’après la théorie, un objet n’appartient à personne contrairement aux liens.

La suppression d’un objet qui pose un vrai problème de sécurité ou de droit d’utilisation dans un pays peut être géré de façon exceptionnelle. L’entité à qui appartient le serveur peut se voir disposer du pouvoir de suppression améliorée d’objets sur son serveur ainsi que la possibilité de le placer en liste de bannissement. Il faut de toute façon mettre en place la gestion de la liste de bannissement de l’entité cerberus : nebule/danger.

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 :

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

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…

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