Comment utiliser SUID, SGID et Sticky Bits sur Linux

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.

Ils sont déjà utilisés

L'intégration de la sécurité dans un système d'exploitation multi-utilisateurs pose plusieurs problèmes. Prenez 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. De toute évidence, comme les mots de passe sont les clés du royaume, ils doivent être protégé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 root les privilèges peuvent accéder au fichier contenant les mots de passe. Cela peut sembler correct, mais cela pose un dilemme: si seulement les personnes root les privilèges 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

Habituellement, les commandes et programmes Linux s'exécutent avec le même ensemble d'autorisations que la personne qui lance le programme. Quand root dirige le passwd pour changer un mot de passe, il s'exécute avec rootLes autorisations de. Cela signifie que le passwd La commande peut accéder librement aux mots de passe stockés dans le /etc/shadow fichier.

L'idéal serait un schéma dans lequel n'importe qui sur le système pourrait lancer le passwd programme, mais ont la passwd programme conserver rootPrivilèges élevés de. Cela permettrait à quiconque de changer son propre mot de passe.

Le scénario ci-dessus est précisément ce que le bit Set User ID (SUID) Est-ce que. 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 améliorez 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 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 une personne de travailler avec le mot de passe d'une autre personne est contenu dans le passwd programme, pas le système d'exploitation et le programme 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 envisagez, puis vous vous en inspirez. 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 que vous pouvez consulter le code source vous-même ou vous référer à des évaluations par des pairs de confiance. Dans le code source du passwd programme, il y a des contrôles, vous pouvez donc 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).

Ceci est le code qui détecte si quelqu'un est root.

Voici un exemple dans lequel cela est pris en compte. Car root peut modifier n'importe quel mot de passe, le programme n'a pas à se soucier des vérifications qu'il effectue généralement pour voir quels mots de passe la personne a l'autorisation de modifier. Donc pour root, il ignore ces vérifications et quitte la fonction de vérification.

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

Il s'agit de logiciels tiers, en particulier ceux qui ne sont pas open source, vous devez être extrêmement prudent lors de l'utilisation SUID avec. Nous ne disons pas que vous ne le faites pas, mais si vous le faites, vous voulez vous assurer qu'il 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 qui utilisent SUID

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

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 signifient lire, écrire et exécuter. Si les lettres sont présentes, cette autorisation a été accordée. Si un tiret (-) au lieu d'une lettre est présente, cependant, cette autorisation n'a pas été accordée.

Il existe trois groupes de ces autorisations (de gauche à droite): ceux pour le propriétaire du fichier, pour les membres du groupe du fichier et pour les autres. Quand le SUID bit est défini sur un fichier, un «s» représente l'autorisation d'exécution du propriétaire.

Si la SUID bit est défini sur un fichier qui n'a pas de capacités exécutables, un "S" en majuscule indique cela.

Nous allons voir un exemple. Utilisateur régulier dave tape le passwd commander:

passwd

le passwd invites de commande dave pour son nouveau mot de passe. Nous pouvons utiliser le 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 recherchez le passwd processus. Nous utiliserons également le -e (chaque processus) et -f (format complet) options avec ps.

Nous tapons la commande suivante:

ps -e -f | grep passwd

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

On voit le passwd processus fonctionne de la même manière que si root l'avait lancé.

Définition du bit SUID

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

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

Le véritable 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é par.

Nous tapons ce qui suit:

ls -lh htg

./htg

Lorsque nous exécutons la copie locale du programme, nous voyons que les ID réels et effectifs sont tous deux définis sur dave. Donc, il se comporte comme un programme normal.

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

Nous tapons ce qui suit, en utilisant chmod pour définir SUID bit, puis vérifiez 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 /usr/local/bin dossier:

htg

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

htg

Le vrai ID est maryet l'ID effectif est root. Le programme s'exécute avec les autorisations de l'utilisateur root.

Le bit SGID

L'ID de groupe défini (SGID) est très similaire au SUID bit. Quand le SGID bit 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 peaufiné notre htg programme de sorte qu'il montre aussi le groupe efficace. Nous allons changer le groupe des htg programme à utiliser maryLe groupe par défaut, mary. Nous utiliserons également le u-s et g+s modes symboliques avec chown pour supprimer le SUID mordre et régler la 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

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

Avant d'exécuter le programme, déterminons quels groupes dave et mary appartenir à. Nous utiliserons le id commande avec le -G (groupes), pour imprimer tous les ID de groupe. Ensuite, nous exécuterons le htg programme comme 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 des htg programme est 1001. Ainsi, bien qu'il ait été lancé par dave, il fonctionne avec les autorisations des membres du mary groupe. C’est la même chose que si dave avait rejoint le mary groupe.

Appliquons le SGID bit dans 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 la SGID peu sur le répertoire.

Quand nous utilisons ls pour vérifier les paramètres du répertoire, nous utiliserons également le -d (répertoire) afin que nous voyions 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 SGID bit et groupe «geek» sont définis. Ceux-ci affecteront tous les éléments créés dans le work annuaire.

Nous tapons ce qui suit pour entrer le work répertoire, créez un répertoire appelé "démo" et vérifiez ses propriétés:

cd work

mkdir demo

ls -lh -d demo

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

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

touch useful.sh

ls -lh useful.sh

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

The Sticky Bit

Le bit collant tire son nom de son objectif historique. Lorsqu'il est défini sur un exécutable, il signale au système d'exploitation que les parties de texte de l'exécutable doivent être conservées en swap, ce qui accélère leur réutilisation. Sous Linux, le bit collant n'affecte qu'un répertoire – le placer sur un fichier n'aurait aucun sens.

Lorsque vous définissez le bit collant 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 des autorisations de fichier définies 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é. 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 o+t mode symbolique avec chmod pour définir le bit collant sur ce répertoire. Nous allons ensuite examiner les autorisations sur ce répertoire, ainsi que les /tmp et /var/tmp répertoires.

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 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.

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

Avec ces autorisations, n'importe qui devrait, théoriquement, être en mesure de faire n'importe quoi. Cependant, le bit collant 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 postuler SGID aux répertoires et fichiers.
• Vous ne pouvez appliquer le bit collant qu'aux répertoires.
• Si la "s","g", ou "t"Les indicateurs apparaissent en majuscules, le bit exécutable (x) n'a pas été défini.