Les grands experts en securite de Debian en prennent pour leur rhume

On Sun, 27 Mar 2005 01:31:34 -0500, GP wrote:

The claim arose because the Debian maintainers wrongly and without proper
regard for security thought it was a good idea to install pppoe setuid-root.
(I believe they have since backed away from this.)

Complètement imprécis : rp-pppoe était setuid root mais exécutable
uniquement par les utilisateurs du groupe dip. Groupe qui est _vide_ par
défaut. Encore du bon GP-FUD.

Sam.
--
Sam Hocevar <sam@zoy.org> <http://sam.zoy.org/>
Software should be free -- http://www.debian.org/
Media access should be free -- http://www.videolan.org/
Knowledge must be free -- http://www.wikipedia.org/

On Sun, 27 Mar 2005 01:31:34 -0500, GP wrote:

The claim arose because the Debian maintainers wrongly and without proper
regard for security thought it was a good idea to install pppoe setuid-root.
(I believe they have since backed away from this.)

Complètement imprécis : rp-pppoe était setuid root mais exécutable
uniquement par les utilisateurs du groupe dip. Groupe qui est _vide_ par
défaut. Encore du bon GP-FUD.

Sam.
--
Sam Hocevar <sam@zoy.org> <http://sam.zoy.org/>
Software should be free -- http://www.debian.org/
Media access should be free -- http://www.videolan.org/
Knowledge must be free -- http://www.wikipedia.org/

Sam Hocevar wrote:

On Sun, 27 Mar 2005 01:31:34 -0500, GP wrote:

The claim arose because the Debian maintainers wrongly and without proper
regard for security thought it was a good idea to install pppoe setuid-root.
(I believe they have since backed away from this.)

Complètement imprécis : rp-pppoe était setuid root mais exécutable
uniquement par les utilisateurs du groupe dip. Groupe qui est _vide_ par
défaut. Encore du bon GP-FUD.

Alors, il n'y avait aucun problème de sécurité? Pourquoi donc avoir fait une
entrée chez Mitre... qui n'a toujours pas été reconnue comme faille de
sécurité depuis juin 2004?

Mais je comprends que Debian ne puisse faire erreur, surtout pas conjointement
avec Mandrake. Alors, c'est à RP qu'il faut écrire, parce que si le FUD vient
de quelque part, c'est bien de là:

«Any Linux distro that installs pppoe setuid root is just plain dangerous.»

http://marc.theaimsgroup.com/?l=bugtraq&m0253341209450&w=2

GP

On 2005-03-27, GP <gilpel@inverse.nretla.org> wrote:

Mais je comprends que Debian ne puisse faire erreur, surtout pas conjointement
avec Mandrake. Alors, c'est à RP qu'il faut écrire, parce que si le FUD vient
de quelque part, c'est bien de là:

«Any Linux distro that installs pppoe setuid root is just plain dangerous.»

Le monsieur y'en a eu dire à toi que Debian par défaut pas avoir
utilisateurs dans groupe qui a droit executer pppoe. Le monsieur y'en a
jamais avoir dit à toi que problème pas exister avec pppoe.
Moi y'en a rajouter que toi pas très malin mais tout le monde y'en a
déjà le savoir.
Toi y'en a avoir compris quand moi y'en a expliquer doucement ?

--
Irvin

On Sun, 27 Mar 2005 13:38:15 -0500, GP wrote:

Complètement imprécis : rp-pppoe était setuid root mais exécutable
uniquement par les utilisateurs du groupe dip. Groupe qui est _vide_ par
défaut. Encore du bon GP-FUD.

Alors, il n'y avait aucun problème de sécurité? Pourquoi donc avoir fait une
entrée chez Mitre... qui n'a toujours pas été reconnue comme faille de
sécurité depuis juin 2004?

