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

Kees Cook, бивш главен системен администратор на kernel.org и ръководител на екипа за сигурност на Ubuntu, който сега работи в Google за защита на Android и ChromeOS, изрази загриженост относно текущия процес на коригиране на грешки в стабилните клонове на ядрото. Всяка седмица около сто корекции се включват в стабилните клонове и след затварянето на прозореца за приемане на промени в следващото издание се приближава до хиляда (поддържащите държат корекциите, докато прозорецът се затвори и след формирането на „ -rc1” те публикуват натрупаните наведнъж), което е твърде много и изисква много труд за продукти за поддръжка, базирани на Linux ядрото.

Според Кийс на процеса на работа с грешки в ядрото не се обръща необходимото внимание и на ядрото липсват поне 100 допълнителни разработчици за координирана работа в тази област. Основните разработчици на ядрото редовно коригират грешки, но няма гаранция, че тези корекции ще бъдат пренесени към варианти на ядрото, използвани от трети страни. Потребителите на различни продукти, базирани на ядрото на Linux, също нямат начин да контролират кои грешки са коригирани и кое ядро ​​се използва в техните устройства. В крайна сметка производителите са отговорни за сигурността на своите продукти, но с много високата интензивност на публикуване на корекции в стабилни клонове на ядрото, те бяха изправени пред избор - да пренесат всички поправки, да пренесат избирателно най-важните или да игнорират всички поправки .

Оптималното решение би било да се мигрират само най-важните поправки и уязвимости, но изолирането на такива грешки от общия поток е основният проблем. Най-много проблеми, които възникват, са следствие от използването на езика C, което изисква голямо внимание при работа с памет и указатели. За да влошат нещата, много потенциални корекции за уязвимост не са снабдени с CVE идентификатор или им е присвоен CVE идентификатор известно време след публикуването на корекцията. В такава среда за производителите е много трудно да отделят дребните поправки от важните проблеми със сигурността. Според статистиката повече от 40% от уязвимостите се коригират преди да бъде назначен CVE и средно забавянето между пускането на корекция и присвояването на CVE е три месеца (т.е. първоначално корекцията се възприема като обикновена грешка, но само след няколко месеца става ясно, че уязвимостта е коригирана).

В резултат на това, без отделен клон с корекции за уязвимости и без получаване на информация за връзката за сигурност на конкретен проблем, производителите на продукти, базирани на ядрото на Linux, са оставени непрекъснато да прехвърлят всички корекции от най-новите стабилни клонове. Но тази работа изисква много труд и среща съпротива в компаниите поради страх от появата на регресивни промени, които могат да нарушат нормалната работа на продукта.

Нека припомним, че според Линус Торвалдс всички грешки са важни и уязвимостите не трябва да се отделят от другите видове грешки и да се поставят в отделна категория с по-висок приоритет. Това мнение се обяснява с факта, че за обикновен разработчик, който не е специализиран в проблемите на сигурността, връзката между корекция и потенциална уязвимост не е очевидна (за много корекции само отделен одит позволява да се разбере, че те се отнасят до сигурността ). Според Линус, специалистите по сигурността от екипите, отговорни за поддръжката на пакетите на ядрото в Linux дистрибуциите, трябва да участват в идентифицирането на потенциални уязвимости от общия поток от пачове.

Kees Cook вярва, че единственото решение за поддържане на сигурността на ядрото на разумна дългосрочна цена е компаниите да преместят инженерите, участващи в пренасянето на корекции към локални надстройки на ядрото, в съвместни, координирани усилия за поддържане на корекции и уязвимости в основното ядро ​​(нагоре по веригата ). В настоящата му форма много производители не използват най-новите версии на ядрото в продуктите си и пренасят корекциите вътрешно, т.е. Оказва се, че инженерите в различни компании дублират работата си, решавайки един и същ проблем.

Например, ако 10 компании, всяка с един инженер, който пренася едни и същи корекции, пренасочат тези инженери към коригиране на грешки нагоре по веригата, тогава вместо да пренасят една корекция, те биха могли да коригират 10 различни грешки за обща полза или да се присъединят към прегледа на предложените промени и предотвратява включването на код с грешки в ядрото. Ресурси могат също да бъдат отделени за създаване на нови инструменти за тестване и анализ на код, които биха позволили ранно откриване на често срещани класове грешки, които се появяват отново и отново.

Kees Cook също предлага по-активно използване на автоматизирано и fuzzing тестване директно в процеса на разработка на ядрото, използване на системи за непрекъсната интеграция и изоставяне на архаичното управление на разработката чрез имейл. Понастоящем ефективното тестване е възпрепятствано от факта, че основните процеси на тестване са отделени от разработката и се случват след формирането на версиите. Keys също препоръчва използването на езици, които осигуряват по-високо ниво на сигурност, като Rust, при разработването, за да се намали броят на грешките.

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