Кис Кук из Google призвал модернизировать процесс работы над ошибками в ядре Linux
5 августа 2021 года
Кис Кук (Kees Cook), бывший главный системный администратор kernel.org и лидер Ubuntu Security Team, ныне работающий в компании Google над обеспечением защиты Android и ChromeOS, выразил опасение текущим процессом исправления ошибок в стабильных ветках ядра. Еженедельно в стабильные ветки включается около ста исправлений, что слишком много и требует больших трудозатрат для сопровождения продуктов на базе ядра Linux.
По мнению Киса процессу работы с ошибками в ядре не уделяется должное внимание и ядру не хватает как минимум 100 дополнительных разработчиков для скоординированной работы в этой области. Основные разработчики ядра регулярно исправляют ошибки, но нет никаких гарантий, что эти исправления будут перенесены в варианты ядра, используемые сторонними производителями. У пользователей различных продуктов на базе ядра Linux также нет возможности проконтролировать то, какие ошибки исправлены и какое ядро используется в их устройствах. В конечном счёте за безопасность своих продуктов отвечают производители, но в условиях очень большой интенсивности публикации исправлений в стабильных ветках ядра они оказались поставлены перед выбором - переносить все исправления, выборочно портировать самое важное или игнорировать все исправления.
Оптимальным решением был бы перенос только самых важных исправлений и уязвимостей, но в выделении таких ошибок из общего потока и состоит основная проблема. Наибольшее число всплывающих проблем является следствием использования языка Си, требующего большой аккуратности при работе с памятью и указателями. Усугубляет ситуацию то, что многие потенциальные исправления уязвимостей не снабжаются идентификаторами CVE или получают подобный идентификатор через какое-то время после публикации исправления. В подобных условиях производителям очень трудно разделить второстепенные исправления от важных проблем, влияющих на безопасность. По статистике более 40% уязвимостей устраняются до присвоения CVE и в среднем задержка между выпуском исправления и присвоением CVE составляет три месяца (т.е. вначале исправление воспринимается как обычная ошибка, но лишь спустя несколько месяцев становится ясно, что имело место устранение узявимости).
В итоге, не имея отдельной ветки с исправлениями уязвимостей и не получая сведений о связи с безопасностью той или ной проблемы, производителям продуктов на базе ядра Linux остаётся непрерывно переносить все исправлений из свежих стабильных веток. Но данная работа требует больших трудозатрат и сталкивается в компаниях с сопротивлением из-за опасения в появлении регрессивных изменений, способных нарушить нормальную работу продукта.
Напомним, что по мнению Линуса Торвальдса, все ошибки важны и уязвимости не следует отделять от других видов ошибок и выделять в отдельную более приоритетную категорию. Объясняется такое мнение тем, что для обычного разработчика, не специализирующегося на вопросах безопасности, не очевидна связь исправления с потенциальной уязвимостью (для многих исправлений лишь проведение отдельного аудита позволяет понять, что они касаются безопасности). По мнению Линуса, вопросами выделения из общего потока исправлений потенциальных уязвимостей должны заниматься специалисты по безопасности из команд, отвечающих за поддержку пакетов с ядром в дистрибутивах Linux.
Кис Кук считает, что в единственным решением для поддержания безопасности ядра при разумных долгосрочных затратах является перевод компаниями инженеров, занимающихся портированием исправлений в локальные сборки ядра, к совместной скоординированной работе над сопровождением исправлений и уязвимостей в основном ядре (upstream). В текущем виде, многие производители используют в своих продуктах не самые новые версия ядра и бэкпортируют исправления собственными силами, т.е. получается, что инженеры в разных компаниях дублируют работу друг друга, решая одну и туже проблему.
Например, если 10 компаний, в каждой из которых один инженер занимается бэкпорированием одних и тех же исправлений, переориентируют данных инженеров на исправление ошибок в upstream, то они вместо портирования одного исправления могли бы исправить 10 разных ошибок для общей пользы или подключиться к рецензированию предлагаемых изменений и не допустить включения кода с ошибками в ядро. Ресурсы также можно было бы направить на создание новых инструментов для тестирования и анализа кода, которые позволили бы на ранней стадии автоматически выявлять типовые классы ошибок, которые всплывают вновь и вновь.
Кис Кук также предлагает более активно использовать автоматизированное и fuzzing-тестирование непосредственно в процессе разработки ядра, применять системы непрерывной интеграции и отказаться от архаичного управления разработкой через email. В настоящее время эффективному тестированию мешает то, что основные процессы тестирования отделены от разработки и происходят уже после формирования релизов. Кис также рекомендовал применять при разработке языки, обеспечивающие более высокий уровень безопасности, такие как Rust.
Источники
править
Любой участник может оформить статью: добавить иллюстрации, викифицировать, заполнить шаблоны и добавить категории.
Любой редактор может снять этот шаблон после оформления и проверки.
Комментарии
Если вы хотите сообщить о проблеме в статье (например, фактическая ошибка и т. д.), пожалуйста, используйте обычную страницу обсуждения.
Комментарии на этой странице могут не соответствовать политике нейтральной точки зрения, однако, пожалуйста, придерживайтесь темы и попытайтесь избежать брани, оскорбительных или подстрекательных комментариев. Попробуйте написать такие комментарии, которые заставят задуматься, будут проницательными или спорными. Цивилизованная дискуссия и вежливый спор делают страницу комментариев дружелюбным местом. Пожалуйста, подумайте об этом.
Несколько советов по оформлению реплик:
- Новые темы начинайте, пожалуйста, снизу.
- Используйте символ звёздочки «*» в начале строки для начала новой темы. Далее пишите свой текст.
- Для ответа в начале строки укажите на одну звёздочку больше, чем в предыдущей реплике.
- Пожалуйста, подписывайте все свои сообщения, используя четыре тильды (~~~~). При предварительном просмотре и сохранении они будут автоматически заменены на ваше имя и дату.
Обращаем ваше внимание, что комментарии не предназначены для размещения ссылок на внешние ресурсы не по теме статьи, которые могут быть удалены или скрыты любым участником. Тем не менее, на странице комментариев вы можете сообщить о статьях в СМИ, которые ссылаются на эту заметку, а также о её обсуждении на сторонних ресурсах.
