Kees gatuan Unë bëj një postim në blog në të cilin ka ngritur shqetësime në lidhje me procesin e rregullimit të gabimeve duke vazhduar në degët e qëndrueshme të kernel Linux dhe është kjo përmendni se javë për javë përfshihen rreth njëqind korrigjime në degë të qëndrueshme, e cila është shumë dhe kërkon shumë përpjekje për të ruajtur produktet e bazuara në kernel Linux.
Sipas Kees, procesi i trajtimit të gabimit të kernelit anashkalohet dhe kernelit i mungojnë të paktën 100 zhvillues shtesë për të punuar në mënyrë të koordinuar në këtë fushë. Përveç përmendjes se zhvilluesit kryesorë të kernelit rregullojnë rregullisht defektet, por nuk ka asnjë garanci që këto rregullime do të kalojnë në variantet e kernelit të palëve të treta.
Duke vepruar kështu, ai përmend se përdoruesit e produkteve të ndryshme të bazuara në kernel Linux gjithashtu nuk kanë asnjë mënyrë për të kontrolluar se cilat defekte janë fikse dhe cilat kernel përdoren në pajisjet e tyre. Në fund të fundit, shitësit janë përgjegjës për sigurinë e produkteve të tyre, por të ballafaquar me një shkallë shumë të lartë të arnave në degët e qëndrueshme të kernelit, ata u përballën me zgjedhjen e migrimit të të gjitha arnave, migrimit në mënyrë selektive të atyre më të rëndësishme, ose injorimit të të gjitha arnave. Me
Zhvilluesit e kernelit në rrjedhën e sipërme mund të rregullojnë defektet, por ata nuk kanë kontroll mbi atë që një shitës në rrjedhën e poshtme zgjedh të përfshijë në produktet e tyre. Përdoruesit përfundimtarë mund të zgjedhin produktet e tyre, por ata në përgjithësi nuk kanë kontroll mbi cilat defekte janë rregulluar ose cili kernel përdoret (një problem në vetvete). Në fund të fundit, shitësit janë përgjegjës për mbajtjen e bërthamave të produkteve të tyre të sigurta.
Kees gatuan sugjeron që zgjidhja optimale do të ishte transferimi i vetëm rregullimeve dhe dobësive më të rëndësishme, por problemi kryesor është ndarja e këtyre gabimeve nga rrjedha e përgjithshme, meqenëse shumica e problemeve që dalin janë pasojë e përdorimit të gjuhës C, e cila kërkon shumë kujdes gjatë punës me kujtesën dhe treguesit.
Për t'i bërë gjërat më keq, shumë rregullime të mundshme të cenueshmërisë nuk etiketohen me identifikues CVE ose nuk marrin një identifikues CVE disa kohë pasi të lëshohet arna.
Në një mjedis të tillë, është shumë e vështirë për prodhuesit të ndajnë rregullimet e vogla nga çështjet kryesore të sigurisë. Sipas statistikave, më shumë se 40% e dobësive hiqen para caktimit të CVE, dhe mesatarisht, vonesa midis një lëshimi fiks dhe një caktimi CVE është tre muaj (domethënë, në fillim, ajo percepton një zgjidhje si një gabim të zakonshëm ,
Si rezultat, duke mos pasur një degë të veçantë me rregullime për dobësitë dhe mos marrja e informacionit në lidhje me lidhjen me sigurinë e këtij ose atij problemi, prodhuesit e produkteve të bazuara në kernel Linux duhet të transferojnë vazhdimisht të gjitha rregullimet të degëve të reja të qëndrueshme. Por kjo punë është punë intensive dhe përballet me rezistencë nga kompanitë për shkak të frikës së ndryshimeve regresive që mund të prishin funksionimin normal të produktit.
Çelësat Gatuaj beson se e vetmja zgjidhje për ta mbajtur kernelin të sigurt me një kosto të arsyeshme në afat të gjatë është zhvendosja e inxhinierëve të arnave për ndërtimin e kernelit të çmendurTë punojmë së bashku në mënyrë të koordinuar për të ruajtur arna dhe dobësi në bërthamën e sipërme. Siç duket, shumë shitës nuk përdorin versionet më të fundit të kernelit në produktet e tyre dhe rregullojnë backport -in e tyre, që do të thotë se inxhinierë nga kompani të ndryshme dalin të dyfishojnë punën e njëri -tjetrit, duke zgjidhur të njëjtin problem.
Për shembull, nëse 10 kompani, secila me një inxhinier që mbështet të njëjtat rregullime, i përcjellin këta inxhinierë për të rregulluar defektet në rrjedhën e sipërme, në vend që të migrojnë një rregullim, ata mund të rregullojnë 10 defekte të ndryshme për përfitimin e përgjithshëm ose të mblidhen për të rishikuar defektet e propozuara Me Dhe shmangni përfshirjen e kodit të gabuar në kernel. Burimet mund të përdoren gjithashtu për të krijuar mjete të reja të analizës dhe testimit të kodit që do të zbulonin automatikisht në një fazë të hershme klasat tipike të gabimeve që shfaqen pa pushim.
Çelësat Gatuaj gjithashtu propozon që të përdoret testimi dhe fuzimi i automatizuar në mënyrë më aktive drejtpërdrejt në procesin e zhvillimit të kernelit, përdorni sisteme të vazhdueshme integrimi dhe braktisni menaxhimin arkaik të zhvillimit përmes e-mail.
Fuente: https://security.googleblog.com