setuid, setgid et Sticky Bit expliqués

Les autorisations familières de lecture, d’écriture et d’exécution couvrent la plupart de ce que vous faites avec les fichiers, mais Linux dispose de trois bits d’autorisation supplémentaires qui modifient la façon dont les programmes s’exécutent et le comportement des répertoires partagés. Ils expliquent pourquoi un utilisateur ordinaire peut changer son propre mot de passe avec un outil appartenant à root, pourquoi les fichiers créés dans un répertoire d’équipe partagent tous le même groupe et pourquoi n’importe qui peut y écrire. /tmp mais je ne peux pas y supprimer les fichiers d’un autre utilisateur. Ce sont les bits setuid, setgid et sticky.

Ce guide explique ce que chaque autorisation spéciale fait sur les fichiers et sur les répertoires, comment les définir et les lire, ainsi que les points de sécurité à garder à l’esprit.

Où s’adaptent les embouts spéciaux #

Le mode d’un fichier comporte trois groupes d’autorisations, pour le propriétaire, le groupe et les autres, chacun avec des autorisations de lecture, d’écriture et d’exécution. Les bits spéciaux se trouvent à côté d’eux et sont affichés dans les mêmes positions d’exécution. En numérique chmod valeur, ils forment un quatrième chiffre initial :

• 4 – setuid
• 2 – setgid
• 1 – morceau collant

Donc chmod 4755 définit setuid plus 755et chmod 2770 définit setgid plus 770. Vous pouvez également les définir symboliquement avec u+s, g+set +tce qui est souvent plus clair.

Le bit setuid #

Le bit setuid (« set user ID ») s’applique aux fichiers exécutables. Normalement, un programme s’exécute avec les privilèges de l’utilisateur qui le démarre. Lorsque le bit setuid est défini, le programme s’exécute avec les privilèges du propriétaire du fichier. L’exemple classique est passwdqui appartient à root car il doit écrire dans /etc/shadowun fichier que les utilisateurs ordinaires ne peuvent pas toucher :

ls -l /usr/bin/passwd

-rwsr-xr-x 1 root root 68208 Jan 1 09:00 /usr/bin/passwd

Le s dans la position d’exécution du propriétaire (là où vous vous attendez à x) est le bit setuid. Étant donné que le fichier appartient à root et porte setuid, tout utilisateur qui exécute passwd le fait avec les privilèges root pendant la durée de cette commande, ce qui leur permet de mettre à jour leur propre entrée dans un fichier protégé.

Définissez le bit sur un fichier sous l’une ou l’autre des formes :

sudo chmod u+s program
sudo chmod 4755 program

Si le fichier n’a pas également le bit d’exécution défini, la liste affiche une majuscule S au lieu de squi signale setuid sans exécuter et est généralement une erreur.

Le bit setgid #

Le bit setgid (« set group ID ») se comporte différemment selon qu’il est défini sur un fichier ou un répertoire, et le cas du répertoire est le plus utile des deux.

Sur un fichier exécutable, setgid fonctionne comme setuid mais pour le groupe : le programme s’exécute avec les privilèges de groupe du fichier plutôt qu’avec ceux de l’appelant.

Sur un répertoire, setgid modifie la propriété des nouveaux fichiers qu’il contient. Normalement, un nouveau fichier prend le groupe principal de l’utilisateur qui l’a créé. Avec setgid défini sur le répertoire, chaque nouveau fichier et sous-répertoire hérite du groupe du répertoire, et les nouveaux sous-répertoires conservent également le bit setgid.

Il s’agit de la manière standard de configurer un dossier de projet partagé dans lequel tout ce qui est créé doit appartenir à un seul groupe d’équipe. En supposant que developers le groupe existe déjà, vous pouvez attribuer le répertoire à ce groupe et définir le bit comme ceci :

sudo chgrp developers /srv/project
sudo chmod 2775 /srv/project
ls -ld /srv/project

drwxrwsr-x 2 root developers 4096 Jan 1 09:00 /srv/project

Le s dans la position d’exécution du groupe se trouve le bit setgid. Désormais, les nouveaux fichiers créés par les membres dans /srv/project hériter du developers groupe automatiquement, de sorte que l’équipe n’a pas à définir manuellement la propriété du groupe. L’accès en écriture du groupe dépend toujours du mode fichier, du umaskou une ACL par défaut, définissez donc ces valeurs par défaut pour qu’elles correspondent au fonctionnement de l’équipe. Réglez le bit symboliquement avec chmod g+s /srv/project.

Le morceau collant #

