Enterprise Linux работает примерно по такой модели:

Принимается решение сделать мгновенный снимок неких восходящих свободных проектов по состоянию на определённую версию (это касается, в том числе, ядра Linux) и заложить этот снапшот в качестве основы для новой целостной версии, дистрибутива Enterprise Linux. Коллекция программ останется замкнута на уровне этих конкретных версий на протяжении всей службы этого релиза Enterprise Linux – а этот срок часто составляет 10 лет или даже больше.

Разработчики, специалисты по поддержке и тестировщики, стоящие за этим дистрибутивом, затем должны выполнить массу неблагодарной работы: исправлять баги, тестировать код, обеспечивать качество, писать документацию, т.д. Это огромное начинание, сводящееся к нудной изнурительной работе. В конце этого процесса получается относительно стабильный дистрибутив Linux, который работает хорошо, и который можно выпустить в мир.

Для этого релиза начинается следующий кусок сложной работы. Чтобы держать большой комплект софта максимально защищённым и при этом свободным от багов, не хуже, чем его вышестоящие аналоги, придётся постоянно месить код и выпускать новые и новые версии. Те, кто отвечают за поддержку вашего Enterprise-дистрибутива Linux, должны тщательно ориентироваться в океане изменений.

Часто этот процесс выглядит так:


На практике это выливается в долгосрочную фиксацию пакетов на конкретной версии и даже в обратное портирование исправлений для самых одиозных багов или брешей в безопасности, которые заносятся в базу CVE.

Звучит хорошо, да? Нет. Только не с точки зрения безопасности. С этой моделью многое не так.
По данным исследования:

«Несмотря на то, что в Национальном Реестре Уязвимостей (NVD) публикуются выявленные уязвимости, абсолютное большинство уязвимостей и тех патчей, которые их купируют, не попадают в открытый доступ».

Давайте в качестве примера рассмотрим один из самых крупных опенсорсных проектов, развивающихся прямо сейчас: ядро Linux. Согласно отчёту об истории развития ядра Linux за 2020 год, в проект вносится примерно 10 изменений в час или примерно 225 изменений в сутки. Команда, занимающаяся ядром, не выделяет баги, касающиеся безопасности, на фоне других багов. Просто ещё один баг и всё. Все баги в проекте равны. В логах фиксации исправление конкретного бага, касающегося безопасности, не выделяется в особую категорию. Информационные бюллетени не публикуются. Фактически, абсолютное большинство записей в CVE, касающихся ядра Linux, идентифицируются только запоздало, когда исследователи-безопасники и заинтересованные стороны перебирают изменения и приходят к выводу, что некоторые из внесённых багфиксов позволили устранить бреши в безопасности. Только тогда сообщение о данной проблеме отправляется в CVE.

Распространена ситуация, в которой большинство выявляемых уязвимостей, попадающих в CVE, купируются спустя месяцы после выпуска стабильной версии ядра. Здесь мы даже не говорим об огромной куче необнаруженных CVE, прячущихся в море багфиксов. Помножьте эту проблему на общее количество пакетов, входящих в состав Enterprise-дистрибутива Linux – и перед вами откроется гигантское окно уязвимостей.

Фундаментальная проблема такова: enterprise-модель Linux — это оптимизация в пользу стабильности ценой безопасности. Замыкая пакеты на конкретных версиях и ограничиваясь обратным портированием избранных исправлений, мы приходим к тому, что эти дистрибутивы серьёзно отстают от свежих версий в области багфиксов в области безопасности (возможно, так получается и ненамеренно).

Сторонники такой модели могут парировать, что это необходимый компромисс. Невозможно рассчитывать на стабильность и одновременно держать в самом свежем виде набор багфиксов. Не уверен, что найдутся такие дистрибутивы Linux, в которых было бы и первое, и второе. При выкатывании новых версий у таких дистрибутивов как OpenSUSE Tumbleweed новейшие разработки учитываются гораздо полнее, но и стабильность при этом поддерживается благодаря тщательному автоматизированному тестированию. Кроме того, есть такие дистрибутивы, как Fedora Linux. Технически это не плавающий релиз (rolling release), но он всё равно держится поближе к новейшим версиям, следуя их регулярной каденции.