Bien sûr qu'il y a un problème de sécurité. Mais rejeter la faute sur
Debian lorsqu'on fait un programme qui nécessite des permissions root
dont on sait très bien que l'utilisateur lambda va vouloir l'utiliser,
c'est un peu gonflé. Certes, un wrapper setuid est une excellente
solution : dans ce cas pourquoi ne pas le fournir avec rp-pppoe ?

Mais je comprends que Debian ne puisse faire erreur, surtout pas
conjointement avec Mandrake. Alors, c'est à RP qu'il faut écrire,
parce que si le FUD vient de quelque part, c'est bien de là:

Comment ça conjointement avec Mandrake ? rp-pppoe n'est pas setuid
root sur une Mandrake. Pourtant ils ont corrigé le problème quand même.

«Any Linux distro that installs pppoe setuid root is just plain dangerous.»

http://marc.theaimsgroup.com/?l=bugtraq&m0253341209450&w=2

Ici "setuid root" est pour "world-executable setuid root". Sur
Debian, ce n'est pas le cas.

Sam.
--
Sam Hocevar <sam@zoy.org> <http://sam.zoy.org/>
Software should be free -- http://www.debian.org/
Media access should be free -- http://www.videolan.org/
Knowledge must be free -- http://www.wikipedia.org/

Irvin Probst wrote:

On 2005-03-27, GP <gilpel@inverse.nretla.org> wrote:

Mais je comprends que Debian ne puisse faire erreur, surtout pas conjointement
avec Mandrake. Alors, c'est à RP qu'il faut écrire, parce que si le FUD vient
de quelque part, c'est bien de là:

«Any Linux distro that installs pppoe setuid root is just plain dangerous.»

Le monsieur y'en a eu dire à toi que Debian par défaut pas avoir
utilisateurs dans groupe qui a droit executer pppoe.

Debian sa manière, mais si pas problème, pourquoi faire jappard chez Mitre?
Wrappers pas pour les chiens! Si crétins Mandrake installer RP-PPPOE SUID, pas
problème Debian, pas problème RP-PPPOE.

Le monsieur y'en a
jamais avoir dit à toi que problème pas exister avec pppoe.

M. RP-PPPOE dire justement ça. Dire Debianiais crétins profonds(1) parce que
aller embêter populace avec faux rapports chez Mitre. Détruire réputation gens
compétents Roaring Penguin qui fournir excellent outil Linux. Moi sais, moi
déjà utilisé RP avec 0 problème Slackware.

(1) Auteurs de Linux Administration Handbook aussi dire ça souvent.

Moi y'en a rajouter que toi pas très malin mais tout le monde y'en a
déjà le savoir.

Moi y en a encore ajouter toi sombre crétin, seulement tarés idiots pas savoir ça.

GP

On 2005-03-27, GP <gilpel@inverse.nretla.org> wrote:

Moi y'en a rajouter que toi pas très malin mais tout le monde y'en a
déjà le savoir.

Moi y en a encore ajouter toi sombre crétin, seulement tarés idiots pas savoir ça.

Les "tarés idiots" se reconnaitront et apprécieront.
Allez hop à la niche, on t'a assez vu pour la journée.

--
Irvin

Sam Hocevar wrote:

On Sun, 27 Mar 2005 13:38:15 -0500, GP wrote:

Complètement imprécis : rp-pppoe était setuid root mais exécutable
uniquement par les utilisateurs du groupe dip. Groupe qui est _vide_ par
défaut. Encore du bon GP-FUD.

Alors, il n'y avait aucun problème de sécurité? Pourquoi donc avoir fait une
entrée chez Mitre... qui n'a toujours pas été reconnue comme faille de
sécurité depuis juin 2004?

Bien sûr qu'il y a un problème de sécurité.

Il n'y en avait pas pour le .deb de Debian, à ce que je comprends. Pourtant,
c'est Debian qui se plaint de problèmes qui pourraient survenir si d'autres
distributions commettaient des imbécilités!

