Pourquoi nosuid empêche un assistant VPN de devenir root

Le chiffrement du disque et un montage nosuid ressemblent à des variantes de la même idée, et ils n’ont aucun rapport. L’un protège les données au repos, et l’autre décide si le noyau respectera un bit de privilège au moment où un programme démarre. Un assistant qui n’atteint pas l’identité qu’il attend se plaint du second. L’hypothèse que le premier en est responsable pousse les gens à réinstaller des clients qui n’ont jamais été cassés.

Deux Propriétés Sans Rapport

Le chiffrement du disque répond à la question de savoir qui peut lire les blocs quand la machine est éteinte. Une option de montage répond à ce que le noyau fera des bits de mode d’un fichier quand quelqu’un l’exécute. Rien dans le premier ne contraint le second, et un portable entièrement chiffré peut monter un système de fichiers avec toutes les restrictions en place.

Les lire comme une seule propriété produit la théorie selon laquelle un dossier personnel chiffré empêche l’accès root. Cette théorie survit parce que les deux symptômes apparaissent sur la même machine, pas parce qu’ils partagent une cause.

Ce Qui Supprime Réellement la Transition

La référence d’execve décrit comment un exécutable set-user-ID change l’identité effective du nouveau processus pour celle du propriétaire du fichier. La même page énumère les conditions qui suppriment cette transition et l’équivalent pour les identifiants de groupe : un réglage no_new_privs, un système de fichiers monté avec nosuid et un processus en cours de traçage. Les capacités de fichier sont ignorées dans les mêmes conditions. Ces quatre règles couvrent presque tous les signalements de ce type.

Cette liste explique pourquoi le mode affiché par ls n’est jamais toute l’histoire de l’autorisation. Elle ne dit pas quelle condition a provoqué un message d’échec précis, et l’application peut signaler une opération d’identifiants sans rapport avec les mêmes mots. Notez le programme exact, le lanceur et la séquence d’erreurs avant de conclure.

Identifiez l’exécutable installé par le paquet pris en charge, son propriétaire, son chemin réel et la politique du système de fichiers qui le contient. Une copie dans un dossier de téléchargements n’est pas l’assistant installé, quoi qu’en dise son mode.

Ce Qu’il Ne Faut Pas Faire

Poser des bits set-user-ID sur un binaire non vérifié et le déplacer jusqu’à ce que la restriction disparaisse n’est pas une réparation. Cela remplace une politique que vous ne compreniez pas par un privilège que vous ne pouvez pas auditer, et la même technique appliquée à un assistant est une voie d’élévation bien connue. Retirer nosuid d’un montage est pire, parce que cela touche tous les programmes de ce système de fichiers, pas un seul.

La voie prise en charge est l’installation documentée de l’assistant ou du service par le client, réalisée par un administrateur, qui place le binaire là où la politique l’attend. Cela conserve un seul mécanisme de privilège au lieu de deux.

Confirmer le Contexte de Lancement Réel

Après une correction autorisée, lancez l’assistant comme le produit le lance, et non depuis un shell root. Un succès en root ne prouve rien du chemin d’un utilisateur ordinaire, et la différence entre ces deux contextes est exactement ce dont parlait l’échec.

Confirmez ensuite l’opération réseau pour laquelle l’assistant existe. Un assistant qui démarre mais ne peut pas configurer l’interface a déplacé le problème d’une étape, sans le résoudre.

findmnt -no TARGET,OPTIONS /home
getcap /usr/libexec/openvpn-helper 2>/dev/null; ls -l /usr/libexec/openvpn-helper

Notez les options de montage et la propriété de l’assistant dans la même note. Sinon, la prochaine personne qui débogue cela reprendra la théorie du chiffrement depuis le début.