Hello, Le 22/10/2016 à 00:14, Sappas a écrit : Le linux natif dans Windaubeten n'est pas estampillé Kernel GNU/Linux mais plutôt Microsoft tout court (Merci à Philippe pour ce rappel!) Avec systemd sous GNU/Linux, on n'est pas encore sorti de l'auberge ! La réponse se trouve dans l’émission Cash Investigation ... Ce n'est pas plutôt le cheval blanc d'Henri IV ? -- Linuxement vôtre, -------------------------- dptech ~ David Pinson http://www.linux-azur.org -------------------------- var beer = new beer(); if (beer.empty) { beer.refill(); } else { beer.drink(); }

Le 22/10/2016 à 15:58, Sappas a écrit : J'ai mieux à faire... La vie à vivre est belle <3 Salutations ensoleillées, -- Véronique Fritière ~ Linux ? C'est le luxe ! Linuxazuréenne http://www.linux-azur.org Afulienne https://aful.org Chef de projet Multimédia http://webverow.com

On 22/10/2016 22:04, Sappas wrote: Cela dépends des chiffres que tu prends, il faudrait classer les vulnérabilités par dangerosité et par utilisation. Je peux décider de prendre les statistiques sous un autre angle, par exemple le nombre d'exploits par système : http://www.cvedetails.com/vendor/33/Linux.html 29 exploits http://www.cvedetails.com/vendor/49/Apple.html 48 exploits http://www.cvedetails.com/vendor/26/Microsoft.html 192 exploits On peut décider d'en tirer une conclusion immédiate, elle ne serait pas plus juste que celle du nombre de vulnérabilités. Les systèmes les plus répandus sont aussi les plus exposés. Le nombre de faille n'est pas complet. Les failles utilisant les pilotes propriétaire qui n'apparaissent pas en tant que vendor du système: https://www.cvedetails.com/vulnerability-list/vendor_id-5264/Nvidia.html . Par exemple https://www.cvedetails.com/cve/CVE-2013-5986/ [ qui affecte tous les systèmes utilisant le pilote propriétaire ... ] ne sera pas comptabilise en tant que vulnérabiltié Microsoft, ce qui est normal. Un système linux sans utilisation de pilote propriétaire n'est exposé qu'à ses failles, pour les autres il faut cumuler ceux de tous les pilotes potentiels. Et il faut ajouter à cela le support des architectures matérielles, nombre de vulnérabilité du noyau linux l'on été pour les architectures ARM poussés probablement par l'utilisation de linux en tant que noyau pour les téléphones portables sous android et par l'activité accrue sur ces plateformes de manière générale. Autant dire que pour donner une bonne lecture d'expositions des vulnérabilités d'un système donné, il n'est pas aisé de simplifier ... D'autres facteurs jouent : Pour un système propriétaire il est plus facile de corriger silencieusement une faille sans en publier une CVE publique. Il y a des organismes d'états intéressés à conserver privées des failles pour pouvoir les utiliser à dessein. En matière de sécurité il est préférable d'exposer le code source pour donner à tous d'auditer la qualité du logiciel et de comprendre en profondeur lorsqu'une faille est trouvée d'où vient le problème. Il est plus difficile de créer des vulnérabilités volontaires dans un système où le code est fourni, même si cela reste possible et a été démontré ( dans le cadre des machines à voter ). La mantra de Bruce Schneier, expert reconnu et auteur de nombreux livres sur la sécurité informatique est 'Sécurité réelle : pas de sécurité par l'obscurité' ( https://fr.wikipedia.org/wiki/S%C3%A9curit%C3%A9_par_l'obscurit%C3%A9)%A9). L'important est le temps d'exposition de la vulnérabilité entre le temps où la faille est découverte et celle où elle corrigée. Et il est très difficile d'obtenir des chiffre fiables pour le temps réél d'exposition. Dans le cas du logiciel libre, aucun éditeur ne peut empêcher ses utilisateurs de chercher à corriger le problème et de fournir un correctif. Rien est parfait en ce monde. Il existe des systèmes tes OpenBSD qui placent la sécurité au coeur de tous leurs développements, ces systèmes sont très certainement les plus sûrs à l'heure actuelle. A chacun de choisir le système qui lui convient.

On 23/10/2016 19:07, Vincent wrote: Comme il s'agit d'une faille portée par une race condition je pense qu'elle est très dépendante du nombre de coeurs de ta machine. L'exploit est donc assez aléatoire et peut ne pas sembler affecter ta machine sur une série de tests. Pour ma part je me suis contenté de vérifier que le noyau utilisé était bien celui du paquet debian contenant le correctif...

On 23/10/2016 20:54, Vincent wrote: non je ne pense pas qu'il soit nécessaire de mettre à niveau, une mise à jour doit suffire, il est cependant nécessaire de redémarrer pour activer le nouveau noyau. as-tu essayé sudo apt-get dist-upgrade ? C'est quoi le contenu de ton /etc/apt/sources.list ?

Le 23/10/2016 à 21:25, Vincent a écrit : Ok, j'ai redémarré, et la mise en jour vers le noyau 3.13.0-100-generic est en cours... A+