SUID : Set User ID
Sécurité
SUID : Set User ID. « Positionner l'identifiant d'utilisateur », par analogie avec un badge d'accès que le propriétaire d'un local prête le temps d'une seule tâche. Un exécutable portant ce bit tourne avec les droits de son propriétaire, et non avec ceux de la personne qui le lance.
Fonctionnement : À l'exécution, le noyau attribue au processus l'UID effectif du propriétaire du fichier. Le bit vaut 4000 en octal, se pose avec chmod u+s et apparaît comme un « s » à la place du « x » du propriétaire dans ls -l (un « S » majuscule signale le bit sans droit d'exécution).
Usages légitimes : passwd, su ou sudo appartiennent à root et portent ce bit afin qu'un utilisateur ordinaire puisse modifier /etc/shadow ou changer d'identité dans un cadre contrôlé. Linux ignore le bit sur les scripts interprétés, qui ne s'exécutent donc pas avec les droits de leur propriétaire.
Exploitation : Un binaire SUID root mal conçu, ou un outil généraliste comme find ou vim doté du bit par erreur, permet d'ouvrir un shell root en une ligne. Ce badge est prêté à tout le monde, et chacun peut fixer sa propre tâche.
Repérage et atténuation : La commande find / -perm -4000 -type f liste les exécutables concernés. L'option de montage nosuid neutralise le bit sur une partition, et les capacités Linux remplacent souvent un SUID root complet par un privilège unique.
Ce qui arrive si on s'en passe
Sans le bit SUID, un utilisateur ordinaire ne pourrait plus lancer passwd pour changer son propre mot de passe, ni su ou sudo pour obtenir légitimement des droits supplémentaires : ces programmes doivent écrire dans des fichiers réservés à root, comme /etc/shadow. Il faudrait alors confier le mot de passe root à davantage de personnes ou multiplier les interventions de l'administrateur, ce qui élargit la surface d'attaque au lieu de la réduire. À l'inverse, chaque exécutable SUID superflu reste un point d'entrée : une faille ou une option détournée y donne directement les droits du propriétaire. Il ne s'agit donc pas de supprimer le mécanisme, mais de le réserver aux quelques binaires qui en ont réellement besoin et de remplacer les autres par des capacités Linux ciblées.
Explication de la marmotte
Sur un ordinateur, chaque personne a un compte avec des droits limités, et un compte spécial, l'administrateur, peut tout faire. Certains programmes ont pourtant besoin de faire une chose réservée à l'administrateur, par exemple enregistrer le nouveau mot de passe d'une personne. On leur colle alors une sorte d'étiquette qui dit : « quand quelqu'un lance ce programme, il agit avec les droits de son propriétaire ». C'est comme un gardien qui prête sa clé pour ouvrir une seule porte. Le danger apparaît si le programme peut être détourné pour faire autre chose : la personne garde alors la clé et peut ouvrir toutes les portes.
Où ce terme est utilisé
- Élévation de privilège via un binaire SUID root mal configuré (27 occurrences)
- Linux shell, permissions et processus, le modèle de contrôle d'accès (11 occurrences)
- Détournement de bibliothèque partagée Linux et ld.so (8 occurrences)
- Dirty COW CVE-2016-5195 : course dans le copy-on-write Linux (6 occurrences)
- Durcir un serveur Linux avant la mise en production, checklist (2 occurrences)
- Isolation des conteneurs Docker : namespaces, cgroups et évasions (2 occurrences)
- Écrire des scripts Bash système fiables et sûrs en production (1 occurrence)