Résumé

  • Dans le modèle Postfix à maître privilégié, la plupart des services ouvrent d’abord les fichiers nécessaires puis abandonnent root avant de traiter des requêtes ; quatre services de distribution conservent une identité root sauvegardée pour des opérations ciblées.
  • Le maître non privilégié réduit les droits du superviseur, mais supprime une partie de la séparation interne, expose davantage secrets et journaux en cas de compromission et n’est autorisé que pour un ensemble restreint de configurations en production.

Demander si un serveur de courrier « tourne en root » ne suffit pas à décrire son risque. L’architecture Postfix invite à poser des questions plus précises : quel processus a besoin de quel droit, à quel moment, et sur quels fichiers ou ressources appartenant à d’autres utilisateurs ?

Un message reçu par SMTP ou QMQP passe d’abord par un service exposé au réseau. Celui-ci vérifie l’entrée puis transmet l’enveloppe et le contenu à cleanup(8). Cette étape effectue le dernier traitement avant la mise en file, écrit le message dans la file d’arrivée et avertit qmgr(8). Le gestionnaire de file choisit ensuite les agents de distribution. Il conserve une file active limitée : un grand retard n’oblige donc pas le processus à ouvrir tous les messages en attente. Le processus résident master(8) supervise ces services, les lance à la demande et applique les limites de processus configurées.

Le superviseur et les processus qui traitent les requêtes n’ont pas la même fonction. Dans le modèle Postfix à maître privilégié, un service peut démarrer avec les droits root, ouvrir des fichiers sensibles — clés privées TLS ou mots de passe de base de données, par exemple — puis abandonner irrévocablement root avant de traiter les requêtes. La documentation de sécurité précise qu’un service compromis après cette étape ne peut plus ouvrir ces fichiers, bases de données ou journaux.

Root intervient donc pendant l’initialisation et la sélection des privilèges ; il n’est pas nécessairement accordé sans interruption à chaque processus accessible depuis le réseau.

Il existe des exceptions. La plupart des services perdent définitivement root, mais local(8), pipe(8), spawn(8) et virtual(8) gardent une identité root effective sauvegardée. Ils en ont besoin pour agir sous l’identité d’un utilisateur cible ou sur une ressource extérieure à Postfix, comme une boîte aux lettres ou une commande externe. Postfix distingue ces deux rôles : root peut séparer les privilèges entre services Postfix et confiner Postfix lorsqu’un service accède aux fichiers d’un utilisateur ou lance un logiciel tiers. La seule étiquette « processus root » masque ces frontières différentes.

Lors d’une présentation à LISA en 2010, Wietse Venema décrivait Postfix comme une architecture partitionnée de moindre privilège. Il citait parmi ses influences un système de pare-feu qui séparait la réception du courrier de sa distribution au moyen de processus peu privilégiés et placés dans un chroot. Il expliquait aussi que de petits programmes peuvent faciliter la maintenance, une fois l’infrastructure de communication construite. Ce témoignage situe une conception à l’époque ; il ne donne ni le nombre actuel de démons Postfix ni une mesure des résultats de sécurité.

La documentation actuelle décrit, elle, la séparation opérationnelle entre réception, nettoyage, gestion des files et distribution.

Le changement récent ne prétend pas que retirer root au superviseur rend automatiquement l’ensemble plus sûr. La documentation Postfix indique que Venema avait d’abord réalisé une version non privilégiée de master(8) pour des tests d’intégration non publiés en 2025. Après une demande d’un client en 2026, il l’a adaptée à un usage de production limité et a ajouté la documentation. Dans ce mode, master fonctionne sous l’identité fixe postfix, plutôt que root. Les services utilisent alors les mêmes privilèges Postfix durant leur initialisation et pendant le traitement des requêtes. Le projet précise que ce modèle ne conserve ni la séparation interne des privilèges Postfix ni le confinement habituel pour les fichiers externes, les boîtes aux lettres et les commandes tierces.

La différence se matérialise dans les permissions. Les fichiers de clés secrètes Postfix doivent être lisibles par l’utilisateur postfix ; un service compromis peut donc les lire. Les journaux Postfix facultatifs doivent appartenir à postfix, ce qui permet à un service compromis de les consulter, modifier ou supprimer. La configuration ne doit pas appartenir à cet utilisateur. Dans une installation à instances multiples, toutes les instances doivent utiliser le maître privilégié, ou toutes le maître non privilégié : les deux modes ne se mélangent pas.

La limite de production est étroite. Postfix autorise ce mode pour les installations qui relaient tous les messages par SMTP ou LMTP. Il déconseille formellement en production les configurations où les services locaux exécutent des programmes non-Postfix ou déposent les messages dans des boîtes aux lettres. L’un des risques cités est qu’une commande inscrite dans le fichier .forward d’un utilisateur s’exécute avec les droits de postfix, au lieu de ceux de l’utilisateur cible, et permette à celui-ci de prendre le contrôle du système de courrier. L’avertissement porte sur des configurations précises, mais il est explicite.

La leçon n’est donc ni « root est sûr » ni « root est dangereux ». Un changement de privilèges déplace le risque entre les frontières. Un maître sans root peut convenir à un relais limité, mais ses services partagent alors l’accès aux secrets et journaux que le modèle privilégié peut protéger derrière l’initialisation et l’abandon de privilèges. Avant de changer l’identité du maître, les opérateurs doivent inventorier les chemins de distribution et vérifier que le mode choisi correspond aux fichiers et commandes accessibles à chaque service.

La documentation publique définit cet arbitrage ; elle ne mesure ni la fréquence de chaque mode ni les résultats obtenus en production.

Sources