Кийс Кук от Google призова за модернизация на процеса по работа с грешки в ядрото на Linux

Кис Кук (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-тестиране директно в процеса на разработване на ядрото, да се прилагат системи за непрекъсната интеграция и да се откаже от архаичния метод на управление на разработката чрез имейл. В момента ефективното тестване се затруднява, тъй като основните процеси на тестване са отделени от разработката и се извършват след създаването на релизите. Кис също препоръчва за намаляване на броя на грешките да се използват при разработката езици, които осигуряват по-добра сигурност. високо ниво на сигурност, като Rust.

Източник: opennet.ru