Le kernel Linux est-il suffisamment sécurisé ?

closeCet article a été publié il y a 15 ans 3 mois 5 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

linux secureVoici une interview qui va probablement faire grincer de dents les inconditionnels du noyau Linux. Elle est parue aujourd’hui sur le Journal du Net Solutions. Qu’en est-il réellement et que reproche-t-on à Linux ?

Chaouki Bekrar expert en failles de sécurité travaillant pour la société VUPEN Security déclare : « Le plus mauvais élève est incontestablement l’organisation Linux Kernel qui corrige les vulnérabilités du noyau Linux sans en indiquer la criticité ou les conséquences, et sans publier de bulletin dédié. »

Ce n’est pas la première fois que le travail et les choix de Linus Torvald en matière de sécurité sont mises en causes. Selon Wikipédia :

Brad Spengler développeur chez Grsecurity accuse Linux de parfois centrer ses efforts sur les fonctionnalités au détriment de la sécurité. Il prétend que Linus Torvalds lui aurait dit ne pas être intéressé par l’ajout d’options de sécurité utiles pour éviter des débordements de tampon, car cela ralentirait le chargement des applications.

Il reproche l’absence d’une personne chargée officiellement de la sécurité, avec qui il serait possible de communiquer en privé en toute sécurité. À la place la seule solution est d’envoyer un e-mail sur une liste de diffusion relative aux questions de sécurité où les failles découvertes sont parfois utilisées à des fins malveillantes avant qu’une mise à jour de sécurité ne soit diffusée, alors que les usagers de Linux ne sont pas au courant de l’existence de cette faille.

Enfin il remet en cause l’implantation du système LSM depuis la version 2.6 du noyau qui aurait été implanté par laxisme et qui faciliterait l’insertion de rootkits invisibles au sein du système en les faisant passer pour des modules de sécurité, mais cela est devenu impossible depuis la version 2.6.24. D’autres développeurs du noyau reprochent à ce système de consommer des ressources non négligeables et de permettre le détournement de la licence GPL du noyau en y ajoutant des composantes propriétaires.

Qu’en est-il dans les faits ? Difficile de le savoir sans se lancer dans une bataille de chiffres.

Reste l’expérience sur le terrain. Si je me base sur mon expérience personnelle, les risques liés à la sécurité augmentent souvent avec la diffusion du système concerné. On l’a vu avec les premières versions de Firefox qui était peu concernées par des failles de sécurité. Au fur et à mesure de l’augmentation du nombre d’utilisateurs, ces failles sont devenues plus nombreuses car il y avait pour les hacker une nouvelle cible qui valait la peine que l’on s’intéresse à elle.

Linux aujourd’hui est peu diffusé au niveau des postes de travail (malheureusement). J’avoue ne pas avoir eu à ce jour connaissance de quelqu’un dont le poste Linux ait été infesté par un virus ou autre troyen.

Les serveurs exploitant un noyau Linux sont nombreux sur internet. Si Linux était aussi peu sécurisé, il me semble que cette plateforme aurait été abandonnée ou en tout cas serait beaucoup moins présente. Ce n’est pas une preuve dans l’absolue, les problèmes existent.

Mais le plus grand « trou » de sécurité n’est-il pas souvent l’administrateur du serveur et son éventuel manque de vigilance ou de rigueur. Qui plus est, ce n’est pas un problème spécifique à Linux.

Le débat est donc ouvert !

Philippe Scoffoni

Je barbote dans la mare informatique depuis 30 ans (premier ordinateur à 16 ans, un ORIC ATMOS) et je travaille à mon compte au travers de ma société Open-DSI. J'accompagne les associations, TPE et PME dans leurs choix et dans la mise en oeuvre se solutions informatiques libres.

4 réponses

  1. Virtual_Spirit dit :

    Grsecurity à été refuser du noyaux et Brad Spengler tente désespérément de le faire accepter…

    je ne pense pas que son avis soit complétement neutre donc.

    Autre point important, les vulnérabilité son corriger mais il n’y à pas d’indication supplémentaire, car ça ajoute un travaille considérable, des bug banales peuvent se révéler être des failles très critiques (comme pour les Buffer-overflow par exemple). Il faut des testes et beaucoup de recherche pour déterminer cela, sans compter que ça peut aussi dépendre de beaucoup d’autre facteur… Le choix de Linux à été de ne rien spécifier, et de ne pas perdre de temps avec un bug/faille qui est résolue.

    Son approche est compréhensible, et je ne pense pas que ça soit là une négligence vis à vis de la sécurité.

    Grsecurity à été apparemment refuser non pas à cause du faite qu’il ralentie le chargement d’application, mais parce qu’il ne respecte pas la philosophie linux. Ce qui provoquerais un bordel si il était inclu ans le noyaux, cela fait des années que linux le répète au dev de Grsecurity, mais il ne veulent pas changer leurs mode de développement. Selon eux, si il se plie au règles classique il perdes en sécurité.

    Le point de vu des deux parti est donc compréhensible, et la meilleur méthode reste donc surement celle actuel, développer Grsecurity à côté et le proposer sous forme de patch.

  2. Peck dit :

    D’autre part, le fait que les LSM facilite l’insertion de rookit est du fud. Ce sont des modules simplifier l’architecture, mais ils sont prévus pour ne pas pouvoir être changés dynamiquement.

  3. Lenezir dit :

    Ça fait réfléchir tout ça… 😐

    J’ai entendu plus d’une fois dire que Linus Torvald n’est pas un modèle de « sagesse » pour ses choix et ses trolls…
    Je pense que je vais commencer à étudier le noyau Hurd et la série des *BSD pour ne pas être perdu si ça devient trop n’importe quoi…
    A suivre…

  4. teto dit :

    Torvalds regrette que la recherche des failles mobilisent autant de ressources.
    D’après ce que j’ai lu dans un magazine jecrois, découvrir une faille, c’est s’assurer une renommée certaine du coup beaucoup parmi les meilleurs éléments passent leur temps à ca au lieu de le consacrer au développement des nouvelles fonctionnalités.
    Perso s’il y a un choix à faire, je prefere privilégier les fonctionnalités à la correction des failles parce que je suis un particulier.L’approche peut s’avérer différente pr l’entreprise.

    Parce que ce qui prend du temps,c’est également communiquer sur les bugs,sur le bugtracker etc…

    TROLL: Puis des failles on en trouvera tjrs, ou bien on bloque le dév du noyau.