setuid - setuid

« SGID » redirige ici. Pour la société qui a brièvement utilisé ce symbole boursier, voir Silicon Graphics .

Les drapeaux de droits d'accès Unix setuid et setgid (abréviation de "set user ID" et "set group ID") permettent aux utilisateurs d'exécuter un exécutable avec les permissions du système de fichiers du propriétaire ou du groupe de l'exécutable respectivement et de modifier le comportement dans les répertoires. Ils sont souvent utilisés pour permettre aux utilisateurs d'un système informatique d'exécuter des programmes avec des privilèges temporairement élevés afin d'effectuer une tâche spécifique. Bien que les privilèges d'ID utilisateur ou d'ID de groupe fournis ne soient pas toujours élevés, ils sont au minimum spécifiques.

Les indicateurs setuidet setgidsont nécessaires pour les tâches qui nécessitent des privilèges différents de ceux qui sont normalement accordés à l'utilisateur, comme la possibilité de modifier les fichiers système ou les bases de données pour changer leur mot de passe de connexion. Certaines des tâches qui nécessitent des privilèges supplémentaires peuvent ne pas être immédiatement évidentes, comme la pingcommande, qui doit envoyer et écouter les paquets de contrôle sur une interface réseau.

Effets

Les drapeaux setuidet setgidont des effets différents, selon qu'ils sont appliqués à un fichier, à un répertoire ou à un fichier exécutable binaire ou non. Les drapeaux setuidet setgidn'ont d'effet que sur les fichiers exécutables binaires et non sur les scripts (par exemple, Bash, Perl, Python).

Lorsqu'il est défini sur un fichier exécutable

Lorsque les attributs setuidou setgidsont définis sur un fichier exécutable , tout utilisateur capable d'exécuter le fichier exécutera automatiquement le fichier avec les privilèges du propriétaire du fichier (généralement root ) et/ou du groupe du fichier, en fonction des indicateurs définis. Cela permet au concepteur du système d'autoriser l'exécution de programmes de confiance qu'un utilisateur ne serait autrement pas autorisé à exécuter. Ceux-ci peuvent ne pas toujours être évidents. Par exemple, la commande ping peut avoir besoin d'accéder à des privilèges réseau auxquels un utilisateur normal ne peut pas accéder ; par conséquent, il peut recevoir le drapeau setuid pour s'assurer qu'un utilisateur qui a besoin d'envoyer un ping à un autre système peut le faire, même si son propre compte n'a pas le privilège requis pour envoyer des paquets.

Pour des raisons de sécurité, le système interdit généralement à l'utilisateur invocateur de modifier le nouveau processus de quelque manière que ce soit, par exemple en utilisant ptrace, LD_LIBRARY_PATHou en lui envoyant des signaux, pour exploiter le privilège élevé, bien que les signaux du terminal soient toujours acceptés.

Les bits setuidet setgidsont normalement définis avec la commande chmoden définissant le chiffre octal de poids fort sur 4 pour setuidou 2 pour setgid. " " définira à la fois les bits et (4+2=6), rendant le fichier en lecture/écriture/exécutable pour le propriétaire (7), et exécutable par le groupe (premier 1) et les autres (second 1). Lorsqu'un utilisateur autre que le propriétaire exécute le fichier, le processus s'exécute avec les autorisations d'utilisateur et de groupe définies par son propriétaire. Par exemple, si le fichier appartient à l'utilisateur et au groupe , il s'exécutera comme peu importe qui exécute le fichier. chmod 6711 filesetuidsetgidrootwheelroot:wheel

La plupart des implémentations de la chmodcommande prennent également en charge des arguments symboliques plus fins pour définir ces bits. Le mode de préférence à granularité plus fine est indiqué dans la démonstration ci-dessous sous la forme " chmod ug+s"

Impact sur la sécurité

Bien que la setuidfonctionnalité soit très utile dans de nombreux cas, son utilisation inappropriée peut poser un risque de sécurité si l' setuidattribut est affecté à des programmes exécutables qui ne sont pas soigneusement conçus. En raison de problèmes de sécurité potentiels, de nombreux systèmes d'exploitation ignorent l' setuidattribut lorsqu'il est appliqué à des scripts shell exécutables .

La présence d' setuidexécutables explique pourquoi l' chrootappel système n'est pas accessible aux utilisateurs non root sous Unix. Voir les limitations dechroot pour plus de détails.

Lorsqu'il est défini sur un répertoire

La définition de l' setgidautorisation sur un répertoire (" chmod g+s") fait que les nouveaux fichiers et sous-répertoires créés dans celui-ci héritent de son ID de groupe , plutôt que de l'ID de groupe principal de l'utilisateur qui a créé le fichier (l'ID du propriétaire n'est jamais affecté, seul l'ID du groupe) .

  1. Les sous-répertoires nouvellement créés héritent du setgidbit. Ainsi, cela permet un espace de travail partagé pour un groupe sans l'inconvénient de demander aux membres du groupe de modifier explicitement leur groupe actuel avant de créer de nouveaux fichiers ou répertoires.
  2. affecte uniquement l'ID de groupe des nouveaux fichiers et sous-répertoires créés après la setgiddéfinition du bit, et n'est pas appliqué aux entités existantes.
  3. n'affecte pas l'ID de groupe des fichiers créés ailleurs et déplacés vers le répertoire en question. Le fichier continuera à porter l'ID de groupe qui a été effectué quand et où il a été créé.

