Comment utiliser SUID, SGID, et Sticky Bits sur Linux

• Dave McKay

  @TheGurkha

• Le 26 février 2020, 8 :00am EDT

SUID, SGID, et Sticky Bits sont de puissantes permissions spéciales que vous pouvez définir pour les exécutables et les répertoires sur Linux. Nous allons partager les avantages – et les pièges potentiels – de leur utilisation.

Ils sont déjà utilisés

Intégrer la sécurité dans un système d’exploitation multi-utilisateurs présente plusieurs dilemmes. Prenez le concept (apparemment) de base des mots de passe, par exemple. Ils doivent tous être stockés afin que chaque fois que quelqu’un se connecte, le système puisse comparer le mot de passe qu’il tape à la copie stockée. Évidemment, comme les mots de passe sont les clés du royaume, ils doivent être sauvegardés.

Sur Linux, les mots de passe stockés sont protégés de deux façons : ils sont chiffrés et seule une personne ayant des privilèges root peut accéder au fichier qui contient les mots de passe. Cela peut sembler bien, mais cela présente un dilemme : si seules les personnes ayant les privilèges root peuvent accéder aux mots de passe stockés, comment ceux qui n’ont pas cet accès peuvent-ils changer leurs mots de passe ?

Élever votre statut

En général, les commandes et les programmes Linux s’exécutent avec le même ensemble de permissions que la personne qui lance le programme. Lorsque root exécute la commande passwd pour changer un mot de passe, elle s’exécute avec les permissions de root. Cela signifie que la commande passwd peut accéder librement aux mots de passe stockés dans le fichier /etc/shadow.

Ce qui serait idéal, c’est un schéma dans lequel n’importe qui sur le système pourrait lancer le programme passwd, mais que le programme passwd conserve les privilèges élevés de root. Cela permettrait à n’importe qui de changer son propre mot de passe.

Le scénario ci-dessus est précisément ce que fait le bit Set User ID (SUID). Il exécute les programmes et les commandes avec les permissions du propriétaire du fichier, plutôt que les permissions de la personne qui lance le programme.

Vous élevez le statut du programme

Il y a cependant un autre dilemme. Il faut empêcher la personne de se mêler du mot de passe de quelqu’un d’autre. Linux intègre le schéma SUID qui lui permet d’exécuter des applications avec un ensemble de permissions temporairement empruntées-mais ce n’est que la moitié de l’histoire de la sécurité.

Le mécanisme de contrôle qui empêche quelqu’un de travailler avec le mot de passe d’une autre personne est contenu dans le programme passwd, pas dans le système d’exploitation et le schéma SUID.

Les programmes qui s’exécutent avec des privilèges élevés peuvent poser des risques de sécurité s’ils ne sont pas créés avec un état d’esprit de « sécurité par conception ». Cela signifie que la sécurité est la première chose que vous considérez, et ensuite vous construisez sur cela. N’écrivez pas votre programme, puis essayez de lui donner une couche de sécurité par la suite.

Le plus grand avantage des logiciels libres est que vous pouvez regarder le code source vous-même ou vous référer à des examens par les pairs fiables de celui-ci. Dans le code source du programme passwd, il y a des vérifications, donc vous pouvez voir si la personne qui exécute le programme est root. Différentes capacités sont autorisées si quelqu’un est root (ou quelqu’un utilisant sudo).

Voici le code qui détecte si quelqu’un est root.

Voici un exemple dans lequel cela est pris en compte. Comme root peut changer n’importe quel mot de passe, le programme n’a pas à s’embarrasser des vérifications qu’il effectue habituellement pour voir quels mots de passe la personne a la permission de changer. Donc, pour root, il saute ces vérifications et sort de la fonction de vérification.

Avec les commandes et utilitaires Linux de base, vous pouvez être sûr qu’ils ont la sécurité intégrée et que le code a été revu de nombreuses fois. Bien sûr, il y a toujours la menace d’exploits encore inconnus. Cependant, les correctifs ou les mises à jour apparaissent rapidement pour contrer toute vulnérabilité nouvellement identifiée.

C’est avec les logiciels tiers – en particulier ceux qui ne sont pas open-source – que vous devez être extrêmement prudent quant à l’utilisation de SUID. Nous ne disons pas de ne pas le faire, mais, si vous le faites, vous voulez vous assurer que cela n’exposera pas votre système à des risques. Vous ne voulez pas élever les privilèges d’un programme qui ne va pas s’auto-gouverner correctement ainsi que la personne qui l’exécute.

Commandes Linux qui utilisent SUID

