Votre commande VPN s’exécute sans privilèges ; le service, non

La commande VPN s’exécute sous votre utilisateur, aucun mot de passe n’apparaît et le tunnel monte. Cette séquence ressemble à une opération sans privilèges, et ce n’est généralement pas le cas. Un service distinct effectue les changements réseau, et la question intéressante est ce que ce service fera pour un appelant qu’il n’a pas vérifié. Compter les invites de mot de passe ne vous dit rien sur cette frontière.

L’interface, le mécanisme et la vérification

L’interface accepte des demandes : connecter, déconnecter, choisir un profil. Le mécanisme possède les opérations réseau : créer des interfaces, changer des routes, appliquer des filtres. La vérification d’autorisation décide si cet appelant peut demander cette action. Ces trois peuvent être répartis entre un binaire, un assistant et un service système, et l’utilisateur ne voit que le premier.

Les rôles peuvent vivre dans un seul binaire, dans deux processus ou dans un client et un service système, et la commande que voit l’utilisateur révèle rarement lequel. Une icône de la zone de notification et un démon système peuvent ressembler à une seule application tout en s’exécutant avec une autorité très différente. Le privilège au moment de l’installation et le privilège au moment de la demande sont aussi deux choses différentes. Un installateur qui a tourné en root peut laisser un service à l’écoute de demandes ultérieures, longtemps après que le gestionnaire de paquets a terminé. C’est ce service, et non la commande que vous avez tapée, qui détient l’autorité.

La délégation est la conception normale

Déléguer le travail réseau privilégié à un service est l’architecture raisonnable. Elle garde les applications ordinaires sans privilèges et centralise les opérations qui demandent du soin. Le dispositif ne paie que lorsque le service vérifie aussi qui demande et pour quoi. Sans cette vérification, ce n’est qu’une porte plus large.

NetworkManager est l’exemple concret sous Linux. Son guide de configuration explique comment PolicyKit autorise les demandes non root dans la configuration par défaut. Cela montre une autorisation déléguée dans un produit réel. Cela ne prouve pas que chaque client commercial utilise NetworkManager, et cela ne décrit ni le chemin de socket ni la politique d’un fournisseur particulier.

Le schéma est une délégation avec une politique derrière. L’exemple est une mise en œuvre de ce schéma, pas une mise en œuvre universelle.

Lisez la frontière, pas l’invite

Trouvez le service, le propriétaire de sa configuration et l’interface locale que le frontal utilise. Demandez ensuite quels utilisateurs peuvent demander quelles opérations. Pouvoir monter et descendre un profil enregistré n’est pas la même permission que charger une configuration que l’opérateur n’a jamais relue. La différence, c’est toute la question de sécurité.

Commencez par le gestionnaire de services et par la vue du client sur ses propres permissions. Les commandes ci-dessous montrent si le démon tourne, ce que l’appelant peut lui demander et ce que le démon expose sous son répertoire d’exécution.

systemctl status NetworkManager
nmcli general permissions
ls -l /run/NetworkManager

Demandez aussi sur quoi l’opération agit. Un élément de menu qui semble personnel peut changer les routes et le DNS de toute la machine, ce qui signifie qu’il peut perturber les sessions d’autres utilisateurs. Le rayon d’impact relève de la même revue que la permission, et il décide généralement si le service a besoin d’un rôle plus étroit.

Corrigez les permissions de la manière prise en charge

Rendre un socket de contrôle protégé inscriptible par tous, ou ajouter un compte à un groupe administratif large, supprime une erreur de permission et en crée une plus grande. L’erreur était la seule chose qui vous disait que cette frontière existait. Utilisez le processus documenté d’appartenance ou d’autorisation, y compris le rafraîchissement de session qu’il exige. L’appartenance à un groupe ne s’applique souvent qu’aux nouvelles sessions de connexion, ce qui explique qu’un changement peut sembler sans effet jusqu’à la connexion suivante.

Si le produit expose un rôle plus étroit pour l’opération, préférez-le à une autorisation générale. Écrivez le rôle choisi et son propriétaire à côté du nom du service.

À quoi ressemble une bonne séparation

Les applications ordinaires restent sans privilèges, le service n’effectue que la préparation pour laquelle il a été conçu, et chaque appelant est vérifié contre une politique que quelqu’un possède. C’est une conception défendable. Elle est aussi auditable, parce que la politique a un nom qui lui est attaché. Tout ce qui est plus large mérite une exception écrite plutôt qu’un changement silencieux de permissions.

Le mode de défaillance est un service qui exécute toute demande de tout utilisateur local parce que l’interface est commode. Du côté de l’utilisateur, cela paraît identique, et cela porte une autorité bien plus grande. Testez une demande refusée, pas seulement celle qui réussit. Un refus qui vient de la politique est la preuve que la politique existe.