pasBill pasGates a écrit 16356 commentaires

Le 1er compte, car il faut un admin, les autres non (Vista +)

Ensuite, au lieu de reconnaitre la puissance du gestionnaire de paquet, tu dévie la question sur les logiciels propriétaires qui ne rentrent pas dans le moule. Je te remercie de nous montrer la supériorité du libre sur le propriétaire, mais ca on le savait déjà. Et je te retourne la question : sur Windows, comment on fait pour identifier tous les logiciels qui dépendent d'une bibliothèque ?

Tu me fais rire, je te demandes un truc, tu me donnes une solution qui ne marche qu'a 50%
La superiorite du libre sur le proprio elle est tres drole et n'a rien a voir la dedans, c'est le fait que le soft ne soit pas package qui est le point faible.

Et je te retourne la question : sur Windows, comment on fait pour identifier tous les logiciels qui dépendent d'une bibliothèque ?

Inutile de me retourner la question, la reponse est que c'est une chose impossible a faire quel que soit le systeme.

Pour revenir au sujet :
- Si la machine ne comporte que des logiciels packagés, alors je peux laisser le gestionnaire de paquet gérer les dépendances, c'est son boulot.
- Si elle héberge en plus des logiciels non packagés (propriétaires ou pas), on sait reconnaitre ces logiciels et les redémarrer, parce qu'on s'est donné la peine de les installer avec un peu de méthode. Si on ne veut pas se prendre
la tête, on redémarre systématiquement ces logiciels en cas de mise à jour.

a) Oui, mais c'est plutot utopique
b) Oui, idem sous Windows en fait

J'aimerais que tu nous explique quel sont les cas qui ne sont pas pris en compte par les trois points ci-dessus, et surtout comment on peut faire la meme chose sous Windows.

Il y a un truc qui s'appelle MSI sous Windows, tu devrais chercher ce qu'il fait, ca t'apprendrais des trucs je pense.

Si c'est possible, ça demande du temps. Après tu pèses le pour et le contre. Perso je me prends pas la tête, les softs proprios je les redémarre quand je fais une mise à jour.
Mais il est possible de d'automatiser cette tâche de détection de librairie. Je n'ai jamais essayé, mais vu que tu arrives à isoler tous les fichiers, tu peux facilement faire un script qui va te donner la liste de toutes les librairies nécessaires puis lister les paquets contenant ces librairies (le gestionnaire de paquet de Debian te permet de savoir à quel paquet un fichier appartient).

Non tu ne peux pas le faire. Tu ne sais pas quand et sous quelles conditions le soft va decider de charger la librairie, si tu fais tourner ton script hors de cette condition, tu ne verras pas la librairie.

Quand a ne pas te prendre la tete, c'est justement la bonne solution, parce que c'est la seule qui soit sure.
Maintenant quand tu deploies ton patch et que tu dois redemarrer tous ces softs sur X machines differentes, faut savoir comment le faire sur chaque machine, garder la chose a jour, etc... un vrai bordel compare a "je me prends pas la tete" comme tu le dis qui est de redemarrer le systeme.

De la magie personne ne peut en faire. Ni Microsoft, ni Debian, ni Apple. Mais actuellement le seul système qui s'approche de la perfection en terme de gestion des mises à jour reste Debian et je crois pas que Microsoft s'approche de ça.

Que Microsoft ne soit pas parfait je n'en doutes pas une seconde, que Debian en soit proche sur ce point, permet moi de rire, c'est le genre de systeme ou soit tu y arrives completement, soit tu n'y arrives pas, il y a pas de milieu, car le milieu signifie que tu restes vulnerable sans le savoir, et Debian n'y arrives pas completement, bref, il est exactement au meme stade que MS.
Que les gens ne s'en rendent pas compte et suivent aveuglement le troupeau ne signifie pas que le troupeau a raison.

Si il charge les librairies à la demande, il n'y a rien à faire, je vois pas où tu veux en venir, là ...

Vraiment ?

Le soft X charge a la demande OpenSSL, un patch pour OpenSSL surgit.

Tu l'installes, tu redemarres tous les softs, sauf le soft X car tu ne sais pas qu'il utilise OpenSSL, ce soft reste vulnerable.

