Comment utiliser SUID, SGID et Sticky Bits sous Linux



Les autorisations spéciales SUID, SGID et Sticky Bits offrent un contrôle puissant sur les exécutables et les répertoires sous Linux. Cet article explore leurs avantages et les écueils potentiels de leur utilisation.

Utilisation fréquente

La gestion de la sécurité dans un environnement d’exploitation multi-utilisateur présente des défis complexes. Prenez l’exemple des mots de passe. Ils doivent être stockés pour permettre la vérification lors de chaque connexion. Il est impératif de les protéger car ils sont la clé d’accès au système.

Sous Linux, les mots de passe sont protégés de deux manières: ils sont chiffrés et seul l’administrateur (root) a accès au fichier de stockage. Bien que cela semble correct, cela crée un problème: si seules les personnes disposant de privilèges root peuvent accéder à ces mots de passe, comment les autres utilisateurs peuvent-ils les modifier?

Élévation des privilèges

Normalement, les commandes et programmes Linux s’exécutent avec les mêmes autorisations que l’utilisateur qui les lance. Quand root exécute la commande passwd pour changer un mot de passe, elle fonctionne avec ses privilèges root. Ainsi, la commande passwd peut accéder au fichier /etc/shadow contenant les mots de passe.

Idéalement, tout utilisateur du système devrait pouvoir exécuter la commande passwd tout en conservant les privilèges élevés de root. Cela permettrait à chacun de modifier son propre mot de passe.

C’est précisément le rôle du bit Set User ID (SUID). Il permet d’exécuter des programmes avec les droits du propriétaire du fichier, plutôt que ceux de l’utilisateur qui lance le programme.

Renforcement des droits du programme

Un autre défi est d’empêcher un utilisateur de modifier le mot de passe d’un autre. Linux intègre le mécanisme SUID qui permet l’exécution d’applications avec des autorisations empruntées temporairement – mais ce n’est qu’une partie de l’histoire en matière de sécurité.

Le contrôle empêchant un utilisateur d’interférer avec le mot de passe d’autrui est intégré au sein même du programme passwd, et non dans le système d’exploitation ni le mécanisme SUID.

Les programmes exécutés avec des privilèges élevés peuvent présenter des risques de sécurité s’ils ne sont pas conçus en tenant compte de la « sécurité dès la conception ». Cela implique que la sécurité soit la priorité absolue, et non un ajout a posteriori.

L’avantage majeur des logiciels open source est que vous pouvez consulter le code source ou vous référer à des évaluations par des pairs. Dans le code source de passwd, des vérifications sont en place pour identifier si l’utilisateur est root. Des fonctionnalités différentes sont autorisées en fonction de ce statut (ou si l’utilisateur utilise sudo).

Ce code détecte si un utilisateur est root.

Voici un exemple concret. Puisque root peut modifier n’importe quel mot de passe, le programme n’a pas besoin d’effectuer les vérifications habituelles pour identifier les mots de passe que l’utilisateur est autorisé à modifier. Par conséquent, pour root, ces vérifications sont ignorées.

Avec les commandes et outils de base de Linux, vous pouvez être assuré qu’ils ont intégré la sécurité et que le code a été examiné à plusieurs reprises. Bien sûr, le risque d’exploitation de failles inconnues existe toujours, mais des correctifs sont rapidement mis à disposition pour contrer les vulnérabilités.

La prudence est de mise avec les logiciels tiers, surtout ceux qui ne sont pas open source, lors de l’utilisation de SUID. Il est crucial de s’assurer que cela ne compromettra pas la sécurité de votre système. Évitez d’élever les privilèges d’un programme qui pourrait ne pas être fiable.

Commandes Linux utilisant SUID

Voici quelques commandes Linux utilisant le bit SUID pour accorder des privilèges élevés lorsqu’elles sont exécutées par un utilisateur standard:

ls -l /bin/su
ls -l /bin/ping
ls -l /bin/mount
ls -l /bin/umount
ls -l /usr/bin/passwd

Les noms de fichiers sont mis en évidence en rouge, indiquant que le bit SUID est activé.

Les autorisations sur un fichier ou un répertoire sont généralement représentées par trois groupes de trois caractères: rwx (lecture, écriture, exécution). La présence d’une lettre signifie que l’autorisation est accordée. Un tiret (-) indique que l’autorisation n’est pas accordée.

Il y a trois groupes d’autorisations (de gauche à droite): celles du propriétaire, des membres du groupe et des autres. Quand le bit SUID est activé, un « s » remplace l’autorisation d’exécution du propriétaire.

Si le bit SUID est activé sur un fichier sans capacités exécutables, un « S » majuscule est affiché.

Prenons un exemple. L’utilisateur normal dave saisit la commande passwd:

passwd

La commande passwd demande à Dave de saisir son nouveau mot de passe. Nous pouvons utiliser la commande ps pour visualiser les détails des processus en cours.

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

Voici la commande:

ps -e -f | grep passwd

Deux lignes sont affichées, la seconde étant le processus grep cherchant les commandes contenant la chaîne «passwd». La première ligne nous intéresse, c’est celle du processus passwd lancé par Dave.

On constate que le processus passwd s’exécute comme s’il avait été lancé par root.

Activation du bit SUID