La définition du setgidbit sur les sous-répertoires existants doit être effectuée manuellement, avec une commande telle quefind /path/to/directory -type d -exec chmod g+s '{}' \;

L' setuidautorisation définie sur un répertoire est ignorée sur la plupart des systèmes UNIX et Linux . Cependant, FreeBSD peut être configuré pour interpréter setuidd'une manière similaire à setgid, auquel cas il force tous les fichiers et sous-répertoires créés dans un répertoire à appartenir au propriétaire de ce répertoire - une simple forme d'héritage. Ce n'est généralement pas nécessaire sur la plupart des systèmes dérivés de BSD , car par défaut les répertoires sont traités comme si leur setgidbit était toujours défini, quelle que soit la valeur réelle. Comme indiqué dans open(2), "Quand un nouveau fichier est créé, il reçoit le groupe du répertoire qui le contient."

Exemples

Vérification des autorisations

Les autorisations d'un fichier peuvent être vérifiées sous forme octale et/ou sous forme alphabétique avec l'outil de ligne de commande stat 

[ torvalds ~ ] $ stat -c "%a %A" ~/test/
1770 drwxrwx--T

SUID

4701 sur un fichier exécutable appartenant à 'root' et au groupe 'root'

Un utilisateur nommé 'thompson' tente d'exécuter le fichier. L'autorisation exécutable pour tous les utilisateurs est définie (le « 1 ») afin que « thompson » puisse exécuter le fichier. Le propriétaire du fichier est « root » et l'autorisation SUID est définie (le « 4 ») - le fichier est donc exécuté en tant que « root ».

La raison pour laquelle un exécutable serait exécuté en tant que « root » est qu'il peut modifier des fichiers spécifiques auxquels l'utilisateur ne serait normalement pas autorisé, sans lui donner un accès root complet.

Une utilisation par défaut de ceci peut être vue avec le /usr/bin/passwdfichier binaire. /usr/bin/passwddoit être modifié /etc/passwdet /etc/shadowqui stocke les informations de compte et les hachages de mot de passe pour tous les utilisateurs, et ceux-ci ne peuvent être modifiés que par l'utilisateur « root ».

[ thompson ~ ] $ stat -c "%a %U:%G %n" /usr/bin/passwd
4701 root:root /usr/bin/passwd

[ thompson ~ ] $ passwd
passwd: Changing password for thompson

Le propriétaire du processus n'est pas l'utilisateur exécutant le fichier exécutable mais le propriétaire du fichier exécutable

SGID

2770 sur un répertoire nommé 'music' appartenant à l'utilisateur 'root' et au groupe 'engineers'

Un utilisateur nommé 'torvalds' qui appartient principalement au groupe 'torvalds' mais secondairement au groupe 'ingénieurs' crée un répertoire nommé 'électronique' sous le répertoire nommé 'musique'. La propriété du groupe du nouveau répertoire nommé « électronique » hérite des « ingénieurs ». C'est la même chose lors de la création d'un nouveau fichier nommé 'imagine.txt'

Sans SGID, la propriété du groupe du nouveau répertoire/fichier aurait été 'torvalds' car il s'agit du groupe principal d'utilisateurs 'torvalds'. 

[ torvalds ~ ] $ groups torvalds
torvalds : torvalds engineers

[ torvalds ~ ] $ stat -c "%a %U:%G %n" ./music/
2770 root:engineers ./music/

[ torvalds ~ ] $ mkdir ~/music/electronic

[ torvalds ~ ] $ stat -c "%U:%G %n" ./music/electronic/
torvalds:engineers ./music/electronic/

[ torvalds ~ ] $ echo 'NEW FILE' > ./music/imagine.txt

[ torvalds ~ ] $ stat -c "%U:%G %n" ./music/imagine.txt
torvalds:engineers ./music/imagine.txt

[ torvalds ~ ] $ touch ~/test

[ torvalds ~ ] $ stat -c "%U:%G %n" ~/test
torvalds:torvalds ~/test

Peu collant

Voir aussi : Bit collant

1770 sur un répertoire nommé 'videogames' appartenant à l'utilisateur 'torvalds' et au groupe 'engineers'.

Un utilisateur nommé 'torvalds' crée un fichier nommé 'tekken' dans le répertoire nommé 'videogames'. Un utilisateur nommé 'wozniak', qui fait également partie du groupe 'ingénieurs', tente de supprimer le fichier nommé 'tekken' mais il ne peut pas, puisqu'il n'en est pas le propriétaire.