Sinon quand tu prends un logiciel, tu dois toute façon savoir quelles librairies (autres que celle qu'il amène lui-même) tu dois avoir sur ton système et ton logiciel tu vas l'installer dans un répertoire bien délimiter pour que tu puisses voir l'entier du truc sans te prendre la tête.

Quand le soft depend de librairies qui sont quasiment toujours presentes et que l'editeur ne te donne pas l'info (souvent il ne l'a pas d'ailleurs ce qui est drole), tu fais comment ?

Si justement c'est une vue de tout ton système et toutes le dépendances

Je viens de te demontrer par A+B que non, car il ne gere pas les softs non-packages, et qu'il n'est pas possible de creer ces packages soi-meme de maniere sure et complete.

Rien j'est jamais complet, mais il est assez evident que niveau softs dispos Linux a qqe trains de retard

Si l'admin a prévu le coup il a fait un paquet qui permet de "caler" ton logiciel dans le système de paquet. C'est un paquet qui ne fait rien d'autre que de te garantir les dépendances et tout et tout durant les mises à jour. Le paquet en lui même ne met pas de fichier.

Ben ca va etre drole a faire quand tu te rendras compte que le soft il loade des librairies a la demande plutot qu'en etant linke directement a elles(sans parler que ca va etre rigolo de faire cette liste des libs linkees, car faut la refaire a chaque update du soft en question, pour chaque soft au cas ou ca change, et il faut trouver les binaires de chaque soft, nombre qui peut augmenter a chaque release / update).

Eh oui pas de chance, marche pas non plus.

Debian a un système de gestion de paquets connu et reconnu, ce n'est pas un hasard, c'est un outil qui a été développé par une communauté qui fait tourner le monde des serveurs depuis longtemps et ça se ressent à l'utilisation, c'est un vrai régal.

Ce systeme de gestion de paquets ne resoud rien car il ne represente pas l'entier du systeme et ses dependances.

Ouais mais toi t'es suisse, tu vis sur une ile un peu aussi :+)

Ben non c'est incomplet, nombre de softs proprio ne sont pas disponibles dans le packaging de la distribution.

Ton systeme ne fonctionne pas et est dangereux pour le systeme.

Mais bon, je te comprends, tu n'as pas l'habitude...

Au contraire, j'ai l'habitude, la preuve.

Ton dpkg il inclut tous ces softs metiers et autres qui ne sont pas livres en tant que .deb ? Il est baleze dis donc.

Parce que le gros probleme c'est bien ca, le systeme de packaging il ne couvre pas tout, surtout lorsque il s'agit de logiciels proprio et dieu sait si les entreprises en utilisent.

Essaie de faire ca sans etre admin, ca va etre tres drole

Je te suggeres d'utiliser un compte utilisateur plutot qu'admin, il est un peu normal qu'on te demande pas le mot de passe admin si t'es logge en tant que tel...

Tout a fait, mais personne n'a jamais essaye de faire croire qu'ils etaient securises, contrairement a Fedora.

Je parles evidemment de la lignee NT, les versions precedentes n'avaient meme pas le concept d'admin/user, permettre a un "utilisateur" d'installer des softs etait donc tout a fait normal et pas un trou dans l'architecture de securite du systeme, vu qu'il n'y avait tout simplement pas de securite.

Le fait qu'un compte soit admin ou pas n'a absolument rien a voir avec le fait de laisser un utilisateur quelconque installer des softs globalement sur le systeme. Dans un des cas, le systeme fonctionne en suivant l'architecture de securite prevue, dans l'autre, on cree un trou beant dans cette architecture.

Faire cela signifie que l'on ouvre toutes grandes les portes du systeme a tout un chacun, c'est a mon sens une tres tres grosse betise, car l'admin n'est plus capable de controler ce que le systeme devient, hors la raison principale de cette separation entre user et admin c'est ca, l'admin gere et controle le systeme, l'utilisateur utilise le systeme.

De plus etant quelqu'un d'assez coherent, je trouvais ce comportement idiot sous windows et donc je ne vois pas pourquoi je le trouverai bien parceque c'est sous linux.

Tu manques de memoire en tout cas, Windows n'a jamais permis a un utilisateur simple d'installer qqe chose sur le systeme en global.

On pourra mettre toutes les possibilités imaginables sur le redemarrage lors de l'install des mises à jour, ça change pas le problème de base. Pourquoi faut il systematiquement redemarrer un serveur pour n'importe quelle mise à jour ?

C'est du a la maniere dont Windows gere les dlls et exe (tu peux pas remplacer un dll ou exe pendant qu'il est utilise).

