Lorsque l’on pense aux permissions sous Linux ou Unix, les droits classiques de lecture (r), écriture (w) et exécution (x) viennent immédiatement à l’esprit. Cependant, au-delà de ces permissions de base, il existe des mécanismes moins connus mais tout aussi puissants pour gérer l’accès aux fichiers et aux répertoires : Les bits spéciaux. Parmi eux, trois méritent une attention particulière : setuid, setgid et sticky bit. Ces bits spéciaux jouent un rôle déterminant dans le fonctionnement des programmes, des scripts, des dossiers partagés et dans la sécurité globale d’un système. Comprendre leur utilité permet d’optimiser la gestion des fichiers exécutables, des répertoires de travail collaboratif et de mieux contrôler les droits d’accès.

Mieux comprendre setuid : Exécuter un fichier avec les droits de son propriétaire

Le bit setuid, abréviation de set user ID on execution, est un mécanisme fondamental du système de permissions Unix/Linux. Il est conçu pour répondre à un besoin spécifique : permettre à un utilisateur d’exécuter un fichier en adoptant temporairement l’identité de l’utilisateur propriétaire de ce fichier, souvent, il s’agit de root. Dans un système multi-utilisateur, chaque processus s’exécute normalement avec les droits de l’utilisateur qui l’a lancé. Cela garantit que les utilisateurs ne peuvent pas accéder ou modifier des ressources qui ne leur appartiennent pas. Cependant, certains programmes système doivent être exécutables par tous, tout en accédant à des fichiers protégés. C’est ici que setuid entre en jeu.

Prenons l’exemple de la commande passwd. Elle permet à chaque utilisateur de modifier son propre mot de passe. Or, cette action nécessite de modifier le fichier /etc/shadow, un fichier ultra-sensible du système qui stocke les mots de passe chiffrés et qui est normalement accessible uniquement à root. Sans setuid, seul l’administrateur pourrait le modifier. Pourtant, grâce à setuid, la commande passwd s’exécute avec les droits de son propriétaire (root), même si elle est lancée par un utilisateur lambda. Cela permet une modification sécurisée et contrôlée sans donner un accès total à root à tout le monde (voir notamment notre article sur les rootkits). Voici comment se présente ce fichier dans le système :

ls -l /usr/bin/passwd
-rwsr-xr-x 1 root root 54256 jan  1 12:34 /usr/bin/passwd

Le détail important se trouve ici : -rwsr-xr-x. Le s à la place du x dans le champ utilisateur indique que le bit setuid est actif. Cela signifie que ce programme sera exécuté avec les privilèges de son propriétaire (dans ce cas, root). Si la permission d’exécution n’était pas activée, on verrait un S majuscule, ce qui signale une erreur de configuration (le bit setuid est défini, mais le fichier n’est pas exécutable).

Comment activer ou désactiver le setuid

L’activation du setuid se fait avec la commande chmod, à l’aide de l’option u+s (user + setuid) :

chmod u+s monscript.sh

Pour le désactiver :

chmod u-s monscript.sh

Il est également possible d’utiliser la notation octale pour appliquer ce bit spécial. Le setuid correspond à la valeur 4000. Ainsi, pour rendre un fichier exécutable par tous et activer le setuid :

chmod 4755 monscript.sh

Ce chiffre est obtenu en combinant :

• 4 pour setuid
• 7 pour lecture, écriture et exécution pour le propriétaire
• 5 pour lecture et exécution pour le groupe
• 5 pour lecture et exécution pour les autres

Pourquoi le setuid peut poser problème s’il est mal utilisé

Malgré ses avantages, le bit setuid peut devenir dangereux s’il est appliqué de manière irréfléchie, notamment sur des scripts. Lorsqu’un script shell est exécuté avec le setuid, il peut être manipulé ou interrompu, permettant à un utilisateur malveillant d’injecter du code ou de détourner son fonctionnement pour obtenir des droits supérieurs. Cela représente une faille de sécurité potentielle majeure.

Pour cette raison, la plupart des systèmes modernes désactivent par défaut le support du setuid sur les scripts interprétés (comme les fichiers .sh, .py, .pl, etc.). Même si vous activez le setuid sur un script, le système peut l’ignorer, rendant la commande inopérante.

Le setuid est donc réservé aux programmes compilés en langages natifs comme le C ou le C++, où le contrôle du comportement à l’exécution est beaucoup plus rigoureux. Ces programmes doivent être écrits avec soin pour éviter d’exposer des fonctions sensibles à des utilisateurs non autorisés.

Cas d’usage concrets du setuid

En dehors de passwd, d’autres programmes courants utilisent le setuid :

• ping : Pour envoyer des paquets ICMP, une opération qui nécessite un accès bas niveau au réseau, souvent réservé à root.
• mount : Pour monter des systèmes de fichiers, dans certains cas configurés pour être utilisables par les utilisateurs normaux via fstab.
• su : Pour changer d’utilisateur, souvent vers root, avec authentification.

Il est important de noter que ces fichiers sont étroitement surveillés, et régulièrement mis à jour par les distributions Linux pour corriger toute vulnérabilité potentielle. La moindre erreur dans la gestion des droits peut ouvrir une porte aux escalades de privilèges.

Audit et vérification des fichiers setuid

Pour identifier les fichiers qui ont le bit setuid activé sur votre système, vous pouvez utiliser la commande suivante :

find / -perm -4000 -type f 2>/dev/null

