le bit s dans -rwsr-sr-x

"@(none)" <""olivier"@(none)"> writes:

int main(){
printf("%sn",(getpwuid( getuid())->pw_name));
printf("%dn",(chdir("/root")));
system("ls");
return 0;
}
ls: .: Permission denied
j ai oublie ou pas compris un truc ?

Oui, tu as oublié de lire man system !

Do not use system() from a program with suid or sgid privileges,
because strange values for some environment variables might be
used to subvert system integrity. Use the exec(3) family of

Ajouter:
printf("%sn",(getpwuid(geteuid())->pw_name));
system("bash -c 'echo UID=$UID EUID=$EUID'");
pour se rendre compte.


En plus, tu as oublié de tester dans le programme si l'utilisateur a
officiellement le droit de lire le répertoire de root (par exemple, si
c'est "olivier").

--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/

Ok pour le man system qui dit il faut pas ....!

Sinon pour avoir vraiment les droit de root
j'avais oublier d'ajouter setuid(0) ca marche dans le main.

int main(){
setuid(0);
printf("%sn",(getpwuid( getuid())->pw_name));
printf("%dn",(chdir("/root")));
system("ls");
return 0;
}
Et si les appels systems se contentent de faire des ls, diff et des
petits coups de sed, sans utiliser de variables d'environnement est ce
qu'il y a vraiment un probleme a utiliser system dans un programme avec
les privileges set-Uid ?

SnopO

"@(none)" <""olivier"@(none)"> writes:

Ok pour le man system qui dit il faut pas ....!

Sinon pour avoir vraiment les droit de root
j'avais oublier d'ajouter setuid(0) ca marche dans le main.

Et si les appels systems se contentent de faire des ls, diff et des
petits coups de sed, sans utiliser de variables d'environnement est ce
qu'il y a vraiment un probleme a utiliser system dans un programme
avec les privileges set-Uid ?

Non, mais il faut le faire, vider l'environnement!

int main(){
clearenv();

setuid(0);

Ça, ça ne marche que si le programe est setuid root!

Normalement, les programmes setuid, on les donne à un autre user, afin
de limiter les risques. Par exemple, si on veut déposer un message
dans une drop box, on fait:

su
chown messager deposer # messager et PAS root!
chmod u+s deposer
chown messager dropbox/
chmod 700 dropbox/
exit
./deposer message

printf("%sn",(getpwuid( getuid())->pw_name));
printf("%dn",(chdir("/root")));
system("ls");

Et alors reste le problème que system remet l'UID dans l'EUID.
C'est pour ça qu'il vaut mieux piper, forker et execer à la main.

return 0;
}

--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/

2004-01-27, 12:33(+01), Pascal Bourguignon:
[...]

Et alors reste le problème que system remet l'UID dans l'EUID.
[...]

Seulement avec bash, il me semble. Enfin, ce n'est pas spécifié
par POSIX et je ne connais pas d'autre shell qui ait ce
comportement.

$ sudo install -o test -m 4755 ºsh .
$ sudo install -o test -m 4755 =pdksh .
$ sudo install -o test -m 4755 =zsh .
$ sudo install -o test -m 4755 =ash .
$ sudo install -o test -m 4755 Úsh .
$ ./ash -c 'id -un'
test
$ ./dash -c 'id -un'
test
$ ./pdksh -c 'id -un'
test
$ ./ksh93 -c 'id -un'
test
$ ./zsh -c 'id -un'
test
$ ./bash -c 'id -un'
chazelas
$ ./bash -pc 'id -un'
test

`-p'
Turn on privileged mode. In this mode, the `$BASH_ENV' and
`$ENV' files are not processed, shell functions are not
inherited from the environment, and the `SHELLOPTS' variable,
if it appears in the environment, is ignored. If the shell
is started with the effective user (group) id not equal to the
real user (group) id, and the `-p' option is not supplied,
these actions are taken and the effective user id is set to
the real user id. If the `-p' option is supplied at startup,
the effective user id is not reset. Turning this option off
causes the effective user and group ids to be set to the real
user and group ids.

--
Stéphane ["Stephane.Chazelas" arobase "free.fr"]

Stephane Chazelas <cette.adresse@est.invalid> writes:

2004-01-27, 12:33(+01), Pascal Bourguignon:
[...]

Et alors reste le problème que system remet l'UID dans l'EUID.
[...]

Seulement avec bash, il me semble. Enfin, ce n'est pas spécifié
par POSIX et je ne connais pas d'autre shell qui ait ce
comportement.
$ ./bash -c 'id -un'
chazelas

Sympa, hein, bash ! Il pense à notre sécurité, lui, au moins.

--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/

2004-01-27, 16:42(+01), Pascal Bourguignon:
[...]

Sympa, hein, bash ! Il pense à notre sécurité, lui, au moins.

Oui, mais bon, c'est pas ça qui rend secure les scripts setuid
(sur les systèmes qui les supportent) au contraire.
Ça oblige à mettre "#! /bin/bash -p" pour avoir un script
setuid.

Et alors, si je fais:

ln -s /path/to/setuid-script /tmp/-i
PATH=/tmp:$PATH -i

J'ai un bash interactif en tant que root (sauf sur les systèmes
qui ouvrent le script et passent /dev/fd/n à l'interpreteur). Le
Bourne shell ne connait pas ENV, BASH_ENV, SHELLOPT; les shells
POSIX n'utilisent pas ENV si euid != uid non plus.

Donc, on peut mettre:

#! /bin/sh -

Et avoir un script suid qui n'a pas le problème sur le nom du
script pris pour une option (il en a d'autres cela-dit), donc,
c'est mieux que

#! /bin/bash -
qui droppe le privilege -> pas setuid

ou

#! /bin/bash -p
qui a le problème du nom du script pris pour une option

(note que le shebang n'autorise qu'un argument, donc pas de
#! /bin/bash -p -)

--
Stéphane ["Stephane.Chazelas" arobase "free.fr"]