En pratique, j'ai compté 7 mises à jour du noyau sous debian depuis Janvier 2009, donc ceux qui ont redemarré pour charger le nouveau noyau ont quand même eu des uptimes plus long qu'un mois (http://www.debian.org/security/2009/).

Et lors des updates a openssl et autres, tu as parcouru la liste de tous les softs l'utilisant et les a tous redemarres ? Sur toutes tes machines ? Ca a du etre drole a faire.

En pratique pour avoir du microsoft en serveur depuis avril, c'est rare quand l'uptime depasse 1 mois.

Logique vu qu'on sort nos patchs chaque mois.

Encore pratique, dans un réseau d'entreprise, un linux non mis à jour peut tenir plusieurs années sans poser de problème en terme de piratage ou attaque de virus (c'est du vecu).

Mets moi dans ton reseau d'entreprise, tu commenceras tres vite a avoir des sueurs froides.

Ce n'est pas parce que les gens ne le font pas que ce n'est pas faisable.

Choix au hasard :
- http://www.samba.org/samba/security/CVE-2009-0022.html
- http://www.vupen.com/english/advisories/2009/0029
- http://www.samba.org/samba/security/CVE-2008-1105.html

Désolé, c'est moi qui suit du côté pratique, tu ne peux pas utiliser ce mot ...

Dis nous alors, tes machines ont ete attaquees ? Tu as des elements montrant que c'est utilise activement ?

... surtout quand c'est complètement à côté. Depuis le début de l'année, 8 redémarrages, dont 2 redémarrage d'affilé (2 jours d'intervalle).

Tu vas chez Redhat, tu comptes le nombre de patchs de securite du kernel, cette annee ils en sont a 8, l'annee passee a 10.

Sur les serveurs, tu peux rajouter les libs genre openssl vu le nombre de softs qui les utilisent (tu peux t'amuser a aller sur chaque machine, trouver les softs les utilisant, trouver comment les arreter un par un et etre bien sur que t'en as pas oublie mais un reboot sera bien plus simple et sur), sur les clients les libs KDE et Gnome.

Au final, t'arrives a environ un mois voire plus

Non je serais cohérent si je continuais à dire que c'est un scandale que Microsoft ne sorte pas un patch pour le trou smb1 et 2, mais je crois que le débat à glisser un peu parce que Microsoft a décidé que ce n'est pas grave. Donc ce n'est pas grave.

On a dit qu'on sortirait pas de patch ? Non.

Enfin bon, desole de faire les choses proprement plutot que sortir un truc en 30s qui se refera trouer en 2 jours et qui risque de tout casser. Visiblement depuis l'annonce tu as eu tous tes serveurs qui ont ete attaques.

Sinon pour les mises à jour (puisqu'on est sur le sujet), il y a moyen de faire plus précis que "auto / pas auto" (ça c'est Microsoft).

Et hop, on ressort les petites phrases la con sur MS.

Tu remarqueras que c'est plus que auto / pas auto , il peut toutes les installer et retarder le reboot, ne pas rebooter si qq'un est logge, etc... mais visiblement cette partie de la phrase tu l'as ratee.

Oui dans le cas de Windows, mais dans les autres systèmes (je dirais presque tous les autres), il y a possibilité de mettre à jour des parties du système pouvant être rechargée sans nécessité un redémarrage complet de la machine. En fait on redémarre uniquement quand on met à jour le noyau Linux.

En pratique sous Linux tu dois rebooter au moins une fois par mois vu le nombre d'updates du kernel, sous Windows c'est idem.

Rooh, sois sérieux, éteindre un serveur à distance il me semble que c'est grave. Suffisamment pour avoir un patch critique

C'est grave oui,au point de sortir un patch oui, au point de sortir le patch dans les 30 secondes sans le tester correctement, non.

