Un gestionnaire d'affichage à privilèges séparés.

• Une frontière de privilèges qu'un bogue de session ne peut pas franchir en sens inverse
• Des identifiants qui ne survivent pas à l'instant où ils sont utilisés
• Aucun chemin par lequel une interface compromise puisse démarrer une session
• Une reprise après plantage qui ne dépend pas du bon fonctionnement de l'écran

Présentés comme des décisions plutôt que comme des fonctionnalités, parce que chacune a coûté quelque chose de réel. Voici dans quel sens celle-ci a tranché et ce que cela a permis.

1. 01

   Trois processus, pas un seul

   Un démon root démarre un processus de travail par connexion, qui possède tout le cycle de vie de l'authentification, et ce processus crée par fork l'enfant de session, qui abandonne définitivement ses privilèges avant d'exécuter quoi que ce soit de l'utilisateur. Le processus qui détient le descripteur d'authentification ne devient jamais l'utilisateur, et le processus qui devient l'utilisateur ne le détient jamais. Une conception à processus unique est bien plus simple et fait de tout bogue qu'elle contient un bogue root.

2. 02

   L'interface est sans privilèges et remplaçable

   L'interface d'accueil s'exécute sous son propre compte sans privilèges et dialogue avec le démon par un protocole versionné sur socket unix, avec une trame préfixée par sa longueur, une taille maximale et une négociation de version. Elle ne peut pas démarrer de session non authentifiée et ne peut pas faire passer une commande libre à travers la frontière : elle peut seulement désigner une session que le système a lui-même découverte. Publier ce protocole sous une licence permissive est ce qui permet à quelqu'un d'écrire une autre interface sans hériter de la licence du démon.

3. 03

   Monothread et bloquant, délibérément

   Pas d'environnement d'exécution asynchrone, pas de pool de threads. Un processus qui fait un fork ne doit pas avoir d'autres threads actifs à ce moment-là, et tout le modèle repose sur un fork correct à l'instant exact où les privilèges changent. Renoncer à la concurrence ici procure la seule garantie dont le modèle de sécurité ne peut pas se passer.

4. 04

   Un écran noir est traité comme un défaut, pas comme un accident

   L'état du terminal est restauré depuis des gestionnaires de signaux, en n'utilisant que des appels sûrs dans ce contexte, plutôt que depuis le code de nettoyage ordinaire qu'un plantage brutal n'atteint jamais, avec un crochet de service et une vérification au démarrage suivant en renfort. Les consoles texte restent disponibles comme chemin de retour. C'est la voie de reprise pour le cas où ce qui a échoué est précisément ce qui aurait servi à diagnostiquer.

L'alternative

Un seul processus, exécuté en root, qui fait les trois. C'est la forme de l'outil que celui-ci remplace et il est réellement plus simple : aucun protocole à définir, aucune négociation de version, aucune sérialisation, aucune défaillance partielle entre composants, et un cycle de vie de session qu'on peut lire de haut en bas dans un seul fichier.

Ce que cela a coûté

Une grande quantité de complexité, définitivement, pour un programme dont tout le travail est d'afficher une boîte de mot de passe. Un format d'échange avec négociation de version, un socket dont l'interlocuteur doit être vérifié, des appels à fork aux moments exacts, et un ensemble de modes de défaillance qui n'existent que parce que les éléments sont séparés. Tout cela est du code qui peut être faux, dans un programme où se tromper coûte cher.

Pourquoi le compromis tient

Dans un processus unique, un bogue dans la partie qui analyse les touches du clavier est un bogue dans la partie qui détient root, parce que c'est le même espace d'adressage. Ce n'est pas un profil de risque hypothétique, c'est une identité. La séparation fait passer le pire cas d'une compromission complète de la machine à une interface plantée qui n'aurait de toute façon pas pu démarrer de session. La complexité est un prix qui peut être payé une fois et relu ; la conception à processus unique ne facture son prix qu'une fois, et ne le rembourse jamais.

• ArticleChoisir un système d'init, et pourquoi 0dyssey utilise runitLe système pour lequel celui-ci est construit : ce qui démarre une machine, comment juger un système d'initialisation par rapport à un autre, et pourquoi le service qui supervise une connexion a la forme qu'il a.
• ArticleModèles de paquets, et la dette que l'on reporte en figeantComment un logiciel arrive sur une machine et passe d'un état connu à un autre, ce par quoi un gestionnaire d'affichage doit être installé et mis à jour sans laisser personne devant un écran noir.
• Produit0dyssey, le système d'exploitationLe système d'exploitation dont il est la couche de connexion : la composition nommée, les décisions prises et ce qui n'existe pas encore.