Le bit SUID est facilement modifié avec chmod. Le mode symbolique u+s active le bit SUID et u-s le désactive.

Pour illustrer le fonctionnement du bit SUID, nous avons créé un programme nommé htg. Il se trouve dans le répertoire personnel de dave et n’a pas le bit SUID activé. Lorsqu’il est exécuté, il affiche les identifiants utilisateur réels et effectifs (UID).

Le véritable UID correspond à la personne qui a lancé le programme. L’identifiant effectif correspond au compte avec lequel le programme fonctionne comme s’il avait été lancé.

Voici les commandes:

ls -lh htg
./htg

Lorsque nous exécutons la copie locale du programme, les identifiants réels et effectifs sont tous les deux définis sur dave. Il se comporte donc comme un programme normal devrait le faire.

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

Nous allons utiliser les commandes suivantes, en utilisant chmod pour activer le bit SUID, puis vérifier si c’est bien le cas:

sudo cp htg /usr/local/bin
sudo chmod u+s /usr/local/bin/htg
ls -hl /usr/local/bin/htg

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

htg

Bien que Dave ait lancé le programme, l’identifiant effectif est défini sur l’utilisateur root. Si Mary lance le programme, le même résultat se produit, comme le montre l’exemple ci-dessous:

htg

L’identifiant réel est Mary et l’identifiant effectif est root. Le programme s’exécute avec les autorisations de root.

Le bit SGID

Le bit Set Group ID (SGID) est très similaire au bit SUID. Lorsqu’il est activé 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, et non avec celles 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 également les modes symboliques u-s et g+s avec chown pour désactiver le bit SUID et activer SGID.

Voici les commandes:

sudo chown root:mary /usr/local/bin/htg
sudo chmod u-s,g+s /usr/local/bin/htg
ls -lh /usr/local/bin/htg

Le bit SGID est représenté par un « s » dans les autorisations du groupe. Le groupe est défini sur mary, et le nom du fichier est mis en évidence en jaune.

Avant d’exécuter le programme, identifions les groupes auxquels Dave et Mary appartiennent. Nous utiliserons la commande id avec l’option -G (groupes), pour afficher tous les identifiants de groupe. Ensuite, nous allons exécuter le programme htg en tant que dave.

Voici les commandes:

id -G dave
id -G mary
htg

L’identifiant de groupe par défaut pour mary est 1001 et le groupe effectif du programme htg est 1001. Bien qu’il ait été lancé par Dave, il fonctionne avec les autorisations des membres du groupe mary. C’est comme si Dave avait rejoint le groupe de Mary.

Appliquons le bit SGID à un répertoire. Nous allons créer un répertoire nommé « travail », changer son groupe en « geek » et activer le bit SGID.

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

Voici les commandes:

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 activés. Cela affectera tous les éléments créés dans le répertoire de travail.

Voici les commandes pour entrer dans le répertoire de travail, créer un répertoire nommé « 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 ».

Créons un fichier avec la commande touch et vérifions ses propriétés:

touch useful.sh
ls -lh useful.sh

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

Le Sticky Bit

Le sticky bit tire son nom de son usage historique. Lorsqu’il était activé sur un exécutable, il signalait au système d’exploitation que les parties de texte de l’exécutable devaient être conservées dans la mémoire d’échange (swap), accélérant leur réutilisation. Sous Linux, le sticky bit n’a d’effet que sur un répertoire : il est inutile de l’activer sur un fichier.

Quand vous activez le sticky bit sur un répertoire, les utilisateurs ne peuvent supprimer que les fichiers qui leur appartiennent dans ce répertoire. Ils ne peuvent pas supprimer les fichiers appartenant à autrui, quels que soient les droits des fichiers.

Cela vous permet de créer un répertoire que tout le monde – et les processus qu’ils lancent – peuvent utiliser comme stockage de fichiers partagés. Les fichiers sont protégés car personne ne peut supprimer les fichiers des autres.

Créons un répertoire nommé « shared ». Nous utiliserons le mode symbolique o+t avec chmod pour activer le sticky bit. Nous allons examiner les autorisations sur ce répertoire, ainsi que les répertoires /tmp et /var/tmp.

Voici les commandes:

mkdir shared
sudo chmod o+t shared
ls -lh -d shared
ls -lh -d /tmp
ls -lh -d /var/tmp

Quand le sticky bit est activé, le bit exécutable de « l’autre » ensemble d’autorisations de fichier est défini sur « t ». Le nom du fichier est également mis en évidence en bleu.

Les dossiers /tmp et /var/tmp sont deux exemples de répertoires avec tous les droits de fichier pour le propriétaire, le groupe et les autres (ce qui explique leur mise en évidence en vert). Ils sont utilisés comme emplacements partagés pour les fichiers temporaires.

En théorie, avec ces autorisations, tout le monde devrait pouvoir tout faire. Cependant, le sticky bit prend le dessus et empêche la suppression de fichiers appartenant à d’autres utilisateurs.

Rappel

Voici un résumé des points abordés ci-dessus pour référence:

SUID fonctionne uniquement sur les fichiers.
SGID s’applique aux répertoires et aux fichiers.
Le sticky bit ne s’applique qu’aux répertoires.
Si les indicateurs « s », « g » ou « t » apparaissent en majuscules, le bit exécutable (x) n’a pas été activé.