Une interview de Brad Spengler

Posté par patrick_g (site web personnel) le 24 juillet 2009 à 16:25. Modéré par j.

Étiquettes :

juil.

2009

Brad Spengler, le mainteneur du projet grsecurity et l'auteur du dernier exploit en date dans le noyau Linux, a accepté de répondre à quelques questions pour LinuxFr.org.

Sous le pseudonyme de "Spender", Brad s'est rendu célèbre en découvrant de nombreuses vulnérabilités du noyau Linux et en prouvant, à l'aide d'exploits, que ces trous de sécurité étaient exploitables. Il est le mainteneur principal du patch externe grsecurity, qui vise à renforcer la sécurité du noyau en ajoutant divers mécanismes qui restreignent l'impact des vulnérabilités ou qui les bloquent complètement. Après la publication de son dernier exploit plusieurs questions lui ont été envoyées par mail (en une seule fois) et il a eu la gentillesse d'y répondre. Qu'il en soit remercié. Personnel

Question 01 : Quel système d'exploitation utilises-tu sur ton laptop/desktop et pourquoi as tu choisi ce système d'exploitation particulier ?

Spender : Je sais que cela va probablement énerver certains des lecteurs, mais en ce moment je suis en train d'utiliser Windows 7 RC. Avant ça, je faisais tourner Windows Vista et je n'ai pas utilisé Linux sur ma machine principale environ depuis la fac. Maintenant que j'ai un boulot et que mon temps libre est limité, je ne peux plus perdre des jours à essayer de faire fonctionner tel ou tel pilote ou à essayer de récupérer un système complètement cassé parce que je ne l'ai pas mis à jour depuis un certain temps et que maintenant je veux mettre à jour Pidgin. Si je veux mettre à jour une application spécifique sur la machine alors je veux juste updater cette application - Je ne veux pas avoir à mettre à jour 140 autres dépendances.

Donc pour des raisons de maintien de ma santé mentale (et pour pouvoir jouer à des jeux sans devoir me restreindre à Wine/Cedega), j'utilise Windows. Linux reste dans une machine virtuelle sur ma machine principale, même si j'ai d'autres machines qui tournent directement sous Linux afin de tester grsecurity.

Question 02 : De façon générale que penses tu du mouvement du logiciel libre ? Accordes tu de l'importance à la philosophie du logiciel libre (comme RMS) ou te préoccupes tu seulement des mérites techniques de ce modèle de développement (comme Linus) ?

