N'empilez pas le durcissement systemd sur la descente user d'OpenVPN

Deux recettes de moindre privilège collées ensemble ne produisent pas un déploiement plus strict. Un modèle laisse le démon démarrer avec des privilèges puis descendre vers un compte non privilégié après l'initialisation ; l'autre fait lancer le service par le gestionnaire sous une identité restreinte dès la première instruction. Chacun fonctionne seul, et la combinaison produit souvent un service qui ne peut faire proprement ni l'une ni l'autre des deux tâches. Le reste parcourt la décision dans l'ordre.

Deux modèles, un seul propriétaire du basculement

Le premier modèle appartient au démon. Les options OpenVPN de la version communautaire user et group changent d'identité une fois le tunnel et les clés en place, et persist-key avec persist-tun gardent ces ressources utilisables ensuite.

Le second modèle appartient au gestionnaire de services. Un réglage systemd User= ou Group= décide de l'identité sous laquelle le processus démarre, et les directives de capacités décident de ce qu'il peut détenir. Choisir entre les modèles est une question d'empaquetage avant d'être une question de sécurité, et le mainteneur du paquet y a déjà répondu. Votre travail est de trouver cette réponse plutôt que d'inventer une troisième option.

Les deux sont légitimes. L'erreur est de les traiter comme des couches d'une même conception, car le second modèle peut faire du changement d'identité du premier une opération que le processus n'a plus le droit d'exécuter.

Décidez où l'identité change

Si l'unité démarre déjà sous un compte dédié, ajouter une instruction du démon pour devenir un autre compte demande une transition setuid qu'un service durci n'a jamais été censé faire. La panne apparaît comme une erreur de permission au démarrage plutôt que comme un message de politique clair. Cela se lit comme une capacité manquante, ce qui pousse les gens vers un ensemble de limites plus large au lieu de la question de l'identité.

Lisez ce que le paquet installé fournit réellement avant de modifier quoi que ce soit, y compris son répertoire drop-in. Certaines unités omettent délibérément la descente propre au démon parce que le gestionnaire s'en charge déjà, et d'autres s'appuient sur ces options pour le basculement après initialisation. Retirer l'une ou l'autre sans savoir quel modèle vous avez hérité est la façon dont un service qui fonctionne cesse de démarrer.

Écrivez le modèle choisi en une ligne : propriété du gestionnaire ou propriété du démon. Chaque directive ultérieure doit être cohérente avec cette phrase, et une unité mixte doit être traitée comme un défaut et non comme un compromis.

Les capacités sont des limites, pas des dons

Un ensemble de limites de capacités dit ce qu'un processus peut détenir au maximum. C'est un plafond, et y lister une capacité ne donne rien en soi, c'est pourquoi une unité dotée d'un ensemble de limites généreux peut malgré tout échouer à créer un tunnel.

Ce qui place réellement une capacité dans l'ensemble ambiant d'un service, c'est AmbientCapabilities=. La référence d'exécution de systemd documente les deux directives séparément, et cette distinction explique l'essentiel des conseils confus sur les capacités en ligne.

N'ajoutez une capacité qu'après que l'opération défaillante l'a identifiée. Un ensemble de limites plus large masque la cause réelle et laisse le service plus privilégié que la conception ne le prévoyait. Il rend aussi l'unité plus difficile à relire, car le plafond ne décrit plus le travail. Retirez la capacité supplémentaire une fois le vrai défaut corrigé.

Cartographiez l'autorité sur le cycle de vie

Listez ce que le processus doit faire à chaque étape : démarrage, régime stable, réauthentification et démontage. La création d'interface, les changements de routes, la lecture d'une clé protégée et l'appel d'un assistant ne se produisent pas tous au même moment ni sous les mêmes exigences. Triez la liste par étape avant de la trier par capacité.

Les options de persistance conservent des ressources à travers la renégociation, et elles n'accordent pas des permissions qui n'ont jamais été détenues. Une clé que le processus ne peut pas lire au démarrage restera illisible ensuite, quoi que disent les indicateurs de persistance. Les indicateurs conservent ce qui fonctionnait déjà.

Utilisez un compte dédié plutôt qu'un compte partagé. Les développeurs d'OpenVPN mettent en garde contre l'habitude d'utiliser nobody comme exemple générique, car d'autres services de l'hôte tournent peut-être déjà sous ce compte et l'isolation que vous croyez avoir n'est pas là.

Les fonctions qui modifient la charge locale, comme le déchargement du canal de données ou une compilation liée différemment, peuvent déplacer les opérations nécessaires. Révisez la carte quand le paquet change, pas seulement quand quelque chose casse.

Écrivez le plan et gardez un accès de secours

Un registre de déploiement devrait nommer le gestionnaire, l'identité de démarrage, l'identité stable visée et chaque autorisation avec l'opération qui l'exige. C'est ce registre qui rend le changement suivant relisible au lieu d'expérimental.

Gardez un accès console pendant que vous modifiez, car une unité qui échoue au démarrage est difficile à réparer à distance. Testez un redémarrage et un redémarrage complet avant de déclarer le changement terminé. Une unité qui survit à un redémarrage peut encore échouer avant que le réseau soit prêt.

Le succès est un cycle de vie d'autorité minimale compris, pas un processus qui se trouve tourner sous un nom non-root.