Le 13/08/07 21:41, dans <20070813193945$, « Vincent Lefevre » <vincent+ a écrit :
Dans l'article <C2E49862.AFD98%, Eric Levenez écrit:
Le 12/08/07 2:21, dans <20070812001919$, « Vincent Lefevre » <vincent+ a écrit :
Un tty n'est pas plus sécurisé qu'un pipe.
Normalement si, cela a été inventé pour cela justement.
Conceptuellement, il n'y a aucune raison pour que le pipe soit moins sécurisé. Ou alors c'était une question d'implémentation dans le passé, qui n'est probablement plus valable aujourd'hui?
La sécurité venait du fait que sans pseudo-tty, il n'était pas possible de rediriger /dev/tty et donc de faire des scripts pour cracker des mots de passe. Dès que l'on a accès à un pseudo-tty on peut tout faire il est vrai.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 13/08/07 21:41, dans <20070813193945$0661@prunille.vinc17.org>, « Vincent
Lefevre » <vincent+news@vinc17.org> a écrit :
Dans l'article <C2E49862.AFD98%news@levenez.com>,
Eric Levenez <news@levenez.com> écrit:
Le 12/08/07 2:21, dans <20070812001919$0598@prunille.vinc17.org>, « Vincent
Lefevre » <vincent+news@vinc17.org> a écrit :
Un tty n'est pas plus sécurisé qu'un pipe.
Normalement si, cela a été inventé pour cela justement.
Conceptuellement, il n'y a aucune raison pour que le pipe soit moins
sécurisé. Ou alors c'était une question d'implémentation dans le passé,
qui n'est probablement plus valable aujourd'hui?
La sécurité venait du fait que sans pseudo-tty, il n'était pas possible de
rediriger /dev/tty et donc de faire des scripts pour cracker des mots de
passe. Dès que l'on a accès à un pseudo-tty on peut tout faire il est vrai.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 13/08/07 21:41, dans <20070813193945$, « Vincent Lefevre » <vincent+ a écrit :
Dans l'article <C2E49862.AFD98%, Eric Levenez écrit:
Le 12/08/07 2:21, dans <20070812001919$, « Vincent Lefevre » <vincent+ a écrit :
Un tty n'est pas plus sécurisé qu'un pipe.
Normalement si, cela a été inventé pour cela justement.
Conceptuellement, il n'y a aucune raison pour que le pipe soit moins sécurisé. Ou alors c'était une question d'implémentation dans le passé, qui n'est probablement plus valable aujourd'hui?
La sécurité venait du fait que sans pseudo-tty, il n'était pas possible de rediriger /dev/tty et donc de faire des scripts pour cracker des mots de passe. Dès que l'on a accès à un pseudo-tty on peut tout faire il est vrai.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Eric Levenez
Le 13/08/07 21:56, dans <20070813194156$, « Vincent Lefevre » <vincent+ a écrit :
Dans l'article <C2E49A6F.AFD9A%, Eric Levenez écrit:
Le problème est que souvent le setuid d'un shell est mal utilisé car le shell est souvent lisible par tous et les "programmeurs" y placent des données confidentielles.
C'est juste un problème avec les mauvais programmeurs.
Pas uniquement. Plus il y a de programmes setuid, plus il y a de problèmes potentiels. C'est d'ailleurs le gros problème pour la sécurité Unix. Souvent quand un problème de sécurité est corrigé c'est dans un programme setuid. Alors on peut dire qu'il n'y a que des mauvais programmeurs dans le monde, mais je ne pense pas.
Et puis si écrire un script sh setuid est assez risqué, un script Perl setuid (avec l'option -T, obligatoire, je crois) l'est beaucoup moins.
Peut-être que les programmeurs Perl sont tous sans exception de bons programmeurs (même si j'écris souvent en Perl), mais il vaut mieux interdire tous les scripts avec setuid que de laisser passer des trous à cause de certains.
Quand Perl tourne en setuid ce n'est plus la même version de Perl, c'est une version qui essaye de se protéger des problèmes de sécurité sur les données en entrée/sortie. Le programme Perl ne fait donc même pas confiance à son programmeur... :-)
Pour éviter d'avoir 36 programmes setuid sur le système, le sudo doit être utilisé.
C'est moins pratique, et ça demande un accès root pour permettre l'utilisation du sudo. Et il y a des différences. Par exemple:
The real and effective uid and gid are set to match those of the target user [...]
Les uid/gid réels *et* effectifs sont tous deux modifiés. Enfin, ceci est tout de même paramétrable avec l'option stay_setuid. D'autre part, peut-on spécifier l'uid et le gid dans le fichier /etc/sudoers?
Je n'ai pas regardé cela.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 13/08/07 21:56, dans <20070813194156$29fc@prunille.vinc17.org>, « Vincent
Lefevre » <vincent+news@vinc17.org> a écrit :
Dans l'article <C2E49A6F.AFD9A%news@levenez.com>,
Eric Levenez <news@levenez.com> écrit:
Le problème est que souvent le setuid d'un shell est mal utilisé car le
shell est souvent lisible par tous et les "programmeurs" y placent des
données confidentielles.
C'est juste un problème avec les mauvais programmeurs.
Pas uniquement. Plus il y a de programmes setuid, plus il y a de problèmes
potentiels. C'est d'ailleurs le gros problème pour la sécurité Unix. Souvent
quand un problème de sécurité est corrigé c'est dans un programme setuid.
Alors on peut dire qu'il n'y a que des mauvais programmeurs dans le monde,
mais je ne pense pas.
Et puis si
écrire un script sh setuid est assez risqué, un script Perl setuid
(avec l'option -T, obligatoire, je crois) l'est beaucoup moins.
Peut-être que les programmeurs Perl sont tous sans exception de bons
programmeurs (même si j'écris souvent en Perl), mais il vaut mieux interdire
tous les scripts avec setuid que de laisser passer des trous à cause de
certains.
Quand Perl tourne en setuid ce n'est plus la même version de Perl, c'est une
version qui essaye de se protéger des problèmes de sécurité sur les données
en entrée/sortie. Le programme Perl ne fait donc même pas confiance à son
programmeur... :-)
Pour éviter d'avoir 36 programmes setuid sur le système, le sudo
doit être utilisé.
C'est moins pratique, et ça demande un accès root pour permettre
l'utilisation du sudo. Et il y a des différences. Par exemple:
The real and effective uid and gid are set to match those of the
target user [...]
Les uid/gid réels *et* effectifs sont tous deux modifiés. Enfin, ceci
est tout de même paramétrable avec l'option stay_setuid. D'autre part,
peut-on spécifier l'uid et le gid dans le fichier /etc/sudoers?
Je n'ai pas regardé cela.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 13/08/07 21:56, dans <20070813194156$, « Vincent Lefevre » <vincent+ a écrit :
Dans l'article <C2E49A6F.AFD9A%, Eric Levenez écrit:
Le problème est que souvent le setuid d'un shell est mal utilisé car le shell est souvent lisible par tous et les "programmeurs" y placent des données confidentielles.
C'est juste un problème avec les mauvais programmeurs.
Pas uniquement. Plus il y a de programmes setuid, plus il y a de problèmes potentiels. C'est d'ailleurs le gros problème pour la sécurité Unix. Souvent quand un problème de sécurité est corrigé c'est dans un programme setuid. Alors on peut dire qu'il n'y a que des mauvais programmeurs dans le monde, mais je ne pense pas.
Et puis si écrire un script sh setuid est assez risqué, un script Perl setuid (avec l'option -T, obligatoire, je crois) l'est beaucoup moins.
Peut-être que les programmeurs Perl sont tous sans exception de bons programmeurs (même si j'écris souvent en Perl), mais il vaut mieux interdire tous les scripts avec setuid que de laisser passer des trous à cause de certains.
Quand Perl tourne en setuid ce n'est plus la même version de Perl, c'est une version qui essaye de se protéger des problèmes de sécurité sur les données en entrée/sortie. Le programme Perl ne fait donc même pas confiance à son programmeur... :-)
Pour éviter d'avoir 36 programmes setuid sur le système, le sudo doit être utilisé.
C'est moins pratique, et ça demande un accès root pour permettre l'utilisation du sudo. Et il y a des différences. Par exemple:
The real and effective uid and gid are set to match those of the target user [...]
Les uid/gid réels *et* effectifs sont tous deux modifiés. Enfin, ceci est tout de même paramétrable avec l'option stay_setuid. D'autre part, peut-on spécifier l'uid et le gid dans le fichier /etc/sudoers?
Je n'ai pas regardé cela.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Vincent Lefevre
Dans l'article <C2E691BF.AFF7D%, Eric Levenez écrit:
Le 13/08/07 21:56, dans <20070813194156$, « Vincent Lefevre » <vincent+ a écrit :
Dans l'article <C2E49A6F.AFD9A%, Eric Levenez écrit:
Le problème est que souvent le setuid d'un shell est mal utilisé car le shell est souvent lisible par tous et les "programmeurs" y placent des données confidentielles.
C'est juste un problème avec les mauvais programmeurs.
Pas uniquement. Plus il y a de programmes setuid, plus il y a de problèmes potentiels.
Pas vraiment. Car les utilisateurs les remplacent par des solutions beaucoup plus sales, genre utilisation du sudo avec mot de passe stocké en clair sur le système de fichiers... Ou des permissions moins strictes, permettant à l'ensemble des utilisateurs d'avoir accès aux fichiers (au lieu d'un simple script setuid). Ou des programmes C setuid, avec des buffer overflows...
Quand Perl tourne en setuid ce n'est plus la même version de Perl, c'est une version qui essaye de se protéger des problèmes de sécurité sur les données en entrée/sortie. Le programme Perl ne fait donc même pas confiance à son programmeur... :-)
C'est plutôt qu'il essaie de minimiser les risques.
Dans l'article <C2E691BF.AFF7D%news@levenez.com>,
Eric Levenez <news@levenez.com> écrit:
Le 13/08/07 21:56, dans <20070813194156$29fc@prunille.vinc17.org>, « Vincent
Lefevre » <vincent+news@vinc17.org> a écrit :
Dans l'article <C2E49A6F.AFD9A%news@levenez.com>,
Eric Levenez <news@levenez.com> écrit:
Le problème est que souvent le setuid d'un shell est mal utilisé car le
shell est souvent lisible par tous et les "programmeurs" y placent des
données confidentielles.
C'est juste un problème avec les mauvais programmeurs.
Pas uniquement. Plus il y a de programmes setuid, plus il y a de
problèmes potentiels.
Pas vraiment. Car les utilisateurs les remplacent par des solutions
beaucoup plus sales, genre utilisation du sudo avec mot de passe
stocké en clair sur le système de fichiers... Ou des permissions
moins strictes, permettant à l'ensemble des utilisateurs d'avoir
accès aux fichiers (au lieu d'un simple script setuid). Ou des
programmes C setuid, avec des buffer overflows...
Quand Perl tourne en setuid ce n'est plus la même version de Perl,
c'est une version qui essaye de se protéger des problèmes de
sécurité sur les données en entrée/sortie. Le programme Perl ne fait
donc même pas confiance à son programmeur... :-)
C'est plutôt qu'il essaie de minimiser les risques.
Dans l'article <C2E691BF.AFF7D%, Eric Levenez écrit:
Le 13/08/07 21:56, dans <20070813194156$, « Vincent Lefevre » <vincent+ a écrit :
Dans l'article <C2E49A6F.AFD9A%, Eric Levenez écrit:
Le problème est que souvent le setuid d'un shell est mal utilisé car le shell est souvent lisible par tous et les "programmeurs" y placent des données confidentielles.
C'est juste un problème avec les mauvais programmeurs.
Pas uniquement. Plus il y a de programmes setuid, plus il y a de problèmes potentiels.
Pas vraiment. Car les utilisateurs les remplacent par des solutions beaucoup plus sales, genre utilisation du sudo avec mot de passe stocké en clair sur le système de fichiers... Ou des permissions moins strictes, permettant à l'ensemble des utilisateurs d'avoir accès aux fichiers (au lieu d'un simple script setuid). Ou des programmes C setuid, avec des buffer overflows...
Quand Perl tourne en setuid ce n'est plus la même version de Perl, c'est une version qui essaye de se protéger des problèmes de sécurité sur les données en entrée/sortie. Le programme Perl ne fait donc même pas confiance à son programmeur... :-)
C'est plutôt qu'il essaie de minimiser les risques.
Le 15/08/07 4:00, dans <20070815015333$, « Vincent Lefevre » <vincent+ a écrit :
Dans l'article <C2E691BF.AFF7D%, Eric Levenez écrit:
Le 13/08/07 21:56, dans <20070813194156$, « Vincent Lefevre » <vincent+ a écrit :
Dans l'article <C2E49A6F.AFD9A%, Eric Levenez écrit:
Le problème est que souvent le setuid d'un shell est mal utilisé car le shell est souvent lisible par tous et les "programmeurs" y placent des données confidentielles.
C'est juste un problème avec les mauvais programmeurs.
Pas uniquement. Plus il y a de programmes setuid, plus il y a de problèmes potentiels.
Pas vraiment.
Tous les experts de sécurité Unix sont d'accord sur ce point pourtant.
Car les utilisateurs les remplacent par des solutions beaucoup plus sales, genre utilisation du sudo avec mot de passe stocké en clair sur le système de fichiers... Ou des permissions moins strictes, permettant à l'ensemble des utilisateurs d'avoir accès aux fichiers (au lieu d'un simple script setuid).
On peut toujours trouver des mauvaises solutions pire que ce que l'on veut corriger.
Ou des programmes C setuid, avec des buffer overflows...
Justement c'est là le problème principal.
Quand Perl tourne en setuid ce n'est plus la même version de Perl, c'est une version qui essaye de se protéger des problèmes de sécurité sur les données en entrée/sortie. Le programme Perl ne fait donc même pas confiance à son programmeur... :-)
C'est plutôt qu'il essaie de minimiser les risques.
Il essaye.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 15/08/07 4:00, dans <20070815015333$1e0b@prunille.vinc17.org>, « Vincent
Lefevre » <vincent+news@vinc17.org> a écrit :
Dans l'article <C2E691BF.AFF7D%news@levenez.com>,
Eric Levenez <news@levenez.com> écrit:
Le 13/08/07 21:56, dans <20070813194156$29fc@prunille.vinc17.org>, « Vincent
Lefevre » <vincent+news@vinc17.org> a écrit :
Dans l'article <C2E49A6F.AFD9A%news@levenez.com>,
Eric Levenez <news@levenez.com> écrit:
Le problème est que souvent le setuid d'un shell est mal utilisé car le
shell est souvent lisible par tous et les "programmeurs" y placent des
données confidentielles.
C'est juste un problème avec les mauvais programmeurs.
Pas uniquement. Plus il y a de programmes setuid, plus il y a de
problèmes potentiels.
Pas vraiment.
Tous les experts de sécurité Unix sont d'accord sur ce point pourtant.
Car les utilisateurs les remplacent par des solutions
beaucoup plus sales, genre utilisation du sudo avec mot de passe
stocké en clair sur le système de fichiers... Ou des permissions
moins strictes, permettant à l'ensemble des utilisateurs d'avoir
accès aux fichiers (au lieu d'un simple script setuid).
On peut toujours trouver des mauvaises solutions pire que ce que l'on veut
corriger.
Ou des
programmes C setuid, avec des buffer overflows...
Justement c'est là le problème principal.
Quand Perl tourne en setuid ce n'est plus la même version de Perl,
c'est une version qui essaye de se protéger des problèmes de
sécurité sur les données en entrée/sortie. Le programme Perl ne fait
donc même pas confiance à son programmeur... :-)
C'est plutôt qu'il essaie de minimiser les risques.
Il essaye.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 15/08/07 4:00, dans <20070815015333$, « Vincent Lefevre » <vincent+ a écrit :
Dans l'article <C2E691BF.AFF7D%, Eric Levenez écrit:
Le 13/08/07 21:56, dans <20070813194156$, « Vincent Lefevre » <vincent+ a écrit :
Dans l'article <C2E49A6F.AFD9A%, Eric Levenez écrit:
Le problème est que souvent le setuid d'un shell est mal utilisé car le shell est souvent lisible par tous et les "programmeurs" y placent des données confidentielles.
C'est juste un problème avec les mauvais programmeurs.
Pas uniquement. Plus il y a de programmes setuid, plus il y a de problèmes potentiels.
Pas vraiment.
Tous les experts de sécurité Unix sont d'accord sur ce point pourtant.
Car les utilisateurs les remplacent par des solutions beaucoup plus sales, genre utilisation du sudo avec mot de passe stocké en clair sur le système de fichiers... Ou des permissions moins strictes, permettant à l'ensemble des utilisateurs d'avoir accès aux fichiers (au lieu d'un simple script setuid).
On peut toujours trouver des mauvaises solutions pire que ce que l'on veut corriger.
Ou des programmes C setuid, avec des buffer overflows...
Justement c'est là le problème principal.
Quand Perl tourne en setuid ce n'est plus la même version de Perl, c'est une version qui essaye de se protéger des problèmes de sécurité sur les données en entrée/sortie. Le programme Perl ne fait donc même pas confiance à son programmeur... :-)
C'est plutôt qu'il essaie de minimiser les risques.
Il essaye.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
kurtz le pirate
dans le même genre, comment 'disk utility' fait pour réparer les autorisations sans être root ?
-- klp
dans le même genre, comment 'disk utility' fait pour réparer les
autorisations sans être root ?
