apparemment, sous mac os x, ça n'a pas d'effet de mettre un setuid sur
un script shell
et donc d'après ce qu'on m'a dit, c'est obligatoire de prgmer un
exécutable (par ex en c)
est ce qu'il existe des exécutables prévus à cet effet, pour lancer une
autre commande et pas n'importe lesquelles ?
ou bien il faut que je me paye cette programmation ?
--
j'agis contre l'assistanat, je travaille dans une SCOP !
apparemment, sous mac os x, ça n'a pas d'effet de mettre un setuid sur un script shell et donc d'après ce qu'on m'a dit, c'est obligatoire de prgmer un exécutable (par ex en c)
est ce qu'il existe des exécutables prévus à cet effet, pour lancer une autre commande et pas n'importe lesquelles ?
sudo est fait pour ça, mais j'imagine que tu connais et que ça ne convient pas à tes besoins. (on peut configurer sudo pour qu'il n'accepte que quelques commandes)
ou bien il faut que je me paye cette programmation ?
Si tu sais progrmmer en C:
man 3 exec Ca se programme en 5 minutes.
-- Sind zu sein und es seiend in einem Schiff. Fällt zu sein hat das Wasser. Wer bleibt er? -- Heidegger
Thomas :
bonjour :-)
apparemment, sous mac os x, ça n'a pas d'effet de mettre un setuid sur
un script shell
et donc d'après ce qu'on m'a dit, c'est obligatoire de prgmer un
exécutable (par ex en c)
est ce qu'il existe des exécutables prévus à cet effet, pour lancer une
autre commande et pas n'importe lesquelles ?
sudo est fait pour ça, mais j'imagine que tu connais et que ça ne convient
pas à tes besoins. (on peut configurer sudo pour qu'il n'accepte que
quelques commandes)
ou bien il faut que je me paye cette programmation ?
Si tu sais progrmmer en C:
man 3 exec
Ca se programme en 5 minutes.
--
Sind zu sein und es seiend in einem Schiff. Fällt zu sein hat das Wasser.
Wer bleibt er? -- Heidegger
apparemment, sous mac os x, ça n'a pas d'effet de mettre un setuid sur un script shell et donc d'après ce qu'on m'a dit, c'est obligatoire de prgmer un exécutable (par ex en c)
est ce qu'il existe des exécutables prévus à cet effet, pour lancer une autre commande et pas n'importe lesquelles ?
sudo est fait pour ça, mais j'imagine que tu connais et que ça ne convient pas à tes besoins. (on peut configurer sudo pour qu'il n'accepte que quelques commandes)
ou bien il faut que je me paye cette programmation ?
Si tu sais progrmmer en C:
man 3 exec Ca se programme en 5 minutes.
-- Sind zu sein und es seiend in einem Schiff. Fällt zu sein hat das Wasser. Wer bleibt er? -- Heidegger
Olivier Croquette
Thomas wrote, On 24/11/07 13:06:
bonjour :-)
Salut!
apparemment, sous mac os x, ça n'a pas d'effet de mettre un setuid sur un script shell
Il y a des OS où ce n'est pas le cas?
et donc d'après ce qu'on m'a dit, c'est obligatoire de prgmer un exécutable (par ex en c)
On peut aussi lancer le script en passant par sudo.
Thomas wrote, On 24/11/07 13:06:
bonjour :-)
Salut!
apparemment, sous mac os x, ça n'a pas d'effet de mettre un setuid sur
un script shell
Il y a des OS où ce n'est pas le cas?
et donc d'après ce qu'on m'a dit, c'est obligatoire de prgmer un
exécutable (par ex en c)
On peut aussi lancer le script en passant par sudo.
apparemment, sous mac os x, ça n'a pas d'effet de mettre un setuid sur un script shell
Il y a des OS où ce n'est pas le cas?
et donc d'après ce qu'on m'a dit, c'est obligatoire de prgmer un exécutable (par ex en c)
On peut aussi lancer le script en passant par sudo.
blanc
Thomas wrote:
apparemment, sous mac os x, ça n'a pas d'effet de mettre un setuid sur un script shell
Normal. Ça serait beaucoup trop dangereux. Facile en effet de repérer dans un script quelles commandes sont lancées, et de se débrouiller pour que d'autres soient lancées à la place.
Et amha tu tombes dans le même trou de sécurité si tu lances le script avec un programme C qui aurait lui le setuid. :-/
-- JiPaul. / /--/--// Jean-Paul Blanc |/| L | quelquepart en (somewhere in) /|| = ||| FRANCE
Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:
apparemment, sous mac os x, ça n'a pas d'effet de mettre un setuid sur
un script shell
Normal. Ça serait beaucoup trop dangereux. Facile en effet de repérer
dans un script quelles commandes sont lancées, et de se débrouiller pour
que d'autres soient lancées à la place.
Et amha tu tombes dans le même trou de sécurité si tu lances le script
avec un programme C qui aurait lui le setuid. :-/
--
JiPaul.
/ /--/--//\ Jean-Paul Blanc
|/| L |\ quelquepart en (somewhere in)
/|| = |||\ FRANCE
apparemment, sous mac os x, ça n'a pas d'effet de mettre un setuid sur un script shell
Normal. Ça serait beaucoup trop dangereux. Facile en effet de repérer dans un script quelles commandes sont lancées, et de se débrouiller pour que d'autres soient lancées à la place.
Et amha tu tombes dans le même trou de sécurité si tu lances le script avec un programme C qui aurait lui le setuid. :-/
-- JiPaul. / /--/--// Jean-Paul Blanc |/| L | quelquepart en (somewhere in) /|| = ||| FRANCE
Vincent Lefevre
Dans l'article <fia6ng$sso$01$, Olivier Croquette écrit:
Thomas wrote, On 24/11/07 13:06:
apparemment, sous mac os x, ça n'a pas d'effet de mettre un setuid sur un script shell
Il y a des OS où ce n'est pas le cas?
Linux, et Solaris (sauf si ça a changé). Ces deux systèmes sont protégés contre les attaques classiques par lien symbolique. Mais peut-être que ce n'est pas le cas de Mac OS X.
et donc d'après ce qu'on m'a dit, c'est obligatoire de prgmer un exécutable (par ex en c)
On peut aussi lancer le script en passant par sudo.
sudo est destiné à root, alors qu'un utilisateur lambda peut avoir un programme setuid.
Dans l'article <fia6ng$sso$01$1@news.t-online.com>,
Olivier Croquette <ocroquette@ocroquette.free.fr> écrit:
Thomas wrote, On 24/11/07 13:06:
apparemment, sous mac os x, ça n'a pas d'effet de mettre un setuid sur
un script shell
Il y a des OS où ce n'est pas le cas?
Linux, et Solaris (sauf si ça a changé). Ces deux systèmes sont
protégés contre les attaques classiques par lien symbolique. Mais
peut-être que ce n'est pas le cas de Mac OS X.
et donc d'après ce qu'on m'a dit, c'est obligatoire de prgmer un
exécutable (par ex en c)
On peut aussi lancer le script en passant par sudo.
sudo est destiné à root, alors qu'un utilisateur lambda peut avoir un
programme setuid.
Dans l'article <fia6ng$sso$01$, Olivier Croquette écrit:
Thomas wrote, On 24/11/07 13:06:
apparemment, sous mac os x, ça n'a pas d'effet de mettre un setuid sur un script shell
Il y a des OS où ce n'est pas le cas?
Linux, et Solaris (sauf si ça a changé). Ces deux systèmes sont protégés contre les attaques classiques par lien symbolique. Mais peut-être que ce n'est pas le cas de Mac OS X.
et donc d'après ce qu'on m'a dit, c'est obligatoire de prgmer un exécutable (par ex en c)
On peut aussi lancer le script en passant par sudo.
sudo est destiné à root, alors qu'un utilisateur lambda peut avoir un programme setuid.
Dans l'article <1i83z0f.1a7tusac00fdqN%, JiPaul écrit:
Thomas wrote:
apparemment, sous mac os x, ça n'a pas d'effet de mettre un setuid sur un script shell
Normal. Ça serait beaucoup trop dangereux. Facile en effet de repérer dans un script quelles commandes sont lancées, et de se débrouiller pour que d'autres soient lancées à la place.
Ce n'est pas une bonne raison. Cela interdit aussi les script Perl setuid, alors que c'est bien moins dangereux qu'un programme écrit en C (avec des risques de buffer overflow, pas de taint, etc.).
Dans l'article <1i83z0f.1a7tusac00fdqN%blanc@empty.org>,
JiPaul <blanc@empty.org> écrit:
Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:
apparemment, sous mac os x, ça n'a pas d'effet de mettre un setuid sur
un script shell
Normal. Ça serait beaucoup trop dangereux. Facile en effet de repérer
dans un script quelles commandes sont lancées, et de se débrouiller pour
que d'autres soient lancées à la place.
Ce n'est pas une bonne raison. Cela interdit aussi les script Perl
setuid, alors que c'est bien moins dangereux qu'un programme écrit
en C (avec des risques de buffer overflow, pas de taint, etc.).
Dans l'article <1i83z0f.1a7tusac00fdqN%, JiPaul écrit:
Thomas wrote:
apparemment, sous mac os x, ça n'a pas d'effet de mettre un setuid sur un script shell
Normal. Ça serait beaucoup trop dangereux. Facile en effet de repérer dans un script quelles commandes sont lancées, et de se débrouiller pour que d'autres soient lancées à la place.
Ce n'est pas une bonne raison. Cela interdit aussi les script Perl setuid, alors que c'est bien moins dangereux qu'un programme écrit en C (avec des risques de buffer overflow, pas de taint, etc.).
À (at) Mon, 26 Nov 2007 15:53:36 +0000 (UTC), Vincent Lefevre <vincent+ écrivait (wrote):
D'accord, mais l'utilisateur lambda ne peut pas modifier le sudoers pour autant.
Il suffit de l'ajouter une bonne fois pour toutes comme utilisateur autorisé de 'visudo' !
;-)
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Olivier Croquette
Vincent Lefevre wrote, On 26/11/07 12:39:
Linux, et Solaris (sauf si ça a changé).
Je sais pas quand tu as essayé, mais cela fait plusieurs années que Linux n'honore pas le setuid sur les scripts par défaut. http://www.google.de/search?q=linux+setuid+scripts
Different Unix-like systems handle the security issue for setuid scripts in different ways. Some systems, such as Linux, completely ignore the setuid and setgid bits when executing scripts, which is clearly a safe approach. Most modern releases of SysVr4 and BSD 4.4 use a different approach to avoid the kernel race condition. On these systems, when the kernel passes the name of the set-id script to open to the interpreter, rather than using a pathname (which would permit the race condition) it instead passes the filename /dev/fd/3. This is a special file already opened on the script, so that there can be no race condition for attackers to exploit. Even on these systems I recommend against using the setuid/setgid shell scripts language for secure programs, as discussed below.
Vincent Lefevre wrote, On 26/11/07 12:39:
Linux, et Solaris (sauf si ça a changé).
Je sais pas quand tu as essayé, mais cela fait plusieurs années que
Linux n'honore pas le setuid sur les scripts par défaut.
http://www.google.de/search?q=linux+setuid+scripts
Different Unix-like systems handle the security issue for setuid scripts
in different ways. Some systems, such as Linux, completely ignore the
setuid and setgid bits when executing scripts, which is clearly a safe
approach. Most modern releases of SysVr4 and BSD 4.4 use a different
approach to avoid the kernel race condition. On these systems, when the
kernel passes the name of the set-id script to open to the interpreter,
rather than using a pathname (which would permit the race condition) it
instead passes the filename /dev/fd/3. This is a special file already
opened on the script, so that there can be no race condition for
attackers to exploit. Even on these systems I recommend against using
the setuid/setgid shell scripts language for secure programs, as
discussed below.
Je sais pas quand tu as essayé, mais cela fait plusieurs années que Linux n'honore pas le setuid sur les scripts par défaut. http://www.google.de/search?q=linux+setuid+scripts
Different Unix-like systems handle the security issue for setuid scripts in different ways. Some systems, such as Linux, completely ignore the setuid and setgid bits when executing scripts, which is clearly a safe approach. Most modern releases of SysVr4 and BSD 4.4 use a different approach to avoid the kernel race condition. On these systems, when the kernel passes the name of the set-id script to open to the interpreter, rather than using a pathname (which would permit the race condition) it instead passes the filename /dev/fd/3. This is a special file already opened on the script, so that there can be no race condition for attackers to exploit. Even on these systems I recommend against using the setuid/setgid shell scripts language for secure programs, as discussed below.
Vincent Lefevre
Dans l'article <fifcvf$asc$00$, Olivier Croquette écrit:
Vincent Lefevre wrote, On 26/11/07 12:39:
Linux, et Solaris (sauf si ça a changé).
Je sais pas quand tu as essayé, mais cela fait plusieurs années que Linux n'honore pas le setuid sur les scripts par défaut. http://www.google.de/search?q=linux+setuid+scripts
Ben sous Linux, je le fais tous les jours sans aucun problème:
C'est mon script qui permet de poster et récupérer les news (entre inn2 et le serveur de mon FAI). Le fait que tu puisses voir cet article est une preuve que ça fonctionne. :)
C'est sous Solaris que je n'ai pas essayé depuis plusieurs années.
Different Unix-like systems handle the security issue for setuid scripts in different ways. Some systems, such as Linux, completely ignore the setuid and setgid bits when executing scripts,
Je peux voir ici que c'est faux. Mais c'est peut-être le shell lui-même qui empêche de voir le bit setuid à cause de la différence UID/EUID. En Perl, ça ne fonctionne pas jusqu'à ce qu'on fait un:
$< = $>; # set real to effective uid
which is clearly a safe approach. Most modern releases of SysVr4 and BSD 4.4 use a different approach to avoid the kernel race condition. On these systems, when the kernel passes the name of the set-id script to open to the interpreter, rather than using a pathname (which would permit the race condition) it instead passes the filename /dev/fd/3.
C'est effectivement ce que fait Solaris. Je suppose que Linux fait pareil.
This is a special file already opened on the script, so that there can be no race condition for attackers to exploit. Even on these systems I recommend against using the setuid/setgid shell scripts language for secure programs, as discussed below.
OK, c'est vrai pour les scripts shell, mais les scripts Perl setuid offrent une meilleure sécurité que les programmes écrits en C (à condition de connaître le langage et de ne pas faire n'importe quoi, évidemment).
Dans l'article <fifcvf$asc$00$1@news.t-online.com>,
Olivier Croquette <ocroquette@ocroquette.free.fr> écrit:
Vincent Lefevre wrote, On 26/11/07 12:39:
Linux, et Solaris (sauf si ça a changé).
Je sais pas quand tu as essayé, mais cela fait plusieurs années que
Linux n'honore pas le setuid sur les scripts par défaut.
http://www.google.de/search?q=linux+setuid+scripts
Ben sous Linux, je le fais tous les jours sans aucun problème:
C'est mon script qui permet de poster et récupérer les news (entre
inn2 et le serveur de mon FAI). Le fait que tu puisses voir cet
article est une preuve que ça fonctionne. :)
C'est sous Solaris que je n'ai pas essayé depuis plusieurs années.
Different Unix-like systems handle the security issue for setuid
scripts in different ways. Some systems, such as Linux, completely
ignore the setuid and setgid bits when executing scripts,
Je peux voir ici que c'est faux. Mais c'est peut-être le shell lui-même
qui empêche de voir le bit setuid à cause de la différence UID/EUID. En
Perl, ça ne fonctionne pas jusqu'à ce qu'on fait un:
$< = $>; # set real to effective uid
which is clearly a safe approach. Most modern releases of SysVr4 and
BSD 4.4 use a different approach to avoid the kernel race condition.
On these systems, when the kernel passes the name of the set-id
script to open to the interpreter, rather than using a pathname
(which would permit the race condition) it instead passes the
filename /dev/fd/3.
C'est effectivement ce que fait Solaris. Je suppose que Linux fait
pareil.
This is a special file already opened on the script, so that there
can be no race condition for attackers to exploit. Even on these
systems I recommend against using the setuid/setgid shell scripts
language for secure programs, as discussed below.
OK, c'est vrai pour les scripts shell, mais les scripts Perl setuid
offrent une meilleure sécurité que les programmes écrits en C (à
condition de connaître le langage et de ne pas faire n'importe quoi,
évidemment).
Dans l'article <fifcvf$asc$00$, Olivier Croquette écrit:
Vincent Lefevre wrote, On 26/11/07 12:39:
Linux, et Solaris (sauf si ça a changé).
Je sais pas quand tu as essayé, mais cela fait plusieurs années que Linux n'honore pas le setuid sur les scripts par défaut. http://www.google.de/search?q=linux+setuid+scripts
Ben sous Linux, je le fais tous les jours sans aucun problème:
C'est mon script qui permet de poster et récupérer les news (entre inn2 et le serveur de mon FAI). Le fait que tu puisses voir cet article est une preuve que ça fonctionne. :)
C'est sous Solaris que je n'ai pas essayé depuis plusieurs années.
Different Unix-like systems handle the security issue for setuid scripts in different ways. Some systems, such as Linux, completely ignore the setuid and setgid bits when executing scripts,
Je peux voir ici que c'est faux. Mais c'est peut-être le shell lui-même qui empêche de voir le bit setuid à cause de la différence UID/EUID. En Perl, ça ne fonctionne pas jusqu'à ce qu'on fait un:
$< = $>; # set real to effective uid
which is clearly a safe approach. Most modern releases of SysVr4 and BSD 4.4 use a different approach to avoid the kernel race condition. On these systems, when the kernel passes the name of the set-id script to open to the interpreter, rather than using a pathname (which would permit the race condition) it instead passes the filename /dev/fd/3.
C'est effectivement ce que fait Solaris. Je suppose que Linux fait pareil.
This is a special file already opened on the script, so that there can be no race condition for attackers to exploit. Even on these systems I recommend against using the setuid/setgid shell scripts language for secure programs, as discussed below.
OK, c'est vrai pour les scripts shell, mais les scripts Perl setuid offrent une meilleure sécurité que les programmes écrits en C (à condition de connaître le langage et de ne pas faire n'importe quoi, évidemment).