Voici quelques-unes des commandes Linux qui utilisent le bit SUID pour donner à la commande des privilèges élevés lorsqu’elle est exécutée par un utilisateur régulier :

ls -l /bin/su

ls -l /bin/ping

ls -l /bin/mount

ls -l /bin/umount

ls -l /usr/bin/passwd

Notez que les noms de fichiers sont surlignés en rouge, ce qui indique que le bit SUID est activé.

Les permissions sur un fichier ou un répertoire sont généralement représentées par trois groupes de trois caractères : rwx. Ceux-ci signifient lecture, écriture et exécution. Si les lettres sont présentes, cette permission a été accordée. En revanche, si un tiret (-) au lieu d’une lettre est présent, cette permission n’a pas été accordée.

Il existe trois groupes de ces permissions (de gauche à droite) : celles du propriétaire du fichier, des membres du groupe du fichier et des autres. Lorsque le bit SUID est défini sur un fichier, un « s » représente la permission d’exécution du propriétaire.

Si le bit SUID est défini sur un fichier qui n’a pas de capacités d’exécution, un « S » majuscule le dénote.

Nous allons examiner un exemple. L’utilisateur régulier dave tape la commande passwd:

passwd

La commande passwd demande à dave son nouveau mot de passe. Nous pouvons utiliser la commande ps pour voir les détails des processus en cours d’exécution.

Nous utiliserons ps avec grep dans une autre fenêtre de terminal et chercherons le processus passwd. Nous utiliserons également les options -e (chaque processus) et -f (format complet) avec ps.

Nous tapons la commande suivante:

ps -e -f | grep passwd

Deux lignes sont rapportées, la seconde étant le processus grep à la recherche de commandes contenant la chaîne « passwd ». C’est la première ligne qui nous intéresse, cependant, car c’est celle du processus passwd que dave a lancé.

Nous pouvons voir que le processus passwd s’exécute de la même manière que si root l’avait lancé.

Définir le bit SUID

Il est facile de changer le bit SUID avec chmod. Le mode symbolique u+s définit le bit SUID et le mode symbolique u-s efface le bit SUID.

Pour illustrer certains des concepts du bit SUID, nous avons créé un petit programme appelé htg. Il se trouve dans le répertoire racine de l’utilisateur dave, et il n’a pas le bit SUID activé. Lorsqu’il est exécuté, il affiche les ID utilisateur (UID) réels et effectifs.

L’UID réel appartient à la personne qui a lancé le programme. L’ID effectif est le compte par lequel le programme se comporte comme s’il avait été lancé.

Nous tapons ce qui suit :

ls -lh htg

./htg

Lorsque nous exécutons la copie locale du programme, nous voyons que les ID réel et effectif sont tous deux définis à dave. Donc, il se comporte exactement comme un programme normal devrait le faire.

Copions-le dans le répertoire /usr/local/bin pour que d’autres puissent l’utiliser.

Nous tapons ce qui suit, en utilisant chmod pour activer le bit SUID, puis nous vérifions qu’il a été activé :

sudo cp htg /usr/local/bin

sudo chmod u+s /usr/local/bin/htg

ls -hl /usr/local/bin/htg

Donc, le programme est copié, et le bit SUID est activé. Nous allons l’exécuter à nouveau, mais cette fois-ci nous allons exécuter la copie dans le dossier /usr/local/bin:

htg

Même si dave a lancé le programme, l’ID effectif est défini sur l’utilisateur root. Donc, si mary lance le programme, la même chose se produit, comme indiqué ci-dessous :

htg

L’ID réel est mary, et l’ID effectif est root. Le programme s’exécute avec les permissions de l’utilisateur root.

RELATED : Comment utiliser la commande chmod sous Linux

Le bit SGID

Le bit Set Group ID (SGID) est très similaire au bit SUID. Lorsque le bit SGID est défini sur un fichier exécutable, le groupe effectif est défini sur le groupe du fichier. Le processus s’exécute avec les autorisations des membres du groupe du fichier, plutôt qu’avec les autorisations de la personne qui l’a lancé.

Nous avons modifié notre programme htg pour qu’il affiche également le groupe effectif. Nous allons changer le groupe du programme htg pour qu’il soit le groupe par défaut de l’utilisateur mary, mary. Nous utiliserons aussi les modes symboliques u-s et g+s avec chown pour enlever le bit SUID et mettre le SGID.

Pour ce faire, nous tapons ce qui suit:

sudo chown root:mary /usr/local/bin/htg

sudo chmod u-s,g+s /usr/local/bin/htg