Sans sticky bit, 'wozniak' aurait pu supprimer le fichier, car le répertoire nommé 'videogames' permet la lecture et l'écriture par les 'ingénieurs'. Une utilisation par défaut de ceci peut être vue dans le /tmpdossier. 

[ torvalds /home/shared/ ] $ groups torvalds
torvalds : torvalds engineers

[ torvalds /home/shared/ ] $ stat -c "%a  %U:%G  %n" ./videogames/
1770  torvalds:engineers  ./videogames/

[ torvalds /home/shared/ ] $ echo 'NEW FILE' > videogames/tekken

[ torvalds /home/shared/ ] $ su - wozniak
Password:

[ wozniak ~/ ] $ groups wozniak
wozniak : wozniak engineers

[ wozniak ~/ ] $ cd /home/shared/videogames

[ wozniak /home/shared/videogames/ ] $ rm tekken
rm: cannot remove ‘tekken’: Operation not permitted

Bit collant avec SGID

3171 sur un répertoire nommé 'blog' appartenant au groupe 'ingénieurs' et à l'utilisateur 'root'

Un utilisateur nommé « torvalds » qui appartient principalement au groupe « torvalds » mais secondairement au groupe « ingénieurs » crée un fichier ou un répertoire nommé « pensées » dans le répertoire « blog ». Un utilisateur nommé « wozniak » qui appartient également au groupe « ingénieurs » ne peut pas supprimer, renommer ou déplacer le fichier ou le répertoire nommé « pensées », car il n'en est pas le propriétaire et le bit collant est défini. Cependant, si 'thoughts' est un fichier, alors 'wozniak' peut le modifier.

Sticky bit a la décision finale. Si sticky bit et SGID n'avaient pas été définis, l'utilisateur 'wozniak' pourrait renommer, déplacer ou supprimer le fichier nommé 'thoughts' car le répertoire nommé 'blog' permet la lecture et l'écriture par groupe, et wozniak appartient au groupe, et la valeur par défaut 0002 umask permet de modifier les nouveaux fichiers par groupe. Sticky bit et SGID peuvent être combinés avec quelque chose comme un umask en lecture seule ou un attribut d'ajout uniquement.

[ torvalds /home/shared/ ] $ groups torvalds
torvalds : torvalds engineers

[ torvalds /home/shared/ ] $ stat -c "%a  %U:%G  %n" ./blog/
3171  root:engineers  ./blog/

[ torvalds /home/shared/ ] $ echo 'NEW FILE' > ./blog/thoughts

[ torvalds /home/shared/ ] $ su - wozniak
Password:

[ wozniak ~/ ] $ cd /home/shared/blog

[ wozniak /home/shared/blog/ ] $ groups wozniak
wozniak : wozniak engineers

[ wozniak /home/shared/blog/ ] $ stat -c "%a  %U:%G  %n" ./thoughts
664  torvalds:engineers  ./thoughts

[ wozniak /home/shared/blog/ ] $ rm thoughts
rm: cannot remove ‘thoughts’: Operation not permitted

[ wozniak /home/shared/blog/ ] $ mv thoughts /home/wozniak/
mv: cannot move ‘thoughts’ to ‘/home/wozniak/thoughts’: Operation not permitted

[ wozniak /home/shared/blog/ ] $ mv thoughts pondering
mv: cannot move ‘thoughts’ to ‘pondering’: Operation not permitted

[ wozniak /home/shared/blog/ ] $ echo 'REWRITE!' > thoughts

[ wozniak /home/shared/blog/ ] $ cat thoughts
REWRITE!

Sécurité

Les développeurs conçoivent et implémentent des programmes qui utilisent ce bit sur les exécutables avec soin afin d'éviter les failles de sécurité, notamment les dépassements de mémoire tampon et l' injection de chemin . Les attaques par dépassement de mémoire tampon réussies sur les applications vulnérables permettent à l'attaquant d'exécuter du code arbitraire sous les droits du processus exploité. Dans le cas où un processus vulnérable utilise le setuidbit pour s'exécuter en tant que root, le code s'exécutera avec les privilèges root, donnant en fait à l'attaquant un accès root au système sur lequel le processus vulnérable s'exécute.

L' environnement du setuidprocessus est particulièrement important dans le cas d'un processus. Si l'environnement n'est pas correctement nettoyé par un processus privilégié, son comportement peut être modifié par le processus non privilégié qui l'a démarré. Par exemple, GNU libc était à un moment donné vulnérable à un exploit utilisant et une variable d'environnement qui permettait d'exécuter du code à partir de bibliothèques partagées non fiables . setuid

Histoire

Le setuidmors a été inventé par Dennis Ritchie et inclus dans su. Son employeur, alors Bell Telephone Laboratories , a déposé un brevet en 1972 ; le brevet a été accordé en 1979 sous le numéro de brevet US 4135240  "Protection du contenu des fichiers de données". Le brevet a ensuite été placé dans le domaine public .

Voir également

Les références

Liens externes