Cela affiche tous les fichiers exécutables dotés du bit setuid. Il est fortement recommandé de limiter ces fichiers au strict nécessaire, et de comprendre leur rôle dans le système.

Les bonnes pratiques autour du setuid

• Ne jamais activer setuid sur un fichier sans comprendre ses conséquences ;
• Éviter son usage sur des scripts interprétés ;
• Limiter son usage à des binaires fiables et maintenus ;
• Auditer régulièrement les fichiers setuid à l’aide de scripts automatisés ou de systèmes d’alerte ;
• Utiliser sudo comme alternative plus contrôlable pour exécuter des commandes avec élévation de privilège.

Explorer setgid et sticky bit : Les permissions avancées pour répertoires et exécutables

En dehors du bit setuid, qui modifie temporairement les privilèges d’un utilisateur lors de l’exécution d’un fichier, le système Unix/Linux propose deux autres mécanismes de permissions spéciales tout aussi importants : setgid et sticky bit. Ces deux options, souvent méconnues des développeurs ou administrateurs débutants, jouent pourtant un rôle essentiel dans la gestion des droits sur les répertoires partagés ou les fichiers exécutables.

Comprendre leur comportement respectif permet de mieux organiser les collaborations entre utilisateurs, de renforcer la sécurité dans les environnements multi-utilisateurs et d’automatiser la gestion des droits dans des projets complexes.

Setgid sur un fichier : Exécuter avec les droits du groupe

Le bit setgid (set group ID) appliqué à un fichier exécutable permet au processus lancé par ce fichier de s’exécuter avec les droits du groupe propriétaire du fichier, peu importe le groupe primaire de l’utilisateur qui l’exécute. Cela peut être utile pour accorder à plusieurs utilisateurs des accès spécifiques sans leur modifier individuellement leur groupe principal.

Exemple de commande pour activer setgid :

chmod g+s programme

Affichage typique dans la sortie de ls -l :

-rwxr-sr-x 1 root dev 123456 sep 7 09:00 programme

Le caractère s remplace le x dans le bloc des permissions du groupe. Si le bit d’exécution est absent mais que le setgid est actif, on verra alors un S majuscule, indiquant une configuration incorrecte ou incomplète.

Ce type d’usage reste relativement rare, mais peut être utile dans des environnements très cloisonnés, où les permissions doivent être ajustées sans modifier les groupes système.

Setgid sur un répertoire : Uniformiser les groupes dans un dossier partagé

Le comportement du setgid est bien plus courant et utile lorsqu’il est appliqué à un répertoire. Dans ce cas, tous les fichiers ou sous-dossiers créés à l’intérieur de ce répertoire hériteront automatiquement du groupe du dossier parent, et non du groupe principal de l’utilisateur qui les crée. Cela permet de garantir une cohérence des droits d’accès dans les espaces de travail collaboratif.

Voici un exemple classique :

mkdir projet
chown :devs projet
chmod g+s projet

Avec cette configuration :

• Le répertoire projet appartient au groupe devs.
• Tous les fichiers créés à l’intérieur seront automatiquement associés au groupe devs.
• Il n’est donc pas nécessaire de forcer chaque utilisateur à modifier manuellement le groupe de chaque fichier.

C’est une solution très pratique dans les équipes de développement, les services de design ou tout autre contexte où plusieurs utilisateurs partagent un répertoire commun. Cela évite les conflits de droits et les erreurs d’accès en lecture/écriture.

Permission affichée dans ls -l :

drwxrwsr-x 2 alice devs 4096 sep 7 09:30 projet

Notez le s dans le bloc des permissions du groupe, qui indique que le setgid est actif sur ce dossier.

Sticky bit : Empêcher la suppression des fichiers par d’autres utilisateurs

Le sticky bit est un autre mécanisme essentiel pour la gestion des droits sur les répertoires, mais son objectif est tout à fait différent. Appliqué uniquement à des répertoires, il empêche les utilisateurs de supprimer ou de renommer les fichiers appartenant à d’autres utilisateurs dans ce répertoire, même s’ils ont des droits d’écriture sur le dossier lui-même.

C’est particulièrement utile pour des répertoires publics comme /tmp, où tous les utilisateurs peuvent déposer des fichiers, mais ne doivent en aucun cas supprimer ceux des autres.

Exemple concret :

ls -ld /tmp
drwxrwxrwt 10 root root 4096 sep 7 10:30 /tmp

Le t à la fin des permissions indique que le sticky bit est activé. Sans ce bit, un utilisateur pourrait effacer les fichiers d’un autre utilisateur, simplement parce qu’il dispose de droits en écriture sur le dossier.

Pour activer le sticky bit sur un répertoire :

chmod +t dossier

Et pour le désactiver :

chmod -t dossier

Le sticky bit est aussi utilisé sur des répertoires partagés dans des structures éducatives ou de coworking, où la confidentialité de chaque utilisateur doit être respectée malgré un espace commun.

Tableau récapitulatif des bits spéciaux

Voici un tableau synthétique pour visualiser l’usage de setuid, setgid et sticky bit selon le type de fichier ou dossier :

Cette synthèse permet de mieux identifier la nature et le comportement de chaque bit spécial. Bien qu’ils soient discrets, leur impact sur la gestion des droits et la sécurité est réel.

Comme toujours en administration système, il est recommandé de n’activer ces options que lorsqu’elles sont justifiées, et de les désactiver une fois leur usage terminé. Un audit périodique des permissions sur les fichiers sensibles et répertoires partagés reste la meilleure garantie pour un environnement sécurisé et bien organisé.