Le bit collant s’applique aux répertoires. Lorsqu’il est défini, un utilisateur ne peut supprimer ou renommer un fichier dans le répertoire que s’il possède ce fichier (ou possède le répertoire, ou est root), même lorsque le répertoire lui-même est accessible en écriture par tout le monde. L’exemple canonique est /tmpoù chaque utilisateur doit créer des fichiers mais aucun utilisateur ne devrait pouvoir supprimer ceux d’un autre :

ls -ld /tmp

drwxrwxrwt 10 root root 4096 Jan 1 09:00 /tmp

Le t dans la position d’exécution des autres se trouve le bit collant. Sans cela, un répertoire accessible en écriture à tout le monde permettrait à n’importe quel utilisateur de supprimer n’importe quel fichier qu’il contient, car l’autorisation de suppression dépend du répertoire et non du fichier. Le morceau collant comble cet écart. Définissez-le sur un répertoire partagé sous l’une ou l’autre des formes :

sudo chmod +t /shared/dropbox
sudo chmod 1777 /shared/dropbox

Comme pour les autres bits, un majuscule T apparaît à la place de t lorsque le répertoire ne dispose pas de l’autorisation d’exécution des autres.

Lecture des bits dans la sortie ls #

Chaque bit spécial réutilise un emplacement d’exécution dans la chaîne d’autorisation, vous les lisez donc par position :

• setuid remplace celui du propriétaire xmontré comme s (ou S sans exécuter).
• setgid remplace celui du groupe xmontré comme s (ou S sans exécuter).
• collant remplace celui des autres xmontré comme t (ou T sans exécuter).

Une lettre minuscule signifie que l’autorisation d’exécution sous-jacente est également définie ; une lettre majuscule signifie que ce n’est pas le cas. Pour rechercher des programmes setuid à travers le système, utilisez find avec un -perm tester par exemple sudo find / -perm -4000 -type f -print.

Référence rapide #

Pour une référence rapide imprimable aux modes chmod, consultez l’aide-mémoire chmod .

Notes de sécurité #

Setuid et setgid sont puissants, et un programme setuid-root est une cible courante pour les attaquants, car une faille dans celui-ci peut transférer les privilèges root. Gardez ces points à l’esprit :

• Définissez setuid ou setgid uniquement sur les programmes qui en ont réellement besoin et préférez les outils système bien audités aux scripts personnalisés.
• Le noyau Linux ignore les bits setuid et setgid des scripts shell, vous ne pouvez donc pas exécuter un script en tant qu’autre utilisateur de cette façon. Utiliser sudo règles à la place.
• Auditez périodiquement les programmes setuid sur un système avec sudo find / -perm -4000 -type f -print et enquêtez sur tout ce qui est inattendu.

FAQ #

A quoi sert le bit setuid ?
Il exécute un exécutable avec les privilèges du propriétaire du fichier plutôt que de l’utilisateur qui le démarre. Un programme setuid-root tel que passwd s’exécute en tant que root, ce qui permet aux utilisateurs ordinaires d’effectuer une action privilégiée étroitement limitée.

Quelle est la différence entre setgid sur un fichier et sur un répertoire ?
Sur un fichier, setgid exécute le programme avec les privilèges de groupe du fichier. Sur un répertoire, les nouveaux fichiers et sous-répertoires héritent du groupe du répertoire au lieu du groupe principal du créateur, ce qui permet aux dossiers d’équipe partagés de conserver un groupe cohérent.

Pourquoi ne puis-je pas supprimer un fichier dans /tmp que je ne possède pas ?
Le bit collant est allumé /tmp. Dans un répertoire avec le sticky bit, seul le propriétaire d’un fichier (ou le propriétaire du répertoire ou la racine) peut le supprimer ou le renommer, même si le répertoire est accessible en écriture par tout le monde.

Setuid fonctionne-t-il sur les scripts shell ?
Non. Le noyau ignore setuid et setgid sur les scripts pour des raisons de sécurité. Pour permettre à un utilisateur d’exécuter un script avec des privilèges plus élevés, accordez cette commande via sudo configuration à la place.

Conclusion #

Les bits setuid, setgid et sticky étendent le modèle d’autorisation standard pour contrôler la façon dont les programmes s’exécutent et le comportement des répertoires partagés. Utilisez setuid et setgid avec parcimonie et uniquement sur des programmes fiables, appuyez-vous sur les répertoires setgid et le sticky bit pour des espaces partagés sécurisés, et recherchez sudo plutôt que des scripts setuid. Pour le modèle d’autorisation sous-jacent, consultez notre guide sur les autorisations de fichiers Linux et la commande chmod .