Spender : Eh bien, sans le mouvement du logiciel libre, beaucoup des logiciels que j'utilise n'existeraient pas (pas plus que le logiciel que j'ai créé) donc j'éprouve de la gratitude pour ça. Au début, ce qui m'importait, c'était la gratuité. Avoir le code source a aussi été une formidable ressource pour mon apprentissage.

Question 03 : Y a t-il vraiment un marché pour vendre des vulnérabilités ? En as-tu déjà vendu à des acheteurs légitimes ? As-tu déjà pensé en vendre à des acheteurs non légitimes (black hat) ?

Spender : Oui, il y a vraiment un marché : iDefense, ZDI, Immunity, etc. achètent les exploits. J'ai déjà vendu des vulnérabilités/exploits à des acheteurs légitimes. Je ne vendrai jamais une vulnérabilité à aucun acheteur illégitime ni ne vendrai une vulnérabilité qui serait liée à grsecurity. Cela irait à l'encontre du but même du projet (et en plus ce ne serait pas éthique).

Question 04 : Il y a pas mal de commentaires rigolos dans le code source de ton dernier exploit (et il y a même de l'ascii art). Est-ce amusant d'écrire un exploit ? Éprouves-tu une sensation de joie extatique quand tu découvres une vulnérabilité dans le noyau ?

Spender : L'exploit Cheddar Bay a été super fun à écrire :) Depuis l'ascii art jusqu'aux bips du système en passant par l'aventure textuelle interactive et le bout de littérature française existentialiste (tout à la fin). L'exploit fait 31337 octets et le tgz fait 12345 octets et c'est parfaitement vrai -comme mentionné dans l'exploit - que la plus grande partie du temps de développement a été passée dans la réalisation de l'expérience audiovisuelle.

L'aspect technique pur de l'exploit a été assez simple (pour le plus grand embarras des personnes concernées, quelqu'un ayant une heure de temps libre peut démolir toutes les protections qui ont été mises en place). J'ai peut-être un sens de l'humour bizarre, mais moi je trouve ça hilarant et je pense que d'autres personnes ont aussi vu l'humour absurde qu'il y avait là dedans. Trouver des trous de sécurité dans le noyau est excitant. Mais comme il y a beaucoup de trous, le sentiment général qui domine est plutôt celui de la dépression :-)

Question 05 : J'ai lu ce message d'Ingo Molnar sur le site LWN. Penses-tu que les experts en sécurité ont une mentalité différente de celle des développeurs du noyau ? Y a t-il y des inconvénients (psychologiques ou autres) à être un créateur d'exploits ?

Spender : Bon, je suis un développeur moi aussi mais je comprends que, particulièrement dans le domaine de la sécurité, on doit avoir un mode de pensée offensif. Parfois, cela signifie faire réellement le travail qui consiste à rechercher une vulnérabilité et à l'exploiter. Cela signifie collaborer avec d'autres personnes qui font des recherches similaires. Cela signifie ne jamais se reposer sur ses lauriers, toujours évaluer son code et tenter activement de le percer.

Nous n'avons pas une mentalité du type : « Bon, on va juste écrire une fonction de sécurité quelconque, penser que ça marche, et nous auto-congratuler ». En matière de sécurité, quelqu'un qui se consacre entièrement au développement du noyau ne peut tout simplement pas lutter contre le talent de ceux qui se consacrent entièrement à la sécurité.

L'écriture d'exploits implique peut-être plus d'esprit créatif que de faire juste du développement normal. Mais non, nous n'avons pas plus de problèmes psychologiques que les développeurs normaux ;-)

grsecurity

Question 06 : Penses tu que ton dernier exploit aurait été possible avec un noyau ayant le patch grsecurity ?

Spender : Eh bien, pour commencer, nous n'avons pas encore sorti de patch pour le noyau 2.6.30 à l'heure actuelle. Comme c'est le 2.6.30 (ou le 2.6.30.1) qui contient la faille, alors aucun noyau paché avec grsecurity n'a été vulnérable. Maintenant, si on tente d'imaginer un scénario dans lequel le bug existerait pour le noyau 2.6.29.6, pour lequel il y a bien un patch grsecurity, alors il y a un certain nombre de choses qui s'interposeraient:

PaX UDEREF : Cela empêche tout simplement la vulnérabilité d'être exploitable. Non seulement cela protège contre le déréférencement des pointeurs à NULL, mais aussi contre tous les accès invalides de l'espace utilisateur par le noyau.
PaX KERNEXEC : C'est un effort pour supprimer toute possibilité d'exécution de code arbitraire par le noyau, tout comme c'est fait dans l'espace utilisateur. En plus de ça, cela oblige les sections du noyau qui sont marquées comme étant en read-only à être vraiment en lecture seule. Dans un noyau normal, les données en "read only" sont en fait inscriptibles. Le pointeur de fonction file_operation que j'ai modifié dans mon exploit existait dans cette région de la mémoire qui aurait du être en lecture seule. KERNEXEC aurait empêché cette modification. KERNEXEC entre aussi en jeu lorsqu'il s'agit d'éviter l'exécution ring 0 dans l'espace utilisateur, ce que mon exploit utilise également.
Hier, j'ai écrit un exploit de démonstration pour une autre vulnérabilité qui utilise le fait de forcer le noyau à exécuter du code en espace utilisateur. Pas besoin de déréférencement de pointeur NULL ! KERNEXEC se serait interposé et aurait empêché cela.
grsecurity HIDESYM : Ici on vise (de préférence en utilisant aussi le système de droits RBAC pour rendre /boot et /usr/src inaccessibles aux simples utilisateurs) à empêcher un attaquant de savoir où sont localisées les choses spécifiques qu'il - ou elle - veut attaquer.
Ce qui a fait que l'exploit Cheddar Bay était si petit et si simple était dû au fait que l'option CONFIG_KALLSYMS_AL était activée dans le noyau, ce qui donnait à l'attaquant une correspondance symbole -> adresse pour virtuellement tout ce qui l'intéressait. Sans cette information fiable sur quoi attaquer (donc sans provoquer de kernel panic et donc perte de la possibilité de l'exploiter), alors l'agresseur aurait sans doute eu besoin d'informations additionnelles venant d'une autre vulnérabilité. Un truc auquel je suis arrivé, et qui est maintenant PAX_USERCOPY, peut aussi aider dans ce domaine.

Question 07 : J'ai vu sur le site de grsecurity une critique féroce de LSM. J'ai aussi vu que LSM avait été modifié récemment pour permettre l'arrivée de modules de sécurité basés sur le chemin (TOMOYO). Penses-tu qu'il est possible d'avoir d'autres modifications de LSM de façon à pouvoir incorporer des bouts de grsecurity dans la branche principale du noyau ?

Spender : Nous ne sommes pas intéressés par le fait d'avoir des bouts de grsecurity dans la branche principale du noyau. Plusieurs fonctions de grsecurity apportent un effet additif qui n'existerait pas si seulement l'une de ces fonctions avait été implémentée. Par exemple la façon dont UDEREF et KERNEXEC travaillent ensemble pour empêcher à la fois l'exécution de code et l'accès aux données en espace utilisateur par le noyau. Ou les fonctions anti-bruteforce et anti-fuite d'information qui sont ajoutées dans grsecurity en support de la fonction de randomisation de l'espace d'adressage de PaX. On n'obtient pas la sécurité d'une défense en profondeur tant qu'on n'a pas la "profondeur".

Question 08 : De façon générale, considérant le rythme de développement rapide de Linux, est-il possible de maintenir un patch externe tel que grsecurity ?

Spender : Si tu n'es pas au courant des patchs de « test » sur lesquels nous travaillons continuellement, nous arrivons généralement à nous maintenir au contact de chaque nouvelle version stable du noyau Linux. Du fait de certaines contraintes de temps libre récemment, pour moi comme pour l'équipe PaX, nous n'avons pas encore le patch pour le noyau 2.6.30, mais c'est une exception plutôt qu'une règle. Le rythme de développement rend les choses difficiles, surtout pour une équipe de deux personnes. Sur le plan de la sécurité ce n'est également pas bon d'introduire 80 Mo de changements tous les trois mois dans un noyau censé être stable. Donc c'est malheureux qu'autant de notre temps soit consacré à ce travail de portage constant alors qu'il pourrait être mieux utilisé à implémenter de nouvelles technologies de sécurité.

Question 09 : Après le problème de sponsor de grsecurity à la fin de l'année dernière, il y a eu quelques courriels sur la liste de diffusion qui demandaient l'inclusion de grsecurity dans Linux. Les réponses de Linus ou de Robert Hancock ont été de dire que le patch devait être découpé en petites parties ayant du sens. Que penses-tu de cette option ? Y-a-t-il un vrai effort en ce moment pour incorporer grsecurity dans la branche principale ?

Spender : Tu noteras que dans toutes les demandes d'inclusion de grsecurity dans la branche principale, il manque un truc important : notre participation à la discussion. Dit simplement, les gens demandant l'inclusion en mainline ne parlent pas pour nous et de toute façon cela ne nous ferait pas gagner du temps. Nous finirions pas perdre notre temps à débattre avec des gens qui ne sont pas experts en sécurité sur comment faire telle chose dans le noyau alors que nous préférerons juste faire cette chose.

Question 10 : Certains disent que vous ne voulez pas incorporer grsecurity dans la branche principale car cela vous ferait perdre votre gagne-pain. Est-ce vrai ? Gagnez-vous beaucoup d'argent avec grsecurity en tant que patch externe ?

Spender : Ce n'est pas vrai. Si grsecurity était ma principale source de revenu alors je serai un SDF. J'aimerais bien parvenir à gagner beaucoup d'argent avec ça (nous accueillons toujours volontiers de nouveaux sponsors), mais ce n'est tout simplement pas vrai. J'ai gagné juste assez l'an dernier, en provenance de grsecurity, pour payer le matériel de test et la facture de la bande passante (qui a augmenté cette année, merci à notre fournisseur). Donc grsecurity n'est pas quelque chose qui m'enrichit.

Question 11 : J'ai vu le graphique impressionnant sur l'influence de grsecurity. Avais-tu jamais pensé à poser des brevets sur tes développements logiciels ? Que penses tu des brevets logiciels en général ?

Spender : Je peux seulement parler pour moi, mais je n'ai aucun intérêt, ni plan, pour breveter quoi que ce soit. Et de façon générale, je n'aime pas les brevets logiciels.

OpenBSD

Question 12 : En ce qui concerne la sécurité que penses-tu de la qualité générale du code du noyau OpenBSD par rapport à la qualité générale du code du noyau Linux ? La réputation de sécurité d'OpenBSD est-elle vraiment méritée ?

Spender : Tout d'abord, en tant que déclaration générale à propos d'OpenBSD (car il y a en fait deux questions là), je ne les trouve plus vraiment utiles (si tant est qu'il l'ait jamais été). Il y a quelques années, quand j'ai commencé à travailler sur grsecurity, OpenBSD avait la mentalité que les revues de code, à elles seules, pouvaient les protéger...et ils ont découvert que cette stratégie ne marchait pas très bien. Depuis ce temps, ils ont ajoutés des mesures défensives, mais plusieurs années après d'autres dans l'industrie. Par exemple cela ne fait pas très longtemps qu'ils gèrent les binaires PIE. Leur palmarès de sécurité dans l'installation par défaut est plus une blague qu'autre chose, car presque rien n'est activé. Si tu n'a presque rien d'activé, alors il n'y a presque rien à protéger... Ce n'est pas vraiment une déclaration de sécurité.

La qualité de leur code est probablement meilleure que celle de Linux (je ne perds pas mon temps à l'auditer), mais leur noyau est aussi plus primitif sous de nombreux aspects que Linux. Donc cela revient à comparer des pommes et des oranges. La rapidité de développement de Linux est aussi bien plus grande. Donc je ne suis pas vraiment en train de louer la qualité du code de Linux ici. Je souligne juste que je ne pense pas que cela importe vraiment si votre code est impressionnant, si en même temps presque personne ne l'utilise. La même chose peut être avancée en ce qui concerne Linux par rapport à Windows. Donc il vaudrait mieux dire que les développeurs travaillent sur ce qui les intéresse, et que certains systèmes d'exploitations sont plus utilisés que d'autres.

Enfin, il doit être dit qu'au moins Linux est développé en grande partie par les gens qui l'ont créé et qui comprennent plus ou moins son code. De son côté OpenBSD a hérité d'un code que ses développeurs ne comprennent toujours pas vraiment aujourd'hui.

Question 13 : J'ai entendu dire que chaque fois qu'un problème de sécurité était découvert, les développeurs d'OpenBSD utilisaient grep dans leur base de code de façon à corriger toutes les occurrences de ce problème. Pourquoi les développeurs Linux ne font-ils pas la même chose ?

Spender : En premier lieu, la plupart des classes de bugs échappent à grep. Je ne suis pas vraiment sûr que les développeurs Linux n'essayent pas de trouver eux aussi les bugs du même type quand une vulnérabilité importante est découverte. J'ai vu certains commits récemment, en réponse à l'exploit Cheddar Bay, qui suggèrent que certains développeurs Linux sont en train de faire l'effort de trouver les autres cas de cette classe de bug particulière. Cependant il doit aussi être noté qu'au moins les développeurs OpenBSD acceptent la notion de faille de sécurité. La politique Linux officielle est qu'aucun bug n'est plus important qu'un autre (ce qui est à la fois mensonger et décevant à voir dans un système d'exploitation utilisé aussi largement).

Question 14 : Que pensez-vous des fonctions strlcpy et strlcat qui sont utilisés dans OpenBSD ? Pensez-vous qu'elles devraient être ajoutées dans la glibc et utilisées dans Linux ?

Spender : Tous ceux qui veulent remplacer les dépassements de tampons exploitables par des troncatures de chaînes exploitables sont libres d'ajouter leur propre copie de strlcpy et strlcat dans leur code source. Je ne vois aucune raison pour ajouter ces fonctions dans la glibc.

Question 15 : Y-a-t-il des leçons venant d'OpenBSD qui pourraient être adoptées par les développeurs Linux. Ou bien les deux systèmes d'exploitation sont ils trop différents pour adopter les mêmes méthodes ?

Spender : Quelqu'un a suggéré que j'ai dit que la leçon à tirer de tout ça c'est que « le code écrit par des abrutis sera utilisé seulement par des abrutis » ... mais je suis plus gentil que ça ;) Ce n'est pas une question utile que de faire des hypothèses à ce sujet car nous avons vu plus d'une fois que le développement de Linux suit son chemin sans dévier.

Linux

Question 16 : Vous avez déclaré que les bugs de sécurité du noyau étaient corrigés en catimini par les mainteneurs de la branche -stable. Pouvez-vous expliquer pourquoi il est important de dédier des ressources à la classification des bugs ? Est-il vraiment possible de correctement classifier les bugs de sécurité ? Pourquoi essayer de classifier les bugs si les utilisateurs appliquent tous les correctifs ?

Spender : c'est important parce que quand les bugs ne sont pas classifiés correctement, on ne peut pas estimer précisément le risque. Il n'est pas possible de classifier de façon parfaite les bugs de sécurité (il y aura toujours quelqu'un avec une astuce inédite), mais il est certainement possible de faire bien mieux que de tout classer en déni de service tant qu'il n'y a pas un exploit public. Les vendeurs Linux se font des centaines de millions de dollars de revenu, ils n'ont donc pas d'excuse quand ils n'en dépensent pas une fraction pour prendre sérieusement en charge les problèmes de sécurité. Dans un monde idéal tout le monde appliquerait les correctifs, mais dans le monde réel cela ne se passe pas comme ça. Pourquoi devriez-vous appliquer un correctif qui ne vous concerne pas ? Il y a tout simplement trop de bugs signalés dans le noyau Linux pour que les gens puissent faire des mises à jour chaque fois qu'un nouveau bug est annoncé. Ils seront certainement plus empressés de faire une mise à jour s'ils sont affectés par un exploit root à distance qui désactive SELinux, plutôt que si c'est encore un déni de service dans le code d'un pilote qui n'est même pas compilé dans leur noyau.
Donc il est important de fournir aux gens une information adéquate afin qu'ils puissent évaluer précisément le risque pour leur configuration particulière.

Question 17 : Pensez-vous que le noyau Linux à besoin d'un responsable sécurité ? Si oui et si vous étiez le détenteur du poste, avec des pouvoirs réels, quelles seraient vos premières décisions ?

Spender : Je ne suis pas sûr qu'un seul responsable sécurité serait vraiment efficace au sein de la communauté du noyau Linux. La performance est reine et beaucoup des développeurs ne comprennent tout simplement pas la sécurité comme peuvent le faire les gens qui sont dans cette industrie. J'imagine que quiconque ayant un boulot comme celui-là deviendrait incroyablement frustré.
Si j'avais un pouvoir réel et si j'avais une solution aux problèmes que provoque le modèle de développement actuel, et tout ça en gardant les fans du modèle actuel contents, je me concentrerais là-dessus. Malheureusement je ne suis pas sûr qu'une telle solution existe.

Question 18 : Dans le passé vous avez critiqué Linus Torvalds à propos de la sécurité du noyau. Que pensez-vous de ses décisions dans ce domaine ? Et de ses compétences techniques en ce qui concerne le domaine spécifique de la sécurité ? Et à propos de son leadership général du projet ?

Spender : Il peut à l'occasion comprendre les problèmes de sécurité mieux que les autres développeurs, mais la sécurité ne fait pas partie de ses buts principaux. De la même façon, je ne suis pas certain qu'il comprenne vraiment sa base utilisateur, en particulier les utilisateurs en entreprise. Mais cela va sans doute avec la commercialisation générale de Linux. C'est le boulot des vendeurs de s'inquiéter de choses comme ça et c'est le boulot de Linus de juste s'inquiéter de diriger le noyau vers ce qu'il estime être le mieux.

Ses idées en ce qui concerne la sécurité ont conduit à la politique officielle des développeurs du noyau qui est de ne pas mentionner les informations de sécurité dans les changelogs et de traiter tous les bugs de la même façon. Ses idées sont destructrices. Ce n'est pas juste moi qui me plaint à ce propos, même les vendeurs admettent que tenter de cacher les bugs de sécurité rend leur travail de rétro-portage des corrections de sécurité bien plus difficile.

Question 19 : Afin d'avoir un système d'exploitation vraiment sécurisé, pensez-vous que nous devrions utiliser un autre paradigme (micro-noyau, système d'exploitation managé, système d'exploitation vérifié avec des méthodes formelles), ou bien l'architecture actuelle du noyau Linux est-elle compatible avec une sécurité réelle ?

Spender : Le « maillon faible », la chose qui a la confiance du système de sécurité, c'est le noyau. Donc le noyau doit être protégé contre lui-même, ça c'est sûr. Nous avons passé beaucoup de temps à travailler sur ce sujet (spécialement l'équipe PaX), et il y a d'autres super trucs qui sont planifiés dans un futur proche. Donc à la question de savoir si cette auto-protection peut se faire au sein de l'architecture actuelle ou pas, vous devrez attendre de le voir par vous-même ;)

Merci pour les questions et j'espère que je ne vais pas provoquer trop de flame wars :)

Brad

Aller plus loin

grsecurity (20 clics)
Exploit local dans le noyau Linux 2.6.30 (25 clics)
La fin de Grsecurity ? (janvier 2009) (11 clics)

# Surpris plus qu'énervé

Posté par MrAzerty le 24 juillet 2009 à 17:05. Évalué à 10.

J'ai tellement été scié par sa première réponse que j'ai eu du mal à me concentrer sur le reste.
- [^] # Re: Surpris plus qu'énervé
  
  Posté par Prae le 24 juillet 2009 à 17:15. Évalué à 6.
  
  D'un autre côté pour la réponse #1, il a pas totalement tord...
  Certes les applis windows, en général, répliquent les DLL (systèmes) dans leurs propres installs...
  - [^] # Re: Surpris plus qu'énervé
    
    Posté par Thomas Douillard le 24 juillet 2009 à 17:28. Évalué à 8.
    
    C'est surtout que ça ne rend absolument pas le reste de ce qu'il a à dire moins pertinent. Techniquement au moins. Pour le reste, en ce qui me concerne c'est des choix personnels et il fait ce qu'il veut.
    - [^] # Re: Surpris plus qu'énervé
      
      Posté par Prae le 24 juillet 2009 à 18:48. Évalué à 4.
      
      Sauf erreur de ma part (ou mal interprétation) je n'ai pas soutenu le contraire.
      Ses autres réponses sont pertinentes en tout point, notamment le passage sur un "security manager" au niveau du développement kernel.
  - [^] # Re: Surpris plus qu'énervé
    
    Posté par Olorim le 24 juillet 2009 à 17:33. Évalué à 3.
    
    Je me verrai mal lui jeter la pierre : je suis moi même sur Windows... pour les jeux (après une journée passé à pataugé dans les détail technique, le soir, j'ai pas envi...) : suivant > Suivant...> Terminé. C'est facile et les jeux sont joli et optimisés.
    Après, je ne suis pas d'accord avec ses histoires de mises à jour, parce que c'est autant ci-ce n'est pire sur Windows.
    
    Je ne connait pas son application, aussi, je ne me permettrai pas de la critiquer. Pourtant, je trouve ses accusations un peut gratuites : je suis d'accord, le métier de la sécurité, c'est pas le même que celui de développeur, de même que le métier d'administrateur système. Aucun de ces métiers n'est, à mon sens plus compliqué où important. C'est pourquoi je trouve mal avisé de critiquer quelqu'un pour un sujet qui ne fait pas entièrement parti de son métier.
    
    En ce qui concerne la position de Linus Thorvalds sur le traitement des bestioles, je serai asse d'accord avec Brad Spengler : un bug provoquant la fermeture d'une fenêtre est moins prioritaire qu'un bug qui détruit une parti d'un système de fichier...
    - [^] # Re: Surpris plus qu'énervé
      
      Posté par Prae le 24 juillet 2009 à 18:50. Évalué à 5.
      
      > Aucun de ces métiers n'est, à mon sens plus compliqué où important.
      
      Difficile d'avoir les deux casquettes en même temps;
      Être développeur de feature et aussi développeur "sécurité", c'est assez rare.
      Il est parfois bon d'être un bon dev-feat ou un dev-sec, qu'un demi-dev-feat && demi-dev-sec. (c'est comme les trucs tout en un: ca fait tout mais généralement moins bien que celui qui ne fait qu'une chose mais bien)
  - [^] # Re: Surpris plus qu'énervé
    
    Posté par tinou le 24 juillet 2009 à 17:37. Évalué à 6.
    
    Il peut ne pas vouloir mettre à jour les xxx librairies qui vont avec l'upgrade de son application, mais quand il a juste à utiliser [insérez ici votre gestionnaire de paquet préféré], c'est complètement ignorer le boulot des développeurs des distributions qui se sont tapé le boulot pour lui. Ça discrédite pas mal le personnage.
    - [^] # Re: Surpris plus qu'énervé
      
      Posté par gentildemon le 25 juillet 2009 à 01:53. Évalué à -1.
      
      Sauf que pour mettre à jour une application, sous Linux, faut mettre à jour tout le système!
      
      Des raisons pour mettre à jour une application, il y en a plein contrairement à ce que veulent faire croire certains.
      
      On peut avoir besoin de la dernière version d'OpenOffice pour lire un fichier envoyé par un contact (ami, client, fournisseur, etc.), vouloir mettre à jour ffmpeg ou un player vidéo pour pouvoir lire une vidéo dans un codec spécial, vouloir mettre à jour un jeu pour se connecter au(x) serveur(s), ...
      - [^] # Re: Surpris plus qu'énervé
        
        Posté par daemontux le 25 juillet 2009 à 03:33. Évalué à 9.
        
        "Sauf que pour mettre à jour une application, sous Linux, faut mettre à jour tout le système!"
        Heu non, il suffit de mettre à jour les dépendances de l'application (au moins sous Debian et dérivées).
        
        Pour un spécialiste de la sécurité qui prône des mises à jour de sécurité rapides pour le noyau, c'est un peu bizarre de pas vouloir mettre à jour aussi ses applis (après tout les failles c'est pas que dans le noyau qu'on en trouve).
        
        [^] # Re: Surpris plus qu'énervé
        
        Posté par pasBill pasGates le 25 juillet 2009 à 03:53. Évalué à 2.
        
        Oui, et le probleme est que quand l'appli est un tant soit peu importante, le nombre de dependances devient assez enorme(dependances en cascade).
        
        Quand a ne pas vouloir mettre a jour ses applis, desole mais il y a une sacree difference entre installer les mises a jour de securite et devoir se taper des mises a jour de tout et n'importe quoi pour pouvoir utiliser un traitement de texte ou un programme de dessin.
        
        [^] # Re: Surpris plus qu'énervé
        
        Posté par Yannick le 25 juillet 2009 à 05:30. Évalué à 3.
        
        Oups, une faille dans libpng !
        
        Quand à ne pas vouloir mettre à jour ses applications, désolé mais il y a une sacrée différence entre installer la mise à jour de libpng et se taper les mises à jours de tout et n'importe quoi qui dépend de libpng.
        
        ;-)
        
        [^] # Re: Surpris plus qu'énervé
        
        Posté par geb le 25 juillet 2009 à 22:32. Évalué à 8.
        
        Les mises à jour én général != les mises à jours de sécurité.
        
        Sur debian (et je doute que ce soit le seul exemple), tu peux choisir de n'installer que les
        dernières. Cela se fait simplement en activant *que* les depots de sécurité.
        
        Ces mises à jours sont sensées être non intrusives, ne patcher qu'un point précis du code,
        à l'inverse d'une montée en version. Si ces mises à jours ont lieu dans une monté une version, on backporte.
        
        Cela aide d'ailleurs à comprendre pourquoi Brad suggère de marquer d'un flag particulier les bugs corrigés relevant de la sécurité: Dans le cadre d'un noyau stable, on ne peut pas tout backporter, comment alors trier ce qui relève ou non de la sécurité et qu'il conviendrait de backporter en priorité ?
- [^] # Re: Surpris plus qu'énervé
  
  Posté par gerard delafond le 24 juillet 2009 à 17:52. Évalué à 7.
  
  Je fais la même analyse que lui, même si j'en tire une conclusion opposée.
  
  Certes, les systèmes basés sur Linux sont perfectibles, mais les autres OS le sont à peu près autant (j'ai voulu faire une opération basique récemment sur un Mac, et j'ai terminé en ligne de commande, tellement les outils graphiques donnaient un résultat inexploitable, sans parler des drivers windows, dont je pourrais multiplier les exemples de dysfonctionnements allant jusqu'à l'installation impossible).
  
  En revanche, je préfère continuer à m'accrocher plutôt que de jeter l'éponge, car, pour moi, la licence passe avant tout.
  
  Et je continue à rêver d'une distribution où tous les sous-systèmes seraient au point (je pense au son, mais aussi au mode graphique piloté par le noyau, ou à l'hibernation, etc.), tous les applicatifs en cohérence avec ces sous-systèmes, le tout accompagné d'un système de gestion de paquets sans faille, permettant des mises à jour qui ne cassent pas tout, etc.
  
  Le problème, c'est que la faiblesse des systèmes basés sur Linux réside essentiellement dans les distributions, qui ne parviennent pas à tout tester ni tout anticiper.
  
  En revanche, lorsque les fabricants veulent faire un Linux dédié à une tâche précise, ils parviennent très bien à leurs fins, ce qui confirme la qualité intrinsèque du produit.
  - [^] # Re: Surpris plus qu'énervé
    
    Posté par kursus_hc le 03 août 2009 à 18:54. Évalué à 2.
    
    Et je continue à rêver d'une distribution où tous les sous-systèmes seraient au point (je pense au son, mais aussi au mode graphique piloté par le noyau, ou à l'hibernation, etc.), tous les applicatifs en cohérence avec ces sous-systèmes, le tout accompagné d'un système de gestion de paquets sans faille, permettant des mises à jour qui ne cassent pas tout, etc.
    
    C'est aussi mon cas. Je me rappelle avoir eu un fol espoir quand un mec possédant plus de pognon qu'il n'est possible d'en dépenser en une vie a déclaré vouloir créer sa distribution.
    
    J'imaginais déjà les centaines de postes de travail et les développeurs qui vont avec travailler dans la joie et le plaisir au système qui allait révolutionner le monde.
    
    Bon bah.. tant pis !
- [^] # Re: Surpris plus qu'énervé
  
  Posté par reno le 26 juillet 2009 à 02:25. Évalué à 2.
  
  Si c'est vraiment le cas, fais attention tu es a la frontière entre l'utilisation de Linux pour des raisons objectives au 'zélotisme'.
  
  Ses raisons pour utiliser Windows me semblent très raisonnable:
  1) il utilise Windows pour les jeux et je le comprends tout à fait: il y a plein de jeux sur PC qui n'existent pas sur console et qui ne tournent que sous Windows.
  
  2) pour les mise à jour, la c'est plus subjectif car la mise a jour des applications sous Windows est vraiment mal fichu, mais d'un autre coté on entend souvent parler de mise a jour de distribution Linux qui cassent chez certains utilisateurs ou de nouvelle version de distribution qui intègrent des fonctionnalités pas stables..
  
  Donc les deux sont mauvais, juste mauvais de manière différentes.
  - [^] # Re: Surpris plus qu'énervé
    
    Posté par Sytoka Modon (site web personnel) le 26 juillet 2009 à 10:40. Évalué à 2.
    
    2) -> Changer de distribution.
    
    Sous windows, c'est vrai que c'est plus simple, si tu n'est pas admin, il n'y a quasiment pas de mise à jour... C'est sur qu'avec cela, tu ne casses rien, ce sont les virus qui s'en charge ;-)
    - [^] # Re: Surpris plus qu'énervé
      
      Posté par Littleboy le 26 juillet 2009 à 12:25. Évalué à 2.
      
      Sous windows, c'est vrai que c'est plus simple, si tu n'est pas admin, il n'y a quasiment pas de mise à jour...
      
      Gniii??
- [^] # Re: Surpris plus qu'énervé
  
  Posté par xnx le 02 août 2009 à 13:15. Évalué à -4.
  
  Pareil pour moi, on sent le gamin qui n'a aucune conscience, le logiciel libre n'est qu'accessoire pour lui. C'est bien dommage. On sent le potentiel technique, mais ça s'arrête là.
  - [^] # Re: Surpris plus qu'énervé
    
    Posté par kursus_hc le 03 août 2009 à 18:59. Évalué à 2.
    
    Tu ne sens rien du tout, tu ne le connais pas, tu juges.
    
    Le logiciel libre n'est qu'accessoire pour lui ? Reviens quand tu auras contribué autant que lui.
    
    Inutile.
# C'est Patrick_g !

Posté par Pierre Jarillon (site web personnel) le 24 juillet 2009 à 17:28. Évalué à 6.

Bravo Patrick : De très pertinentes questions ont amené de bonnes réponses. Je ne suis pas certain que Brad ait répondu dans le cas contraire.

Pour avoir suivi de loin la rédaction de cet article, sa traduction n'a pas été une sinécure car pour éviter tout faux-sens, les relecteurs et modérateurs de Linuxfr ont été mis à contribution.

Bravo encore pour ce scoop !
- [^] # Re: C'est Patrick_g !
  
  Posté par jm trivial (site web personnel) le 24 juillet 2009 à 17:30. Évalué à 2.
  
  Vous ne laissez pas une version en langue anglaise, afin d'avoir un plus large public ?
  - [^] # Re: C'est Patrick_g !
    
    Posté par patrick_g (site web personnel) le 24 juillet 2009 à 17:44. Évalué à 6.
    
    Ben ce serait bizarre de poster un article en anglais sur linuxfr non ?
    J'ai proposé ça sur la mailing list modéro mais c'est vrai que je ne savait absolument pas comment faire pour éviter d'avoir une grosse news en anglais en plein milieu du site.
    Si tu a une solution je suis ouvert. Je peux envoyer l'interview originale en anglais à qui me le demande (envoyer un mail sur mon adresse dlfp).
    - [^] # Re: C'est Patrick_g !
      
      Posté par Thomas Douillard le 24 juillet 2009 à 17:51. Évalué à 2.
      
      Je vois pas le problème d'avoir la VO en plus de la VF ... Ou la mettre sur un wiki quelquonque et mettre le liens dans la news.
      Sinon vous pouvez pas essayer de la faire publier ailleurs, genre sur slashdot ?
      
      C'est super d'avoir la traduction, mais tant qu'à avoir la version anglaise, autant s'en servir amha ...
    - [^] # Re: C'est Patrick_g !
      
      Posté par Thomas Douillard le 24 juillet 2009 à 17:58. Évalué à 3.
      
      Autre raison, avoir la source des propos c'est pour moi presque une question de politesse.
      
      Sans vouloir le moins du monde dénigrer la qualité du travail de traduction effectué, une traduction ça reste une traduction. C'est toujours potentiellement utile pour ceux qui le peuvent de pouvoir se référer à la source.
      - [^] # Re: C'est Patrick_g !
        
        Posté par Olorim le 24 juillet 2009 à 18:03. Évalué à 1.
        
        Pourquoi ne pas poster le même article dans la langue de Shakespeare sur un site anglophone et inclure le lien de ce même article dans la dépêche ci-dessus? Un problème de licence ;) ? Ou une histoire d'exclusivité?
        
        [^] # Re: C'est Patrick_g !
        
        Posté par Thomas Douillard le 24 juillet 2009 à 18:06. Évalué à 3.
        
        En l'occurence pour la "licence" t'as juste besoin de demander à l'auteur, et pour l'exclusivité je pense (mais je parle pas pour eux) que l'équipe du site s'en contrefiche comme de sa première chemise (oui, l'équipe a une chemise) :)
    - [^] # Re: C'est Patrick_g !
      
      Posté par jm trivial (site web personnel) le 24 juillet 2009 à 18:05. Évalué à 0.
      
      Je rejoins une partie des propos de Thomas Douillard. Un lien en fin d'article vers une version html (ou txt) de l'interview dans sa version originale apporterait encore plus de poids à cette interview de qualité.
      - [^] # Re: C'est Patrick_g !
        
        Posté par patrick_g (site web personnel) le 24 juillet 2009 à 18:19. Évalué à 4.
        
        Je peux essayer de faire un commentaire dans cette dépêche en mettant l'interview en VO ?
# Très drôle :)

Posté par Dorian le 24 juillet 2009 à 18:05. Évalué à 0.

Franchement je sais pas si c'est le traducteur qui a donné ce ton là, mais ce Brad est très drôle.

Mais ca 1ére réponse m'empêche de le prendre vraiment au sérieux pour le reste.
« En fait, le monde du libre, c’est souvent un peu comme le parti socialiste en France » Troll
- [^] # Re: Très drôle :)
  
  Posté par pasBill pasGates le 24 juillet 2009 à 18:51. Évalué à 2.
  
  Moi au contraire je trouves assez revelateur qu'un gars avec de fortes connaissances en securite utilise Vista et Win7 comme son desktop principal.
  
  Ca met a mal bcp de prejuges que certains ont ici, dur de dire qu'il le fait parce que c'est de la vente liee, parce qu'il ne sait rien utiliser d'autre, ...
  - [^] # Re: Très drôle :)
    
    Posté par patrick_g (site web personnel) le 24 juillet 2009 à 19:03. Évalué à 9.
    
    Ouais enfin il parle surtout de l'install des softs et du nombre de jeux dispos...alors bon ton lien avec une supposée super sécurité de Windows je ne le vois pas trop.
    - [^] # Re: Très drôle :)
      
      Posté par Thomas Douillard le 24 juillet 2009 à 19:25. Évalué à 6.
      
      Je pense pas que PbPg parlait de sécurité, son point (de ce que j'ai compris) c'était de dire que même quelqu'un de techniquement bon peut préférer utiliser windows à Linux pour des raisons d'utilisabilité. Et que ce n'était clairement pas parce qu'il n'avait pas le choix.
      
      Donc que prétendre que la raison pour laquelle Mme Michu n'utilisait pas Linux c'était uniquement la vente liée ou la méconnaissance des alternatives n'était pas valable.
      
      (je paraphrase)
    - [^] # Re: Très drôle :)
      
      Posté par pasBill pasGates le 25 juillet 2009 à 02:41. Évalué à -2.
      
      Mon propos n'est pas de dire que Windows est 236236x plus sur que Linux, mais de dire qu'un type de son genre n'utiliserait certainement pas un OS completement troue, ce qui demonte l'argument de nombre de gens ici disant que Windows est une passoire.
      - [^] # Re: Très drôle :)
        
        Posté par mlinux le 25 juillet 2009 à 12:47. Évalué à 1.
        
        C'est pas tellement que Linux ou Windows soient une passoire, je pense qu'il veut juste se simplifier la vie, avoir des trucs qui marchent du 1er coup quoi, clic, clic, Go ;=)
  - [^] # Re: Très drôle :)
    
    Posté par Antoine le 24 juillet 2009 à 19:28. Évalué à 4.
    
    En même temps ça ne signifie pas qu'il trouve Windows plus sûr que Linux. Peut-être qu'il n'en a tout simplement rien à faire de la sécurité de sa station de travail, ou que les arguments qu'il a donné prime sur la sécurité (ce qui est compréhensible).
    
    Si son but était d'avoir une machine sûr la logique voudrait qu'il utilise son propre système, dont il peut évaluer la robustesse. À moins qu'il se dise « Windows ne peut pas être moins sûr que Linux+grsecurity », ce qui est peu probable, malgré son sens de l'humour.
    
    Je cherche pas à dire que Linux est plus sûr que Windows, je m'en cogne personnelement. Par contre le raisonnement de ta première phrase, qui en gros consiste à dire que si ce mec utilise Windows, c'est qu'il doit penser que Windows est aussi sûr que Linux, tient pas debout.
    
    Linus Torvald a longtemps utilisé Windows dans les évènements publics, cela veut-il dire qu'il trouve le design de Windows meilleur que celui de Linux ? J'en doute. Pourtant c'est un expert reconnu en design d'OS.
    
    Quant aux raisons pour lesquels il utilise Windows, elles sont détaillées dans l'article, donc je vois pas le rapport avec la vente liée, etc. Il a ses propres raisons qui justement sont différentes des préoccupations des utilisateurs victimes de la vente liée par exemple. Ceux pensent que Windows n'a absolument aucun avantage sur Linux sont de mauvaise foi (ou ont des connaissances très limité en informatique), là encore je vois pas l'intérêt de le répéter.
  - [^] # Re: Très drôle :)
    
    Posté par patrick_g (site web personnel) le 24 juillet 2009 à 20:28. Évalué à 10.
    
    >>> Moi au contraire je trouves assez revelateur qu'un gars avec de fortes connaissances en securite utilise Vista et Win7 comme son desktop principal.
    
    J'ai reçu un mail de Spender qui a vu qu'il y avait des commentaires dans la dépêche à propos de son utilisation de Windows :
    
    I saw some questions on there in the comments about why I would use
    Windows if I'm so interested in security. Though my choice to use the
    OS as mentioned was for usability/productivity purposes, I do a number
    of things on Windows to increase security compared to the default
    install:
    
    I browse/IM etc within a virtual machine. DEP (the windows equivalent
    of PaX's PAGEEXEC) is forced on for every application (by default it's
    not enabled on things like Firefox or Office). I also enable a new,
    little-known feature called SEHOP. I've also written a utility that
    displays what loaded DLLs have ASLR disabled and can modify their
    binaries so that ASLR is turned on.
    
    The machine is NATted behind a Linux machine running iptables.
    
    I don't have any need for Anti-Virus software, and with my
    reverse-engineering background can inspect binaries I believe are
    suspicious. I then can then take a VM snapshot, run the binary, and
    revert it afterwards.
    
    Actual grsecurity development of course is done on either a real Linux
    box or a Linux VM, and I always have a number of SSH sessions open to
    Linux machines every day.
    
    You can post this response if you feel it's useful :)
    
    -Brad
    - [^] # Re: Très drôle :)
      
      Posté par mscestdelamerde le 26 juillet 2009 à 16:07. Évalué à 1.
      
      Donc en resume il ne fait pas du tout confiance a windows niveau securite car sa machine desktop windows est derriere une machine linux. Il est fort probable que de tout de facon pour lui aucun OS n'est securise mais sa premiere ligne de defense c'est un linux.
      
      Quel dommage toute la belle theorie de pbpg qui tombe a l'eau :).
- [^] # Re: Très drôle :)
  
  Posté par arnaudus le 24 juillet 2009 à 20:33. Évalué à 8.
  
  Il est drôle... certainement un peu bizarre, certes, mais il ne fait pas vraiment rire, si?
  
  Comme tu dis, on se prend une grosse claque dès la première réponse. S'il avait dit "J'utilise Windows parce que bien configuré, le niveau de sécurité est identique à un Linux patché", on aurait pu se lancer dans le troll. Mais là, ça me parait tellement gros que j'ai du mal à y croire, on a l'impression d'être face aux arguments du gros Windowsien bien lourd qui n'a jamais touché une distrib Linux de sa vie. Est-ce que ce gusse ne serait pas un chouilla cynique? Peut-être que cracher sur la qualité technique du noyau ne lui suffit pas, il faut aussi qu'il montre que Linux est tellement mauvais à ses yeux qu'il préfère utiliser n'importe quoi? Moi, ce qui me parait totalement incohérent, c'est de ne pas appliquer sur son propre PC le fruit de son travail acharné pour rentre Linux moins vulnérable. Humainement, je n'arrive pas à m'expliquer ça, un peu comme si un dev bénévole OpenOffice utilisait Word à la maison : rien à faire, il y a quelque chose qui ne colle pas. D'ici à penser que ce mec est soit fou, soit un gros troll velu, il n'y a qu'un pas que je ne m'amuserais pas à franchir, même à cloche-pied.
  
  Sur le reste, je me méfie toujours un peu du côté clown cynique et méprisant. Il s'est construit un personnage, et il joue son rôle; c'est en quelque sorte son fonds de commerce. En s'affichant ostensiblement comme un ennemi des devs Linux (pas dur de se faire des ennemis en insultant les gens à longueur de journée), il se désolidarise complètement du développement du noyau (c'est très visible sur cette histoire de patch : il a clairement le cul entre deux chaises sur cette question, et il préfère botter en touche). Ça lui permet de se garder le rôle du redresseur de tords et de mener le jeu, puisqu'en choisissant les exploits qu'il publie, il décide purement et simplement de l'emploi du temps des développeurs du kernel. Bref, à le lire, on a l'image d'un type extrêmement compétent, extrêmement intelligent, mais qui joue à des jeux dangereux que j'ai du mal à trouver drôles. En tout cas, si je bossais sur le noyau, je ne trouverais pas ça drôle du tout.
  - [^] # Anti-Windowsiens primaire
    
    Posté par Zenitram (site web personnel) le 24 juillet 2009 à 22:14. Évalué à 4.
    
    Mais là, ça me parait tellement gros que j'ai du mal à y croire, on a l'impression d'être face aux arguments du gros Windowsien bien lourd qui n'a jamais touché une distrib Linux de sa vie.
    
    Mais bordel, arrêtez de prendre les Windowsiens pour des neuneus.
    Certes, plein de monde l'a "par défaut", mais aussi plein de monde l'a "par choix".
    
    Il vous faut qui pour comprendre que Linux Desktop est chiant quand on a pas envie de s'emmerder? Le mec, ce n'est pas un petit gars comme moi dans son coin (qui pense exactement la même chose), c'est le développeur de grsecurity!!!
    
    La seule chose que vous voulez faire, c'est imposer votre OS favori : si on ne le veut pas, vous décrétez qu'on est stupide.
    A la place de "nous" insulter, prenez note des remarques contre votre OS chéri, et corrigez les.
    
    Dites-vous que le mec, il connait sur le bout des doigts Linux, et pour son desktop, il préfère quand même Windows. C'est qu'il y a une raison, arrêtez d'éviter de vous en rendre compte.
    
    PS : je connais Linux, j'ai quasiment tout de libre chez moi, sauf l'OS. Pas par obligation, mais par choix (exactement les mêmes raisons que Brad)
    - [^] # Re: Anti-Windowsiens primaire
      
      Posté par Laurent Cligny (site web personnel) le 24 juillet 2009 à 22:23. Évalué à 9.
      
      Tout comme j'ai fais le choix inverse en laissant tomber Windows après 11 ans d'utilisation. Et tout comme toi j'imagine, je ne compte pas revenir en arrière, car s'il y a des problèmes ils sont moindres que ceux que j'ai eu avec Windows. Et je suis aussi beaucoup moins stressé :D
      
      Dans tous les cas il ne faut pas généraliser que ce soit un "camp" ou l'autre. Les zélotes font du bruit certes, mais ce n'est pas pour ça qu'ils représentent la majorité.
    - [^] # Re: Anti-Windowsiens primaire
      
      Posté par arnaudus le 24 juillet 2009 à 23:21. Évalué à 9.
      
      Justement, tu n'as pas compris le sens de mon intervention. Je n'ai jamais dit qu'il n'y avait pas de bonnes raisons d'utiliser Windows (même si je le pense :-P ), j'ai dit que les raisons qu'il donnait étaient indignes de lui. Relis juste:
      
      Je ne peux plus perdre des jours à essayer de faire fonctionner tel ou tel pilote
      
      Franchement? C'est pas débile ça? Si tu veux un Linux qui marche out of the box, tu te mets une Mandriva ou une Ubuntu sur du matos pas trop exotique. Dire qu'avec Linux on passe des jours à faire marcher un pilote, c'était peut-être vrai il y a 7 ou 8 ans, mais les choses ont quand même progressé! Quel est l'intérêt de balancer une phrase aussi trollogène comme si c'était une évidence?
      
      ou à essayer de récupérer un système complètement cassé parce que je ne l'ai pas mis à jour depuis un certain temps et que maintenant je veux mettre à jour Pidgin. Si je veux mettre à jour une application spécifique sur la machine alors je veux juste updater cette application - Je ne veux pas avoir à mettre à jour 140 autres dépendances.
      
      Et ça, c'est fin comme argument peut-être? Un spécialiste de la sécurité qui a la flemme de mettre à jour son système de temps en temps? Qui fait semblant de ne pas connaitre toutes les possibilités de faire ce qu'il veut faire avec n'importe quelle distrib? Qui met les distribs à releases tournantes et les distribs à release fixes dans le même panier? Qui nous fait croire qu'un 'apt-get upgrade' va laisser son système «complètement cassé»?
      
      Donc pour des raisons de maintien de ma santé mentale [...], j'utilise Windows.
      Bon, bah là il a carrément marché dans la merde de troll, non? Quelle argumentation pertinente, ouhlala. S'il est aussi incisif sur les ML kernel, Linus doit rester sans voix...
      
      Alors oui, franchement, un mec intelligent qui me sort des arguments intelligents pour expliquer pourquoi il a choisi d'être sous Windows, c'est respectable, et on a beau ne pas être d'accord, on peut poursuivre la discussion en développant les arguments, en pesant le pour et le contre, etc. Mais un gusse qui veut se faire passer pour un mec ouvert et rationnel, et qui te sort que Windows c'est mieux pour sa santé mentale, que chaque mise à jour explose son système et qu'il faut passer des jours à faire marcher des drivers, qu'est-ce qu'on doit en penser? À quoi ça sert d'être soi-disant hyper-compétent, et en parallèle de déballer sans honte des arguments que même Bill Gates n'oserait pas sortir?
      
      Surtout qu'en fait, il trouve trop compliqué de mettre à jour son système, mais il fait tourner son navigateur dans une machine virtuelle, il scanne les binaires à la recherche de problèmes de sécurité, et sa machine est derrière un serveur Linux configuré, patché et tuné comme une Golf GTI de Jacky.... Tu vas me dire qu'il se paye pas notre tronche?
      - [^] # Re: Anti-Windowsiens primaire
        
        Posté par liberforce (site web personnel) le 27 juillet 2009 à 20:06. Évalué à 4.
        
        Je ne peux plus perdre des jours à essayer de faire fonctionner tel ou tel pilote
        
        Franchement? C'est pas débile ça? Si tu veux un Linux qui marche out of the box, tu te mets une Mandriva ou une Ubuntu sur du matos pas trop exotique.
        
        Bienvenue il y a 6 ou 7 ans alors...
        http://linuxfr.org/~NickNolte/28598.html
      - [^] # Re: Anti-Windowsiens primaire
        
        Posté par Pierre Tramonson le 03 août 2009 à 13:32. Évalué à 0.
        
        Les pilotes ATI et le bordel des APIs sur la gestion du son sous Linux sont du passé pour toi ?
        
        D'autre part il le dit lui-même, il n'a pas envie de passer trop de temps à tenir son système à jour chez lui.
        Ceci dit il provoque un peu la réaction du linuxien, c'est rigolo ça marche :)
    - [^] # Re: Anti-Windowsiens primaire
      
      Posté par Grunt le 24 juillet 2009 à 23:53. Évalué à 3.
      
      Si seulement sous Linux on pouvait utiliser un soft récent (du genre Firefox 3.5 ou OpenOffice 3.0) sans mettre à jour des libs aussi utilisées par le système..
      
      Garder les libs en un seul exemplaire (donc une seule version) c'est très bien pour économiser de la place, mais vu le prix du Go ce n'est plus vraiment nécessaire.
      
      Et rien que pour ça, je comprends Brad Spengler.
      THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
      - [^] # Re: Anti-Windowsiens primaire
        
        Posté par Bapt (site web personnel) le 25 juillet 2009 à 00:53. Évalué à 3.
        
        Tu as d'autres OS libres qui te le permettent tout en ayant un vrai unix :)
        
        [^] # Re: Anti-Windowsiens primaire
        
        Posté par patrick_g (site web personnel) le 25 juillet 2009 à 01:13. Évalué à 7.
        
        Ben même sous Linux c'est possible. Je poste ce message sous Firefox 3.5 alors que ma distro est une Ubuntu Hardy.
        
        [^] # Re: Anti-Windowsiens primaire
        
        Posté par Grunt le 25 juillet 2009 à 01:53. Évalué à 1.
        
        Ouais, avec à chaque fois des bidouilles crades. Si tu veux installer une dizaines de softs récents sur une base stable, faut aller trifouiller des dépots et des préférences pratiquement à chaque logiciel.
        De surcroit, si le logiciel "machin" dépend de la lib "truc" dans une version récente, tout ton système se retrouve à utiliser la lib "truc" récente, même si elle est un peu buggée.
        THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
        
        [^] # Re: Anti-Windowsiens primaire
        
        Posté par Sytoka Modon (site web personnel) le 25 juillet 2009 à 02:47. Évalué à 10.
        
        Tu peux prendre la version binaire et la mettre dans /opt. Ensuite, un p'tit alias et c'est bon...
        
        C'est pas parce qu'on a apt-get qu'il faut aussi devenir neuneu !
        
        Au moins, avec /opt, les choses sont propres parce que sous Windows, il y a pas mal de polution de la base de registre qui ne sera jamais nettoyer ensuite.
        
        [^] # Re: Anti-Windowsiens primaire
        
        Posté par khivapia le 25 juillet 2009 à 15:08. Évalué à 4.
        
        tu sais pour Firefox il suffit de prendre l'archive binaire proposée sur le site de mozilla, l'extraire (généralement un double-clic) et puis un petit lien symbolique sur le bureau (cliquer, glisser par exemple, sisi ça marche) et zou on se retrouve avec la "facilité" de windows... Et en plus on n'a même pas besoin de toucher au système ni d'être root pour faire ça.
        
        [^] # Re: Anti-Windowsiens primaire
        
        Posté par Grunt le 25 juillet 2009 à 01:55. Évalué à 2.
        
        Oui, je suis de plus en plus tenté par un démon ces derniers-temps.
        THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
      - [^] # Re: Anti-Windowsiens primaire
        
        Posté par yellowiscool le 25 juillet 2009 à 02:02. Évalué à 3.
        
        C'est possible. Rien qu'avec un chroot déjà, cela laisse pas mal de possibilités. Sinon tu peut utiliser des versions compilés avec les librairies en static.
        
        C'est juste une question de volonté. Face à un aptitude dist-upgrade de temps en temps, je préfère ne pas avoir la dernière version de tel logiciel.
        Envoyé depuis mon lapin.
  - [^] # Re: Très drôle :)
    
    Posté par daemontux le 25 juillet 2009 à 03:49. Évalué à -1.
    
    Tout à fait d'accord. Je ne voudrais pas paraître impolis, mais au delà de ses compétences techniques probablement très bonnes, ce Brad Spengler m'a tout l'air d'être un gros con.
    
    On a à faire à un professionnel de la sécurité et il nous sort des clichés de kévin qui n'a jamais utilisé Linux en guise d'argument. S'il veut vraiment se donner des airs supérieurs en dénigrant le travail des autres, qu'il le fasse au moins sur des arguments valables.
    
    En fait, il me fait un peu penser à Hans Reiser (qui était lui aussi compétent mais également un gros troll, utilisant ostensiblement Windows pour ses présentations lors de conférences et complètement asocial sur les ML du kernel). Si j'étais la femme de Brad je m'inquiéterais... ^^
    - [^] # Re: Très drôle :)
      
      Posté par zul (site web personnel) le 25 juillet 2009 à 17:23. Évalué à 2.
      
      Hum c'est sûrement toi qui a jamais utilisé Linux. Ce qu'il dit est globalement vrai, à par deux trois logiciels fournis en binaire statique (firefox, OpenOffice), utiliser la dernière version d'un logiciel c'est assez chiant, c'est soit :
      - mettre à jour la distro et donc tout récupérer ce qui vient avec
      - se taper tout à la main (avec les nouvelles dépendances et tout).
      
      Après, on en tire les conclusions qu'on veut, lui il a pas envie de se faire chier, c'est son choix.
      
      Quand à juger de l'intelligence d'une personne sur le choix de son système d'exploitation, hum bah je pense qu'on sait de quelle côté est l'intelligence. La seule chose qu'on peut juger c'est de ses qualités techniques, et là encore, je pense que tu as du boulot pour rattraper.
      
      Bonne continuation quand même :)
      - [^] # Re: Très drôle :)
        
        Posté par Jean B le 26 juillet 2009 à 03:21. Évalué à 6.
        
        utiliser la dernière version d'un logiciel c'est assez chiant, c'est soit :
        - mettre à jour la distro et donc tout récupérer ce qui vient avec
        - se taper tout à la main (avec les nouvelles dépendances et tout).
        Ou pas...
        http://wiki.debian.org/AptPinning
        
        [^] # Re: Très drôle :)
        
        Posté par zul (site web personnel) le 26 juillet 2009 à 19:27. Évalué à -5.
        
        Oui mais debian ... :) Niveau sécurité, faut pas en parler avant quelques années :)
        
        De plus, notons bien :
        
        Pinning allows you to run certain packages from one version (stable, testing, unstable) without the necessity of upgrading your entire system. However, pulling in packages from "later" distributions are prone to pull in libraries as well, which might have you end up with a system that has the disadvantages of stable (old software), the disadvantages of unstable/testing (security support not as good as stable, bugs) without the advantages of either.
        
        Enfin, ça reste encore plus difficile de savoir ce qu'on a sur le système. Evidemment, on a le package "récent" mais quid des dépendances ? et des libs en dépendances qui ont cassé leur API entre temps (un truc qui arrive jamais dans le monde libre) => d'autres softs cassés sauf si ils sont mis à jour, etc ... Clairement pas la panacée. Je préfère encore le faire à la main, au moins, je sais ce que j'ai récupéré et le système va pas m'exploser à la tête.
        
        [^] # Re: Très drôle :)
        
        Posté par geb le 26 juillet 2009 à 21:25. Évalué à 6.
        
        Les packages ont des informations de dépendances sur les versions. Ce qui permet d'adresser les problèmes dont tu parles. Beaucoup de gens utilisent de telles configurations pour mixer stable/testing/unstable cela marche très bien. Cela sert aussi pour les backports.
        
        [^] # Re: Très drôle :)
        
        Posté par zul (site web personnel) le 27 juillet 2009 à 00:46. Évalué à -1.
        
        Bien sûr que le système de package résoult le problème. Je dis juste qu'on ne peut pas "juste" récupérer la dernière version du logiciel, et que cela induit plein d'autres conséquences sur le système, donc sur sa sécurité (en particulier un mix stable / testing / sid, ça doit pas être génial pour les mises à jour de sécurité).
        
        Après ça marche "très" bien, y'a des gens qui tournent "très" bien en sid tout le temps, un mix c'est pas vraiment pire pour la cohésion du système mais ça reste pas vraiment la panacée, surtout pour des gens qui s'inquiètent de la sécurité.
        
        [^] # Re: Très drôle :)
        
        Posté par Jean B le 27 juillet 2009 à 01:37. Évalué à 6.
        
        Par ce que quand l'application embarque ses propres librairies ça n'induit rien sur la sécurité ?
        
        Tu demande à avoir un système stable et certaines applications très à jour. C'est exactement ce que te propose l'apt pinning tout en restant géré par le gestionnaire de paquet donc les mises à jours restent centralisées. Alors oui certes si une application demande _obligatoirement_ une version récente d'une librairie eh bien il faudra la mettre à jour. Mais dans la grande majorité des cas les logiciels ne requièrent pas la dernière version d'une bibliothèque.
        Exemple concret: je veut iceweasel 3.5 (dépots expérimentaux) tu peut voir que la version requise de la libc est antérieure à etch. Autrement dit je peut avoir le firefox le plus récent sur la plus ancienne libc encore supportée par Debian.
        http://packages.debian.org/experimental/iceweasel
        http://packages.debian.org/etch/libc6
        
        Alors on peut trouver une foule de contre exemple, à commencer par celui que je viens de donner si tu es sur une archi exotique mais globalement ça marche.
        
        Je sais pas ce que tu cherche à prouver mais tu donne l'air d'être à cours d'arguments et de persister quand même.
        
        [^] # Re: Très drôle :)
        
        Posté par fabricius le 30 juillet 2009 à 13:32. Évalué à 1.
        
        oui mais ce n'est pas *simple*. En tout cas utiliser des backports demande de lire un minimum de doc. Alors que sous windows c'est click-click et hop ca marche.
    - [^] # Re: Très drôle :)
      
      Posté par Kangs le 25 juillet 2009 à 19:15. Évalué à 3.
      
      >>Je ne voudrais pas paraître impolis
      C'est vraiment raté.