Expliques au lieu de simplement nier (avec des sources, si possible, car tu ne mets jamais de source, c'est lourd à la fin).

Tu veux que je t'expliques quoi ? Que notre systeme ne reboote pas les serveurs automatiquement ?

http://blogs.technet.com/mu/archive/2008/10/02/windows-updat(...)

Le systeme te demande ce que tu veux faire au setup, si tu decides de les installer automatiquement, alors il y aura reboot avec le pop-up et t'as des options pour le delai de reboot, ne pas rebooter si qq'un est logge, ..., si tu decides de download et laisse l'utilisateur decider, alors elles s'installeront quand tu le voudras, si tu decides de rien faire, alors il ne fera rien.

Ben justement, peu importe la carte graphique sur le serveur, ton client sur connecte sur le serveur Terminal Services, il ecrit son document Word a la con, trouve son boulot chiant et il veut voir une anim Direct3D, les instructions D3D seront executees en local sur le client, en tirant partie de la carte graphique du client. Resultat le serveur n'est pas charge par tout ce bordel et c'est plus fluide pour l'utilisateur qu'avoir simplement le buffer de l'anim qui passe.

Idem pour la video(faut que ca passe par DirectShow je crois)

Mais c'est ça que je critique. Ce n'est pas à vous de juger de la gravité de la situation.

Alors on fait quoi ? On sort 300 patchs par jour car pour chacun d'eux il cree une situation critique pour quelqu'un quelque part sur la planete ? C'est irrealiste, il faut donc qu'on fasse un jugement sur la gravite du probleme.

J'ai souvenir d'une boîte de dialogue qui venait tout les X temps et laissait X minutes avant de redémarrer automatiquement.

Et si tu lisais la doc, tu saurais comment l'eviter.

Non, c'est toi qui ne connaît pas bien l'histoire de ta boîte je crois. Par contre les licences j'y ai jamais, au grand jamais, rien compris ... Mais t'inquiète pas, je ne fais plus de Microsoft maintenant ... Je ressasse seulement mes souvenirs.

Voyons voir, ca fait 9 ans que je bosses sur les patchs de Windows chez MS, marrant, mais j'ai comme la drole d'impression que je sais 10x mieux de quoi je parles que toi.

Tu voulais dire 1975-2003 ?
Sinon je penses bien que vous débauchez les meilleures. Mais ça veut pas dire que votre système est le meilleure (c'est pas parce que Ian Murdock est chez OpenSolaris que ce système va être aussi bon que Debian (en terme de distribution)).

Mais mon cher, les boites de securite, elles basent pas leur jugement sur qui on embauche, elles basent leur jugements sur nos produits et nos processus.

Snyder elle etait chez nous pendant plusieurs annees, c'est la ou elle s'est fait un nom en bonne partie, si le resultat de son boulot avait ete de la merde, crois-moi ca se saurait dans les milieux specialises

Mais n'importe quoi. Je dis pas de revenir à l'ancienne méthode (dont on parlera plus loin), mais dans certains cas, et celui-ci en ai un, préparer un workaround disponible ne casse pas le système de mise à jour et permet à ceux qui le juge nécessaire. On parle quand même de pouvoir éteindre un serveur à distance. Ce n'est pas rien.

Non ce n'est pas rien, mais ce n'est pas la fin du monde non plus.

Ensuite ce n'est pas à Microsoft de décider si c'est exploitable ou pas. Si j'en parle à mon apprenti de ce problème, ben tu peux être certain qu'au cours il va bien s'amuser avec les serveurs de l'école. Donc avoir le choix de pouvoir appliquer un patch risquer ou attendre la version finale, c'est un choix qu'un administrateur devrait pouvoir faire (et si je serais dans une école, par exemple, je choisirais le patch moisi). Mais comme vous prenez tous vos clients pour des cons, c'est clair que vous faites vous ce choix.

Ben oui evidemment qu'on prend tous nos clients pour des cons...

Le système de diffusion des patchs étaient décriés parce qu'il redémarrait le serveur automatiquement (même si c'était un patch qui changeait le fond d'écran). Donc les entreprises en avaient un peu plein l'os de voir leurs serveurs redémarrer de manière aléatoire. Donc oui, c'est insupportable de vivre avec une épée de Microsoft au-dessus de la tête ("Mon serveur redémarrera aujourd'hui ?").

Notre systeme n'a _jamais_ redemarre un serveur automatiquement, tu racontes n'importe quoi.

C'est un choix fantastique que Microsoft propose ... Vraiment ...

Visiblement tu n'as rien compris au systeme d'update de MS, heureusement que tu n'es pas mon admin.

Finalement à vous cachez derrière "on doit tester pour que ce soit super parfait", montres bien que vous avez préférez protéger la campagne de marketing au lieu de la sécurité, un patch critique en période de lancement aurait fait trop de vagues.

Oui bien sur, ca montre bien a quel point tu ne sais pas de quoi tu parles. On a deja sorti des patchs de securite pour Win7 depuis Octobre.

Microsoft n'est pas un partenaire efficace quand on parle de sécurité, c'est connu et reconnu pas par hasard.

Malheureusement pour toi c'est exactement l'inverse, MS est reconnu pour etre maintenant a l'avant-garde de ce cote dans le monde de la securite apres s'etre pris une claque qu'on pourrait qualifier d'enorme en 2002-2003.
Si tu demandes a des boites genre IOActive, Leviathan ou autre quelle boite il faut copier niveau securite, un des premiers noms que tu entendras est MS. C'est pas par hasard que Mozilla est alle chercher sa directeur de securite chez nous hein(Window Snyder, qui est partie de Mozilla depuis).

Mais j'ai parlé du système de mise à jour ? Un exe qu'on puisse aller télécharger sur le site. Simplement.

Ca ne regle qu'une partie du probleme, ca laisse ces PMEs qui comptaient sur les updates automatiques dans la mouise, ca nous oblige a tester un truc 2x alors que rien ne presse vraiment pour le moment ce qui nous fait perdre du temps, ...

Toi sors de ton monde. Il y a des administrateurs très capables qui sont prêt à mettre en patch qui demande de redémarrer le serveur en fin de journée si cela permet de ne pas risquer de faire perdre de l'argent (et donc sa place) à son patron.

Tout a fait, il y en a. Il en y a aussi enormement parmis eux qui vont faire la chose suivante :
- Attendre qu'on sorte le patch teste, car ils ne sont pas attaques

La plupart suivent les mailing-lists de securite et regardent si la vulnerabilite est activement exploitee pour decider si ils doivent sortir de leur cycle de patch ou pas, dans le cas present la reponse est toute claire : non

Tu as déjà bossé dans du service ? Le serveur il doit jamais planter, faire le café au boss, trouver les clés de la voiture, ... bref résoudre tous les problèmes.
Le fournisseur d'accès se broute et la connexion internet est perdue : "dring ... Allo ? Internet marche pas, il faut réparer. Mais c'est votre fournisseur d'accès qui a un problème. M'en fout, vous venez me réparer ça tout de suite ... tut tut tut"

Le truc que malheureusement tu ne comprends pas, c'est qu'avant, on sortait les patchs a peu pres comme tu le demandais, et on a change... Pourquoi ? Parce que les entreprises nous l'ont demande...

Facile tes quelques millions de couillons, mais sors des labs de Microsoft et va dans une vrai PME (ce qui reste le gros du marché de Microsoft) et viens ensuite nous parler des tes problèmes de patch pas iso-machin-chose.

Justement, la methode qu'on applique, elle vient de nos clients.

Il faut des solutions (des workarounds) dans les 5 minutes. C'est pas parfait, mais ça permet d'éviter le pire et pour un truc tip-top pile-poil, ça peut attendre.

Tout a fait, c'est pour ca que dans nos advisories on donne les workarounds quand il y en a. Mais le patch lui, si il peut attendre d'etre teste, on ne le sortira que teste.

Le partage de fichier est quand même une fonction de base d'un serveur. Si celle-ci est défectueuse au point de pouvoir empêcher l'entreprise de fonctionner de manière aléatoire durant une demi-heure, c'est un problème.

Tout a fait, mais ce n'est pas le cas, faut que tu sois attaque pour que ce soit le cas.
Si demain on voit que les attaques se multiplient, on sortira le patch en le testant moins, mais jusqu'a aujourd'hui il n'y a aucune raison de couper les tests.

Une vrai réponse de Microsoft aurait été un patch disponible rapidement mais pas super-testé et tout. Après l'administrateur décide si ce patch est nécessaire ou pas, c'est le minimum.

Non pas du tout, car nombre de gens utilisent les updates automatiques, leur balancer un patch pas teste pourrait leur crasher leur systeme si il y a un probleme, pas vraiment une bonne idee.

La vraie reponse c'est de voir ce qui se passe dans le monde reel, tu regardes autour de toi, tu verras que cette vulnerabilite n'est pas exploitee activement, personne n'est sous un deluge d'attaques ou autre, donc aucune raison de sortir un patch bacle.

Microsoft n'est pas à la hauteur en terme de réactivité depuis toujours et ce n'est pas prêt de changer.

Au contraire, entre un patch teste et un patch non teste, j'ai tres tres vite fait mon choix, surtout dans ce cas ou ce n'est visiblement pas exploite activement.
Faut que vous sortiez un peu de votre petit monde et vous rendiez compte que sortir un patch pour des millions de systemes utilises dans un tas de configs differentes par des gens souvent pas competents, c'est pas aussi simple qu'ecrire 3 lignes de code, compiler et jeter ca sur le net.

Les changements dans R2 n'ont rien mais alors rien a voir avec un SP.

- Enlevement du dispatch lock
- RDP avec remoting de DirectX et video
- DirectAccess
- Live Migration pour HV
- Passage de HV a 64 CPUs
- DNSSEC
- BranchCache
...

Jamais un service pack n'a eu de features pareilles, et de loin