Mais rejeter la faute sur
Debian lorsqu'on fait un programme qui nécessite des permissions root
dont on sait très bien que l'utilisateur lambda va vouloir l'utiliser,
c'est un peu gonflé. Certes, un wrapper setuid est une excellente
solution : dans ce cas pourquoi ne pas le fournir avec rp-pppoe ?

Je ne sais pas quelle solution RP adopte. J'ai utilisé RP quelques mois il y a
deux ans et demi. Si je me souviens bien, je n'avais pas utilisé la version
qui vient avec Slackware parce qu'il y en avait une plus récente sur le site
de RP. J'ai lu la doc, j'ai fait l'installation tel que prescrit. Je n'ai pas
fait de SUID -- à l'époque, c'est à peine si je savais ce que c'était -- et
ç'a très bien fonctionné.

Alors, si je comprends bien ton point de vue, c'est qu'alors que RP reproche
aux distros imbéciles de faire une installation SUID, c'est exactement le
genre d'installation que RP faisait par défaut? Et Slackware, qui utilisait
RP, n'a jamais noté de problème?

J'ai désinstallé RP et je n'ai pas vraiment envie de jouer à réinstaller mais,
si tu veux, je peux envoyer un résumé de ce que tu me dis ici avec ton email
en spécifiant bien que tu es un développeur Debian et on va voir ce que RP en
dit. Ça te va?

Non, mieux! Je te laisse confondre le pauvre imbécile :)

Mais je comprends que Debian ne puisse faire erreur, surtout pas
conjointement avec Mandrake. Alors, c'est à RP qu'il faut écrire,
parce que si le FUD vient de quelque part, c'est bien de là:

Comment ça conjointement avec Mandrake ?

Mandrake a ajouté son nom au CVE. Pas Suse, pas Red Hat, pas Slackware.
Seulement Debian et Mandrake.

GP

On Sun, 27 Mar 2005 17:15:26 -0500, GP wrote:

Mais rejeter la faute sur
Debian lorsqu'on fait un programme qui nécessite des permissions root
dont on sait très bien que l'utilisateur lambda va vouloir l'utiliser,
c'est un peu gonflé. Certes, un wrapper setuid est une excellente
solution : dans ce cas pourquoi ne pas le fournir avec rp-pppoe ?

[...]

Alors, si je comprends bien ton point de vue, c'est qu'alors que RP reproche
aux distros imbéciles de faire une installation SUID, c'est exactement le
genre d'installation que RP faisait par défaut? Et Slackware, qui utilisait
RP, n'a jamais noté de problème?

Je n'ai jamais dit cela. Seule une déformation irréversible de
l'encéphale permet d'aboutir à de telles conclusions. Une *installation*
setuid ne signifie pas que le binaire puisse tourner setuid. Il suffit
de lire le security advisory avec ses deux yeux :

| When the program is running setuid root (which is not the case in a
| default Debian installation) [...]

J'ai désinstallé RP et je n'ai pas vraiment envie de jouer à
réinstaller mais, si tu veux, je peux envoyer un résumé de ce que tu
me dis ici avec ton email en spécifiant bien que tu es un développeur
Debian et on va voir ce que RP en dit. Ça te va?

Que *TU* écrives un résumé de ce que je dis ici ? Si tu as aussi bien
compris ce que je dis que ce que tu laisses entendre, c'est complètement
hors de question.

Non, mieux! Je te laisse confondre le pauvre imbécile :)

Le pauvre imbécile tout le monde le connait déjà.