# Pas tendre

Posté par campagnard le 24 juillet 2009 à 18:21. Évalué à 3.

Interview très interessante, merci à l'equipe !

Je note quand meme qu'il n'est pas tendre avec OpenBSD, notamment cette phrase :
"Enfin, il doit être dit qu'au moins Linux est développé en grande partie par les gens qui l'ont créé et qui comprennent plus ou moins son code. De son côté OpenBSD a hérité d'un code que ses développeurs ne comprennent toujours pas vraiment aujourd'hui."

PAN ! Dans les dents !
- [^] # Re: Pas tendre
  
  Posté par v_atekor le 24 juillet 2009 à 22:49. Évalué à 1.
  
  Pas tendre, mais ca va faire bouger les choses, et c'est tant mieux.
  
  Bravo à l'équipe pour cette interview très intéressante.
  - [^] # Re: Pas tendre
    
    Posté par Anonyme le 05 août 2009 à 18:31. Évalué à 1.
    
    Ah, par ce que dire aux gens qu'ils sont nuls, ca fait bouger les choses ?
# Original version for the non French-speaking readers

Posté par patrick_g (site web personnel) le 24 juillet 2009 à 18:23. Évalué à 10.

> #####
> You
> #####
>
> 01) Wich OS do you use daily on your laptop/desktop and why did you
> choose this OS ?

