Lacombe Eric

Après avoir introduit Fuddly [1] au travers de la modélisation d’un protocole dans le précédent article [2], nous poursuivons par la pratique. Sont ainsi présentées différentes approches complémentaires pour l’évaluation de la robustesse d’une cible mettant en œuvre le protocole modélisé au sein du framework. Et pour conclure, nous abordons brièvement l’outil mis à disposition pour faciliter l’analyse des résultats recueillis.

Cet article présente Fuddly, un framework de fuzzing et de manipulation de données, écrit en python sous GPLv3, qui fournit de nombreuses briques que l’on retrouve dans d’autres framework de fuzzing, mais qui se différencie par la flexibilité de représentation des données et la diversité des altérations qu’il rend possible.

Après une introduction à l'infrastructure Gadget USB, penchons-nous à présent plus spécifiquement sur la couche Composite permettant de faire cohabiter plusieurs Function Drivers et donc de présenter à un hôte USB un périphérique remplissant plusieurs fonctions...

L'infrastructure Gadget USB du noyau Linux facilite la création de périphériques USB, en proposant un cadre et un certain nombre de primitives qui permettent d'une part d'abstraire les contrôleurs matériels de périphériques USB, et d'autre part d'en utiliser les ressources et fonctionnalités afin de créer n'importe quelle fonction USB désirée : qu'elle réponde aux standards (tels que « Mass Storage », « CDC Eth »…), qu'elle soit l'incarnation de vos besoins particuliers, ou bien encore qu'elle soit une combinaison des deux.

Nous avons le plaisir de vous présenter dans un première partie quelques pensées de Andrew Morton et de Greg Kroah-Hartman (deux figures de renom dans la communauté noyau) sur la maturité du noyau Linux et de sa communauté, sur l'importance de l'adaptation continue de Linux à son environnement, ainsi que sur des sujets liés à la maintenabilité du noyau vis-à-vis de la flexibilité que l'ABI peut apporter à l'espace utilisateur. Nous finissons par un éclairage de Tejun Heo (mainteneur des control groups) sur la refonte de l'infrastructure des control groups (en cours d'intégration depuis le 3.10 et accessible via l'option de montage « __DEVEL__sane_behavior »), où le sujet de la flexibilité est au cœur des décisions prises.

Nous traitons dans cet article de l'infrastructure des espaces de noms et présentons un aspect essentiel qui a été intégré au noyau 3.8, à savoir l'instantiabilité de l'espace des comptes utilisateurou,autrement dit : la possibilité de créer de nouveaux espacesd'UID et GID.

C'est depuis l'arrivée du noyau 3.8 qu'il est possible de contrôler l'utilisation de la mémoire noyau par les processus du système grâce à l'infrastructure des control groups. Cette brève explore cette nouvelle aptitude du noyau Linux.

Le noyau intègre enfin, dans sa version 3.7, une fonctionnalité de sécurité, longtemps attendue par certains, dont une implémentation existait depuis bien des années dans RHEL et Fedora : MODSIGN ou le mécanisme de signature cryptographique des modules noyau. Après de multiples rebondissements, des discussions enflammées sur la LKML et ailleurs, une solution convenable pour la communauté a vu le jour. C'est ce que nous vous proposons de découvrir dans cet article.

Nous voilà de retour dans cette seconde partie d'analyse des évolutions des noyaux 3.5 et 3.6. Un assez long développement est consacré à l'infrastructure VFIO qui comble les limitations de UIO pour le développement de drivers en espace utilisateur. La sécurité est également abordée avec l'intégration de mécanismes de protection empêchant toute exploitation de vulnérabilités ToCtToU liées à l'utilisation de liens symboliques et physiques. D'autres aspects sont aussi traités, comme l'ajout de l'infrastructure Uprobes.