Кис Кук (Kees Cook), бившият главен системен администратор на kernel.org и лидер на Ubuntu Security Team, в момента работи в Google, където се грижи за сигурността на Android и ChromeOS. Той изрази притеснение относно текущия процес на коригиране на грешки в стабилните клонове на ядрото. На седмична база се включват около сто корекции в стабилните клонове, а след затварянето на прозореца за подаване на изменения в следващото издание, числото достига почти хиляда (поддържащите задържат корекциите до затварянето на прозореца, а след формирането на „-rc1“ публикуват натрупаното веднъж), което е прекалено много и изисква значителни усилия за поддържане на продуктите, базирани на Linux ядрото.
Според Кук, процесът на работа с грешките в ядрото не получава необходимото внимание и ядрото се нуждае най-малко от 100 допълнителни разработчици за координирана работа в тази област. Основните разработчици на ядрото редовно коригират грешки, но няма гаранции, че тези корекции ще бъдат пренесени в вариантите на ядрото, използвани от трети производители. Потребителите на различни продукти, базирани на Linux ядрото, също нямат възможността да проследят кои грешки са коригирани и коя версия на ядрото е използвана в техните устройства. В крайна сметка производителите носят отговорност за сигурността на своите продукти, но в условията на много интензивно публикуване на корекции в стабилните клонове на ядрото, те са поставени пред избор — да пренесат всички поправки, да изберат най-важното или да игнорират всички промени.
В крайна сметка, без отделен клон с корекции на уязвимости и без информация за връзката с безопасността на конкретен проблем, производителите на продукти на базата на ядрото Linux трябва непрекъснато да прехвърлят всички корекции от новите стабилни клонове. Но тази работа изисква значителни трудозатрати и среща съпротива в компаниите поради опасения от възникване на регресивни промени, които могат да нарушат нормалната работа на продукта.
Да припомним, че според Линус Торвалдс, всички грешки са важни и уязвимостите не трябва да се отделят от другите видове грешки и да се издигат в отделна, по-приоритетна категория. Това мнение се обяснява с факта, че за обикновения разработчик, който не е специализиран в сигурността, не е очевидна връзката между корекцията и потенциалната уязвимост (за много корекции само извършването на отделен одит позволява да се разбере, че те касаят сигурността). Според Линус, въпросите за отделянето на потенциални уязвимости от общия поток на корекциите трябва да се разглеждат от експерти по сигурност от екипите, отговорни за поддръжката на пакетите с ядро в дистрибуциите на Linux.
Кис Кук смята, че единственото решение за поддържане на сигурността на ядрото с разумни дългосрочни разходи е преминаването на компаниите към съвместно координирано работене над поддръжката на корекции и уязвимости в основното ядро (upstream), вместо да бъдат ангажирани инженери за портироване на корекции в локални версии на ядрото. В настоящия си вид, много производители използват не най-новите версии на ядрото в своите продукти и обратно портирват корекции самостоятелно, което означава, че инженерите в различните компании дублират работата си по решаване на една и съща проблематика.
Например, ако 10 компании, в които по един инженер работи по обратно портирването на едни и същи корекции, пренасочат тези инженери към коригиране на грешки в upstream, те вместо да портирват една корекция могат да коригират 10 различни грешки за общата полза или да се включат в рецензиране на предложените промени, за да предотвратят вмъкването на грешен код в ядрото. Ресурсите също биха могли да бъдат насочени към създаването на нови инструменти за тестване и анализ на кода, които биха позволили на ранен етап автоматично да идентифицират типичните класове грешки, които се появяват отново и отново.
Кис Кук предлага също така по-активно използване на автоматизирано и fuzzing-тестиране директно в процеса на разработване на ядрото, прилагане на системи за непрекъсната интеграция и отказ от остарялото управление на разработката чрез email. В момента ефективното тестване е затруднено от факта, че основните процеси на тестване са отделени от разработката и протичат след образуването на версията. Кис също така препоръча за намаляване на броя на грешките да се прилагат при разработването езици, осигуряващи по-подробно високо ниво на сигурност, като Rust.
Източник: opennet.ru