I know this will probably upset some of your readers, but I actually
am running Windows 7 RC right now. Prior to that I had been running
Windows Vista. I haven't used Linux as a primary desktop since college
or so. Now that I have a job and my free time is limited, I can't be
wasting days trying to get some driver to work, or trying to recover a
totally broken system because I haven't updated in a while and now want
to upgrade pidgin. If I want to update a specific application on the
machine, I only want to update that specific application -- I don't want
140 other dependencies forced on me. So for reasons of maintaining
sanity (and being able to play games, not just the ones supported by
Wine/Cedega), I use Windows. Linux stays inside VMs on my main
machine, though I do have some machines here that run Linux on the raw
hardware for grsecurity testing purposes.

> 02) Generally what do you think about the free (as in freedom) sofware
> movement ? Did you care about the philosophy behind free softwares
> (like RMS) or did you care only about the technical merits of this
> development model (like Linus) ?

Well, without the free software movement, a lot of the software I use
wouldn't exist (nor would the software I create) so I'm thankful for
that. Initially I cared that it was free (as in beer) and having source
code available was a great learning resource.

>
> 03) I there really a market for selling vulnerabilities ? Did you ever
> sell a vulnerability to a legitimate purchasers ? Did you ever
> consider selling a vulnerability to a blackhat ?

