Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

ADR-073 — Doctrine de configuration binaire : pas de conf en texte clair, CLI dédié exigeant le mot de passe administrateur

Statut : Accepté (2026-07-07, décision BDFL directe). Doctrine transverse à tous les composants Air porteurs de configuration. S’appuie sur la Charte (valeurs) et les Principes d’ingénierie (méthode). Premier consommateur : ADR-074 (air-sshd). Rime avec la posture « prévisible / fait ce qu’il dit » et « sur-sécuriser puis dégraisser » (Principe 5).

Catégorie : Doctrine de sécurité transverse (nouvelle). N’altère aucune couche scellée ; cadre les composants à configuration présents et futurs.

Contexte — le modèle de menace

Les démons et outils Unix classiques se configurent par des fichiers texte en clair (~/.ssh/config, /etc/ssh/sshd_config, /etc/…). Ces fichiers sont, par construction, lisibles et modifiables par quiconque possède les droits du propriétaire — c’est-à-dire par un attaquant qui a pris le shell d’un utilisateur.

Le scénario qui nous préoccupe :

  1. Un attaquant obtient le shell d’un utilisateur (phishing, exploit applicatif, clé compromise…). Il lit immédiatement ~/.ssh/config (hôtes, options, agents, ProxyCommand…) — renseignement gratuit.
  2. Il modifie cette conf (ajout d’un ProxyCommand, d’un LocalForward, d’une directive Include…) pour détourner ou intercepter les connexions futures.
  3. Si le shell dispose d’un sudo permissif, il réécrit la conf du démon (sshd_config : PermitRootLogin, AuthorizedKeysCommand, ForceCommand…) → compromission durable de la machine.

Le fichier de configuration en clair est la surface d’attaque. Un simple éditeur suffit ; aucune compétence, aucun outil, aucune ré-authentification n’est requis.

Décision

Tout composant Air porteur de configuration utilise un fichier de configuration BINAIRE, jamais du texte en clair. Trois règles :

  1. Format binaire. La configuration effective d’un composant Air est un fichier binaire (schéma versionné, cf. les schémas capn’proto déjà employés ailleurs dans Air). Il n’est ni lisible ni modifiable avec un éditeur de texte.

  2. Manipulation par un CLI dédié, sous ré-authentification. La configuration ne se modifie que via un outil en ligne de commande dédié qui exige la ressaisie du mot de passe administrateur de la machine avant d’appliquer un changement. La possession du shell (voire d’un sudo permissif) ne suffit plus à réécrire la conf : il faut un secret que l’attaquant n’a pas et une action explicite. (Le mécanisme d’autorisation exact — dérivation, stockage, vérification du secret administrateur — est hors périmètre de cet ADR et fera l’objet d’un RFC dédié.)

  3. Compatibilité par sérialiseur / désérialiseur. Quand l’interopérabilité l’exige (importer une conf tierce, exporter pour un outil externe), le CLI fournit un sérialiseur (import : texte tiers → binaire Air) et un désérialiseur (export : binaire Air → texte). Le texte n’est alors qu’un format d’échange transitoire, jamais la source de vérité vivante du composant.

Objectif assumé — retarder, pas rendre impossible

Le but est fonctionnel : retarder et complexifier la capacité d’un attaquant à modifier une configuration pour compromettre la machine — défense en profondeur, pas prétention à l’inviolabilité absolue. Un attaquant qui obtient aussi le mot de passe administrateur et l’outil peut encore agir ; mais on supprime la modification triviale par simple accès au système de fichiers, qui est aujourd’hui le mode opératoire par défaut. On élève le coût, on réduit la surface, on force une action authentifiée et traçable.

Conséquences

  • Positif : la conf n’est plus modifiable par simple accès au FS ; l’attaquant doit franchir une ré-authentification administrateur ; le renseignement passif (lecture de la conf en clair) est supprimé ; les changements passent par un point unique outillable (audit, journalisation, validation de schéma).
  • Chaque composant à conf doit fournir : un schéma binaire versionné, un codec (lecture au démarrage), et l’import/export texte de compatibilité.
  • Dépendance : le mécanisme d’autorisation administrateur (règle 2) reste à spécifier (RFC) ; les composants peuvent démarrer par le format binaire + codec + import/export, l’autorisation venant s’y brancher.
  • Ergonomie : éditer une conf devient une commande explicite, pas un vim. C’est un choix assumé (rigueur > commodité, posture Air).
  • Cohérence : renforce la valeur « composant prévisible qui fait ce qu’il dit » — la conf effective est exactement celle validée par le CLI, pas un texte éditable à l’insu du composant.

Alternatives rejetées

  • Statu quo (conf texte en clair) : c’est précisément la surface d’attaque à éliminer.
  • Conf texte chiffrée au repos : une fois déchiffrée pour lecture, elle redevient éditable ; et la gestion de clé de déchiffrement recrée le problème. Le binaire + CLI + ré-auth adresse la modification, pas seulement la confidentialité au repos.
  • Restreindre par ACL / permissions seules : n’arrête pas le propriétaire du shell (ni un sudo permissif). Orthogonal, insuffisant seul.
  • Signer la conf texte : détecte la falsification mais ne l’empêche pas, et complexifie sans supprimer l’éditabilité triviale.