Даже в таком случае, дистрибутивы такого типа – не панацея, и даже такая стратегия не избавляет нас от эксплуатационных издержек. Пусть мы и будем держаться поближе к последней версии, это может не соответствовать нуждам вашего приложения и команды.

Промежуточного варианта здесь не существует, но вам, вероятно, не нравится такое слышать.

К вопросу об Oracle Linux

Сейчас необходимо отбросить рефлекторное (и оправданное) неприятие к тому, что я написал. Да, я знаю, что Oracle полностью оправдывает свою репутацию в кругу инженеров. Я совершенно разделяю ваши мысли и никаким образом не аффилиирован с Oracle.

Но ненадолго остыньте и выслушайте меня.

Проект Oracle Linux был запущен в октябре 2006 года на основе перестройки второстепенной версии RHEL. Они просто взяли исходники Red Hat, перекомпилировали и навесили на них свой бренд, а потом стали продавать от своего лица контракты на поддержку, пытаясь перекрыть кислород бизнесу Red Hat.

Годами эта работа продолжалась, все её результаты публиковались на yum.oracle.com и сейчас находятся в свободном доступе. Вот как они сами объясняют это на своём сайте в разделе FAQ:

Вопрос:
Подождите, разве Oracle Linux не платный?

Ответ:
Поддержка Oracle Linux стоит денег. Если вы хотите только софт – он 100% бесплатный. Весь он лежит в вашем репозитории yum на сайте yum.oracle.com. Мажорные версии, замеченные ошибки, вот это всё. Бесплатный исходный код, бесплатные бинарники, бесплатные обновления, их можно свободно распространять и использовать в продакшене. Да, это, конечно, Oracle, но он фактически бесплатный. Серьёзно.

Всё интересное началось в сентябре 2010 года, когда Oracle анонсировала опциональный отход от своего клона RHEL: он помпезно назывался Unbreakable Enterprise Kernel (нерушимое ядро для больших предприятий).

Теперь Oracle предлагает каждому два ядра: ядро, совместимое с Red Hat (RHCK) и их собственное нерушимое ядро для больших предприятий (UEK).

Со временем UEK эволюционировало в уникальное Enterprise-ядро Linux, которое шло в фарватере главного ядра Linux достаточно близко к нему. Было решено не выдёргивать отдельные избранные багфиксы для обратного портирования в собственное ядро (описанная стратегия применяется в большинстве Enterprise-дистрибутивов Linux). Вместо этого они нашли модель, которая работает лучше «и отстаёт от вершины дерева LTS (долговременно поддерживаемых версий) менее чем на четыре недели».

Этот небольшой временной лаг используется для типичной «корпоративной» валидации и тестирования до сдачи обновлённого релиза UEK.

Придерживаясь как можно ближе к релизам основного ядра, причём, нагоняя это ядро с регулярными интервалами, удаётся поспевать и за огромным объёмом багфиксов, попадающих в ядро – независимо от того, лежат они в плоскости безопасности или нет.

Это и есть интересный компромиссный вариант для обслуживания одного из самых важных компонентов дистрибутива Enterprise Linux. Можно быть уверенным в эксплуатационной стабильности всего инструментария этого дистрибутива в целом, продолжая при этом пользоваться относительно новым (и проверенным) ядром.

Кроме того, Oracle публично объявила, что продолжит стремиться сохранять «…в публичном и бесплатном доступе все бинарники и исходный код этого дистрибутива». На момент публикации этой статьи их дистрибутив существует уже около 17 лет, и они пока ни разу не пытались ограничить доступ к его исходному коду.

Мне как-то неудобно положительно высказываться о продукте Oracle, но Oracle Linux – в самом деле, хороший вариант, заслуживающий вашего внимания.

Только не выдавайте Ларри, что я такое сказал.