Кейс Кук из Google призвал модернизировать процесс работы над ошибками в ядре Linux
Автор
Сообщение
news_bot ®
Стаж: 6 лет 2 месяца
Сообщений: 27286
Кейс Кук (Kees Cook), бывший главный системный администратор kernel.org и лидер Ubuntu Security Team, ныне работающий в компании Google над обеспечением защиты Android и ChromeOS, выразил опасение текущим процессом исправления ошибок в стабильных ветках ядра. Еженедельно в стабильные ветки включается около ста исправлений, а после закрытия окна приёма изменений в следующий релиз приближается к тысяче (сопровождающие удерживают исправления до закрытия окна, а после формирования "-rc1" публикуют накопившееся разом), что слишком много и требует больших трудозатрат для сопровождения продуктов на базе ядра Linux.
По мнению Кейса процессу работы с ошибками в ядре не уделяется должное внимание и ядру не хватает как минимум 100 дополнительных разработчиков для скоординированной работы в этой области. Основные разработчики ядра регулярно исправляют ошибки, но нет никаких гарантий, что эти исправления будут перенесены в варианты ядра, используемые сторонними производителями. У пользователей различных продуктов на базе ядра Linux также нет возможности проконтролировать то, какие ошибки исправлены и какое ядро используется в их устройствах. В конечном счёте за безопасность своих продуктов отвечают производители, но в условиях очень большой интенсивности публикации исправлений в стабильных ветках ядра они оказались поставлены перед выбором - переносить все исправления, выборочно портировать самое важное или игнорировать все исправления.
Оптимальным решением был бы перенос только самых важных исправлений ошибок и уязвимостей, но в выделении подобных патчей из общего потока и состоит основная проблема. Наибольшее число всплывающих проблем является следствием использования языка Си, требующего большой аккуратности при работе с памятью и указателями. Усугубляет ситуацию то, что многие потенциальные исправления уязвимостей не снабжаются идентификаторами CVE или получают подобный идентификатор через какое-то время после публикации исправления. В подобных условиях производителям очень трудно разделить второстепенные исправления от важных проблем, влияющих на безопасность. По статистике более 40% уязвимостей устраняются до присвоения CVE и в среднем задержка между выпуском исправления и присвоением CVE составляет три месяца (т.е. вначале исправление воспринимается как обычная ошибка, но лишь спустя несколько месяцев становится ясно, что имело место устранение узявимости).
В итоге, не имея отдельной ветки с исправлениями уязвимостей и не получая сведений о связи с безопасностью той или ной проблемы, производителям продуктов на базе ядра Linux остаётся непрерывно переносить все исправлений из свежих стабильных веток. Но данная работа требует больших трудозатрат и сталкивается в компаниях с сопротивлением из-за опасения в появлении регрессивных изменений, способных нарушить нормальную работу продукта.
Напомним, что по мнению Линуса Торвальдса, все ошибки важны и уязвимости не следует отделять от других видов ошибок и выделять в отдельную более приоритетную категорию. Объясняется такое мнение тем, что для обычного разработчика, не специализирующегося на вопросах безопасности, не очевидна связь исправления с потенциальной уязвимостью (для многих исправлений лишь проведение отдельного аудита позволяет понять, что они касаются безопасности). По мнению Линуса, вопросами выделения из общего потока исправлений потенциальных уязвимостей должны заниматься специалисты по безопасности из команд, отвечающих за поддержку пакетов с ядром в дистрибутивах Linux.
Кейс Кук считает, что единственным решением для поддержания безопасности ядра при разумных долгосрочных затратах является перевод компаниями инженеров, занимающихся портированием исправлений в локальные сборки ядра, к совместной скоординированной работе над сопровождением исправлений и уязвимостей в основном ядре (upstream). В текущем виде, многие производители используют в своих продуктах не самые новые версии ядра и бэкпортируют исправления собственными силами, т.е. получается, что инженеры в разных компаниях дублируют работу друг друга, решая одну и ту же проблему.
Например, если 10 компаний, в каждой из которых один инженер занимается бэкпорированием одних и тех же исправлений, переориентируют данных инженеров на исправление ошибок в upstream, то они вместо портирования одного исправления могли бы исправить 10 разных ошибок для общей пользы или подключиться к рецензированию предлагаемых изменений и не допустить включения кода с ошибками в ядро. Ресурсы также можно было бы направить на создание новых инструментов для тестирования и анализа кода, которые позволили бы на ранней стадии автоматически выявлять типовые классы ошибок, которые всплывают вновь и вновь.
Кейс Кук также предлагает более активно использовать автоматизированное и fuzzing-тестирование непосредственно в процессе разработки ядра, применять системы непрерывной интеграции и отказаться от архаичного управления разработкой через email. В настоящее время эффективному тестированию мешает то, что основные процессы тестирования отделены от разработки и происходят уже после формирования релизов. Кейс также рекомендовал для снижения числа ошибок применять при разработке языки, обеспечивающие более высокий уровень безопасности, такие как Rust.
===========
Источник:
OpenNet.RU
===========
Похожие новости
- Главная ссылка к новости (https://security.googleblog.co...)
- OpenNews: Google работает над использованием обычного ядра Linux в Android
- OpenNews: Проект по продвижению в ядро Linux новых технологий активной защиты
- OpenNews: Управление через почтовые рассылки как барьер, мешающий приходу молодых разработчиков
- OpenNews: Продолжение дискуссии с Линусом Торвальдсом о стабильности API ядра Linux
- OpenNews: Линус Торвальдс столкнулся с дилеммой: устранение уязвимости или сохранение совместимости
Похожие новости:
- Оценка использования уязвимых открытых компонентов в коммерческом ПО
- Google запретит подключение к своим сервисам очень старых версий Android
- Уязвимости в eBPF, позволяющие обойти защиту от атаки Spectre 4
- Выпуск первой бета-версии дистрибутива MX Linux 21
- Драйвер NTFS от Paragon Software может быть принят в состав ядра Linux 5.15
- Root-уязвимость в ядре Linux и отказ в обслуживании в systemd
- Для ядра Linux предложен драйвер GPIO, написанный на Rust
- Реализована загрузка ядра Linux на плате ESP32
- Линус Торвальдс прокомментрировал ситуацию с драйвером NTFS от Paragon Software
- Уязвимость в подсистеме ядра Linux Netfilter
Теги для поиска: #_kernel, #_linux, #_google, #_security
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 29-Апр 03:32
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 2 месяца |
|
|
Кейс Кук (Kees Cook), бывший главный системный администратор kernel.org и лидер Ubuntu Security Team, ныне работающий в компании Google над обеспечением защиты Android и ChromeOS, выразил опасение текущим процессом исправления ошибок в стабильных ветках ядра. Еженедельно в стабильные ветки включается около ста исправлений, а после закрытия окна приёма изменений в следующий релиз приближается к тысяче (сопровождающие удерживают исправления до закрытия окна, а после формирования "-rc1" публикуют накопившееся разом), что слишком много и требует больших трудозатрат для сопровождения продуктов на базе ядра Linux. По мнению Кейса процессу работы с ошибками в ядре не уделяется должное внимание и ядру не хватает как минимум 100 дополнительных разработчиков для скоординированной работы в этой области. Основные разработчики ядра регулярно исправляют ошибки, но нет никаких гарантий, что эти исправления будут перенесены в варианты ядра, используемые сторонними производителями. У пользователей различных продуктов на базе ядра Linux также нет возможности проконтролировать то, какие ошибки исправлены и какое ядро используется в их устройствах. В конечном счёте за безопасность своих продуктов отвечают производители, но в условиях очень большой интенсивности публикации исправлений в стабильных ветках ядра они оказались поставлены перед выбором - переносить все исправления, выборочно портировать самое важное или игнорировать все исправления.  Оптимальным решением был бы перенос только самых важных исправлений ошибок и уязвимостей, но в выделении подобных патчей из общего потока и состоит основная проблема. Наибольшее число всплывающих проблем является следствием использования языка Си, требующего большой аккуратности при работе с памятью и указателями. Усугубляет ситуацию то, что многие потенциальные исправления уязвимостей не снабжаются идентификаторами CVE или получают подобный идентификатор через какое-то время после публикации исправления. В подобных условиях производителям очень трудно разделить второстепенные исправления от важных проблем, влияющих на безопасность. По статистике более 40% уязвимостей устраняются до присвоения CVE и в среднем задержка между выпуском исправления и присвоением CVE составляет три месяца (т.е. вначале исправление воспринимается как обычная ошибка, но лишь спустя несколько месяцев становится ясно, что имело место устранение узявимости). В итоге, не имея отдельной ветки с исправлениями уязвимостей и не получая сведений о связи с безопасностью той или ной проблемы, производителям продуктов на базе ядра Linux остаётся непрерывно переносить все исправлений из свежих стабильных веток. Но данная работа требует больших трудозатрат и сталкивается в компаниях с сопротивлением из-за опасения в появлении регрессивных изменений, способных нарушить нормальную работу продукта. Напомним, что по мнению Линуса Торвальдса, все ошибки важны и уязвимости не следует отделять от других видов ошибок и выделять в отдельную более приоритетную категорию. Объясняется такое мнение тем, что для обычного разработчика, не специализирующегося на вопросах безопасности, не очевидна связь исправления с потенциальной уязвимостью (для многих исправлений лишь проведение отдельного аудита позволяет понять, что они касаются безопасности). По мнению Линуса, вопросами выделения из общего потока исправлений потенциальных уязвимостей должны заниматься специалисты по безопасности из команд, отвечающих за поддержку пакетов с ядром в дистрибутивах Linux. Кейс Кук считает, что единственным решением для поддержания безопасности ядра при разумных долгосрочных затратах является перевод компаниями инженеров, занимающихся портированием исправлений в локальные сборки ядра, к совместной скоординированной работе над сопровождением исправлений и уязвимостей в основном ядре (upstream). В текущем виде, многие производители используют в своих продуктах не самые новые версии ядра и бэкпортируют исправления собственными силами, т.е. получается, что инженеры в разных компаниях дублируют работу друг друга, решая одну и ту же проблему. Например, если 10 компаний, в каждой из которых один инженер занимается бэкпорированием одних и тех же исправлений, переориентируют данных инженеров на исправление ошибок в upstream, то они вместо портирования одного исправления могли бы исправить 10 разных ошибок для общей пользы или подключиться к рецензированию предлагаемых изменений и не допустить включения кода с ошибками в ядро. Ресурсы также можно было бы направить на создание новых инструментов для тестирования и анализа кода, которые позволили бы на ранней стадии автоматически выявлять типовые классы ошибок, которые всплывают вновь и вновь. Кейс Кук также предлагает более активно использовать автоматизированное и fuzzing-тестирование непосредственно в процессе разработки ядра, применять системы непрерывной интеграции и отказаться от архаичного управления разработкой через email. В настоящее время эффективному тестированию мешает то, что основные процессы тестирования отделены от разработки и происходят уже после формирования релизов. Кейс также рекомендовал для снижения числа ошибок применять при разработке языки, обеспечивающие более высокий уровень безопасности, такие как Rust. =========== Источник: OpenNet.RU =========== Похожие новости
|
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 29-Апр 03:32
Часовой пояс: UTC + 5