Bonjour,

Est-ce qu'il y a une limitation secrète du bit setuid qui n'est pas dans le man (sous debian/linux) ?

Explication, j'ai un script que je voulais rendre setuid root, ses droits étaient donc :
-rwxrwx--- 1 root root programme

Mais impossible de réussir à faire fonctionner ça. Un petit "echo `who am i`" au début rendait "dnob700" et pas root, mais comme "sudo echo `who am i`" fait pareil ce n'est peut-être pas éliminatoire (je n'ai jamais bien compris la théorie des utilisateurs réel et effectif tel qu'elle est utilisée par le shell et par sudo). Toujours est-il que j'avais un accès interdit sur le fichier (700 root:root) que le programme doit modifier.

Bon, j'ai contourné le problème avec quelque chose de moins brutal (et peut-être mieux) qu'un setuid en créant un groupe pour ce genre de chose. Mais, si quelqu'un sait pourquoi ça ne fonctionnais pas, merci d'avance pour m'éclairer.

Peut-être que ce script te mettra sur la voie :

1. !/bin/sh

whoami
echo $UID
echo $EUID

Tout ce que je te dirais, c'est que mettre un +s sur un script ça se solde presque sûrement par un échec car on est vite trahit par le "Effective User IDentidier".
La seule manière de venir à bout de ce truc, c'est de coder dans un langage de programmation qui permet de changer la valeur du euid (au hasard, le C).

Tiens, j'ai parlé un peu vite.

Apparemment, après un "su - lfs" (bon, j'ai que ça comme utilisateur de test, désolé ), c'est comme si le bit setuid n'existait pas.

C'est donc encore plus casse-gueule que ce que j'imaginais.

"La seule manière de venir à bout de ce truc, c'est de coder dans un langage de programmation qui permet de changer la valeur du euid (au hasard, le C). "

Oui, mais c'est bizarre qu'il faille que le programme agisse pour rendre le setuid utile. On s'attendrait à ce qu'un programme ne sache pas ce qui lui arrive. Cela dit, j'ai l'impression que ça vient de la gestion des scripts :

$ ./a.out
uid : 1000
euid : 0

$ ./a.ml
uid : 1000
euid : 1000

ou a.out est juste une version compilé de a.ml (et a.ml commence par #!...ocaml), ils sont tout les deux root:root (-rwsr-xr-x).

J'ai l'impression que le mécanisme d'exécution des scripts ne prends pas en compte le setuid. Est-ce que c'est le shell ou le système qui exécute les scripts ?

... après un petit coup de strace, et vu que execve est capable de lancer des scripts je pense que c'est bien le système qui gère ça. Du coup, je suis plus surpris. Parce que si c'était le shell je comprendrais le problème, mais vu que c'est le système je ne vois pas d'où est-ce que ça peut venir.

Surtout que si l'interpréteur de commande (celui qui vient après #!) est setuid alors l'euid est bien modifié, mais s'il ne l'est pas et il tourne lui même avec un euid égale à l'uid si le fichier de script est setuid (là il faut suivre, j'ai un script c qui commence par #!/home/dnob700/a.out avec mon a.out de tout à l'heure, mais qui n'est plus setuid, seulement le fichier c).

Bref, ça m'a l'air d'être un comportement ad-hoc qui fait que le système n'honore par le bit setuid pour les scripts. C'est pas sympa de sa part (et je ne vois pas l'utilité, ce n'est pas plus dangereux que si le programme est compilé).

« Oui, mais c'est bizarre qu'il faille que le programme agisse pour rendre le setuid utile. »
vu différemment, ça serait suicidaire qu'un pauvre script setuid root puisse lancer tout ce qu'il veut en root. Les codeurs du dimanche qui font n'importe quoi, ça court un peu trop les wikis de nos jours malheureusement.
Et puis c'est pas comme si les binaires avec un bit setuid n'étaient pas aussi des démons à éviter (petites pensées pour l'horrible cups et le bestial Xorg).

« Est-ce que c'est le shell ou le système qui exécute les scripts ? » les deux mon colonel. Le shell émet un execXX, et le système y répond. (ha bah oui, tu as pu constaté ça en straçant.)
En vrai, il faudrait creuser un peu plus ce que fait execve dans le cas d'un script. Si ça se trouve, il y a un juste un second appel à execve avec le contenu du shebang, avec perte du setuid au passage.

« ce n'est pas plus dangereux que si le programme est compilé » moi j'ai le sentiment que si. Un programme compilé, c'est relativement statique (modulo l'oubli de -static pour le compilo et les failles de type buffer overflow). Par contre, un script c'est nettement plus interactif, et donc j'ai le sentiment que c'est bien plus simple de profiter de la "promotion" offerte par le bit setuid pour compromettre le système.

De memoire, suid sur un script ca ne marche pas. Je ne sais plus les details, mais je me rappelle bien que ca ne marche pas.

/me confirme

Une des raisons que je vois est la facilité d'injection de commandes shell dans les arguments, profiter du root avec ça serait suicidaire.

Je viens de penser à un truc comme ça :

$ cp /bin/rm ls
$ PATH=`pwd`:$PATH /path/script_avec_bit_setuid.sh

Bien sûr, si le script utilise des chemins absolus partout, pas de problème. Mais c'est bien rare ce genre de scripts.

Exact, à noter que le problème reste le même avec system() & co

Sauf que les programmes setuid root, en général, ils sont audités par les gens de chez openBSD qui ne laissent pas passer ce genre de merdes.

Oui, mais tout ça c'est un peu le système qui essaye de me protéger contre mon grès. Et si j'avais besoin d'être protégé, j'utiliserais MacOS.

Ce que j'entendais pas le système ou le shell qui lance un script c'était de savoir si le shell fait un execve(nom du script) et qu'ensuite le système lance le bon interpréteur (et c'est ça qui se passe en pratique) et là le setuid pourrait être honoré, ou alors le shell voit que le script n'est pas un vrai exécutable et fait un execve(nom de l'interpréteur) auquel cas il est normal que le setuid ne soit pas respecté.

