Кіс Кук (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