(Courriels de diversion: <bohemiennes@recriminiez-transcription.com> <scolariserait@cuti-reaction-aspergeons.com> <radiodiffuses@degrossissaient-refugies.com> <sous-estimions@particularises-embrayons.com> <ravives@galvaniserez-tuerez.com> <erres@trituraient-prejugeons.com> <fragilise@assaisonnee-baladeurs.com> <terminiez@frequentons-crucifiement.com> <figurerait@desodoriserent-retournerez.com> <interrompit@sucera-etatiseront.com> )
Le 6 Avr, jdd écrit :
> je m'explique : exemple, démarrage de la liaison ppp. Plusieurs scripts
> s'enchainent. J'ai écrit "up" qui appelle "suseppp", qui lui-même
> appelle je ne sais pas trop quoi.
>
> en root, tout se passe bien.
> en user, non, même avec les appartenance aux groupes correctes (à
> première vue!), mais ce n'est pas l'objet de cette question.
>
> j'ai voulu mettre "up" en suid. Je l'ai mis en root:user et donc suid.
> up se lance bien en utilisateur, mais pas suseppp. Il semble donc que
> les droits suid ne se transmettent pas. (suseppp n'est pas exécuté avec
> les droits root).
> deux questions, donc.
> *est-ce bien vrai que les droits root ne se transmettent pas, ou ais-je
> oublié quelque chose.
Ils sont transmis, une fois qu'ils ont été donnés. Ton problème vient
sans doute de là : je suppose que « up » est un script. Le noyau Linux
(au moins en 2.0, je ne sais pas ce qu'il en est des versions plus
récentes) n'honorent pas les changements d'identité sur les scripts (ni
sur les fichiers trouvés dans un système de fichiers montés avec
l'option nosuid). Pourquoi ? Parce qu'à l'inverse de Solaris, il ne sait
pas le faire sans ouvrir un trou de sécurité (je ne détaille pas).
Tu as alors deux solutions :
- tu crées un fichier wrapper.c qui contient :
#include <unistd.h>
#include <stdio.h>
int main(void)
{
execl("/bin/bash", "sh", "-p", "up", NULL); /* remplace up par le
chemin de ton script */
perror("wrapper failed to exec up");
exit(1);
}
Tu le compiles, tu le mets suid, et ça roule.
(pas testé cette instance particulière ; mais j'ai déjà fait).
- ou tu vérifies que le logiciel libre, c'est pas du vent, et que la
disponibilité des sources est un plus. Dans les sources du noyau,
tu vas dans le répertoire fs. Ce qui t'intéresse, ce sont les
fichiers binfmt_elf.c et binfmt_script.c. Dans le premier, tu
cherches « euid » dans la fonction do_load_elf_binary. Cela doit
t'amener sur des lignes qui ressemblent à ça :
current->suid = current->euid = current->fsuid = bprm->e_uid;
current->sgid = current->egid = current->fsgid = bprm->e_gid;
Tu les copies au début de la fonction do_load_script du second
fichier. Tu recompiles le noyau et tu boutes dessus. Voilà ! Ton
noyau sait exécuter des scripts suid.
(pas testé ; je ne suis pas absolument certain que cette manip
suffise).
Evidemment, les deux méthodes introduisent des trous de sécurité
(surtout la deuxième). A toi de voir.
> *si il faut traiter tous les fichiers, y a-t-il moyen de savoir quelle
> est la liste des fichiers exécutés sans plonger dans le source (un sorte
> de traceroute)?
Le plus tout terrain est de tenter un « strace -f -o /tmp/trace » sur
ta commande, puis de chercher les appels à open et execve dedans. Tu
devrais tout attraper (tu ne peux pas le faire si tes commandes sont
suid ; tu dois le faire en root).
--
Marc Thirion | Toulouse, France
Un Travail pour Chacun : http://www.multimania.com/untravailchacun/
_______________________________________________________________________
Le CULTe sur le ouebe: http://savage.iut-blagnac.fr/