Setuid dans le sous-système pour les applications UNIX

setuid et setgid

Sous-système pour les applications UNIX et identités

Considérations d’installation relatives à Setuid dans le sous-système pour les applications UNIX

Les mécanismes setuid et setgid permettent à un programme d’adopter à l’exécution certaines spécificités d’une entité de sécurité autres que celles de l’utilisateur qui exécute le programme. Ils autorisent le programme à passer des spécificités de l’utilisateur auteur de l’appel à celles d’une autre entité de sécurité.

Les privilèges appropriés sont différents. Alors que les mécanismes setuid et setgid permettent à une application de contrôler la réponse à la question : « Qui êtes-vous ? », les privilèges appropriés répondent à la question : « Que pouvez-vous faire ? ».

Dans les environnements UNIX standard, tous les privilèges sont octroyés à un seul utilisateur. Celui-ci, appelé en règle générale root, est identifié comme suit : uid == 0. Dans le sous-système pour les applications UNIX, tous les privilèges pris en charge sur un système donné sont octroyés aux utilisateurs qui appartiennent au groupe Administrateurs ou au groupe Administrateurs de domaine de ce système. Il n’est pas nécessaire d’ouvrir une session en tant qu’administrateur. Tout utilisateur membre du groupe Administrateurs ou Administrateurs de domaine dispose des privilèges root. Certains privilèges définis dans POSIX ou UNIX ne sont pas disponibles dans SUA. En d’autres termes, certains privilèges ne sont octroyés à aucun utilisateur.

Diverses actions nécessitent en règle générale les privilèges appropriés. Parmi ces actions figurent l’accès au système de fichiers, l’envoi de signaux à d’autres processus (contrôle de processus) ou un changement d’identificateur d’utilisateur (UID) ou de groupe (GID) effectif en vue de modifier la capacité de ce processus à exécuter certaines actions.

Conformément à la norme POSIX, les autorisations associées à un fichier incluent les bits de définition d’un UID (setuid) et d’un GID (setgid). Si l’un ou les deux bits sont définis dans un fichier et qu’un processus exécute ce dernier, le processus extrait l’UID ou le GID du fichier. S’il est utilisé judicieusement, ce mécanisme permet à un utilisateur sans privilège d’exécuter des programmes dont l’exécution requiert les privilèges de niveau supérieur du propriétaire ou du groupe du fichier. Cependant, si son utilisation est incorrecte, ce mécanisme présente des risques de sécurité, car il autorise des utilisateurs sans privilège à exécuter des actions réservées à un administrateur. De ce fait, SUA ne prend pas ce mécanisme en charge par défaut. Si vous tentez d’exécuter un fichier dont le bit setuid ou setgid est défini, SUA ne l’exécute pas et renvoie le code d’erreur ENOSETUID.

Si vous utilisez une application qui requiert un comportement POSIX standard, vous pouvez configurer SUA de sorte à exécuter les fichiers dont le bit setuid ou setgid est défini. Dans ce cas de figure, lorsqu’un processus exécute un fichier dont le bit setuid ou setgid est défini, SUA génère des jetons de sécurité locaux pour le processus, les privilèges étant octroyés au propriétaire ou au groupe du fichier. Puisque les jetons sont locaux, ils ne sont pas reconnus par les autres ordinateurs connectés au réseau. De ce fait, même si le propriétaire du fichier appartient au groupe Administrateurs de domaine, par exemple, le processus ne dispose pas d’un accès approuvé via un réseau Microsoft® Windows® à d’autres ordinateurs du domaine. Les privilèges ne sont alors effectifs que sur l’ordinateur sur lequel s’exécute le processus.

Supposons qu’un processus exécute un fichier de programme dont le bit setuid est défini et qui appartient à un membre du groupe Administrateurs de domaine. Si ce programme tente de modifier le mot de passe d’un utilisateur du domaine, l’opération échoue, car les jetons de sécurité du processus sont locaux et ne sont pas reconnus par les autres systèmes du domaine. En revanche, si le programme tente de modifier le mot de passe d’un utilisateur local, l’opération aboutit, car le propriétaire du fichier est membre du groupe Administrateurs de domaine, qui appartient en règle générale au groupe Administrateurs de l’ordinateur local. Pour plus d’informations sur la configuration de SUA de sorte à exécuter des fichiers dont le bit setuid ou setgid est défini, voir les fichiers d’aide livrés avec le package de téléchargement Utilitaires et Kit de développement logiciel (SDK) du sous-système pour les applications UNIX.

Pour les fonctions setuid(2), setgid(2) et chroot(2), un processus doit disposer de l’UID effective qui renvoie au compte système, au compte administrateur du domaine local ou au compte administrateur du domaine principal. Le compte administrateur local ne peut remplacer l’UID ou le GID que par un autre ID du même domaine.

Pour chown(1), chmod(1) et chgrp(1), un compte doit disposer des privilèges Windows SE_BACKUP et SE_RESTORE pour effectuer des opérations make sur des fichiers appartenant à un autre utilisateur ou groupe, ou pour modifier les autorisations associées à un fichier appartenant à un autre utilisateur. Ces autorisations sont en règle générale octroyées aux comptes administrateur et opérateurs de sauvegarde.