Все ли ядра Linux от производителей небезопасны? Новое исследование говорит да, но есть решение

Согласно официальному документу CIQ, все ядра поставщиков содержат уязвимости безопасности. Примет ли когда-нибудь сообщество Linux вышестоящие стабильные ядра?

В новом официальном документе Vendor Kernels, Bugs and Stability компания CIQ, занимающаяся инфраструктурным программным обеспечением и Rocky Linux, представляет убедительный аргумент в пользу того, что ядра поставщиков Linux изобилуют уязвимостями безопасности из-за ошибочных инженерных процессов, которые возвращают исправления.

Хотя некоторых это может шокировать, в сообществе Linux это ни для кого не секрет. Как недавно сказал Грег Кроа-Хартман, специалист по поддержке стабильного ядра Linux и видный член команды безопасности ядра: «Чтобы быть в безопасности, вы всегда должны использовать последнее долгосрочное стабильное ядро». Ключевое слово здесь «последние». Недостаточно использовать LTS. Вы должны использовать самую последнюю версию, чтобы обеспечить максимальную безопасность.

К сожалению, почти никто этого не делает. Тем не менее, как объяснил инженер ядра Google Linux Кис Кук: «И что же делать поставщику? Ответ прост: если это болезненно: постоянно обновлять ядро до последней версии, основной или стабильной».

Почему? Как объяснил Кроа-Хартман: «Любая ошибка потенциально может стать проблемой безопасности на уровне ядра».

Джонатан Корбет, разработчик ядра Linux и главный редактор LWN, согласился: «В ядре практически любая ошибка, если вы достаточно умны, может быть использована для компрометации системы. Ядро находится в уникальном месте в система... она превращает множество обычных ошибок в уязвимости».

Инженеры CIQ Ронни Салберг, Джонатан Мэйпл и Джереми Эллисон привели эту позицию к конкретным цифрам. Их статья показывает, что при нынешней инженерной практике почти все ядра поставщиков по своей сути небезопасны и что обеспечить безопасность этих ядер невозможно.

Это связано с тем, что ядра поставщиков Linux создавались путем создания моментального снимка конкретной версии Linux и последующего переноса выбранных исправлений по мере возникновения изменений в исходном дереве git. Этот метод, разработанный в эпоху, когда были распространены внешние драйверы устройств, направлен на повышение стабильности и безопасности за счет выбора изменений для обратного переноса. В этой статье рассматривается, как это работает на практике, путем анализа частоты изменений и количества ошибок в Red Hat Enterprise Linux (RHEL) 8.8, версия ядра 4.18.0-477.27.1, а также сравнения с исходными ядрами с сайта kernel.org.

Хотя программисты исследовали RHEL 8.8 конкретно, это общая проблема. Они бы получили те же результаты, если бы исследовали SUSE, Ubuntu или Debian Linux. Дистрибутивы Linux с периодическими выпусками, такие как Arch, Gentoo и OpenSUSE Tumbleweed, постоянно выпускают последние обновления, но они не используются в бизнесе.

Их анализ ядра RHEL 8.8 выявил 111 750 отдельных коммитов в журнале изменений. Эти данные, хотя и не детализируют содержание или размер коммитов, дают общее представление о процессе резервного копирования. Первоначально уровень поддержки был стабильным, но он снизился примерно в ноябре 2021 года и снова значительно снизился в ноябре 2022 года, что соответствует выпуску RHEL 8.5 и RHEL 8.7 соответственно. Эта модель, по мнению авторов, отражает сдвиг в сторону более консервативной поддержки для повышения стабильности по мере продвижения цикла основных выпусков.

Их проверка выявила 5034 неисправленные ошибки в RHEL 8.6; 4767 неисправленных ошибок в RHEL 8.7; и 4594 неисправленных ошибок в RHEL 8.8.

Эти цифры представляют собой известные ошибки с исправлениями исходной версии, которые не были перенесены в RHEL. Более раннее прекращение обратного переноса в RHEL 8.6 и 8.7 привело к увеличению количества неисправленных ошибок по сравнению с RHEL 8.8. Практика Red Hat не публиковать полные изменения исходного кода усложняет ситуацию, что приводит к возможным ложноположительным и отрицательным результатам в данных, с которыми приходилось работать CIQ. Несмотря на эти ограничения, CIQ сообщает, что ручные проверки обеспечивают высокую точность выявления недостающих исправлений.

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

С тех пор как разработчики ядра Linux взяли на себя управление общими уязвимостями и уязвимостями Linux (CVE), было зарегистрировано 270 новых CVE в марте 2024 года и 342 в апреле 2024 года. Они уже исправлены в стабильной ветке git ядра Linux.

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

Кроме того, хотя RHEL 8.8 не разрабатывался активно с конца 2022 года, около 10% всех вновь обнаруженных ошибок по-прежнему затрагивают его. Последний крупный набор исправлений ошибок в RHEL 8.8 вышел в мае 2023 года. То же самое относится и к другим, более старым (но все еще поддерживаемым) корпоративным дистрибутивам Linux. Еще более тревожно то, что, по мнению CIQ, «некоторые из пропущенных нами исправлений явно раскрыты как доступные для использования из пользовательского пространства».

Таким образом, команда CIQ пришла к выводу, что традиционная модель ядра поставщика, характеризующаяся выборочным резервным копированием, ошибочна. Растущее число известных неисправленных ошибок позволяет предположить, что ядра поставщиков менее безопасны, чем стабильные ядра исходной версии. Команда выступает за переход к использованию стабильных веток ядра с сайта kernel.org для повышения безопасности и управления ошибками.

По мнению авторов, «это создает сильный стимул» для клиентов, заботящихся о безопасности, использовать стабильные ядра вместо ядер, специфичных для конкретного поставщика. Они утверждают: «Мы считаем, что единственный реальный способ для клиента узнать, что он использует максимально безопасное ядро, — это переключиться на стабильную ветку ядра».

Эта статья не является критикой специализированных разработчиков ядра Linux. Напротив, это приглашение для отрасли сплотиться вокруг стабильных ядер kernel.org как оптимального долгосрочного решения. Такой сдвиг позволит инженерам больше сосредоточиться на исправлении ошибок, специфичных для клиентов, и улучшении функций, а не на трудоемком процессе резервного копирования.

Таким образом, у них есть четыре важных вывода:

• Модель ядра поставщика сломана и не подлежит восстановлению.
• Ядра поставщиков по своей сути небезопасны, причем ядра поставщиков, стабилизированные на позднем этапе цикла, особенно уязвимы.
  
• Огромное количество известных открытых ошибок делает их анализ и классификацию непрактичными.
  
• Вышестоящие стабильные ядра обеспечивают значительно лучшую защиту от уязвимостей безопасности и ошибок в коде ядра.
  

Итак, будут ли это делать продавцы? Несмотря на все веские причины безопасности для перехода на вышестоящие стабильные ядра, существуют контраргументы, которые сводятся к следующему: если вы всегда обновляетесь до самой последней версии ядра, вы также можете столкнуться с проблемами стабильности. Программа, которая отлично работает с ядром 4.18.0-477.27.1, может не работать с ядром 4.18.0-477.27.1.el8_8. Конечно, в этом конкретном случае новое ядро исправило важную ошибку безопасности.

Все сводится к тонкому балансированию между безопасностью и стабильностью. Некоторые ведущие разработчики ядра Linux и CIQ переходят на сторону безопасности. Посмотрим, что скажет остальная часть сообщества поставщиков Linux.