« Quel est le problème avec Enterprise Linux ? » Un ingénieur expose les problèmes et les limites des distributions Linux destinées aux entreprises

Enterprise Linux est un terme générique qui désigne les distributions Linux conçues pour les besoins des entreprises, comme la stabilité, la sécurité, la performance et le support. Parmi les exemples les plus connus, on trouve Red Hat Enterprise Linux, Ubuntu, Linux Mint et SUSE Linux Enterprise Server. Ces distributions offrent des avantages indéniables pour les environnements professionnels, mais elles ne sont pas exemptes de critiques. Dans un billet, un ingénieur a exposé les problèmes et les limites des distributions Linux destinées aux entreprises.

Le modèle Enterprise Linux fonctionne comme ceci :

Il a été décidé de créer un snapshot d'une collection de projets open source en amont à une version spécifique, y compris le noyau Linux, pour former la base d'une nouvelle version cohérente d'une distribution Enterprise Linux. Cette collection de logiciels restera figée à sa version spécifique tout au long de la durée de vie de cette version de distribution Enterprise Linux - qui est souvent de 10 ans ou plus.

Les ingénieurs, les mainteneurs et les testeurs derrière ces distributions ont ensuite effectué l'énorme travail ingrat de corrections de bogues, de tests, d'assurance qualité, de documentation, etc. C'est une entreprise massive de travail fastidieux et rigoureux. À la fin du processus, vous vous retrouvez avec une distribution Linux relativement stable qui fonctionne bien et ils la diffusent dans le monde.

La prochaine phase de travail acharné commence pour cette version. Garder la grande collection de logiciels sécurisés et aussi exempts de bogues que possible, car leurs homologues en amont continuent de tourner et de publier de nouvelles versions. Les mainteneurs de votre distribution Enterprise Linux doivent suivre attentivement l'océan des changements.

En pratique, cela signifie qu'ils gèlent les packages à une version spécifique pendant une longue période et ne rétroportent que les correctifs pour les bogues ou les problèmes de sécurité les plus flagrants qui reçoivent un CVE.

Ça sonne bien, non ? Non. Pas pour la sécurité. Il y a beaucoup de mal avec ce modèle.


Le modèle Enterprise Linux optimise la stabilité au détriment de la sécurité

Comme le montre la recherche : « Bien que la base de données nationale sur les vulnérabilités (NVD) publie les vulnérabilités identifiées, une grande majorité des vulnérabilités et leurs correctifs de sécurité correspondants restent au-delà de l'exposition publique ».

Concentrons-nous sur l'exemple de l'un des plus grands projets open source en cours : le noyau Linux. Selon le rapport sur l'historique du noyau Linux 2020, le projet de noyau Linux reçoit environ 10 modifications par heure, soit environ 225 modifications par jour. L'équipe derrière le noyau ne traite pas les bogues de sécurité comme quelque chose de spécial. C'est simplement un autre bogue. Tous les bogues sont égaux aux yeux du projet. Ils ne désignent pas un correctif de bogue particulier comme étant lié à la sécurité dans les journaux de validation. Ils ne publient pas d'avis. En fait, la grande majorité des CVE trouvés pour le noyau Linux ne sont identifiés que rétroactivement lorsque les chercheurs en sécurité et les parties intéressées se penchent sur les changements et se rendent compte que quelques-unes de ces corrections de bogues comblent en effet des failles de sécurité. Ce n'est qu'alors qu'ils déposent une demande de CVE pour le problème.

Très souvent, la plupart des CVE identifiés ont été corrigé des mois auparavant dans la version stable du noyau. Cela sans compter l'énorme pile de CVE non identifiés qui se cache dans la mer de corrections de bogues. Multipliez ce problème par le nombre total de packages qui composent une distribution Enterprise Linux et vous vous retrouvez avec une énorme fenêtre de vulnérabilité.

Le problème fondamental est que le modèle Enterprise Linux optimise la stabilité au détriment de la sécurité. En verrouillant les packages sur des versions spécifiques et en ne rétroportant que des correctifs sélectionnés, ces distributions accusent un retard considérable par rapport aux versions en amont en ce qui concerne les corrections de bogues de sécurité, bien que cela ne soit pas intentionnel.

Les défenseurs répondront qu'il s'agit d'un compromis nécessaire - vous ne pouvez pas avoir à la fois la stabilité et être entièrement à jour sur les correctifs de sécurité. Je ne suis pas convaincu que ce soit vrai car il existe d'autres distributions Linux qui ont montré que vous pouvez avoir les deux. Les distributions de versions progressives comme OpenSUSE Tumbleweed suivent de plus près en amont tout en maintenant la stabilité grâce à des tests automatisés approfondis. De plus, des distributions comme Fedora Linux, bien qu'elles ne soient pas techniquement une version continue, ont tendance à se rapprocher des versions en amont à une cadence plus régulière.