Mais disons qu'au moment au je donne, moi, le bit setuid à un exécutable, je réfléchis sérieusement à sa qualité que j'ai audité, etc. et si je l'ai écrit il sera aussi bon que ce soit du code caml compilé ou du code caml interprété (vu qu'en pratique c'est ce que j'ai), donc je trouve désagréable de la part du système de ne pas m'autoriser à setuider mon script.

Bon, en cherchant plus, il semble que ce soit une option du noyau qui est désactivé ou activé selon les distributions.

« si j'avais besoin d'être protégé, j'utiliserais MacOS. » ça me paraît être une drôle d'idée. Pourquoi tu dis ça ?

Sinon, je veux bien que tu donnes la fameuse option du noyau si tu as toujours ça sous le coude. C'est toujours intéressant à savoir ces choses là.

"« si j'avais besoin d'être protégé, j'utiliserais MacOS. » ça me paraît être une drôle d'idée. Pourquoi tu dis ça ? "

Ben c'est l'idée que je me fais de MacOS et de l'écosystème Apple en général où Steve Jobs est là pour savoir ce qui est bon pour moi ou non. Mais bon, je n'ai plus utilisé de Mac depuis le Système 7 donc c'était juste du troll, je ne sais pas comment ça fonctionne en vrai.

L'option du noyau, je ne l'ai pas. J'ai juste trouvé un site qui la mentionnait (sinon, 50% des autres sites indiquaient que setuid fonctionne avec les scripts mais qu'il ne faut pas s'en servir et les 50% autres que ça ne fonctionne pas).

Hum…

50% de oui, 50% de non, et potentiellement 100% de gens qui ont raison. C'est assez marrant je trouve.