Comment fonctionne sudo travailler en interne ? Comment est-il possible qu'il puisse devenir root sans avoir le mot de passe root, contrairement à su ? Quels appels système, etc. sont impliqués dans le processus ? N'est-ce pas une faille de sécurité béante dans Linux (par exemple, pourquoi ne puis-je pas compiler un sudo fortement patché qui vient de faire n'importe quoi de normal sudo l'a fait, mais n'a pas demandé le mot de passe de l'utilisateur non privilégié) ?
J'ai lu login et su internals. J'ai également lu Comment sudo est-il destiné à être utilisé ? mais malgré le titre, ils traitent principalement des différences entre su et sudo .
Réponse acceptée :
Si vous regardez l'exécutable sudo :
$ which sudo
/usr/bin/sudo
$ ls -la /usr/bin/sudo
---s--x--x 2 root root 208808 Jun 3 2011 /usr/bin/sudo
Vous remarquerez qu'il contient les bits d'autorisation ---s--x--x . Ceux-ci peuvent être répartis comme suit :
-|--s|--x|--x
- - first dash denotes if a directory or a file ("d" = dir, "-" = file)
--s - only the setuid bit is enabled for user who owns file
--x - only the group execute bit is enabled
--x - only the other execute bit is enabled
Ainsi, lorsqu'un programme a son bit setuid activé (également appelé SUID), cela signifie que lorsque quelqu'un exécute ce programme, il s'exécutera avec les informations d'identification de l'utilisateur propriétaire du fichier, c'est-à-dire. racine dans ce cas.
Exemple
Si j'exécute la commande suivante en tant qu'utilisateur saml :
$ whoami
saml
$ sudo su -
[sudo] password for saml:
Vous remarquerez que l'exécution de sudo s'exécute en fait en tant que root :
$ ps -eaf|grep sudo
root 20399 2353 0 05:07 pts/13 00:00:00 sudo su -
mécanisme setuid
Si vous êtes curieux de savoir comment SUID fonctionne, jetez un œil à man setuid . Voici un extrait de la page de manuel qui l'explique mieux que moi :
setuid() définit l'ID utilisateur effectif du processus appelant. Si l'UID
effectif de l'appelant est root, l'UID réel et l'ID d'utilisateur
enregistré sont également définis. Sous Linux, setuid() est implémenté comme
la version POSIX avec la fonctionnalité _POSIX_SAVED_IDS. Cela permet à un programme
set-user-ID (autre que root) de supprimer tous ses privilèges d'utilisateur
, d'effectuer des tâches non privilégiées, puis de réengager l'ID utilisateur effectif d'origine dans de manière sécurisée.Si l'utilisateur est root ou si le programme est set-user-ID-root, des précautions particulières
doivent être prises. La fonction setuid() vérifie l'ID utilisateur effectif de
l'appelant et s'il s'agit du superutilisateur, tous les ID utilisateur liés au processus
sont définis sur uid. Après cela, il est impossible pour le
programme de retrouver les privilèges root.
Le concept clé ici est que les programmes ont un identifiant utilisateur réel (UID) et un identifiant effectif (EUID). Setuid définit l'ID utilisateur effectif (EUID) lorsque ce bit est activé.
Connexe :Ssh – Comment tcp-keepalive fonctionne-t-il dans ssh ?
Donc, du point de vue du noyau, on sait que dans notre exemple, saml est toujours le propriétaire d'origine (UID), mais l'EUID a été défini avec le propriétaire de l'exécutable.
setgid
Je dois également mentionner que lorsque nous décomposons les autorisations sur la commande sudo, le deuxième groupe de bits concernait les autorisations de groupe. Les bits de groupe ont également quelque chose de similaire à setuid appelé set group id (aka. setgid, SGID). Cela fait la même chose que SUID sauf qu'il exécute le processus avec les informations d'identification du groupe au lieu des informations d'identification du propriétaire.
Références
- page wikipedia setuid
- page de manuel setuid