Dans l'article <C2E0BFA3.AFA3C%, Eric Levenez écrit:
Ah, j'avais pas vu l'option -S. Comme c'est quand même un trou de sécurité, sudo doit se protéger en invalidant les essais de mots de passe si l'on a trop d'erreurs pendant une durée. Enfin je suppose.
Pourquoi un trou de sécurité? Si le but est d'empêcher les essais automatiques et donc d'interdire l'envoi du mot de passe via stdin, alors il faudrait aussi interdire les pseudo-ttys. Et là, tout un tas de programmes risquent de ne plus marcher (à commencer par "screen", je suppose).
Dans l'article <C2E0BFA3.AFA3C%news@levenez.com>,
Eric Levenez <news@levenez.com> écrit:
Ah, j'avais pas vu l'option -S. Comme c'est quand même un trou de sécurité,
sudo doit se protéger en invalidant les essais de mots de passe si l'on a
trop d'erreurs pendant une durée. Enfin je suppose.
Pourquoi un trou de sécurité? Si le but est d'empêcher les essais
automatiques et donc d'interdire l'envoi du mot de passe via stdin,
alors il faudrait aussi interdire les pseudo-ttys. Et là, tout un
tas de programmes risquent de ne plus marcher (à commencer par
"screen", je suppose).
Dans l'article <C2E0BFA3.AFA3C%, Eric Levenez écrit:
Ah, j'avais pas vu l'option -S. Comme c'est quand même un trou de sécurité, sudo doit se protéger en invalidant les essais de mots de passe si l'on a trop d'erreurs pendant une durée. Enfin je suppose.
Pourquoi un trou de sécurité? Si le but est d'empêcher les essais automatiques et donc d'interdire l'envoi du mot de passe via stdin, alors il faudrait aussi interdire les pseudo-ttys. Et là, tout un tas de programmes risquent de ne plus marcher (à commencer par "screen", je suppose).
OK merci, le pb est simple je voudrais pouvoir executer un script en admin sans qu'il me demande à chaque fois le pwd...
Exécuter le script via un wrapper setuid, ça ne t'irait pas?
Note: le wrapper est généralement nécessaire pour des questions de sécurité. Maintenant, je ne sais pas si les scripts setuid sont secure sous Mac OS X.
Dans l'article <1186738453.627925.241360@x40g2000prg.googlegroups.com>,
unbewust <yvon.thoraval@gmail.com> écrit:
OK merci, le pb est simple je voudrais pouvoir executer un script en
admin sans qu'il me demande à chaque fois le pwd...
Exécuter le script via un wrapper setuid, ça ne t'irait pas?
Note: le wrapper est généralement nécessaire pour des questions de
sécurité. Maintenant, je ne sais pas si les scripts setuid sont secure
sous Mac OS X.
OK merci, le pb est simple je voudrais pouvoir executer un script en admin sans qu'il me demande à chaque fois le pwd...
Exécuter le script via un wrapper setuid, ça ne t'irait pas?
Note: le wrapper est généralement nécessaire pour des questions de sécurité. Maintenant, je ne sais pas si les scripts setuid sont secure sous Mac OS X.
Le 11/08/07 22:48, dans <20070811204225$, « Vincent Lefevre » <vincent+ a écrit :
Dans l'article <C2E0BFA3.AFA3C%, Eric Levenez écrit:
Ah, j'avais pas vu l'option -S. Comme c'est quand même un trou de sécurité, sudo doit se protéger en invalidant les essais de mots de passe si l'on a trop d'erreurs pendant une durée. Enfin je suppose.
Pourquoi un trou de sécurité? Si le but est d'empêcher les essais automatiques et donc d'interdire l'envoi du mot de passe via stdin,
Oui. Un mot de passe devrait passer par un canal sécurisé et pas une simple redirection.
Comme dans l'exemple de l'installeur de Virex, on voit bien que cette méthode de redirection est dangereuse par fournie (parfois) en clair le mot de passe.
alors il faudrait aussi interdire les pseudo-ttys. Et là, tout un tas de programmes risquent de ne plus marcher (à commencer par "screen", je suppose).
Comme à l'origine il n'y avait pas de pseudo-tty, la lecture directe sur /dev/tty empêchait les attaques brutales, maintenant effectivement on peut utiliser les pseudo tty pour faire ce travail.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 11/08/07 22:48, dans <20070811204225$0ba0@prunille.vinc17.org>, « Vincent
Lefevre » <vincent+news@vinc17.org> a écrit :
Dans l'article <C2E0BFA3.AFA3C%news@levenez.com>,
Eric Levenez <news@levenez.com> écrit:
Ah, j'avais pas vu l'option -S. Comme c'est quand même un trou de sécurité,
sudo doit se protéger en invalidant les essais de mots de passe si l'on a
trop d'erreurs pendant une durée. Enfin je suppose.
Pourquoi un trou de sécurité? Si le but est d'empêcher les essais
automatiques et donc d'interdire l'envoi du mot de passe via stdin,
Oui. Un mot de passe devrait passer par un canal sécurisé et pas une simple
redirection.
Comme dans l'exemple de l'installeur de Virex, on voit bien que cette
méthode de redirection est dangereuse par fournie (parfois) en clair le mot
de passe.
alors il faudrait aussi interdire les pseudo-ttys. Et là, tout un
tas de programmes risquent de ne plus marcher (à commencer par
"screen", je suppose).
Comme à l'origine il n'y avait pas de pseudo-tty, la lecture directe sur
/dev/tty empêchait les attaques brutales, maintenant effectivement on peut
utiliser les pseudo tty pour faire ce travail.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 11/08/07 22:48, dans <20070811204225$, « Vincent Lefevre » <vincent+ a écrit :
Dans l'article <C2E0BFA3.AFA3C%, Eric Levenez écrit:
Ah, j'avais pas vu l'option -S. Comme c'est quand même un trou de sécurité, sudo doit se protéger en invalidant les essais de mots de passe si l'on a trop d'erreurs pendant une durée. Enfin je suppose.
Pourquoi un trou de sécurité? Si le but est d'empêcher les essais automatiques et donc d'interdire l'envoi du mot de passe via stdin,
Oui. Un mot de passe devrait passer par un canal sécurisé et pas une simple redirection.
Comme dans l'exemple de l'installeur de Virex, on voit bien que cette méthode de redirection est dangereuse par fournie (parfois) en clair le mot de passe.
alors il faudrait aussi interdire les pseudo-ttys. Et là, tout un tas de programmes risquent de ne plus marcher (à commencer par "screen", je suppose).
Comme à l'origine il n'y avait pas de pseudo-tty, la lecture directe sur /dev/tty empêchait les attaques brutales, maintenant effectivement on peut utiliser les pseudo tty pour faire ce travail.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Eric Levenez
Le 11/08/07 22:52, dans <20070811204946$, « Vincent Lefevre » <vincent+ a écrit :
Maintenant, je ne sais pas si les scripts setuid sont secure sous Mac OS X.
Non on ne peut (heureusement) pas faire un script setuid sur Mac OS X.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 11/08/07 22:52, dans <20070811204946$64bb@prunille.vinc17.org>, « Vincent
Lefevre » <vincent+news@vinc17.org> a écrit :
Maintenant, je ne sais pas si les scripts setuid sont secure
sous Mac OS X.
Non on ne peut (heureusement) pas faire un script setuid sur Mac OS X.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 11/08/07 22:52, dans <20070811204946$, « Vincent Lefevre » <vincent+ a écrit :
Maintenant, je ne sais pas si les scripts setuid sont secure sous Mac OS X.
Non on ne peut (heureusement) pas faire un script setuid sur Mac OS X.
-- É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 <C2E3F01D.AFD43%, Eric Levenez écrit:
Le 11/08/07 22:48, dans <20070811204225$, « Vincent Lefevre » <vincent+ a écrit :
Pourquoi un trou de sécurité? Si le but est d'empêcher les essais automatiques et donc d'interdire l'envoi du mot de passe via stdin,
Oui. Un mot de passe devrait passer par un canal sécurisé et pas une simple redirection.
Un tty n'est pas plus sécurisé qu'un pipe.
Comme dans l'exemple de l'installeur de Virex, on voit bien que cette méthode de redirection est dangereuse par fournie (parfois) en clair le mot de passe.
Là, c'est un autre problème: le trou de sécurité n'est pas le pipe, mais le fait que le mot de passe se trouve en argument.
Dans l'article <C2E3F01D.AFD43%news@levenez.com>,
Eric Levenez <news@levenez.com> écrit:
Le 11/08/07 22:48, dans <20070811204225$0ba0@prunille.vinc17.org>, « Vincent
Lefevre » <vincent+news@vinc17.org> a écrit :
Pourquoi un trou de sécurité? Si le but est d'empêcher les essais
automatiques et donc d'interdire l'envoi du mot de passe via stdin,
Oui. Un mot de passe devrait passer par un canal sécurisé et pas une simple
redirection.
Un tty n'est pas plus sécurisé qu'un pipe.
Comme dans l'exemple de l'installeur de Virex, on voit bien que
cette méthode de redirection est dangereuse par fournie (parfois) en
clair le mot de passe.
Là, c'est un autre problème: le trou de sécurité n'est pas le pipe,
mais le fait que le mot de passe se trouve en argument.
Dans l'article <C2E3F01D.AFD43%, Eric Levenez écrit:
Le 11/08/07 22:48, dans <20070811204225$, « Vincent Lefevre » <vincent+ a écrit :
Pourquoi un trou de sécurité? Si le but est d'empêcher les essais automatiques et donc d'interdire l'envoi du mot de passe via stdin,
Oui. Un mot de passe devrait passer par un canal sécurisé et pas une simple redirection.
Un tty n'est pas plus sécurisé qu'un pipe.
Comme dans l'exemple de l'installeur de Virex, on voit bien que cette méthode de redirection est dangereuse par fournie (parfois) en clair le mot de passe.
Là, c'est un autre problème: le trou de sécurité n'est pas le pipe, mais le fait que le mot de passe se trouve en argument.
Le 12/08/07 2:21, dans <20070812001919$, « Vincent Lefevre » <vincent+ a écrit :
Dans l'article <C2E3F01D.AFD43%, Eric Levenez écrit:
Le 11/08/07 22:48, dans <20070811204225$, « Vincent Lefevre » <vincent+ a écrit :
Pourquoi un trou de sécurité? Si le but est d'empêcher les essais automatiques et donc d'interdire l'envoi du mot de passe via stdin,
Oui. Un mot de passe devrait passer par un canal sécurisé et pas une simple redirection.
Un tty n'est pas plus sécurisé qu'un pipe.
Normalement si, cela a été inventé pour cela justement.
Comme dans l'exemple de l'installeur de Virex, on voit bien que cette méthode de redirection est dangereuse par fournie (parfois) en clair le mot de passe.
Là, c'est un autre problème: le trou de sécurité n'est pas le pipe, mais le fait que le mot de passe se trouve en argument.
Oui, le problème vient d'une "fonctionnalité" mal utilisée.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 12/08/07 2:21, dans <20070812001919$0598@prunille.vinc17.org>, « Vincent
Lefevre » <vincent+news@vinc17.org> a écrit :
Dans l'article <C2E3F01D.AFD43%news@levenez.com>,
Eric Levenez <news@levenez.com> écrit:
Le 11/08/07 22:48, dans <20070811204225$0ba0@prunille.vinc17.org>, « Vincent
Lefevre » <vincent+news@vinc17.org> a écrit :
Pourquoi un trou de sécurité? Si le but est d'empêcher les essais
automatiques et donc d'interdire l'envoi du mot de passe via stdin,
Oui. Un mot de passe devrait passer par un canal sécurisé et pas une simple
redirection.
Un tty n'est pas plus sécurisé qu'un pipe.
Normalement si, cela a été inventé pour cela justement.
Comme dans l'exemple de l'installeur de Virex, on voit bien que
cette méthode de redirection est dangereuse par fournie (parfois) en
clair le mot de passe.
Là, c'est un autre problème: le trou de sécurité n'est pas le pipe,
mais le fait que le mot de passe se trouve en argument.
Oui, le problème vient d'une "fonctionnalité" mal utilisée.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 12/08/07 2:21, dans <20070812001919$, « Vincent Lefevre » <vincent+ a écrit :
Dans l'article <C2E3F01D.AFD43%, Eric Levenez écrit:
Le 11/08/07 22:48, dans <20070811204225$, « Vincent Lefevre » <vincent+ a écrit :
Pourquoi un trou de sécurité? Si le but est d'empêcher les essais automatiques et donc d'interdire l'envoi du mot de passe via stdin,
Oui. Un mot de passe devrait passer par un canal sécurisé et pas une simple redirection.
Un tty n'est pas plus sécurisé qu'un pipe.
Normalement si, cela a été inventé pour cela justement.
Comme dans l'exemple de l'installeur de Virex, on voit bien que cette méthode de redirection est dangereuse par fournie (parfois) en clair le mot de passe.
Là, c'est un autre problème: le trou de sécurité n'est pas le pipe, mais le fait que le mot de passe se trouve en argument.
Oui, le problème vient d'une "fonctionnalité" mal utilisée.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Eric Levenez
Le 12/08/07 2:31, dans <20070812002730$, « Vincent Lefevre » <vincent+ a écrit :
Dans l'article <C2E3F29F.AFD4C%, Eric Levenez écrit:
Le 11/08/07 22:52, dans <20070811204946$, « Vincent Lefevre » <vincent+ a écrit :
Maintenant, je ne sais pas si les scripts setuid sont secure sous Mac OS X.
Non on ne peut (heureusement) pas faire un script setuid sur Mac OS X.
Plutôt malheureusement. Faire des scripts Perl setuid ne pose aucun problème de sécurité sous Linux.
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. Pour éviter d'avoir 36 programmes setuid sur le système, le sudo doit être utilisé.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 12/08/07 2:31, dans <20070812002730$6fe2@prunille.vinc17.org>, « Vincent
Lefevre » <vincent+news@vinc17.org> a écrit :
Dans l'article <C2E3F29F.AFD4C%news@levenez.com>,
Eric Levenez <news@levenez.com> écrit:
Le 11/08/07 22:52, dans <20070811204946$64bb@prunille.vinc17.org>, « Vincent
Lefevre » <vincent+news@vinc17.org> a écrit :
Maintenant, je ne sais pas si les scripts setuid sont secure
sous Mac OS X.
Non on ne peut (heureusement) pas faire un script setuid sur Mac OS X.
Plutôt malheureusement. Faire des scripts Perl setuid ne pose aucun
problème de sécurité sous Linux.
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. Pour éviter d'avoir 36 programmes setuid sur le
système, le sudo doit être utilisé.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 12/08/07 2:31, dans <20070812002730$, « Vincent Lefevre » <vincent+ a écrit :
Dans l'article <C2E3F29F.AFD4C%, Eric Levenez écrit:
Le 11/08/07 22:52, dans <20070811204946$, « Vincent Lefevre » <vincent+ a écrit :
Maintenant, je ne sais pas si les scripts setuid sont secure sous Mac OS X.
Non on ne peut (heureusement) pas faire un script setuid sur Mac OS X.
Plutôt malheureusement. Faire des scripts Perl setuid ne pose aucun problème de sécurité sous Linux.
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. Pour éviter d'avoir 36 programmes setuid sur le système, le sudo doit être utilisé.
-- É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 <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?
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?
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?
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. 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.
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?
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. 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.
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?
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. 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.
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?
