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 . En réponse à la dépêche Une interview de Brad Spengler. Évalué à 10.
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 ;)