> Il y a toujours eu moyen de faire un "Enable module support? No", ça coute pas cher
Ça peut couter cher :
- Généralement tu n'as pas de support pour un noyau compilé à la main et les noyaux supportés ont le support des modules.
- Tout les admins ne savent pas compiler un noyau. C'est beaucoup de compétence pour ne pas avoir de support des modules. Imagine le "bordel" s'il y a une mise à jour et que le spécial "noyau" n'est pas là.
- Les modules offrent des possibilités de paramétrage que n'a pas un noyau complet.
- il y a des drivers fourni packager sous forme de module et très rarement sous forme d'un noyau complet.
Ce ne serait pas la première fois que microsoft reprend du code sous licence BSD. Par contre MS fait la "guerre" à la licence GPL puisqu'il ne peuvent pas repiquer le code.
J'ai pas compris ta réponse car tu parles de l'installeur et dit qu'urpmi vérifie les signatures. Or urpmi n'est pas utilisé à l'installation. De plus tu dis qu'urpmi vérifie les signature et en même temps tu dis :
- "Le rpm --checksig, ça devrait être fait systématiquement."
Pourquoi tu dis ça puisque qu'urpmi le fait ? De plus rpm n'interdit pas l'installation d'un paquet non signé ou à la signature non confirmée et il n'y a pas d'option dans les fichiers de configuration de rpm pour imposer une signature valide (ce que je regrète).
Désolé si j'ai pas compris que Mandrake impose une bonne signature des paquets. C'était pas évident.
> Le rpm --checksig, ça devrait être fait systématiquement.
Oui. Mais pour le faire, il faut importer la clée.
> Dans ce cas, il faut forcément que les clefs MandrakeSoft official keys, et Linux Mandrake Security Team soient importées dès l'installation, sinon comment tu installes les logiciels ?
Le problème n'est pas là. Je peut créer une clée avec le nom "Linux Mandrake Security Team", faire des paquets signés, presser un CD et te le donner en disant que c'est Mandrake. Toi tu installes la distribution, vérifies les paquets avec rpm --checksig et tu n'y vois que du feu (du moins dans un premier temps). Donc l'utilisateur doit toujours contrôler la clée avant de l'importer/utiliser. Sinon la présence de la clée n'a aucune signification puisque je peux usurper l'identité de Mandrake.
> Tandis que si quelqu'un installe un rootkit grace a un module, bah la je le sais pas.
Il y a maintenant une options (je n'ai pas la référence en tête) qui permet d'indiquer que le noyau ne doit plus charger de modules même si tu fais un "echo /sbin/modprobe > /proc/sys/kernel/modprobe". Je ne sais pas si c'est actuellement dans le 2.4 mais c'est dans le 2.6. Dans ce cas les seules possibilités est d'installer un nouveau noyau. Si le pirate a obtenu un accès root, il doit pouvoir, assez facilement, faire planter la bécane en trifouillant /proc/sys. L'admin aura l'impression que sa bécane a planté et ne pensera pas que c'est une attaque. Il est possible de virer le paramétrage du noyau via /proc/sys.
Ce que je veux dire "in fine", c'est que l'inhibition des modules n'est pas l'arme absolue. C'est par rapport à Christophe Baegert qui "claironne" :-) qu'il a évité les attaques car il n'a pas de modules. Je ne crois pas que c'est aussi simple. D'ailleur rien ne dit que ftp.gnu.org avait le support des modules ...
> comment on fait pour savoir quand quelqu'un obtient l'uid 0 grace a un exploit (le genre de truc qui apparait pas dans les logs auth)
Si c'est un exploit (pas via su etc), j'en sais rien.
Puisque que tu sembles avoir une Mandrake, tu peux peut-être me renseigner.
Il me sembre que Beurt dit que sous Mandrake la clef est déjà importée dans rpm. Peux-tu me confirmer ça ?
C'est en "infraction" avec les recommentations de gnupg qui recommande de valider une clef avant utilisation. Via des amis ou un serveur de clef pour ceux qui n'ont pas d'amis :-)
Je vois bien l'intérêt. Mais par principe, je préfère en premier faire en sorte de ne pas avoir de faille que de rendre la vie du pirate plus difficile une fois qu'il est loggué. Parce qu'une fois qu'il est root les possibilités sont presque infinies. Et s'il y a pas de module, il a vite fait d'installer un nouveau noyau et toujours sans module.
C'est surtout pour se rapprocher de la communauté des développeurs. Rien indique que c'est pour faire une distribution plus "user-friendly". Actuellement elle sera plus "user-friendly" comme chaque nouvelle release est plus "user-friendly". Mais comme c'est maintenant un projet plus ouvert, rien n'est garantit. Si tu fais un tour sur mailling list, pour le "user-friendly" le desktop, RedHat estime que ces questions doivent être directement discuté au niveau de Gnome/Kde. Et si tu lis la mailing-list, actuellement les points chauds sont :
- support yum/apt. Il y a une nouvelle version d'up2date qui support les dépôts répertoire, yum, apt et rhn (et tu peux tout mélanger si tu veux).
- Avoir un noyau UML pour faire une installation sans rebooter.
- Et principalement les objectifs/status du projet. Les choses sont flous car le site dédié est fermé ( http://rhn.redhat.com/(...) ) . RedHat a pris la décision de fermer le site car il y était trop orienté développeur et que certains visiteurs ont mal interprété les objectifs du projet (certains commentaires sur slashdot n'étaient pas tendres). La question de la coordination avec les projets externes est aussi "chaude". Le site est fermé depuis longtemps car beaucoup d'employés redhat sont dispersés un peu partout (principalement linuxword). Le rétablissement de ce site est l'objectif principalement actuellement. Après la sortie de RH10, le remanie du site est a nouveau prévus et sera encore la priorité N°1.
Bref, peut de choses relatives au "user-friendly". Ah oui, un truc, gnome 2.4 sera fournit et non gnome 2.2 comme initialement prévus. Celà repousse la sortie d'une quinzaine de jour (sortie mi octobre donc).
Pour installer un rootkit, il faut déjà être root.
Et que je sache, modprobe n'a pas été la seule faille de sécurité sous Linux. De plus c'est faille est vieille (+ un an il me semble). Donc actuellement ça ne marche pas. Tu vas me dire que c'est un risque potentiel. Dans ce cas, désactives tout. Mieux, coupes le courrant.
Faut être un minimum honnète. L'équipe de test n'a pas le dernier mot. Sinon comment tu m'expliques que certain produits sont sortis avec des trous de sécurité béant ? Heureusement, c'est moins le cas maintenant.
Tu vas me dire que l'équipe de test est nulle ?
Ben je suis convaincu que la RH 10 va sortir avec au moins un de ces bugs non fixé.
Et c'est pas le peine de dire que RedHat c'est naze car tout le monde fait comme ça.
> Pour Windows, le manager direct d'un testeur(donc niveau 2 sur l'echelle) peur retarder la sortie de l'OS si il considere que le composant dont il s'occupe ne correspond pas aux criteres, il debarque au meeting, explique pourquoi et si ca tient debout, l'OS est retarde.
Mais c'est pas lui qui prend la décision...
M'enfin, les dev d'MS ne sont pas plus manche que les autres.
MS maintenant m'impressionne moins maintenant car c'est une ENORME machine. Mais dans le début des années 90 où ils ont tombés MS-Office, winNT, win95, MS était vraiment impressionnant. Et les devs devaient travailler comme des oufs.
> Si la machine du developeur est compromise gnupg ne te garantie rien du tout !
Si. Car pour signer un fichier il faut taper un mot de passe. Si le mot de passe est sur un postit scotché sur l'écran... En fait, à chaque foi que tu veux accéder à la clef privée, il faut le mot de passe.
> First off, I'd suggest printing out a copy of the GNU coding standards, and NOT read it. Burn them
Je suis bien d'accord. La lecteur des codes qui suivent la convention GNU est "pénible". Entre autre, l'indentation mini est sans intérêt à notre époque.
À ma connaissance, le bug ptrace n'a pas besoin du support de module.
Le problème lié à modprobe est déjà assez vieux.
Tu peux booter ton système, charger les modules dont tu as besoin puis interdire le chargement de module (faire un echo "" > /proc/sys/kernel/modprobe )
Gnupg te "garanti" la provenance du paquet. Gnupg ne garantit pas la qualité du paquet. Je peux faire une grosse merde avec un virus dedans et signer le paquet. Mais si je signes le paquet, je suis très rapidement découvert si ma cléf a été validée comme digne de confiance par d'autres.
[^] # Re: ftp.gnu.org compromis
Posté par ptit_tux . En réponse à la dépêche ftp.gnu.org compromis. Évalué à -1.
Ça peut couter cher :
- Généralement tu n'as pas de support pour un noyau compilé à la main et les noyaux supportés ont le support des modules.
- Tout les admins ne savent pas compiler un noyau. C'est beaucoup de compétence pour ne pas avoir de support des modules. Imagine le "bordel" s'il y a une mise à jour et que le spécial "noyau" n'est pas là.
- Les modules offrent des possibilités de paramétrage que n'a pas un noyau complet.
- il y a des drivers fourni packager sous forme de module et très rarement sous forme d'un noyau complet.
[^] # Re: ftp.gnu.org piraté
Posté par ptit_tux . En réponse à la dépêche ftp.gnu.org compromis. Évalué à 1.
[^] # Re: les clés, c'est compliqué !
Posté par ptit_tux . En réponse à la dépêche ftp.gnu.org compromis. Évalué à 0.
J'ai pas compris ta réponse car tu parles de l'installeur et dit qu'urpmi vérifie les signatures. Or urpmi n'est pas utilisé à l'installation. De plus tu dis qu'urpmi vérifie les signature et en même temps tu dis :
- "Le rpm --checksig, ça devrait être fait systématiquement."
Pourquoi tu dis ça puisque qu'urpmi le fait ? De plus rpm n'interdit pas l'installation d'un paquet non signé ou à la signature non confirmée et il n'y a pas d'option dans les fichiers de configuration de rpm pour imposer une signature valide (ce que je regrète).
Désolé si j'ai pas compris que Mandrake impose une bonne signature des paquets. C'était pas évident.
[^] # Re: les clés, c'est compliqué !
Posté par ptit_tux . En réponse à la dépêche ftp.gnu.org compromis. Évalué à 1.
Là tu reportes ta confiance sur le revendure et non sur la clef que tu devrais vérifier.
> alosr y'a un moyen pas trop mal pour considerer la clef comme valide
Dump la clef de la base rpm :
rpm -q -i gpg-pubkey-* et compare avec la clef récupérée d'un serveur de clef.
[^] # Re: les clés, c'est compliqué !
Posté par ptit_tux . En réponse à la dépêche ftp.gnu.org compromis. Évalué à 1.
> Le rpm --checksig, ça devrait être fait systématiquement.
Oui. Mais pour le faire, il faut importer la clée.
> Dans ce cas, il faut forcément que les clefs MandrakeSoft official keys, et Linux Mandrake Security Team soient importées dès l'installation, sinon comment tu installes les logiciels ?
Le problème n'est pas là. Je peut créer une clée avec le nom "Linux Mandrake Security Team", faire des paquets signés, presser un CD et te le donner en disant que c'est Mandrake. Toi tu installes la distribution, vérifies les paquets avec rpm --checksig et tu n'y vois que du feu (du moins dans un premier temps). Donc l'utilisateur doit toujours contrôler la clée avant de l'importer/utiliser. Sinon la présence de la clée n'a aucune signification puisque je peux usurper l'identité de Mandrake.
[^] # Re: ftp.gnu.org compromis
Posté par ptit_tux . En réponse à la dépêche ftp.gnu.org compromis. Évalué à 3.
On est d'accord, pas de problème là dessus.
> Tandis que si quelqu'un installe un rootkit grace a un module, bah la je le sais pas.
Il y a maintenant une options (je n'ai pas la référence en tête) qui permet d'indiquer que le noyau ne doit plus charger de modules même si tu fais un "echo /sbin/modprobe > /proc/sys/kernel/modprobe". Je ne sais pas si c'est actuellement dans le 2.4 mais c'est dans le 2.6. Dans ce cas les seules possibilités est d'installer un nouveau noyau. Si le pirate a obtenu un accès root, il doit pouvoir, assez facilement, faire planter la bécane en trifouillant /proc/sys. L'admin aura l'impression que sa bécane a planté et ne pensera pas que c'est une attaque. Il est possible de virer le paramétrage du noyau via /proc/sys.
Ce que je veux dire "in fine", c'est que l'inhibition des modules n'est pas l'arme absolue. C'est par rapport à Christophe Baegert qui "claironne" :-) qu'il a évité les attaques car il n'a pas de modules. Je ne crois pas que c'est aussi simple. D'ailleur rien ne dit que ftp.gnu.org avait le support des modules ...
> comment on fait pour savoir quand quelqu'un obtient l'uid 0 grace a un exploit (le genre de truc qui apparait pas dans les logs auth)
Si c'est un exploit (pas via su etc), j'en sais rien.
[^] # Re: les clés, c'est compliqué !
Posté par ptit_tux . En réponse à la dépêche ftp.gnu.org compromis. Évalué à 1.
Il me sembre que Beurt dit que sous Mandrake la clef est déjà importée dans rpm. Peux-tu me confirmer ça ?
C'est en "infraction" avec les recommentations de gnupg qui recommande de valider une clef avant utilisation. Via des amis ou un serveur de clef pour ceux qui n'ont pas d'amis :-)
[^] # Re: ftp.gnu.org compromis
Posté par ptit_tux . En réponse à la dépêche ftp.gnu.org compromis. Évalué à -1.
Pourquoi ? Si /proc est monté, tu as toutes les infos nécessaires pour faire un noyau proche de l'original.
> On doit encore rebooter pour installer un noyaux si je ne m'abuse
C'est pertinant.
[^] # Re: ftp.gnu.org compromis
Posté par ptit_tux . En réponse à la dépêche ftp.gnu.org compromis. Évalué à -1.
[^] # Re: ftp.gnu.org compromis
Posté par ptit_tux . En réponse à la dépêche ftp.gnu.org compromis. Évalué à -3.
Oui.
Je sais pas pourquoi mais j'adore répondre ça. C'est plus fort que moi.
Sinon, tu le fais expres aussi ?
[^] # Re: Debian a 10 ans !
Posté par ptit_tux . En réponse à la dépêche Debian a 10 ans !. Évalué à 1.
C'est surtout pour se rapprocher de la communauté des développeurs. Rien indique que c'est pour faire une distribution plus "user-friendly". Actuellement elle sera plus "user-friendly" comme chaque nouvelle release est plus "user-friendly". Mais comme c'est maintenant un projet plus ouvert, rien n'est garantit. Si tu fais un tour sur mailling list, pour le "user-friendly" le desktop, RedHat estime que ces questions doivent être directement discuté au niveau de Gnome/Kde. Et si tu lis la mailing-list, actuellement les points chauds sont :
- support yum/apt. Il y a une nouvelle version d'up2date qui support les dépôts répertoire, yum, apt et rhn (et tu peux tout mélanger si tu veux).
- Avoir un noyau UML pour faire une installation sans rebooter.
- Et principalement les objectifs/status du projet. Les choses sont flous car le site dédié est fermé ( http://rhn.redhat.com/(...) ) . RedHat a pris la décision de fermer le site car il y était trop orienté développeur et que certains visiteurs ont mal interprété les objectifs du projet (certains commentaires sur slashdot n'étaient pas tendres). La question de la coordination avec les projets externes est aussi "chaude". Le site est fermé depuis longtemps car beaucoup d'employés redhat sont dispersés un peu partout (principalement linuxword). Le rétablissement de ce site est l'objectif principalement actuellement. Après la sortie de RH10, le remanie du site est a nouveau prévus et sera encore la priorité N°1.
Bref, peut de choses relatives au "user-friendly". Ah oui, un truc, gnome 2.4 sera fournit et non gnome 2.2 comme initialement prévus. Celà repousse la sortie d'une quinzaine de jour (sortie mi octobre donc).
[^] # Re: ftp.gnu.org compromis
Posté par ptit_tux . En réponse à la dépêche ftp.gnu.org compromis. Évalué à -2.
Pour installer un rootkit, il faut déjà être root.
Et que je sache, modprobe n'a pas été la seule faille de sécurité sous Linux. De plus c'est faille est vieille (+ un an il me semble). Donc actuellement ça ne marche pas. Tu vas me dire que c'est un risque potentiel. Dans ce cas, désactives tout. Mieux, coupes le courrant.
[^] # Re: ftp.gnu.org piraté
Posté par ptit_tux . En réponse à la dépêche ftp.gnu.org compromis. Évalué à -1.
Faut être un minimum honnète. L'équipe de test n'a pas le dernier mot. Sinon comment tu m'expliques que certain produits sont sortis avec des trous de sécurité béant ? Heureusement, c'est moins le cas maintenant.
Tu vas me dire que l'équipe de test est nulle ?
Il y a un rapport de bug dans RedHat pour donner la liste des bugs qui bloque la sortie d'une distribution :
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=100643(...)
Ben je suis convaincu que la RH 10 va sortir avec au moins un de ces bugs non fixé.
Et c'est pas le peine de dire que RedHat c'est naze car tout le monde fait comme ça.
[^] # Re: ftp.gnu.org piraté
Posté par ptit_tux . En réponse à la dépêche ftp.gnu.org compromis. Évalué à -3.
Ou il fixe une caméra au dessus du clavier. Ou il kidnappe la fille du développeur pour qu'il avouer le mot de passe, ou ...
C'est bon, je crois qu'on a compris.
[^] # Re: ftp.gnu.org compromis
Posté par ptit_tux . En réponse à la dépêche ftp.gnu.org compromis. Évalué à -1.
T'es sérieux ?
S'il a trouvé un moyen pour être root, pourquoi veux-tu qu'il active modprobe. Pour se logguer une seconde fois sous root ?
[^] # Re: ftp.gnu.org piraté
Posté par ptit_tux . En réponse à la dépêche ftp.gnu.org compromis. Évalué à 1.
Mais c'est pas lui qui prend la décision...
M'enfin, les dev d'MS ne sont pas plus manche que les autres.
MS maintenant m'impressionne moins maintenant car c'est une ENORME machine. Mais dans le début des années 90 où ils ont tombés MS-Office, winNT, win95, MS était vraiment impressionnant. Et les devs devaient travailler comme des oufs.
[^] # Re: ftp.gnu.org piraté
Posté par ptit_tux . En réponse à la dépêche ftp.gnu.org compromis. Évalué à -1.
Si. Car pour signer un fichier il faut taper un mot de passe. Si le mot de passe est sur un postit scotché sur l'écran... En fait, à chaque foi que tu veux accéder à la clef privée, il faut le mot de passe.
[^] # Re: ftp.gnu.org piraté
Posté par ptit_tux . En réponse à la dépêche ftp.gnu.org compromis. Évalué à 2.
Je suis bien d'accord. La lecteur des codes qui suivent la convention GNU est "pénible". Entre autre, l'indentation mini est sans intérêt à notre époque.
[^] # Re: ftp.gnu.org piraté
Posté par ptit_tux . En réponse à la dépêche ftp.gnu.org compromis. Évalué à -3.
Le père de Linus ou de Linux ?
[^] # Re: ftp.gnu.org compromis
Posté par ptit_tux . En réponse à la dépêche ftp.gnu.org compromis. Évalué à 0.
À ma connaissance, le bug ptrace n'a pas besoin du support de module.
Le problème lié à modprobe est déjà assez vieux.
Tu peux booter ton système, charger les modules dont tu as besoin puis interdire le chargement de module (faire un echo "" > /proc/sys/kernel/modprobe )
[^] # Re: Debian a 10 ans !
Posté par ptit_tux . En réponse à la dépêche Debian a 10 ans !. Évalué à 1.
[^] # Re: ftp.gnu.org compromis
Posté par ptit_tux . En réponse à la dépêche ftp.gnu.org compromis. Évalué à 1.
[^] # Re: ftp.gnu.org piraté
Posté par ptit_tux . En réponse à la dépêche ftp.gnu.org compromis. Évalué à 0.
# Re: Initiation à (GNU)/Linux
Posté par ptit_tux . En réponse au journal Initiation à (GNU)/Linux. Évalué à 3.
Pour ma part je trouve la doc RedHat très bonne.
Par exemple le chapitre sur le swap :
http://europe.redhat.com/documentation/rhl9/rhl-cg-fr-9/ch-swapspac(...)
C'est spécifique RedHat, mais si on connait une redhat on peut utiliser n'importe quelles distributions rpm-based (et vice-versa).
Toute la doc est ici :
http://europe.redhat.com/documentation/(...)
C'est sous licence opencontent :
http://www.opencontent.org/(...)
[^] # Re: ftp.gnu.org piraté
Posté par ptit_tux . En réponse à la dépêche ftp.gnu.org compromis. Évalué à 2.
Les clefs sont signés par d'autres personnes. Ça forme une chaine de confiance.
C'est l'un des buts des serveurs de clef. Par exemple :
http://www.keyserver.net/en/(...)
Fait une recherche sur "linux kernel archive". Tu trouveras la signature de kernel.org signée par d'autres personnes.