Yes, there really is a market: iDefense, ZDI, Immunity, etc buy
exploits. I have sold vulnerabilities/exploits before to a legitimate
purchaser. I would never sell a vulnerability though to any
illegitimate purchaser or sell any vulnerabilities in any way related to
grsecurity, as that would completely defeat the point of the project
(and be highly unethical).

> 04) There is a lot of funny comments in the source code of your
> exploit (and ascii art also). Is it fun to write exploit ? Is there a
> feeling of ecstactic joy when you find a hole in the kernel ?

Cheddar Bay was lots of fun to write :) From ascii art to system beeps
to an interactive text adventure, to French existentialist literature
(at the very end), the exploit being 31337 bytes, the tarball being
12345 bytes -- it was very true as mentioned in the exploit that most of
the time was spent on the audio/visual experience of it. The actual
technical aspect of the exploit was quite easy (much to the
embarrassment of those involved, I suppose, that someone in an hour of
their free time can tear down all the security protections that have
been built up). I may have a strange sense of humor, but I found it to
be hilarious, and I think some others saw the absurdity/humor in it as
well. Finding good holes in the kernel is exciting, but there are lots
of holes in general, so the overall feeling is one of depression :)

> 05) I've seen this post by Ingo Molnar in LWN :
> http://lwn.net/Articles/342163/ Do you think security experts and
> exploits creator like you have a different mindset compared to other
> kernel developpers ? Is there downsides (psychological or others) to
> be a exploit creator ?

