Graphe des entités autorités

Afin d’organiser une certaine intendance autour de la diffusion du code des applications, un certain nombre d’entités sont nécessaires.

Le modèle utilisé est assez classique est simple, c’est un schéma de parenté. Il peut être amené à évoluer dans le futur.

La structure du graphe reconnue est la suivant :

  • Le maître du tout (puppetmaster)
    • Les autorités de la sécurité
    • Les autorités du code
    • Les autorités du temps
    • Les autorités de l’annuaire

Une évolution est en cours d’intégration avec la nouvelle version des liens. Si l’entité qui chapeaute toutes les autres est unique, chaque groupe d’autorités n’est plus seulement une entité mais devient un groupe d’entités à pouvoir identique.

Il est à prévoir que le maître du tout deviendra aussi, un jour, des autorités globales. Mais la forme n’est pas encore défini.

Chaque entité ici considérée doit être un objet entité EID (Entity ID) valide avec lien de type, un lien de nommage et un lien de localisation (URL web).

D’un point de vue sémantique, on quitte progressivement la notion de maître historique pour aller vers la notion d’autorité. Outre le rapport à l’esclavage, on est soumis au maître, on se soumet à l’autorité.

Le puppetmaster est un EID qui peut être remplacé. Il va faire référence par des liens dédiés vers les différents d’autorités au moyen de RID dédiés :

  • Autorités de la sécurité
    • a4b210d4fb820a5b715509e501e36873eb9e27dca1dd591a98a5fc264fd2238adf4b489d.none.288
  • Autorités du code
    • 2b9dd679451eaca14a50e7a65352f959fc3ad55efc572dcd009c526bc01ab3fe304d8e69.none.288
  • Autorités du temps
    • bab7966fd5b483f9556ac34e4fac9f778d0014149f196236064931378785d81cae5e7a6e.none.288
  • Autorités de l’annuaire
    • 50e1d0348892e7b8a555301983bccdb8a07871843ed8f392d539d3d90f37ea8c2a54d72a.none.288

C’est à dire que tout EID désigné par un de ces RID (l>RID>EID), et signé par le puppetmaster, devient une autorité dans le groupe considéré.

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…

Entités de recouvrement – implémentation

Dans le précédent article sur les Entités de recouvrement qui date de plus de 6 mois, il était question de l’implémentation du mécanisme dans le code. Jusque là la liste des entités de recouvrement était renvoyée vide.
Ce mécanisme peut être une contrainte légale dans certains pays mais ce peut être aussi un moyen d’assurer plus sereinement la disponibilité des données sans remettre en question significativement la confidentialité de celles-ci. Sa portée est strictement local et ne doit pas devenir un comportement global sous peine de rompre la confiance dans l’ensemble du code de nebule.

La prochaine version de la bibliothèque nebule en PHP intègre le code nécessaire à la détection des entités marquées localement comme entités de recouvrement et le code qui se charge de dupliquer la protection des objets pour ces entités.

La définition des entités de recouvrement est purement locale et est attachée à l’entité instance locale. La détection d’entité de recouvrement se fait sur un lien de type f entre chaque entité définie comme entité de recouvrement et l’entité instance locale. Le champ méta du lien est l’objet de référence contenant nebule/objet/entite/recouvrement. Seuls les liens des autorités strictement locales sont pris en compte, c’est à dire à l’exception du puppetmaster, du maître de la sécurité et du maître du code.

La duplication de la protection se fait au niveau de la fonction (unique) de protection d’un objet setProtected(). Afin d’éviter la suppression du partage de protection avec une entité de recouvrement, la fonction cancelShareProtectionTo() ne supprime pas ce partage si l’entité est dans la liste des entités de recouvrement.
Afin de ne pas perturber l’utilisateur, les applications affichent tous les partages de protection mais n’affichent pas le bouton correspondant pour ces entités de recouvrement.

Les applications option, sylabe et klicty permettaient déjà l’affichage des entités de recouvrement même si elle était vide. Ces affichages ont été améliorés afin d’afficher en plus l’entité autorité locale qui a activé l’entité comme entité de recouvrement. Le but est d’avoir un mécanisme qui peut être contraignant et indiscret mais dont le fonctionnement doit être ouvert et loyal pour maintenir la confiance de l’utilisateur.
L’application option est maintenant le centre de gestion des entités de recouvrement. Il est possible, lorsque l’on déverrouille l’entité instance de serveur, d’ajouter ou de retirer des entités à la liste. Les autres entités ne peuvent faire que de l’affichage. Si un lien est généré par une autre entité, il est ignoré.

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.

Nouvelles applications

En plus de messae qui est une application standard à destination des utilisateurs, il y a maintenant 3 autres applications qui sont cette fois plutôt destinées au côté technique de nebule.

Les nouvelles applications :

  • defolt : Application d’affichage par défaut pour les serveurs sans applications interactives.
  • upload : Application de chargement de liens pré-signés du maître du code exclusivement.
  • option : Application de visualisation et gestion des options de configuration, des applications, des entités de recouvrement et entités autorités locales.

Le bootstrap évolue aussi. Une version en php procédurale est reprise en concurrence de la version php orienté objet. Continuer la lecture de Nouvelles applications

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.

Liens marqués entre le puppetmaster et les autres entités

Il y a quelques jours, le puppetmaster a été réveillé pour générer de nouveaux liens. De nouveaux objets de nebule sont maintenant reconnus comme des objets à usage réservé :

  • nebule/objet/entite/maitre/securite
  • nebule/objet/entite/maitre/code
  • nebule/objet/entite/maitre/annuaire
  • nebule/objet/entite/maitre/temps

Et il permettent de désigner via un lien de type f les différentes entités qui ont les rôles correspondants.

Le code de la librairie nebule en php et le bootstrap s’en servent désormais pour retrouver les entités avec ces rôles.

CF : sylabe – Avancement

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…