Кіс Кук Я роблю пост у блозі, в якому викликав занепокоєння щодо процесу виправлення помилок триває у стабільних гілках ядра Linux і це згадуйте, що тиждень за тижнем включено близько сотні виправлень на стабільних гілках, що занадто багато і вимагає багато зусиль для підтримки продуктів на основі ядра Linux.
За словами Кіз, процес обробки помилок ядра обходить і ядру не вистачає принаймні 100 додаткових розробників працювати злагоджено у цій сфері. На додаток до згадки, що великі розробники ядра регулярно виправляють помилки, але немає гарантії, що ці виправлення перенесуться на сторонні варіанти ядра.
При цьому він згадує, що користувачі різних продуктів на основі ядра Linux також не мають можливості контролювати, які помилки виправлені і яке ядро використовується на їх пристроях. Зрештою, постачальники несуть відповідальність за безпеку своїх продуктів, але зіткнувшись з дуже високим рівнем виправлень на стабільних гілках ядра, вони опинилися перед вибором міграції всіх патчів, вибірково міграції найважливіших або ігнорування всіх патчів. .
Розробники ядра вищого рівня можуть виправляти помилки, але вони не мають контролю над тим, що постачальник подальшого потоку вибирає включити у свої продукти. Кінцеві користувачі можуть вибирати свої продукти, але вони, як правило, не можуть контролювати, які помилки виправлені або яке ядро використовується (проблема сама по собі). Зрештою, постачальники несуть відповідальність за безпеку своїх ядер продуктів.
Кіс Кук припускає, що оптимальним рішенням було б передати лише найважливіші виправлення та вразливості, але основна проблема полягає у тому, щоб відокремити ці помилки від загального потоку, оскільки більшість проблем, що виникають, є наслідком використання мови C, що вимагає багато уваги при роботі з пам’яттю та покажчиками.
Що ще погіршує ситуацію, багато виправлення потенційних уразливостей не позначаються ідентифікаторами CVE або не отримують ідентифікатор CVE через деякий час після випуску виправлення.
У такому середовищі виробникам дуже важко відокремити незначні виправлення від основних проблем безпеки. За статистикою, більше 40% уразливостей усуваються до призначення CVE, і в середньому затримка між випуском виправлення та призначенням CVE становить три місяці (тобто спочатку сприймається рішення як поширена помилка,
В результаті, відсутність окремої гілки з виправленнями для вразливостей і не отримуючи інформації про зв'язок із безпекою тієї чи іншої проблеми, виробникам продуктів на основі ядра Linux доводиться постійно передавати всі виправлення нових стабільних гілок. Але ця робота є трудомісткою і стикається з опором компаній через побоювання регресивних змін, які можуть порушити нормальну роботу продукту.
Ключі Кука вважає, що єдиним рішенням для забезпечення безпеки ядра за розумними цінами в довгостроковій перспективі є переїзд інженерів -патчів до божевільних збірок ядраl працювати злагоджено разом для підтримки виправлень і вразливостей у ядрі висхідного потоку. На сьогоднішній день багато постачальників не використовують найновіші версії ядра у своїх продуктах і виправленнях бекпорту самостійно, тобто виявляється, що інженери з різних компаній дублюють роботу один одного, вирішуючи одну і ту ж проблему.
Наприклад, якщо 10 компаній, кожна з яких має інженера, що підтримує однакові виправлення, перенаправляють цих інженерів для виправлення помилок у потоці, замість того, щоб перенести одне виправлення, вони могли б виправити 10 різних помилок для загальної вигоди або об’єднатися, щоб переглянути помилки. Запропоновані зміни . І уникайте включення коду помилок у ядро. Ресурси також можна використати для створення нових інструментів аналізу та тестування коду, які автоматично виявлятимуть на ранній стадії типові класи помилок, які з’являються знову і знову.
Ключі Кука також пропонує активніше використовувати автоматизоване тестування та нечіткість безпосередньо у процесі розробки ядра, використовувати системи безперервної інтеграції та відмовитися від архаїчного управління розробкою за допомогою електронної пошти.
Фуенте: https://security.googleblog.com