Le bouton VPN exige sudo : encadrez la règle, validez la politique

Le bouton VPN fonctionne pour l’administrateur et échoue pour tous les autres, alors quelqu’un ajoute une ligne à sudoers. Cette ligne survit généralement au problème qu’elle devait résoudre, et elle accorde souvent plus que ce dont le bouton a besoin. Avant de modifier la politique, vérifiez si le propriétaire pris en charge de la connexion peut déjà faire le travail. Les trois conditions ci-dessous décident si sudo entre en jeu.

Condition 1 : le propriétaire pris en charge peut le faire sans sudo

Sur la plupart des bureaux Linux, le gestionnaire réseau possède déjà les connexions VPN, et son autorisation passe par polkit plutôt que par sudo. Un utilisateur autorisé à monter une connexion peut le faire en ligne de commande sans aucune règle root. Vérifiez ce que le gestionnaire permet avant de supposer que le bouton a besoin d’un privilège. Si la réponse est oui, la modification de sudoers résout un problème qui n’existe pas.

nmcli connection show
nmcli connection up "Work VPN"

Si le gestionnaire refuse, lisez pourquoi : une règle polkit manquante, une connexion appartenant à un autre utilisateur ou un profil stocké là où l’utilisateur ne peut pas le lire. Chacun de ces cas a un correctif pris en charge, plus étroit qu’une règle sudo. Une élévation de privilèges est le dernier recours, pas le premier.

Condition 2 : la règle nomme un seul exécutable et ses arguments

Si sudo est réellement nécessaire, la règle devrait nommer la commande exacte et, lorsque c’est possible, les arguments qu’elle peut utiliser. Une règle qui laisse un utilisateur exécuter un script enveloppe n’est sûre que dans la mesure des permissions de ce script, car l’utilisateur peut modifier ce que root exécutera. Une règle avec un joker après la commande est le même problème sous une forme plus courte.

sudo -l -U alice
ls -l /usr/local/sbin/vpn-up

Vérifiez chaque chemin de la chaîne de commande : le binaire, le script qu’il appelle, le fichier de configuration qu’il lit et tout répertoire intermédiaire. Si l’un d’eux est accessible en écriture à l’utilisateur, la règle encadrée est en pratique un root sans restriction. Les arguments comptent aussi, car une commande qui accepte un chemin de configuration peut être dirigée vers un fichier que l’utilisateur contrôle. Écrivez la règle pour l’opération, pas pour le bouton.

Arrêtez-vous si la commande a besoin d’un fichier contrôlé par l’utilisateur pour fonctionner. Alors la conception est mauvaise, et aucune syntaxe sudoers ne la rendra sûre.

Condition 3 : toute la politique s’analyse, pas seulement votre ligne

Validez avec l’éditeur qui verrouille le fichier et vérifie la syntaxe, et validez la politique assemblée plutôt qu’un fragment. Un fichier qui s’analyse seul peut encore casser l’ordre d’inclusion ou dupliquer une règle d’une manière qui change le comportement.manuel de visudo documente à la fois l’éditeur verrouillant et le mode de vérification seule utilisé ici.

sudo visudo -c
sudo visudo -cf /etc/sudoers.d/vpn-launcher

La vérification rapporte le fichier et la ligne lorsqu’elle échoue, et c’est ce rapport qui est utile. Corrigez la modification prévue via l’éditeur plutôt que forcer l’enregistrement d’une erreur connue, car une politique cassée peut verrouiller tous les administrateurs d’un coup. Les fichiers du répertoire d’inclusion ont aussi besoin de la propriété et du mode exigés par le manuel, sinon ils sont ignorés ou rejetés. La syntaxe n’est que la première porte : une fois franchie, relisez la règle et demandez ce qu’elle autorise réellement.

Arrêtez-vous si le seul moyen de faire fonctionner la modification est de désactiver la vérification de syntaxe. Ce n’est pas une politique, c’est une panne qui attend un redémarrage.

Récupération : gardez une session qui fonctionne encore

Avant d’enregistrer, assurez-vous qu’une session administrative autorisée est déjà ouverte et qu’un second chemin vers la machine existe. Une erreur dans sudoers peut vous retirer la capacité de la corriger, et un bouton de bureau ne vaut pas ce risque. Si sudo est déjà cassé, utilisez le chemin de récupération documenté du système plutôt que d’en improviser un.

sudo -n true
id

Des alternatives comme pkexec dépendent de leur propre installation et politique, elles ne sont donc pas une seconde invite root garantie. Gardez aussi l’autorisation locale séparée de la fourniture du secret VPN : une règle sudo ne peut pas déverrouiller un agent de secrets absent, et elle ne satisfait pas le MFA de la passerelle. Après la correction, testez le compte normal en n’effectuant que l’opération prévue, puis utilisez les contrôles habituels du gestionnaire.

La décision se termine lorsque vous pouvez dire quelle condition a justifié sudo, ce que nomme la règle, que toute la politique s’analyse et comment vous récupéreriez sinon. Un lanceur privilégié qui vous coûte l’accès administratif est un mauvais échange, et il est généralement évitable.