Si vous activez le bit setuid sur un script shell appartenant à root, s'exécute-t-il en root ?

Une idée reçue courante : chmod u+s script.sh sur un script appartenant à root donnerait un utilitaire rapide exécuté en root. Sous Linux, ce n'est pas le cas, et cela guide aussi l'audit d'élévation de privilèges.

Ce que fait le noyau

La page de manuel execve(2) indique que Linux « (comme la plupart des Unix modernes) ignore les bits set-user-ID et set-group-ID sur les scripts ». Le noyau lance l'interpréteur de la ligne #! et l'UID effectif reste celui de l'appelant. Une raison historique : les situations de concurrence entre la vérification du fichier par le noyau et sa réouverture par l'interpréteur.

Où le bit s'applique

Le bit set-user-ID est respecté pour un binaire natif. La même page liste des cas où il est ignoré, notamment lorsque le système de fichiers est monté nosuid. Le comportement sur ces montages varie selon la version du noyau : certains refusent l'exécution avec EPERM, d'autres exécutent le fichier sans changement de privilège.

Enseignements sécurité

Lors de l'audit d'un hôte Linux, énumérer les binaires SUID est utile ; les scripts SUID ne le sont pas. Si des administrateurs ont besoin d'un utilitaire privilégié, on utilise un petit wrapper compilé, une règle sudo restreinte ou des capabilities de fichier, chacun avec ses propres risques.

Pourquoi les distracteurs sont tentants

« S'exécute en root » est la réponse intuitive. « Seulement si modifiable par tous » et « seulement bash » inventent des règles inexistantes.

Ce que veulent les recruteurs

« Linux ignore le SUID sur les scripts ; il fonctionne sur les binaires compilés ; nosuid le désactive aussi », avec l'implication pour l'audit.