SUID, SGID et Sticky Bits sont de puissantes autorisations spéciales que vous pouvez définir pour les exécutables et les répertoires sous Linux. Nous partagerons les avantages – et les pièges potentiels – de leur utilisation.
Table des matières
Ils sont déjà utilisés
Intégrer la sécurité dans un système d’exploitation multi-utilisateur présente plusieurs dilemmes. Prenons le concept de base (apparemment) 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.
Sous Linux, les mots de passe stockés sont protégés de deux manières: ils sont cryptés et seule une personne disposant des privilèges root peut accéder au fichier contenant les mots de passe. Cela peut sembler correct, mais cela pose un dilemme: si seules les personnes disposant de privilèges root peuvent accéder aux mots de passe stockés, comment ceux qui n’ont pas cet accès changent-ils leurs mots de passe?
Élever votre statut
Habituellement, les commandes et programmes Linux s’exécutent avec le même ensemble d’autorisations que la personne qui lance le programme. Lorsque root exécute la commande passwd changer un mot de passe, il s’exécute avec les autorisations de root. Cela signifie que la commande passwd peut accéder librement aux mots de passe stockés dans le fichier / etc / shadow.
L’idéal serait un schéma dans lequel n’importe qui sur le système pourrait lancer le programme passwd, mais laisser le programme passwd conserver les privilèges élevés de root. Cela permettrait à quiconque de changer son propre mot de passe.
Le scénario ci-dessus est précisément ce que fait le bit d’ID utilisateur défini (SUID). Il exécute des programmes et des commandes avec les autorisations du propriétaire du fichier, plutôt que les autorisations de la personne qui lance le programme.
Vous rehaussez le statut du programme
Il y a cependant un autre dilemme. La personne doit être empêchée de se mêler du mot de passe de quelqu’un d’autre. Linux incorpore le schéma SUID qui lui permet d’exécuter des applications avec un ensemble d’autorisations 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, et non dans le système d’exploitation et le schéma 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 créés avec un état d’esprit «sécurité dès la conception». Cela signifie que la sécurité est la première chose que vous considérez, puis 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 open source est vous pouvez regarder le code source vous-même ou reportez-vous à des évaluations par des pairs de confiance. Dans le code source du programme passwd, il y a des vérifications afin que vous puissiez voir si la personne exécutant le programme est root. Différentes fonctionnalités sont autorisées si quelqu’un est root (ou quelqu’un utilisant sudo).
Ce est le code qui détecte si quelqu’un est root.
Voici un exemple dans lequel cela est pris en compte. Étant donné que root peut changer n’importe quel mot de passe, le programme n’a pas à se soucier des vérifications qu’il effectue habituellement pour voir quels mots de passe la personne a l’autorisation de changer. Donc, pour la racine, il ignore ces vérifications et quitte la fonction de vérification.
Avec les commandes et utilitaires Linux de base, vous pouvez être sûr qu’ils ont intégré la sécurité et que le code a été revu plusieurs 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 les vulnérabilités nouvellement identifiées.
Il s’agit d’un logiciel tiers, en particulier de tout logiciel non open source, avec lequel vous devez être extrêmement prudent lorsque vous utilisez 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 et la personne qui l’exécute.
Commandes Linux utilisant 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 défini.
Les autorisations sur un fichier ou un répertoire sont généralement représentées par trois groupes de trois caractères: rwx. Ceux-ci représentent la lecture, l’écriture et l’exécution. Si les lettres sont présentes, cette autorisation a été accordée. Si un trait d’union (-) au lieu d’une lettre est présent, cependant, cette autorisation n’a pas été donnée.
Il existe trois groupes de ces autorisations (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 l’autorisation d’exécution du propriétaire.
Si le bit SUID est défini sur un fichier qui n’a pas de capacités exécutables, un «S» majuscule indique cela.
Nous allons jeter un œil à un exemple. L’utilisateur normal dave tape la commande passwd:
passwd
La commande passwd demande à Dave de saisir son nouveau mot de passe. Nous pouvons utiliser la commande ps pour voir les détails des processus en cours.
Nous utiliserons ps avec grep dans une autre fenêtre de terminal et recherchez 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 signalées, la seconde étant le processus grep recherchant les commandes contenant la chaîne «passwd». C’est la première ligne qui nous intéresse, car c’est celle du processus passwd lancé par Dave.
Nous pouvons voir que le processus passwd s’exécute de la même manière que si root l’avait lancé.
Définition du 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 américain 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 le bit SUID n’est pas défini. Lorsqu’il est exécuté, il affiche les ID utilisateur réels et effectifs (UID).
Le vrai UID 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 identifiants réels et effectifs sont tous les deux définis sur dave. Donc, il se comporte exactement comme un programme normal le devrait.
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 définir le bit SUID, puis vérifions qu’il a été défini:
sudo cp htg /usr/local/bin
sudo chmod u+s /usr/local/bin/htg
ls -hl /usr/local/bin/htg
Ainsi, le programme est copié et le bit SUID est défini. Nous l’exécuterons à nouveau, mais cette fois, nous exécuterons 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 autorisations de l’utilisateur root.
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 montre également le groupe efficace. Nous allons changer le groupe du programme htg pour être le groupe par défaut de l’utilisateur mary, mary. Nous utiliserons également les modes symboliques us et g + s avec chown pour supprimer le bit SUID et définir 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 autorisations de groupe. Notez également que le groupe est défini sur mary et que le nom du fichier est maintenant surligné en jaune.
Avant de lancer le programme, établissons à quels groupes appartiennent Dave et Mary. Nous utiliserons la commande id avec l’option -G (groups), pour imprimer tous les ID de groupe. Ensuite, nous exécuterons 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 pour mary est 1001, et le groupe effectif du programme htg est 1001. Ainsi, bien qu’il ait été lancé par Dave, il fonctionne avec les autorisations 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, pas 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. Celles-ci affecteront tous les éléments créés dans le répertoire de travail.
Nous tapons ce qui suit pour entrer dans le répertoire de travail, créer un répertoire appelé «démo» 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 le toucher commande et vérifiez 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 mors 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 parties de texte de l’exécutable devaient être conservées dans le swap, ce qui accélérait leur réutilisation. 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 utilisateurs ne peuvent supprimer que les fichiers qui leur appartiennent dans ce répertoire. Ils ne peuvent pas supprimer les fichiers appartenant à quelqu’un d’autre, quelle que soit la combinaison d’autorisations de fichier définie sur les 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, 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 sticky sur ce répertoire. Nous examinerons ensuite les autorisations sur ce répertoire, ainsi que 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 sticky est défini, le bit exécutable de «l’autre» ensemble d’autorisations de fichier est défini sur «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 fichier définies pour le propriétaire, le groupe et 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, en théorie, être capable de faire n’importe quoi. Cependant, le bit sticky les remplace et personne ne peut supprimer un fichier qui ne lui appartient pas.
Rappels
Ce qui suit est une liste de contrôle rapide de ce que nous avons couvert ci-dessus pour 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 sticky bit qu’aux répertoires.
Si les indicateurs «s», «g» ou «t» apparaissent en majuscules, le bit exécutable (x) n’a pas été défini.