ls -lh /usr/local/bin/htg

Vous pouvez voir le bit SGID indiqué par le « s » dans les permissions de groupe. Notez également que le groupe est défini sur mary et que le nom du fichier est maintenant surligné en jaune.

Avant d’exécuter le programme, établissons à quels groupes dave et mary appartiennent. Nous utiliserons la commande id avec l’option -G (groupes), pour imprimer tous les identifiants des groupes. Ensuite, nous allons lancer le programme htg en tant que dave.

Nous tapons les commandes suivantes :

id -G dave

id -G mary

htg

L’ID du groupe par défaut de mary est 1001, et le groupe effectif du programme htg est 1001. Donc, bien qu’il ait été lancé par dave, il s’exécute avec les permissions des membres du groupe mary. C’est la même chose que si dave avait rejoint le groupe mary.

Appliquons le bit SGID à un répertoire. Tout d’abord, nous allons créer un répertoire appelé « travail », puis changer son groupe en « geek ». Nous allons ensuite définir le bit SGID sur le répertoire.

Lorsque nous utilisons ls pour vérifier les paramètres du répertoire, nous utiliserons également l’option -d (répertoire) afin de voir les détails du répertoire, et non son contenu.

Nous tapons les commandes suivantes :

sudo mkdir work

sudo chown dave:geek work

sudo chmod g+s work

ls -lh -d work

Le bit SGID et le groupe « geek » sont définis. Ceux-ci affecteront tout élément créé dans le répertoire work.

Nous tapons ce qui suit pour entrer dans le répertoire work, créer un répertoire appelé « demo », et vérifier ses propriétés:

cd work

mkdir demo

ls -lh -d demo

Le bit SGID et le groupe « geek » sont automatiquement appliqués au répertoire « demo ».

Tapons ce qui suit pour créer un fichier avec la commande touch et vérifier ses propriétés :

touch useful.sh

ls -lh useful.sh

Le groupe du nouveau fichier est automatiquement défini comme « geek. »

RELATED : Comment utiliser la commande chown sous Linux

Le bit collant

Le bit collant tire son nom de son objectif historique. Lorsqu’il était défini sur un exécutable, il signalait au système d’exploitation que les portions de texte de l’exécutable devaient être maintenues en swap, rendant leur réutilisation plus rapide. Sous Linux, le sticky bit n’affecte qu’un répertoire – le définir sur un fichier n’aurait aucun sens.

Lorsque vous définissez le sticky bit sur un répertoire, les gens ne peuvent supprimer que les fichiers qui leur appartiennent dans ce répertoire. Ils ne peuvent pas supprimer les fichiers qui appartiennent à quelqu’un d’autre, quelle que soit la combinaison d’autorisations de fichiers définie sur les fichiers.

Cela vous permet de créer un répertoire que tout le monde – et les processus qu’ils lancent – peut utiliser comme stockage de fichiers partagé. Les fichiers sont protégés car, encore une fois, personne ne peut supprimer les fichiers de quelqu’un d’autre.

Créons un répertoire appelé « partagé ». Nous utiliserons le mode symbolique o+t avec chmod pour définir le bit collant sur ce répertoire. Nous regarderons ensuite les permissions sur ce répertoire, ainsi que sur les répertoires /tmp et /var/tmp.

Nous tapons les commandes suivantes:

mkdir shared

sudo chmod o+t shared

ls -lh -d shared

ls -lh -d /tmp

ls -lh -d /var/tmp

Si le bit collant est activé, le bit exécutable de l' »autre » ensemble de permissions de fichiers est défini à « t ». Le nom du fichier est également surligné en bleu.

Les dossiers /tmp et /var/tmp sont deux exemples de répertoires qui ont toutes les autorisations de fichiers définies pour le propriétaire, le groupe et les autres (c’est pourquoi ils sont surlignés en vert). Ils sont utilisés comme emplacements partagés pour les fichiers temporaires.

Avec ces autorisations, n’importe qui devrait, théoriquement, pouvoir faire n’importe quoi. Cependant, le bit collant les annule, et personne ne peut supprimer un fichier qui ne lui appartient pas.

Rappels

Voici une liste de contrôle rapide de ce que nous avons couvert ci-dessus pour une référence future:

• SUID ne fonctionne que sur les fichiers.
• Vous pouvez appliquer SGID aux répertoires et aux fichiers.
• Vous ne pouvez appliquer le bit collant qu’aux répertoires.
• Si les indicateurs « s« , « g » ou « t » apparaissent en majuscules, le bit exécutable (x) n’a pas été activé.