Well, I'm a developer as well, but I also understand that particularly
in the security field, you have to think offensively. That sometimes
means actually doing the work to research vulnerabilities and exploiting
them. It means collaborating with other people who do similar research.
It means never resting on your laurels, always second-guessing your
code, and actively trying to break it. We don't have the mindset of
"well we just wrote <security feature> and think it works, time to
congratulate ourselves." Someone who focuses entirely on kernel
development just can't compete with the talent of people who focus
entirely on security, when it comes to matters of security. Exploit
writing perhaps involves more creative thinking than would be involved
in normal development, but no, we don't have any more psychological
problems than normal developers ;)

> #####
> Grsecurity
> #####
>
> 06) Do you think your recent exploit would have been possible with a
> grsecurity patched kernel ?

Well, for starters, we haven't released a 2.6.30 patch yet, and as that
kernel (or 2.6.30.1) was required to have the vulnerability, then from
the get-go no grsecurity-patched kernels were vulnerable. Now if we
were to imagine a scenario where the bug existed for the 2.6.29.6
kernel, for which there does exist a grsecurity patch, there are a
number of things that would stand in its way:

PaX's UDEREF - This will prevent the vulnerability from being
exploitable from the get-go. Not only does it protect against NULL
pointer dereferences, but against any invalid userland access in general
by the kernel.

PaX's KERNEXEC - This is an effort at removing the ability for arbitrary
code execution in the kernel, just as is done in userland. On top of
this, it makes sections of the kernel marked to be read-only actually
read-only. On a normal kernel, "read-only data" is actually writable.
The particular file_operation function pointer I modified in my exploit
existed in this region of memory that should have been read-only.
KERNEXEC would have prevented its modification. KERNEXEC also comes
into play to prevent ring0 execution in userland, which my exploit also
used. I wrote up a demo exploit for another vulnerability yesterday
that uses the capability of making the kernel execute code in userland
-- no NULL ptr dereference involved. KERNEXEC would step in and prevent
that.

grsec's HIDESYM - This (preferably when used with the RBAC system or
with /boot and /usr/src unreadable by non-root users) aims to keep an
attacker from knowing where specific things he/she wants to attack are
located. Much of what made Cheddar Bay so small and simple was due to
the fact that vendor kernels ship with CONFIG_KALLSYMS_ALL enabled,
which gives an attacker a symbol -> address mapping for virtually
anything he/she is interested in. Without reliable information on what
to attack (so as not to panic the kernel and lose the ability to exploit
it), an attacker would likely need an additional information leaking
vulnerability (something I came up with, which is now PAX_USERCOPY,
could help here even).

> 07) I've seen in the grsecurity website a fierce critic of LSM :
> http://grsecurity.net/lsm.php I've also seen that LSM was modified
> recently in order to add pathname based security modules (TOMOYO). Do
> you think it's possible to have some additional LSM modifications in
> order to merge in mainline some part of grsecurity ?

We're not interested in having parts of grsecurity in the mainline
kernel. Many of the features of grsecurity provide an additive effect
that wouldn't exist if only one of its features happened to be
implemented. For instance, the way UDEREF and KERNEXEC work together to
prevent both code execution and data access in userland by the kernel.
Or the anti-bruteforcing and anti-information leaking added to
grsecurity in support of PaX's ASLR. You don't get the security of
defense in depth unless you actually have the 'depth'.

> 08) Generally, considering the rapid pace of Linux development, is it
> possible to maintain an external patch like grsecurity ?

If you're not aware of the 'test' patches we are continually working on,
we do generally keep up with each new stable version of the Linux
kernels. Due to some constraints on free time lately for both myself
and the PaX team we don't have the patch out yet for 2.6.30, but this is
an exception rather than the rule. The development pace does make
things difficult, especially for a two-man team. It's also no good
security-wise to be introducing 80MB of changes into a supposedly stable
kernel every three months. So it is unfortunate that much of our time
goes into this constant porting work that could better be spent on
actually implementing new security technologies.

> 09) After the grsecurity sponsor alert at the end of last year there
> was some lkml mails in january asking for the incorporation of
> grsecurity in linux. The answer from linus
> (http://thread.gmane.org/gmane.linux.kernel/774825/focus=7748(...) or
> from Robert Hancock
> (http://thread.gmane.org/gmane.linux.kernel/774825/focus=7751(...) was
> that the global patch must be splitted in small parts that make sense.
> What do you think about this option ? Is there a real effort currently
> in order to merge grsecurity in mainline ?

You'll notice that in any mention of grsecurity being merged mainline,
there is a distinct lack of something: our involvement in the
discussion. Put simply, people asking to have grsecurity merged into
mainline don't speak for us, and it wouldn't save us any time (we'd end
up wasting time arguing with non-security experts on how something should
be done within their kernel, when we'd rather just get things done.)

> 10) Some says that you don't want to incorporate grsecurity in
> mainline because it means you will lose your livelihood. Is it true ?
> Do you earn a lot of money with grsecurity as an external patch ?

It's not true. If grsecurity were my main source of income, I would be
homeless. I wish it were the case that I made a lot of money from it
(we always welcome new sponsors), but it's simply not true. I earned
just enough last year from grsecurity to pay for hardware for testing
and colo/network fees (which were lifted this year thanks to our
provider), so grsecurity is not something I profit from.

> 11) I've seen the impressive graph of grsecurity influence
> http://grsecurity.net/~spender/grsecurity_pax-influence.png Do you
> ever consider to use patent with your software developpement in
> grsecurity ? What do you think about software patent in general ?

I can only speak for myself, but I have no interest or plans on
patenting anything, and dislike software patents in general.

> #####
> OpenBSD
> ####"
>
> 12) Concerning security what do you think about the general code
> quality of the OpenBSD kernel compared to the general code quality of
> the Linux kernel ? Is the security reputation of OpenBSD really
> deserved ?

First off, as a general statement about OpenBSD (since there are a
couple questions here about them) I don't really find them to be
relevant anymore (if they ever were). Back years ago when I first
started working on grsecurity, OpenBSD was of the mentality that source
code review alone could save them -- as they discovered, that strategy
doesn't work out too well. Since then they've been adding on defensive
measures, but several years behind others in the industry. For
instance, it wasn't too long ago that they finally supported PIE
binaries. The default install security track record is also more of a
gimmick than anything, since nearly nothing is enabled. If you have
nearly nothing enabled, then there's nearly nothing to protect -- not
much of a statement of security.

Their code quality is probably better than Linux (I don't waste my time
auditing it), but their kernel is also more primitive in a lot of ways
than Linux -- so in some respects it's like comparing apples and
oranges. The speed of development in Linux is also much faster. So
I'm not really praising the Linux code quality here, just making the
point that I don't feel it matters much if your code quality is amazing
if hardly anyone uses your OS. The same could be said about Linux
compared to Windows though, so it should just be said that developers
will work on whatever they happen to be interested in, and some OSes
are more used than others.

Finally, it should be mentioned that Linux at least is developed by in
large part by people who started the whole thing and more or less
understand its code base. OpenBSD on the other hand inherited a code
base they still don't quite understand today.

> 13) I heard that, each time a new security problem, OpenBSD
> developpers grep the entire code base in order to fix all occurence of
> this problem. Why Linux developpers don't do the same thing ?

First off, most bug classes can't be grepped for. I'm not really sure
that Linux developers don't try to find other bugs of the same type
after an important one's discovered -- I've seen some commits lately in
response to the Cheddar Bay exploit that suggests some Linux developers
are actually making an effort to find other cases of a particular bug
class. However, it should also be noted that at least OpenBSD accepts
the notion of security vulnerabilities. The official Linux policy is
that no bug is more important than another (which is both a lie and
disappointing to see in such a widely-used OS).

>
> 14) What do you think about the strlcpy and strlcat functions used in
> OpenBSD ? Do you think they should be added in glibc and used in Linux
> ?

Anyone who wants to replace exploitable overflows with exploitable
string truncation is free to add their own copy of strlcpy and strlcat
to their source code. I don't see any reason for it to be added to
glibc.

> 15) Is there lessons from OpenBSD that should be adopted by Linux
> developpers or are the two OS too different to adopt the same method ?