La méthode du wrapper n'est pas pérenne si celui-ci n'est pas fourni
par le mainteneur upstream. Un tel wrapper a deux fonctionnement
possibles : un stupide (avoir une liste des options de ligne de commande
potentiellement dangereux et ne pas les faire passer au binaire
principal) et un moins stupide (avoir une liste des options saines
et n'autoriser que celles-ci). En cas de mise à jour de rp-pppoe, la
méthode stupide expose au risque de nouvelles options dangereuses, et
la moins stupide fait courir le risque de ne pas supporter de nouvelles
options.

Le wrapper fourni par rp-pppoe est un peu une plaisanterie, il
n'autorise que trois réglages (start/stop/status) et ne permet aucun
réglage fin.

Comment ça conjointement avec Mandrake ?

Mandrake a ajouté son nom au CVE. Pas Suse, pas Red Hat, pas Slackware.
Seulement Debian et Mandrake.

Pas Red Hat ? Pourquoi ils corrigent alors ?

http://www.redhat.com/archives/fedora-legacy-list/2005-February/msg00089.html

Sam.
--
Sam Hocevar <sam@zoy.org> <http://sam.zoy.org/>
Software should be free -- http://www.debian.org/
Media access should be free -- http://www.videolan.org/
Knowledge must be free -- http://www.wikipedia.org/

Sam Hocevar wrote:

Le wrapper fourni par rp-pppoe est un peu une plaisanterie, il
n'autorise que trois réglages (start/stop/status) et ne permet aucun
réglage fin.

Ah! Mine de rien, on vient tout de même de gagner quelque chose ici: il y a
effectivement un wrapper! Alors, voyons quel incroyable danger «l'utilisateur
lambda» pouvait courir à faire des «réglages fins». Quels réglages fins?
Changer le MaxMTU à chaque fois qu'il connecte? Qui fait ça? Alterner entre
deux fournisseurs? Il n'y aurait qu'à créer deux fichiers de config.

Mais admettons que lambda ait des réglages fins à faire...

Au lieu de les faire à partir du wrapper, il faudrait qu'il détruise celui-ci
et mette l'exécutable SUID root world execurable -- un concept qu'il ne
connaît absolument pas, mais admettons -- pour passer toutes les options en
ligne de commande à chaque connexion!

On voit tout de suite combien la chose semble probable et quel incroyable
danger courait l'ordi de lambda advenant qu'une entrée n'ait pas été faite
dans le CVE par les dévoués experts en sécurité de Debian!

N'empêche, j'ai maintenant la réponse à la question que je posais il y a
quelques temps. Je sais maintenant pourquoi The Man Volkerding se fout comme
de l'an 40 de la majorité des patches de sécurité des /experts/ de Debian.

Qu'on imagine maintenant, parmi les soi-disant 900 développeurs de Debian, 800
jappards du type Hocevar qui, même devant l'évidence, refusent de lâcher le
morceau, et on comprend tout de suite pourquoi il faudra 3 ans pour sortir une
nouvelle version!

Comment ça conjointement avec Mandrake ?

Mandrake a ajouté son nom au CVE. Pas Suse, pas Red Hat, pas Slackware.
Seulement Debian et Mandrake.

Pas Red Hat ? Pourquoi ils corrigent alors ?

http://www.redhat.com/archives/fedora-legacy-list/2005-February/msg00089.html

Ils corrigent? Pourquoi ne cites-tu pas le texte pertinent?

This update can be downloaded from: http://download.fedoralegacy.org/

redhat/7.3/updates-testing/i386/rp-pppoe-3.3-10.legacy.i386.rpm
redhat/7.3/updates-testing/SRPMS/rp-pppoe-3.3-10.legacy.src.rpm
redhat/9/updates-testing/i386/rp-pppoe-3.5-2.2.legacy.i386.rpm
fedora/1/updates-testing/i386/rp-pppoe-3.5-8.2.legacy.i386.rpm
fedora/1/updates-testing/SRPMS/rp-pppoe-3.5-8.2.legacy.src.rpm

Tu ne vois pas «updates-testing» partout? On a un bon exemple ici de toute la
merde qu'on fout là-dedans! Un autre répertoire dont The Man n'a pas besoin.
Il lit le CVE, quand il arrive à ce genre de débilité profonde, il dit:
«Suivant, next!» L'affaire est réglée en 15 secondes.

Debian, ce doit vraiment être la joie avec des jappards dans ton genre, Hoce.

GP