Le 14 août les administrateurs des serveurs de Fedora ont envoyé un message indiquant qu'ils avaient détecté un problème sérieux et qu'ils étaient en cours d'investigation à ce sujet : http://lwn.net/Articles/294188/
Dans l'intervalle ils conseillaient de ne pas télécharger le moindre paquet : "as a precaution, we recommend you not download or update any additional packages on your Fedora systems".
Evidemment une telle annonce fait immédiatement penser à un grave problème de sécurité et les utilisateurs de Fedora se sont senti inquiets. L'attente a donc commencé pour avoir des détails sur ce problème.
Le 16 août nouveau mail de Fedora indiquant que les administrateurs étaient toujours au travail et demandant aux utilisateurs de prendre leur mal en patience : http://lwn.net/Articles/294324/
"The Fedora Infrastructure team continues to work on the issues we discovered earlier this week (...) Please be patient as we continue to work the problem".
A partir de là les spéculations les plus folles ont commencé à courir. Si cela prenait autant de temps c'est qu'il s'agissait vraisemblablement d'un souci très grave et le pire était à envisager. L'exaspération a commencé à monter chez certains utilisateurs qui voulaient avoir plus d'informations pour évaluer la vulnérabilité de leurs systèmes. Le fait de savoir qu'une grosse merde à du arriver et de ne pas avoir le moindre détail à ce sujet est particulièrement frustrant.
Le 19 août encore un mail des admins de Fedora : http://lwn.net/Articles/294547/
Toujours pas le moindre détail et le "conseil" de ne pas télécharger de paquets est toujours valable.
Le mail demande à la communauté des utilisateurs d'attendre que tout soit revenu à la normale : "Please give the infrastructure team the time they need to do this demanding work (...) We know the community is awaiting more detail on the past week's activities and their causes. We're preparing a timeline and details and will make them available in the near future. We appreciate the community's patience, and will continue to post updates to the fedora-announce-list as soon as possible".
Les commentaires continuent de fuser au sujet de la probable compromission des serveurs. Si les admins mettent autant de temps c'est que la faille doit être importante. Est-ce spécifique à Fedora ou est-ce que les autres distributions sont touchées ? Des paquets trojanés ont-ils été distribués par un pirate ? Peut-être est-ce juste un problème matériel sur les serveurs et pas une brèche de sécurité ? Ou alors une invasion d'extra-terrestres ?
Enfin le 22 août un mail sur la liste de diffusion Fedora-annonce donne les détails et met fin à cette interminable attente : http://lwn.net/Articles/295134/
Une intrusion a bien eu lieu sur les serveurs de Fedora et aussi sur ceux de Red Hat !
Le pirate a pu signer des paquets et Red Hat a sorti un bulletin d'alerte de niveau "Critical" : http://rhn.redhat.com/errata/RHSA-2008-0855.html
Dans cette alerte on lit la phrase suivante qui fait froid dans le dos : "In connection with the incident, the intruder was able to sign a small number of OpenSSH packages".
Il semble toutefois que ces paquets ont seulement pu être signés mais n'ont pas été distribués aux utilisateurs du canal de distribution officiel Red Hat.
En ce qui concerne Fedora l'un des serveurs compromis contenait la clé de signature des paquets de la distributions mais les investigations n'ont pas pu mettre en évidence de compromission de cette clé de signature : "we have high confidence that the intruder was not able to capture the passphrase used to secure the Fedora package signing key".
Par mesure de sécurité la clé a été changée et les paquets ont été vérifiés sans que le moindre cheval de Troie ne soit détecté. Les utilisateurs peuvent maintenant reprendre leurs mises à jour et leurs téléchargements : "At this time we are confident there is little risk to Fedora users who wish to install or upgrade signed Fedora packages".
Bien entendu CentOS, qui est basé sur Red Hat, a investigué de son coté : http://lwn.net/Articles/295221/
D'après les administrateurs il n'y a pas eu de problème : "We can now assure everyone that no compromise has taken place anywhere within the CentOS infrastructure".
Donc au bilan qu'avons nous ?
1) Une intrusion sur les serveurs de Fedora et Red Hat. C'est horriblement inquiétant et il faut absolument savoir comment cela a pu se produire. Pour l'instant aucune info n'est disponible à ce sujet. Est-ce une erreur humaine ou une faille technique ? Si c'est un bug est-il générique à Linux ou spécifique aux serveurs compromis ?
2) Le pirate a réussi a signer le paquet OpenSSH de Red Hat mais, à priori, il n'a rien pu faire de plus. Ni compromettre le paquet, ni le distribuer. A noter que cette absence de distribution ne vaut que pour le canal officiel Red Hat et pas pour des dépôts tiers. Il faudra là aussi attendre pour avoir plus de détails.
3) La rétention de l'information a été parfaite de la part de Fedora/Red Hat. Aucune info n'a fuité avant l'annonce officielle et les admins de la distribution ont pu enquêter sans qu'il y ait une folie médiatique autour d'eux. La contrepartie étant le bouillonnement des spéculations pendant plus d'une semaine et l'incertitude des utilisateurs sur la sécurité de leurs systèmes.
Au final je pense que cette chaude alerte pourrait être bénéfique dans la mesure ou elle incitera sans doute les distributions Linux à renforcer leurs mesures de sécurité. La facilité d'installation des logiciels sous Linux, du fait de l'existence des dépôts centralisés, à une contrepartie : Les serveurs hébergeant ces dépôts doivent être des forteresses !
Journal Intrusion sur les serveurs Fedora/Red Hat
23
août
2008
# Diversité, diversité :)
Posté par Benjamin (site web personnel) . Évalué à 4.
À nouveau, on voit que la diversité des distributions et des canaux permet d'assurer une sécurité généraliste, qui évite les failles à la Microsoft ou 90% du parc mondial est concerné d'un coup ...
N'ayant aucune RedHat/Fedora dans mon parc, me voilà rassuré.
Par contre je pense à une chose : la sécurité de ces dépôts reste, elle, bel et bien centralisée.
Ne serait-il pas une bonne idée de confier une verification tierce de signatures à un tiers indépendant des distribution, genre X s'occupe de vérifier que chaque changement de signature d'un package de la distribution Y est bien issu du processus industriel de validation, et pas d'un changement sauvage sur les serveurs. X peut alors publier une liste (signée par X) des signatures des packages ayant suivi proprement ce processus industriel (sur Debian, le processus prenant du temps (unstable > testing typiquement) cela peut se vérifier assez facilement, je ne sais pas comment on pourrait faire sur les autres distribs.)
[^] # Re: Diversité, diversité :)
Posté par IsNotGood . Évalué à 0.
Mouaif. Vu le faible niveau d'information donné par Fedora/Red Hat, ont peut aussi penser que c'est un problème upstream (période d'embargo). Et dans ce cas tu es aussi en "danger".
> Par contre je pense à une chose : la sécurité de ces dépôts reste, elle, bel et bien centralisée.
La signature est (forcément) centralisée.
> Ne serait-il pas une bonne idée de confier une verification tierce de signatures à un tiers indépendant des distribution,
Ça n'a pas d'intérêt. C'est la distribution qui connait les paquets.
> genre X s'occupe de vérifier que chaque changement de signature d'un package de la distribution.
Il n'y a pas eu de changement de signature, il y a eu abus de l'infrastructure pour signer les paquets avec la signature de Fedora / Red Hat.
[^] # Re: Diversité, diversité :)
Posté par Benjamin (site web personnel) . Évalué à 3.
Ayant déjà vécu ce genre de problème avec d'autres softs upstream, on a généralement des infos sur les listes de sécurité des différentes distributions quasi en même temps : si redhat trouve un problème grâve dans, mettons, openssl, ils préviennent openssl qui prévient à son tour les distributions majeures, c'est assez classique
Donc non, pas d'inquiétude côté upstream apparemment
> Ça n'a pas d'intérêt. C'est la distribution qui connait les paquets.
Peut-être, mais même si elle connaît seule les paquets, toute organisation est finalement monolithique.
Pour cette idée de la vérification de signature, je signalais juste qu'il était possible de mettre en ligne une copie (donc sur des serveurs non gérés par la distribution) des signatures de packages, copie elle-même signée par un tiers (celui qui gère ces serveurs hors distribution), copie qui ne mettrait à jour sa signature locale d'un package que lorsque celui-ci a été observé par un humain (de la même organisation qui gère ces serveurs hors distribution) et que l'humain à constaté que cette mise à jour a été annoncée d'une manière ou d'une autre : soit sur les listes de sécurité de la distribution, soit via le processus habituel (genre le développeur qui renseigne proprement un changelog, le patch associé, le mail sur la liste devel etc.)
D'ici à ce qu'un pirate puisse passer ce _processus_ qui fait finalement appels aux habitudes de la communauté, il faudra de véritables bourdes majeures, et cela peut donc rendre plus robuste l'infrastructure de distribution.
Cela reprend le classique paradigme : pirater un système au hasard est très facile, pirater un système particulier infiniment plus difficile.
Donc pirater un jour quelque chose dont il advient qu'il s'agit d'un serveur principal de distribution, c'est une chose, pirater ensuite l'infrastructure tierce qui co-valide les signatures, c'est une toute autre paire de manches.
[^] # Re: Diversité, diversité :)
Posté par Anonyme . Évalué à -1.
Ayant déjà vécu ce genre de problème avec d'autres softs upstream, on a généralement des infos sur les listes de sécurité des différentes distributions quasi en même temps : si redhat trouve un problème grâve dans, mettons, openssl, ils préviennent openssl qui prévient à son tour les distributions majeures, c'est assez classique
Sauf que tout cela se passe en privé sur des mailling list privés, et il est interdit à ceux qui sont sur ces listes de rendre publique les failles qui y sont discutées avant la date prévue (si ils veullent pouvoir rester sur la liste).
Donc il pourrait très bien y avoir un probleme sur un logiciel upstream sans qu'on soit encore au courant.
[^] # Re: Diversité, diversité :)
Posté par IsNotGood . Évalué à 2.
"Interdit" est trop fort. C'est très très mal vu. Les personnes raisonnablent ne feront pas ça. Ceux qui s'y risquent seront probablement bânis de la mailing.
Par contre Fedora est sous la responsabilité de Red Hat et Red Hat est une boite américaine. Donc Red Hat a des obligations légales (respecter DMCA entre autre).
[^] # Re: Diversité, diversité :)
Posté par ribwund . Évalué à 4.
Le truc c'est surtout que Red Hat est côté en bourse, ils ont donc des obligations légales pour les façons de délivrer des informations.
[^] # Re: Diversité, diversité :)
Posté par IsNotGood . Évalué à 1.
Être en bourse n'implique pas d'appliquer la censure à tout. C'est même souvent l'inverse.
[^] # Re: Diversité, diversité :)
Posté par ribwund . Évalué à 4.
Par exemple (juste une recherche rapide y'a surement d'autres obligations):
http://en.wikipedia.org/wiki/Reg_FD
[^] # Re: Diversité, diversité :)
Posté par IsNotGood . Évalué à 4.
Il y a des obligations pour communiquer, non l'inverse.
# CERTA ...
Posté par Régis . Évalué à 4.
http://www.certa.ssi.gouv.fr/site/CERTA-2008-AVI-428/index.h(...)
Je conseille à tout le monde de tester leurs systèmes avec le script fourni.
[^] # Re: CERTA ...
Posté par Krunch (site web personnel) . Évalué à 0.
Au final cette correction est peut-être plus utile aux utilisateurs que la release du paquet juste pour incrémenter le numéro de version.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: CERTA ...
Posté par herodiade . Évalué à 3.
Ça explique que Red Hat ne se soit pas trop pressé pour distribuer une mise à jour : le CVE-2007-4752 date d'octobre 2007. Ils ont visiblement attendu d'avoir une vraie raison d'upgrader le paquet pour distribuer ce fix.
# deux fois ...
Posté par eastwind☯ . Évalué à -6.
Sinon c'est aussi la deuxième (je me trompe ? ) fois qu'il y a intrusion sur les serveurs d'un gros prestataire du libre (il y avait eu la fois avec Debian aussi ) . Mis à part le fait qu'il fut un temps ou Microsoft a clairement dit qu'il allait démontrer que Linux n'est pas invulnérable , a t-on d'autres (trolls) sur la nature , et l'intention de ces black hat ?
[^] # Re: deux fois ...
Posté par eastwind☯ . Évalué à 0.
:)
ok c'est pas marrant ------>
[^] # Re: deux fois ...
Posté par IsNotGood . Évalué à 9.
[^] # Re: deux fois ...
Posté par Octabrain . Évalué à 7.
La première fois, c'était le paquet Debian d'OpenSSH qui avait un problème, pas OpenSSH lui-même. Cette fois-ci, des paquets d'OpenSSH ont été signés, toujours pas de problème de sécurité dans OpenSSH.
> Selon la formule de Torvalds plus y a de paires d'yeux , plus les bugs deviennent évident .
C'est en fait une formule d'ESR (en:The_Cathedral_and_the_Bazaar).
[^] # Re: deux fois ...
Posté par BAud (site web personnel) . Évalué à 1.
- Software is like sex; it's better when it's free
et sinon la citation est dans http://catb.org/esr/writings/cathedral-bazaar/cathedral-baza(...) et est plus ou moins (?) une reformulation d'écrits de Linus, en tout cas c'est estampillé en:Linus%27s_Law par ESR ;-)
[^] # Re: deux fois ...
Posté par herodiade . Évalué à 10.
Dans les deux cas, une faille d'un autre élément (dans les patchs locaux du paquet openssl de Debian pour la première, dans l'infrastructure de gestion des paquets de Red Hat pour la seconde) a eu des conséquence sur les paquets openssh de ces distributions.
La raison est très simple : openssh est un logiciel stratégique pour la sécurité, parce qu'il gère l'accès distant et complet au système hôte, et parce qu'il est installé sur une grande majorité de serveurs Unix (je pense que c'est le daemon le plus souvent présent sur un serveur unix, plus encore qu'apache, dovecot ou sendmail). La faille du paquet openssl de Debian affectait, en fait, beaucoup d'autres logiciels (dont OpenVPN par exemple), mais on s'est inquiété en premier lieu de ses conséquences sur openssh précisément pour ces raisons. De même, cette position « privilégiée » d'openssh explique clairement pourquoi ce logiciel a été choisi par le pirate des serveurs Red Hat : même s'il avait la possibilité de générer un binaire trafiqué puis signer n'importe quel paquet inclus dans RHEL (ce qui est probable), openssh restait en toute logique la cible de premier choix.
Les failles d'OpenSSH sont rarissimes quand on considère son exposition. Et quand elles arrivent, ce sont soit des problèmes de détail aux conséquences mineures (type vol possible d'un cookie xorg par root), soit failles très sophistiquées et complexes, mais jamais de grossières erreurs de programmation. Ce logiciel est développé par les gens d'OpenBSD, qui sont connus pour faire de leur mieux pour essayer d'éviter les problèmes de sécurité, même lorsque c'est aux dépends des fonctionnalités ou des performances. Et c'est certainement l'un des (sinon _le_) logiciels libres les plus audités : autant par les pirates (la découverte d'une faille dans ce logiciel leur assurerais une efficacité maximum), par les consultants en sécurité (une telle découverte leur garantirais une énorme promotion), par les équipes de sécurité des divers distributions et des autres unix (y compris Mac OS, AIX, Cisco, Juniper & co, qui incluent aussi ce logiciel), par les agences gouvernementales type NSA, il fait partis des programmes audités en boucle par coverty, ... C'est aussi un des premiers logiciels a avoir été mis sous la protection/surveillance de SELinux et d'AppArmor (et dans une moindre mesure, de systrace - et il est généralement compilé avec propolice/-fstack-protector), et un de ceux pour lesquels ces outils sont activés par défaut sur plusieurs distributions : un comportement "bizarre" (ie. dû à une faille encore non révélée en cours d'exploitation) dans ce logiciel se remarquerai très vite.
À mon sens, l'utilisation de serveurs ssh alternatif est moins un gain de sécurité par la diversité qu'un risque dû au manque d'audit intensif de ces derniers (autrement dit, une tentative de sécurité par l'obscurité).
Plus sérieusement, si vous vous inquiétez d'utiliser des logiciels dont le code est fagile et très régulièrement affecté par des problèmes de sécurité, regardez plutôt du coté de l'historique sécu de PHPMyAdmin ou Clamav (ps: et bravo aux distributions responsables qui ont choisi de ne _pas_ inclure cette passoire de phpmyadmin). Je crois qu'il ne se passe pas un mois sans que je soit obligé d'upgrader ces logiciels dans l'urgence sur certains serveurs...
[^] # Re: deux fois ...
Posté par IsNotGood . Évalué à 1.
Pour Red Hat/Fedora, pour l'instant on en sait rien. Paul Frields a promis de donner des explications, mais pour l'instant elles ne sont pas la. Il faut attendre.
# Re:
Posté par IsNotGood . Évalué à 5.
> A noter que cette absence de distribution ne vaut que pour le canal officiel Red Hat et pas pour des dépôts tiers.
Des paquets ont été signé sur les systèmes Red Hat, mais Red Hat n'est pas sûr que ces paquets ne sont pas sorti de leurs systèmes.
[^] # Re: Re:
Posté par Gniarf . Évalué à 7.
[^] # Re: Re:
Posté par HardShooter . Évalué à 0.
[^] # Re: Re:
Posté par IsNotGood . Évalué à 2.
En gros DMCA couvre aussi les moyens de protection de donnée et on ne peut pas annoncer une faille sans quelques précautions. Si tu annonces une faille de sécurité et que tu mets en péril significatif des entreprises (ou leurs "oeuvres"), je crois que tu peux tomber sur DMCA.
[^] # Re: Re:
Posté par Raphaël SurcouF (site web personnel) . Évalué à 3.
De ne pas laisser les utilisateurs dans la panade, l'incertitude, le doute.
Au lieu de cela, ils parlent simplement d'éviter de mettre à jour des paquets via RHN...
Et si jamais il y a des failles de sécurité dans d'autres logiciels, on doit attendre la fin de cette période de rétention d'informations ? Faire nous-même les mises à jour ? Non merci.
À ce niveau-là, les autres distributions (notamment Debian) sont un peu plus transparentes sur leurs problèmes de sécurité.
[^] # Re: Re:
Posté par Krunch (site web personnel) . Évalué à 1.
Où a-t-il été dit d'éviter de mettre à jour des paquets via RHN ?
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Re:
Posté par Raphaël SurcouF (site web personnel) . Évalué à 5.
Dans l'intervalle ils conseillaient de ne pas télécharger le moindre paquet : "as a precaution, we recommend you not download or update any additional packages on your Fedora systems".[^] # Re: Re:
Posté par Krunch (site web personnel) . Évalué à 2.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Re:
Posté par IsNotGood . Évalué à 6.
Ne dit pas de connerie.
Si Fedora/Red Hat n'avait pas dit qu'ils avaient un problème, on en aurait rien su.
Actuellement on est dans le flou et la communication de Fedora/Red Hat ne le nie nullement et elle demande un peu de patience pour avoir toutes les informations.
> À ce niveau-là, les autres distributions (notamment Debian) sont un peu plus transparentes sur leurs problèmes de sécurité.
Et que c'est-il passé pour le dernier problème de Debian avec Openssh ?
Debian a donné l'info dès que Debian à connu le problème ou Debian n'a diffusé l'information que lorsque Debian avait le correctif ? Ben que lorsque que Debian avait le correctif (Dieu merci).
Red Hat/Fedora doit problème faire exactement ce que fait Debian : confirmer le problème, trouver une solution, voire appliquer un embargo si d'autres distributions ont aussi ce problème.
Quand Red Hat (qui trouve beaucoup de failles de sécurité) applique un embargo afin que Debian et d'autres ait le temps de mettre à jour, Debian trouve ça très bien.
> un peu plus transparentes sur leurs problèmes de sécurité.
Red Hat est transparent. Mais parfois, l'information, pour d'excellentes raisons, n'est pas diffusée de suite.
Les données "brutes" sur la sécurté de Red Hat :
https://www.redhat.com/security/data/metrics/
A titre d'exemple, un rapport sur la sécurité de RHEL 4 (en cherchant on en trouvera d'autres) :
http://www.redhatmagazine.com/2008/02/26/risk-report-three-y(...)
Ce n'est absolument pas moins transparent que Debian (et ses patchs qui ne sont pas séparés...).
# Les differences
Posté par kowalsky . Évalué à 3.
sauront tout bientôt.
Sur d'autres systèmes fermé, rien n'aurait transpiré, et une update parmi
tant d'autre aurait été faite.
2°) Tout ce travail fait pour remettre le service en état, communiquer
etc...
Ba c'est gratuit.
Les de telechargement/update serveurs sont rapide, fiable ( a part rare
cas :) , dont celui ci ).
C'est gratuit !
On pourra dire ce que l'on veut ensuite, Debian et la faille OpenSSH,
Fedora ici, la dernière escalade de droit du noyau, etc, des failles
peuvent survenir partout, fermé ou ouvert, tout les systèmes sont
potentiellement vulnerable mais quand même, quand un problème
survient dans le monde Linux ou BSD, il est résolu (relativement) vite,
comme pour le monde proprio je pense, mais surtout pour ici c'est gratuit
et de façon transparente.
Et ça, c'est super !
[^] # Re: Les differences
Posté par ciol . Évalué à 2.
tant d'autre aurait été faite.
Je crois pas qu'il y ait un rapport. Ça se passe au niveau de l'infrastructure, pas du code source des logiciels.
[^] # Re: Les differences
Posté par kowalsky . Évalué à 1.
Je n'etais effectivement pas clair :)
[^] # Re: Les differences
Posté par Dring . Évalué à 3.
Désolé pour la parenthèse, vous pouvez moinsser je comprendrais.
# Les clefs ne sont pas au coffre
Posté par Kerro . Évalué à 7.
Si dans ce cas le pirate à pu signer des paquets, c'est qu'un serveur accessible sur le réseau contient une clef secrète. Et ça, c'est le vrai problème. Qu'un serveur se fasse pirater de temps en temps, ça arrive (erreur humaine, exploit découvert il y a 10 minutes, intrusion physique, etc). Mais que la clef privée soit sur le réseau, argh, désolé mais pour moi ça ne passe pas. Une signature pour ce genre de chose se passe "hors bande", à partir d'une machine au mieux non reliée au réseau (transfert via disque-dur), au pire reliée avec uniquement des connexions de partage de fichiers (je lis le fichier à signer, je le signe, je place la nouvelle copie sur le serveur).
[^] # Re: Les clefs ne sont pas au coffre
Posté par phoenix (site web personnel) . Évalué à 1.
Est-ce que la signature des paquets est une tache automatique ?
[^] # Re: Les clefs ne sont pas au coffre
Posté par ribwund . Évalué à 0.
[^] # Re: Les clefs ne sont pas au coffre
Posté par IsNotGood . Évalué à 3.
Le commentaire de la clé et clair :
$ gpg /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-rawhide
pub 1024D/1CDDBCA9 2003-10-27 Fedora Project automated build signing key (2003) <rawhide@redhat.com>
[^] # Re: Les clefs ne sont pas au coffre
Posté par gemegik . Évalué à 3.
Il n'y a pas à ma connaissance de signature automatisée des paquets.
[^] # Re: Les clefs ne sont pas au coffre
Posté par ribwund . Évalué à 1.
gpg --keyring /etc/apt/trusted.gpg --list-keysCa me donne:
http://wwwkeys.ch.pgp.net:11371/pks/lookup?options=web&o(...)
http://wwwkeys.ch.pgp.net:11371/pks/lookup?options=web&o(...)
http://wwwkeys.ch.pgp.net:11371/pks/lookup?options=web&o(...)
Et donc uniquement la clé de stable n'est pas automatique.
[^] # Re: Les clefs ne sont pas au coffre
Posté par gemegik . Évalué à 0.
Les paquets sont signés manuellement par la clef GPG d'un développeur Debian. Les clefs publiques sont disponibles dans le paquet debian-keyring [cf http://packages.debian.org/sid/debian-keyring]. Même si la clef automatique est corrompue, si quelqu'un l'utilise pour ajouter un paquet à l'archive, apt se plaindra que ledit paquet n'est pas signé et demandera confirmation.
[^] # Re: Les clefs ne sont pas au coffre
Posté par ribwund . Évalué à 2.
Avec la clé automatique on peut générer un release file valide et ça suffit. Aptitude ne demandera pas de confirmation.
Voir sur: http://wiki.debian.org/SecureApt
Ce dont tu parles c'est la signature sur les paquets sources, qui sont signés par le dev et qui sont disponibles sur les mirroirs (le .dsc).
[^] # Re: Les clefs ne sont pas au coffre
Posté par ribwund . Évalué à 3.
Malgré le moinssage, je persiste, les clés pour signer le release file d'unstable et de security sont sans passphrase, et sur une machine en ligne (les signatures sont automatiques).
# Encore une bonne raison...
Posté par ragoutoutou . Évalué à -3.
Déjà les mises à jour de sécurité compromises, c'est grave, mais imaginons que les serveurs de gestion RHN se fassent hacker, c'est la porte ouverte à combien d'entreprises pour le hacker s'il arrive à forcer la mise à jour sur les machines enregistrées...
[^] # Re: Encore une bonne raison...
Posté par Krunch (site web personnel) . Évalué à 10.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Encore une bonne raison...
Posté par ragoutoutou . Évalué à 7.
Le truc amusant via RedHat Network et sa belle interface, c'est que tu peux pousser directement les mises à jour sur les serveurs que tu gères depuis cette interface qui se trouve sur un serveur web sur internet... un beau risque inutile.
Dans le cas où les signatures et le serveur RHN sont compromis, l'attaquant peut pousser lui-même les mises à jour sur les machines enregistrées... c'est pas beau ça?
Inféoder les serveurs de son lan à un serveur sur internet sur lequel on a pas de contrôle, c'est une mauvaise pratique de sécurité.
[^] # Re: Encore une bonne raison...
Posté par IsNotGood . Évalué à 3.
Bref, ceux qui n'utilisent que RHN n'ont pas de soucis à se faire...
Je plussois massivement le commentaire de Krunch ci-dessus.
[^] # Re: Encore une bonne raison...
Posté par BAud (site web personnel) . Évalué à 3.
Après, si tu parlais de crackers, oui cela serait gênant, encore faudrait-il utiliser le bon terme :-).
Mais en entreprise, les mises à jour se doivent de suivre un processus de suivi des mises à jour : cela évite de casser les applications... ces process sont d'ailleurs souvent un peu trop lourds (planification, tests avec des équipes utilisateur pour la non-régression...) et empêchent les mises à jour de sécurité d'arriver jusqu'à la production (j'ai souvent constaté des serveurs non mis à jour depuis 2005, lors de leur mise en place... bon, ce n'était pas du GNU/Linux).
Justement, utiliser le RHN c'est avoir l'espoir d'avoir une équipe dont les prérogatives seraient de gérer les mises à jour et (notamment) arbitrer concernant la sécurité : actuellement, j'ai souvent constaté que seules les mises à jour liées à un problème majeur de sécurité sont prises en compte (ne pas toucher à quelque chose qui marche reste la prérogative qui prend le dessus la plupart du temps...).
[^] # Re: Encore une bonne raison...
Posté par ragoutoutou . Évalué à 2.
Mon propos concernait le risque lié au fait que RHN permet de pousser les mises à jour sur les machines inféodées à ce système... risque théoriquement mitigé par la signature cryptographique des paquets.
Le jour où un rigolo prend le contrôle de RHN ainsi que des mécanismes de signature, ça va faire très mal pour les clients qui auront laissé leurs machines inféodées à RHN.
[^] # Re: Encore une bonne raison...
Posté par BAud (site web personnel) . Évalué à 3.
Après, tu semble omettre ce que j'ai décrit et qui permet (même avec un RHN) de ne pousser que ce que l'on souhaite quand on le souhaite, mais je n'ai pas forcément donné tous les éléments ?
[^] # Re: Encore une bonne raison...
Posté par ragoutoutou . Évalué à 2.
Vu le prix du satellite, de nombreuses entreprises le font encore...
RedHat donne le choix entre une solution que tu qualifies toi-même de débile et une solution onéreuse pour un petit parc... même quand on veut juste pouvoir lancer des "yum install" localement, il faut passer par là si on veut avoir les mises à jour.
[^] # Re: Encore une bonne raison...
Posté par Raphaël SurcouF (site web personnel) . Évalué à 2.
Je pense que l'ouverture du code du RHN Satellite permettra enfin de réaliser à peu de frais les mises à jour.
[^] # Re: Encore une bonne raison...
Posté par ragoutoutou . Évalué à 2.
[^] # Re: Encore une bonne raison...
Posté par BAud (site web personnel) . Évalué à 3.
Tu ne changes pas le canal officiel, tu ne rajoutes qu'un "proxy" sur le chemin... puis bon le prix du satellite, c'est 5 jours * 2 consultants * prix d'un consultant éditeur, donc bon, autant qu'il soit au même prix pour le service et en libre.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.