Someone has suggested I say that the lesson is that "code written by
jerks will be used only by jerks" but I am more kind than that ;) It's
not a useful question to hypothesize an answer to as we've learned more
than once that Linux development is quite set in its ways.

>
> #####
> Linux
> #####
>
> 16) You said that that kernel security bugs are silently fixed by the
> -stable mainteners. Could you explain why it's important to dedicate
> resources in order to correctly classify bugs ? Is it really possible
> to correctly classify security bugs ? If users apply all the fixs
> anyway why try to classify bugs ?

It's important because when bugs aren't correctly classified, then you
cannot accurately determine risk. It's not possible to perfectly
classify security bugs (there will always be someone with some unique
trick) but it is certainly possible to do a lot better than calling
everything a DoS unless there's a public exploit for it. Linux vendors
take in hundreds of millions of dollars in revenue, so there's no excuse
for them not to spend resources to take the handling of security
problems seriously. In the ideal world, everyone would apply all the
fixes, but back in the real world that doesn't happen. Why should you
have to apply a fix that doesn't apply to you? There are simply too
many bugs reported in the Linux kernel for people to be updating every
time one is announced. They're surely more likely to upgrade though if
there're affected by a remote root exploit that disables SELinux than if
it's yet another DoS in some driver code they don't even have compiled
into their kernel. So it's important that people be given adequate
information so that they can accurately evaluate risk for their
particular deployments.

> 17) Do you think the Linux kernel need a security officer ? If yes and
> if you were this security officer, with real power, what would be your
> first decisions ?

I'm not sure any single security officer could be effective within the
Linux kernel community. Performance is king, and many of the developers
simply don't 'get' security in the way people within the industry do. I
imagine anyone with such a job would be incredibly frustrated.

If I had real power and actually had a solution to the problems that the
current development model causes, while keeping fans of the current
development model happy, I would focus on that. Unfortunately I'm not
sure any such solution exists.

>
> 18) In the past you criticized Linus Torvalds about the security of
> the kernel. What do you think about his decisions concerning security
> ? About his technical habilities in this specific domain ? About his
> general leadership of the project ?

He at times can understand security better than some of the other
developers, but security isn't one of his main goals. I'm not sure
either that he fully understand his user-base, particularly corporate
users, but that probably all has to do with the commercialization of
Linux -- it's the job of the vendors to worry about things like that,
and Linus to just worry about driving the creation of the kernel in ways
he thinks is best. His ideas regarding security that have formed the
official policy of kernel developers to omit security-relevant
information in changelogs and treat all bugs the same are destructive.
It's not just me that complains about this, but even the vendors
themselves admit that trying to hide security bugs makes their job of
backporting security fixes much more difficult.

> 19) I order to have a really secure OS do you think we must use
> another paradigm (microkernel, managed OS, formally verified OS, etc)
> or is the current architecture of the Linux kernel compatible with
> real security ?

The "weak link", the thing being trusted by security systems, is the
kernel itself. So the kernel needs to be protected from itself, that
much is sure. We've spent a lot of time working in this area
(especially the PaX Team) and there are more great things planned for
the future. So as to whether this self-protection can be done within
the current architecture or not, is something you'll have to wait to see
for yourself ;)

Thanks for the questions, and hope I didn't cause too many flames :)

