Кис Кук, поранешна ГО на kernel.org и водач на безбедносниот тим на Ubuntu, кој сега работи за Google за обезбедување на Android и ChromeOS, изрази загриженост за тековниот процес на поправање грешки во стабилните гранки на кернелот. Секоја недела, околу сто поправки се вклучени во стабилните гранки, а по затворањето на прозорецот за прифаќање промени на следното издание, се приближува до илјада (одржувачите ги задржуваат поправките додека прозорецот не се затвори, а по формирањето на „-rc1“ тие објавете ги акумулираните одеднаш), што е премногу и бара многу труд за производи за одржување базирани на кернелот на Линукс.
Според Кис, на процесот на работа со грешки во кернелот не му се посветува соодветно внимание и на кернелот му недостасуваат најмалку 100 дополнителни програмери за координирана работа во оваа област. Програмерите на јадрото на јадрото редовно ги поправаат грешките, но нема гаранција дека овие поправки ќе бидат пренесени на варијанти на јадрото што ги користат трети страни. Корисниците на различни производи базирани на кернелот Линукс, исто така, немаат начин да контролираат кои грешки се поправени и кое јадро се користи во нивните уреди. Продавачите се на крајот одговорни за безбедноста на нивните производи, но со многу висока стапка на закрпи во стабилните гранки на јадрото, тие беа соочени со избор помеѓу задно пренесување на сите закрпи, селективно пренесување на најважните или игнорирање на сите закрпи.
Оптималното решение би било да се мигрираат само најважните поправки и пропусти, но изолирањето на таквите грешки од општиот тек е главниот проблем. Повеќето од проблемите што се појавуваат се должат на употребата на јазикот C, кој бара големо внимание кога се работи со меморија и покажувачи. За да бидат работите уште полоши, многу потенцијални поправки на ранливоста не се обезбедени со CVE идентификатори или добиваат таков идентификатор некое време по објавувањето на закрпата. Во такви услови, за производителите е многу тешко да ги одделат малите поправки од големите безбедносни проблеми. Според статистичките податоци, повеќе од 40% од ранливостите се поправени пред да се додели CVE, а просечното доцнење помеѓу објавувањето на закрпата и доделувањето на CVE е три месеци (т.е., на почетокот, закрпата се смета за вообичаена бубачка, но само по неколку месеци станува јасно дека ранливоста е поправена).
Како резултат на тоа, без да имаат посебна гранка со поправки за пропусти и без да добиваат информации за безбедносното поврзување на одреден проблем, производителите на производи базирани на кернелот на Linux се оставени континуирано да ги пренесуваат сите поправки од свежи стабилни гранки. Но, оваа работа бара многу труд и наидува на отпор во компаниите поради страв од регресивни промени кои можат да го нарушат нормалното функционирање на производот.
Потсетиме дека, според Линус Торвалдс, сите грешки се важни и ранливостите не треба да се одвојуваат од другите видови грешки и да се распределуваат во посебна категорија со повисок приоритет. Ова мислење се објаснува со фактот дека за обичен развивач кој не е специјализиран за безбедносни прашања, врската помеѓу поправка и потенцијална ранливост не е очигледна (за многу поправки, само посебна ревизија ви овозможува да разберете дека тие се однесуваат на безбедноста ). Според Линус, зависи од безбедносните тимови во тимовите одговорни за одржување на пакетите на јадрото на дистрибуциите на Линукс да ги изолираат потенцијалните пропусти од општиот тек на закрпи.
Кис Кук верува дека единственото решение за одржување на кернелот безбедно со разумни долгорочни трошоци е компаниите да ги преместат инженерите вклучени во пренесувањето закрпи во локални градби на кернелот за да работат заеднички и координирано за да ги одржуваат закрпите и ранливостите во горното јадро. Во нејзината сегашна форма, многу производители не ја користат најновата верзија на кернелот во нивните производи и самите поправки на задниот дел, т.е. Излегува дека инженерите во различни компании ја дуплираат работата едни на други, решавајќи го истиот проблем.
На пример, ако 10 компании, секоја со еден инженер поддржува исти поправки, ги пренасочат тие инженери да ги поправат грешките нагоре, тогаш наместо да пренесат едно поправка, тие би можеле да поправат 10 различни грешки за општо добро или да се приклучат на прегледот на предложените промени. и спречете го кодот за баг да биде вклучен во кернелот. Ресурсите, исто така, би можеле да се посветат на создавање нови алатки за тестирање и анализа на кодови, што би овозможило во рана фаза автоматски да се идентификуваат типичните класи на грешки кои се појавуваат повторно и повторно.
Kees Cook, исто така, предлага поактивна употреба на автоматизирано и нејасно тестирање директно во процесот на развој на јадрото, употреба на системи за континуирана интеграција и напуштање на архаичното управување со развојот преку е-пошта. Во моментов, ефективно тестирање е попречено од фактот што главните процеси на тестирање се одвоени од развојот и се случуваат по формирањето на изданија. Клучевите исто така препорачуваат користење побезбедни јазици, како што е Rust, за да се намалат грешките.
Извор: opennet.ru