Même ainsi, ces types de distributions ne sont pas une panacée et des défis opérationnels peuvent se présenter en restant proche de l'amont compte tenu des besoins de votre application ou de votre équipe.

Il existe un terrain d'entente, mais vous n'allez probablement pas aimer l'entendre.

Le cas d'Oracle Linux

J'ai besoin que vous mettiez de côté votre répulsion automatique (et justifiée) envers ce que vous venez de lire. Oui, je sais qu'Oracle a gagné sa réputation parmi les ingénieurs. Je suis totalement d'accord avec vous sur ce point - je ne suis en aucun cas affilié à Oracle.

Mais arrête de crier un instant et écoutez-moi.

Le projet Oracle Linux a été lancé en octobre 2006 en tant que reconstruction en aval de RHEL. Ils ont simplement pris les sources de Red Hat, les ont recompilées et y ont apposé leur marque, et ont vendu leurs propres contrats de support pour tenter de saper les activités de Red Hat.

Au fil des ans, ils ont poursuivi ce travail et publient tous leurs travaux sur yum.oracle.com qui est librement disponible. Comme leur propre site et explication l'indique dans la FAQ :

Là où c'est devenu intéressant, c'est en septembre 2010 quand Oracle a annoncé un départ facultatif pour son clone RHEL : le pompeusement nommé Unbreakable Enterprise Kernel.

Oracle offrait désormais à chacun deux noyaux : le noyau compatible Red Hat (RHCK) et son propre Unbreakable Enterprise Kernel (UEK).

Au fil du temps, UEK a évolué pour devenir une offre de noyau Enterprise Linux unique qui suit de plus près le noyau Linux en amont. Plutôt que de sélectionner des correctifs individuels pour rétroporter vers leur noyau comme le font la plupart des distributions Enterprise Linux, le modèle qu'ils ont trouvé qui fonctionne le mieux « a été de retarder la pointe de l'arborescence LTS de moins de quatre semaines ».

Ils utilisent ce petit délai pour effectuer leur processus de validation et de test « d'entreprise » typique avant de livrer une version UEK mise à jour.

En se rapprochant beaucoup plus des versions du noyau en amont à intervalles réguliers, ils sont capables de suivre l'énorme quantité de corrections de bogues qui entrent dans le noyau - qu'elles soient liées à la sécurité ou non.

C'est une option intermédiaire intéressante pour l'un des composants les plus critiques d'une distribution Enterprise Linux. Vous pouvez compter sur la stabilité opérationnelle de l'ensemble des outils de distribution, mais vous disposez toujours d'un noyau relativement mis à jour (et validé).

Oracle a également continué publiquement à s'engager à maintenir « ... les binaires et le code source de cette distribution publiquement et librement disponibles ». À ce stade, leur distribution existe depuis 17 ans et ils n'ont jamais essayé de restreindre l'accès à leur code source pendant cette période.

Il est faux de parler positivement d'un produit Oracle, mais Oracle Linux est en fait une bonne option digne de notre considération.

Ne dites pas à Larry que j'ai dit ça.

Source : billet Cyrus

Et vous ?

Que pensez-vous de son argumentation ? Sur quels points êtes-vous d'accord et sur quels points ne vous alignez pas avec lui ?
Parlant de son exemple, quelle est votre opinion sur le modèle de Oracle Linux qui suit de près le noyau Linux en amont tout en conservant la stabilité de la distribution en aval ?
Pensez-vous que Oracle Linux soit une alternative crédible à Red Hat Enterprise Linux ou à d’autres distributions Linux d’entreprise ?
Avez-vous déjà utilisé Oracle Linux ou envisagez-vous de l’essayer ? Quels sont les avantages et les inconvénients que vous avez rencontrés ou que vous anticipez ?
Quels sont les autres produits ou services d’Oracle que vous utilisez ou que vous aimeriez utiliser ? Comment Oracle Linux s’intègre-t-il avec eux ?
Quelles sont les caractéristiques ou les fonctionnalités que vous aimeriez voir ajoutées ou améliorées dans Oracle Linux ? Comment pensez-vous qu’Oracle pourrait mieux répondre aux besoins des utilisateurs de Linux d’entreprise ?

Voir aussi :

« J'en ai terminé avec Red Hat (Enterprise Linux) ». Un développeur estime que l'entreprise a trahi la communauté des utilisateurs de Linux en mettant le code source de RHEL derrière un paywall
SUSE investit 10 millions de dollars pour créer un fork de RHEL et proposer une alternative à CentOS Stream sans restrictions à l'intention des entreprises mais aussi de la communauté