-Brad
- [^] # Re: Original version for the non French-speaking readers
  
  Posté par jm trivial (site web personnel) le 24 juillet 2009 à 19:47. Évalué à 1.
  
  Merci :)
  - [^] # Re: Original version for the non French-speaking readers
    
    Posté par patrick_g (site web personnel) le 24 juillet 2009 à 23:04. Évalué à 2.
    
    Purée je viens de m'apercevoir que j'ai oublié de traduire un bout de sa réponse à la question 17 :(
    Bon je traduis et je corrige la news.
    - [^] # Re: Original version for the non French-speaking readers
      
      Posté par patrick_g (site web personnel) le 24 juillet 2009 à 23:08. Évalué à 2.
      
      Ayé.
# en résumé...

Posté par neologix le 24 juillet 2009 à 19:06. Évalué à 4.

Quelqu'un qui développe un ensemble de patchs sécuritaires qui dénigre les modèles de sécurité adoptés par tous les systèmes d'exploitation grand public
Etonnant, vraiment...
- [^] # Re: en résumé...
  
  Posté par Thomas Douillard le 24 juillet 2009 à 19:27. Évalué à 3.
  
  C'est pas très étonnant, mais ça suffit pas en soit pour impliquer qu'il ait tort amha ... (je dis ça, j'ai pas du tout les compétences pour juger)
- [^] # Re: en résumé...
  
  Posté par reno le 26 juillet 2009 à 02:31. Évalué à 2.
  
  Pas étonnant d'accord, mais d'un autre coté le niveau de sécurité pas très élevé actuel est-il satisfaisant?
# Arretez ça

Posté par oelson le 24 juillet 2009 à 21:09. Évalué à 2.

Il n'est pas question de Windows dans cet article ou bien j'ai rèvé, mais il parle de LINUX. Si il a envi de pouvoir jouer a des jeux cool sans nécessairement avoir une nVidia, il a le droit non ?

Je pense que lui au moins essaye de faire changer la situation ou sinon il ne passerai pas son temps libre à patcher Linux (ce qui doit être oh so borring).

Le plus grave c'est qu'une bande de gus préfèrent dicter sa conduite à un gars qui s'investit dans l'amélioration du noyau plutôt que de remarquer que malgré sa réputation, Linux n'est absolument pas parfait ! Et de loin, d'après ce que l'on peut voir, s'en est même dramatique.

Je dit ça je dit rien, mais il serait peut être temps de prendre en considération le nombre de gens qui utilisent Linux. Tant que toute distribution ne concernait qu'une poignée de geeks heureux de tripatouiller leur machine (dont je fait partie), tout allait bien. Mais comme il le dit, ila situation est consternante ! Des entreprises utilisent Linux. Imaginez simplement la portée d'une attaque réussie dans le monde de l'entreprise : Linux serait completement discrédité. Au profit de Mac OS et de 7. C'est comme ça que je vois les choses en tout cas. Il y a un gros problème (80 Mo de patch quoi !!)
- [^] # Re: Arretez ça
  
  Posté par AsM0DeUz le 24 juillet 2009 à 21:28. Évalué à 8.
  
  Nous n'avons malheureusement droit qu'a un son de cloche, combien d'autres personnes sont d'un avis tout a fait contraire au sien ?
  
  Un type vous balance que OpenBSD n'est pas aussi sécurisé que ca et hop ... tout le monde est d'accord (sauf moi evidemment :) ) ... c'est affligeant.
  
  A cote de ca, une réputation de sécurité ca ne tombe pas du ciel donc j'ai plutôt tendance a croire que BSD est sur ... meme si ce type clame le contraire (oui il a trouvé une faille de securité ... et alors, il ne faut pas prendre ses paroles pour argent comptant pour autant)
  - [^] # Re: Arretez ça
    
    Posté par Brioche4012 (site web personnel) le 24 juillet 2009 à 22:21. Évalué à 4.
    
    On pourrait toujours envoyer des questionnaires a Linus Torvalds et Theo de Radt.
    - [^] # Re: Arretez ça
      
      Posté par Laurent Cligny (site web personnel) le 24 juillet 2009 à 23:51. Évalué à 8.
      
      Bonne idée, mais il faudra poster ça une semaine de sept vendredis pour tenir la charge trollesque qui s'en suivra.
      - [^] # Re: Arretez ça
        
        Posté par mlinux le 25 juillet 2009 à 13:03. Évalué à 4.
        
        Ca tombe bien c'est les wacances :p
  - [^] # Re: Arretez ça
    
    Posté par rpointel le 26 juillet 2009 à 14:28. Évalué à 3.
    
    Clair, je suis entièrement d'accord.
    
    Personnellement aussi, je crois beaucoup plus en OpenBSD question sécurité que Linux (y'a qu'à voir justement ce qu'apporte le patch grsec à Linux).
    
    Ca me sidère de voir tant de "haines" entre les projets libres.
    - [^] # Re: Arretez ça
      
      Posté par Laurent Cligny (site web personnel) le 28 juillet 2009 à 14:13. Évalué à 2.
      
      On est libre de detester les autres, tout simplement :p
- [^] # Re: Arretez ça
  
  Posté par Anonyme le 05 août 2009 à 18:52. Évalué à -1.
  
  Je pense que lui au moins essaye de faire changer la situation ou sinon il ne passerai pas son temps libre à patcher Linux (ce qui doit être oh so borring).
  
  Par ce que tu penses que les developeurs du noyau n'essaient pas d'ameliorer le noyau, eux ?
  
  Le plus grave c'est qu'une bande de gus préfèrent dicter sa conduite à un gars qui s'investit dans l'amélioration du noyau plutôt que de remarquer que malgré sa réputation, Linux n'est absolument pas parfait ! Et de loin, d'après ce que l'on peut voir, s'en est même dramatique.
  
  Linux n'est pas parfait, mais aucun OS n'est pas parfait. J'aimerais bien savoir ce qui est dramatique.
  
  Je dit ça je dit rien, mais il serait peut être temps de prendre en considération le nombre de gens qui utilisent Linux. Tant que toute distribution ne concernait qu'une poignée de geeks heureux de tripatouiller leur machine (dont je fait partie), tout allait bien. Mais comme il le dit, ila situation est consternante !
  
  Tu te bases sur quoi, pour dire que la situation est consternante ?
  
  Des entreprises utilisent Linux. Imaginez simplement la portée d'une attaque réussie dans le monde de l'entreprise : Linux serait completement discrédité. Au profit de Mac OS et de 7. C'est comme ça que je vois les choses en tout cas. Il y a un gros problème (80 Mo de patch quoi !!)
  
  80Mo de patch, et alors ? Tu crois que les nouveaux drivers et nouvelles features, ca arrive comme ca, par magie, et que ca prend pas 1 ko ?
  Bon, et puis des failles y en a sous Windows et Mac OS X aussi, qui sont utilisés dans des entreprises, alors tes histoires sur "la portée d'une attaque réussie dans le monde de l'entreprise"...
# Bien coder ?

Posté par Kévin Belliz le 26 juillet 2009 à 03:08. Évalué à 2.

Je suis surement un peu HS mais bon...

La plupart des faille de sécurité sont dû à des "erreurs" de programmation. (Comme on l'a encore vue pour le noyaux 2.6.30)

Mais, je n'arrive pas à trouver de _bon_ document ou site sur les "bonnes" façon de programmer et les erreurs à éviter. il y'a un tas de choses sur les erreurs courante (genre dépassement de tampon avec un memcpy() ) mais pour le reste pas grand choses :(

Donc si quelqu'un à de la doc là dessus, je suis preneur. Merci :)
- [^] # Re: Bien coder ?
  
  Posté par Alex le 26 juillet 2009 à 04:21. Évalué à 2.
  
  C'est vrai qu'une recherche rapide sur google donne moin de réponses qu'on ne pourrait l'espérer... avec "secure programming" on trouve quelques liens intéressants
  
  le truc c'est que ça dépend énormément du contexte: langage, site web ou applis standalones, etc...
  en général il faut toujours contrôler les entrées (taille, "échapper" les commandes qui n'ont rien à faire dans une entrée utilisateur (comme dans les injections SQL ou js, chaîne de format, etc...)
  
  ensuite il y a beaucoup de fonctionnel: authentification, chiffrement, utilisation de fichier temporaire etc... si c'est mal fait, on risque des races conditions, des changements de privilèges, etc... en donnant de plus une fausse impression de sécurité... mais bon là c'est souvent une question de bon sens et un travail à faire en amont lors de la conception de l'archi
  
  mais bon, l'erreur reste toujours humaine
- [^] # Re: Bien coder ?
  
  Posté par Krunch (site web personnel) le 26 juillet 2009 à 13:52. Évalué à 3.
  
  Je recommande notamment la lecture de :
  Secure Programming for Linux and Unix HOWTO http://www.dwheeler.com/secure-programs/Secure-Programs-HOWT(...)
  CERT C Secure Coding Standard https://www.securecoding.cert.org/confluence/display/seccode(...)
  pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
- [^] # Re: Bien coder ?
  
  Posté par Thierry Thomas (site web personnel, Mastodon) le 26 juillet 2009 à 17:42. Évalué à 1.
  
  C'est souvent bête, mais par ex. la faille du 2.6.30 dont tu parles (je suppose ?) aurait été évitée en respectant simplement style(9) :
  
  [http://www.freebsd.org/cgi/man.cgi?query=style&sektion=9]
  
  Je suis sûr qu'il existe plus ou moins la même chose pour Linux, mais je ne l'ai pas trouvée...
  - [^] # Re: Bien coder ?
    
    Posté par ouah (site web personnel) le 31 juillet 2009 à 03:30. Évalué à 1.
    
    Je vois pas en quoi respecter le style guide FreeBSD empêche d'éviter ce genre de failles. Le but du style guide est seulement d'avoir un style de programmation commun (indentation, places des braces, nommages des variables, etc.) Le style guide Linux est disponible depuis très longtemps dans les sources du noyau dans Documentation/CodingStyle. Et autant te dire qu'ils sont super picky sur le respect du style.
    
    La faille aurait été cependant évitée si le programmeur avait suivit les recommendations du site Secure Coding Standard
    du CERT (cité par Krunch dans un commentaire plus haut). Et plus particulièrement la règle EXP34-C:
    
    https://www.securecoding.cert.org/confluence/display/seccode(...)
    
    (la référence à la faille Linux a d'ailleurs été ajoutée récemment)
- [^] # Re: Bien coder ?
  
  Posté par intralunaire le 27 juillet 2009 à 15:57. Évalué à 1.
  
  Je me suis souvent posé cette question, pas du point de vue de la sécurité, mais de la qualité (même si c'est lié ...).
  J'aime beaucoup les livres suivants (surtout les 2 premiers) :
  - Tout sur le code de Steve McConnell
  - The Pragmatic Programmer de Andy Hunt et David Thomas
  - La programmation en pratique de Brian W. Kernighan et Robert Pike
  Certains trouvent leurs conseils trop évidents, d'autres comme moi adorent ça, car on est confronté tous les jours aux problématiques bien explicitées par ces livres (en vrac : style du code, indentation, tests, duplication, héritage de vieux code non/mal commenté, nommage des variables, etc.).
# ssh comme OpenSSH ?

Posté par kAworu le 27 juillet 2009 à 00:27. Évalué à 3.

[...]
> First off, as a general statement about OpenBSD (since there are a
> couple questions here about them) I don't really find them to be
> relevant anymore (if they ever were).
[...]
> Actual grsecurity development of course is done on either a real Linux
> box or a Linux VM, and I always have a number of SSH sessions open to
> Linux machines every day.
[...]

*no comments*
- [^] # Re: ssh comme OpenSSH ?
  
  Posté par reno le 27 juillet 2009 à 01:13. Évalué à 2.
  
  C'est toi qui trolle/lit mal: il dit qu'il ne trouve pas OpenBSD utile, il n'a pas dit qu'il trouvait (Open)SSH inutile.
  
  Ce sont deux projets très différent (même s'ils sont liés), ne serait-ce que parce qu'OpenSSH est porté sur plein d'OS..
  - [^] # Re: ssh comme OpenSSH ?
    
    Posté par kAworu le 27 juillet 2009 à 03:28. Évalué à 8.
    
    Salut!
    
    Effectivement, je vais essayer d'argumenter un peu mieux.
    
    OpenBSD est un projet, pas juste un kernel. Sans OpenBSD, OpenSSH n'existerait pas.
    
    Je pense personnellement que OpenBSD est un projets les plus profitable au autres OS libres. Tu retrouve (à tous les niveaux) des parties qui ont été porté, comme PF pour les *BSD, des drivers wifi (comme ath pour linux), strlcy(3) / strlcat(3) qu'on retrouve dans le kernel linux et la libc des *BSD. C'est aussi le projet qui milite le plus pour l'ouverture des spec hardware (chose profitable pour tous les OS libres).
    
    Maintenant je comprend tout à fait qu'on ne partage pas mon avis, mais de là à dire que OpenBSD sert à rien c'est un peu fort, tu trouve même strlcpy(3) dans son patch de grsecurity* :)
    
    * http://www.grsecurity.net/test/grsecurity-2.1.14-2.6.29.6-20(...) ligne 11494
    - [^] # Re: ssh comme OpenSSH ?
      
      Posté par reno le 27 juillet 2009 à 09:15. Évalué à 0.
      
      OpenBSD est aussi le nom de l'OS donc tu peux prendre l'interprétation qui t'arrange mais c'est curieux la mienne est plus cohérente (on peut trouver un OS inutile sans pour autant trouver toutes les applications qui tourne sur cet OS inutiles).
      
      Pour la notion de 'plus profitable aux autres', bof comment tu mesures cela?
      [ C'est grâce a Linux qu'AMD a ouvert le pilote de ses GPU, etc. ]
      
      Ta partie sur strlcpy / strlcat est intéressante par contre: elle contredit sa réponse 14!
      - [^] # Re: ssh comme OpenSSH ?
        
        Posté par kAworu le 27 juillet 2009 à 14:20. Évalué à 4.
        
        C'est pas plus cohérent; vouloir à tout prix séparer OpenSSH d'OpenBSD est un linuxisme. OpenSSH fait partie intégrante d'OpenBSD. C'est pour cela qu'il existe la version "maison" OpenBSD et la version portable (version modifiée pour pouvoir être portée sur d'autres OS).
        
        Tout cela est très bien expliqué sur http://www.openssh.com:
        
        OpenSSH is developed by the OpenBSD Project.
        [...]
        OpenSSH is developed by two teams. One team does strictly OpenBSD-based development, aiming to produce code that is as clean, simple, and secure as possible. We believe that simplicity without the portability "goop" allows for better code quality control and easier review. The other team then takes the clean version and makes it portable (adding the "goop") to make it run on many operating systems -- the so-called -p releases, ie "OpenSSH 5.2p1".
        
        [^] # Re: ssh comme OpenSSH ?
        
        Posté par reno le 27 juillet 2009 à 15:38. Évalué à -7.
        
        Pfff tu te repete, et tu joue encore sur les mots avec OpenBSD le projet et OpenBSD l'OS.
        
        C'est lourd (tout comme ceux qui confondent volontairement le noyau Linux et les distributions Linux d'ailleurs).
        
        [^] # Re: ssh comme OpenSSH ?
        
        Posté par kAworu le 27 juillet 2009 à 15:56. Évalué à 5.
        
        Le projet c'est l'OS, et les outils (comme OpenSSH) forment (entre autre) l'OS. Le fait que tu compare avec Linux prouve justement que t'as rien pigé au mode de développement des projets BSD.
- [^] # Re: ssh comme OpenSSH ?
  
  Posté par herodiade le 30 juillet 2009 à 15:55. Évalué à 10.
  
  Un peu de contexte ne devrait pas nuire à la compréhension de ses réponses, notamment en ce qui concerne ses remarques sur les autres OS : l'objet principal (exclusif ?) du travail de Spender est la sécurité du noyau, ou les mécanismes de sécurité offerts par le noyau (et éventuellement des outils bas niveaux liés, comme le ld par exemple), pas la sécurité d'un OS complet, dans son ensemble.
  
  Voyez sa réponse concernant la sécurisation de Windows : elle concerne les mécanismes mis en place par le kernel et la façon dont sont chargées les bibliothèques. N'entrent pas en considération dans ses réponses - et c'est normal - les aspects sécurité relatif aux logiciels en espace utilisateur pur (les choix de MS concernant l'ActiveX dans MSIE et Outlook, l'authentification système, les fonctions "sûres" offertes par la libc, ce genre de choses). Même chose au sujet de ses réponses sur OpenBSD : il faut comprendre qu'il parle du noyau. Aussi lorsqu'il dit que le projet est sans intérêt, je ne pense pas que sa remarque concerne OpenSSH (qu'il trouve peut-être utile, mais ça n'est pas dans son radar en tant qu'expert de la sécurité noyau).
  
  Lorsqu'il indique que les développeur du noyau Linux font aussi des recherches systématiques par classes de failles (c'est la vérité : voyez par exemple le joli travail de l'équipe qui développe Coccinelle, l'utilisation de certains flags gcc, le développement de Sparse...), il ne s'intéresse pas aux différences pratique de méthode au delà du noyau (le code source de tout l'OS d'OpenBSD - serveurs web, mail, libc, xorg, etc. compris - est dans un seul et même dépôt, et les recherches de classes de failles se font sur l'ensemble de la base de code de l'OS, ce qui serait beaucoup plus difficile avec le code inclus dans une distribution Linux).
  
  Une précision intéressante au sujet de la question des audits automatisés / systématiques : le problème de déreferencement de pointeur noyau utilisé par son exploit a été identifié et relevé par l'outil d'analyse statique et propriétaire Coverty avant qu'il soit découvert et corrigé par les développeurs noyaux, et avant la diffusion de l'exploit de Spender. Il semblerait (selon Coverty) que les développeurs noyaux Linux ne se donnent plus trop la peine de consulter les analyses de code générées par leur outil, ou du moins de corriger les erreurs relevées, comme ils le faisaient à une époque. A contrario les développeurs de Cocinnelle envoyant directement des patchs sur LKML, les bugs relevés par cet outils sont corrigés. Ce qui me fait prendre sa réponse au sujet de la pertinence de développeurs "responsables de la sécurité du noyau" avec des pincettes : il semble qu'il faille que quelqu'un se colle spécifiquement à la lecture des rapports d'analyses appareillées et à l'écriture de patchs pour que certains problèmes soient corrigés (de même que les régressions ne sont vraiment suivies que depuis que qu'un développeur dédié se donne la peine de faire le suivi global _et_ de poster des comptes rendus sur LKML).
  
  Je trouve enfin que ses remarques sur l'utilité, la complexité, et la taille du noyau d'OpenBSD sont assez justes : c'est un noyau très rudimentaire par rapport à Linux, évoluant lentement, et offrant bien moins de fonctionnalités et des performances assez limitées. Il est donc normal que ce noyau soit moins exposé aux problèmes de sécurité. Précisons tout de même que c'est un choix intentionnel de la part des développeur de cet OS (des gros patchs, par exemple implémentant un support des ACL et RBAC, sont régulièrement rejetés au motif que leur complexité risque de fragiliser le système et/ou de rendre la lecture et les audits plus difficiles; c'est aussi pour ça que des fonctionnalités faciles à porter à partir du code de NetBSD ne sont pourtant pas reprises). La contrepartie, c'est que, comme la réponse de Spender le laisse entendre, OpenBSD n'est pas le choix idéal - est "inutile" - pour de nombreux cas d'utilisation (par ex. si besoin de système de fichier performant, de drivers rares, de LVM, ...).
  
  Et c'est où je voulais en venir : dommage qu'aucune question n'ait été posée sur la façon dont Spender établit les limites diverses, accepterai de céder sur certaines exigences, quelle marge de compromis acceptera-t-il entre performances/fonctionnalités d'une part et sécurité d'autre part. Et en corollaire : quels sont les coûts actuels, hors sécu, de ses jeux de patchs grsecurity (que perds-on au profit de la sécurité). Parce que c'est (pour ce dont je me souviens, ça date) précisément son incapacité à faire coïncider ses exigences (sécurité) avec celles des autres (performances, mémoire disponible, ...) qui avait provoqué le rejet net de grsecurity lorsqu'il l'avait initialement proposé pour inclusion dans Linux. Pour ce que j'en comprends, il semble que Spender trouve qu'OpenBSD ne lâche pas assez de lest et manque de perfs ou fonctionnalité, et trouve qu'à l'inverse le noyau Linux accepte trop de changements, trop vite, ne prends pas assez de temps pour analyser ce qui est une faille ou pas, etc. Quoiqu'il en soit, c'est toujours un compromis difficile, mouvant, dynamique, et reflétant l'"état des forces" en rapport à un instant t dans la communauté des développeurs et des sociétés en présence.
  
  Hormis ce petit regret, l'interview reste utile, agréable et bienvenue bien entendu ;)
  - [^] # Re: ssh comme OpenSSH ?
    
    Posté par herodiade le 30 juillet 2009 à 16:01. Évalué à 7.
    
    J'oubliais de donner une réf sur le traitement des rapports Coverty par les développeur noyau.
    Voici un papier détaillé sur le sujet :
    http://www.usenix.org/events/usenix09/tech/full_papers/guo/g(...)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.