Kiss Kuk (Kees Cook), ish-krer i sistemit nĂ« kernel.org dhe lider i Ubuntu Security Team, tani duke punuar nĂ« Google pĂ«r tĂ« siguruar mbrojtjen e Android dhe ChromeOS, shprehu shqetĂ«simin e tij mbi procesin aktual tĂ« korrigjimit tĂ« gabimeve nĂ« degĂ«t stabile tĂ« bĂ«rthamĂ«s. Ădo javĂ«, rreth njĂ«qind korrigjime pĂ«rfshihen nĂ« degĂ«t stabile, dhe pas mbylljes sĂ« dritares sĂ« pranimit tĂ« ndryshimeve pĂ«r lĂ«shimin e ardhshĂ«m, numri afrohet nĂ« njĂ« mijĂ« (mĂ«ntorĂ«t mbajnĂ« korrigjimet deri nĂ« mbylljen e dritares, dhe pas formimit tĂ« "-rc1" publikojnĂ« gjithçka sĂ« bashku), qĂ« Ă«shtĂ« shumĂ« dhe kĂ«rkon njĂ« pĂ«rpjekje tĂ« madhe pĂ«r mbĂ«shtetje tĂ« produkteve tĂ« bazuara nĂ« bĂ«rthamĂ«n Linux.
Sipas Kees, procesi i punĂ«s me gabime nĂ« bĂ«rthamĂ« nuk po i jepet rĂ«ndĂ«sia e duhur dhe bĂ«rthama i mungon tĂ« paktĂ«n 100 zhvillues tĂ« tjerĂ« pĂ«r tĂ« punuar nĂ« mĂ«nyrĂ« tĂ« koordinuar nĂ« kĂ«tĂ« fushĂ«. Zhvilluesit kryesorĂ« tĂ« bĂ«rthamĂ«s rregullisht korrigjojnĂ« gabime, por nuk ka asnjĂ« garanci se kĂ«to korrigjime do tĂ« kalohen nĂ« versionet e bĂ«rthamĂ«s qĂ« pĂ«rdoren nga prodhuesit e tjerĂ«. PĂ«rdoruesit e produkteve tĂ« ndryshme tĂ« bazuara nĂ« bĂ«rthamĂ«n Linux gjithashtu nuk kanĂ« mundĂ«si tĂ« kontrollojnĂ« se cilat gabime janĂ« korrigjuar dhe cila bĂ«rthamĂ« po pĂ«rdoret nĂ« pajisjet e tyre. NĂ« fund tĂ« fundit, prodhuesit janĂ« pĂ«rgjegjĂ«s pĂ«r sigurinĂ« e produkteve tĂ« tyre, por nĂ« kushte tĂ« intensitetit shumĂ« tĂ« madh tĂ« publikimit tĂ« korrigjimeve nĂ« degĂ«t stabile tĂ« bĂ«rthamĂ«s, ata janĂ« vendosur pĂ«rpara njĂ« zgjedhjeje â tĂ« transferojnĂ« tĂ« gjitha korrigjimet, tĂ« portojnĂ« pĂ«rzgjedhshĂ«m ato mĂ« tĂ« rĂ«ndĂ«sishmet ose tĂ« injorojnĂ« tĂ« gjitha korrigjimet.
Si rezultat, duke mos pasur një degë të veçantë për korrigjimet e dobësive dhe duke mos marrë informacione lidhur me sigurinë e ndonjë problemi, prodhuesve të produkteve mbi kernelin Linux u mbetet të transferojnë vazhdimisht të gjitha korrigjimet nga degët stabile të fundit. Por kjo punë kërkon shumë burime dhe përballet me rezistencë nga kompanitë për shkak të frikës nga ndryshimet regresive që mund të prisnin funksionimin normal të produktit.
Kujtojmë se sipas mendimit të Linus Torvalds, të gjitha gabimet janë të rëndësishme dhe dobësitë nuk duhet të ndahen nga lloje të tjera gabimesh dhe të klasifikohen në një kategori më prioritar. Ky mendim shpjegohet me faktin se për një zhvillues të zakonshëm, që nuk specializohet në çështjet e sigurisë, lidhja e një korrigjimi me një dobësi të mundshme nuk është e dukshme (për shumë korrigjime, vetëm kalimi në një auditi të veçantë lejon të kuptohet se ato lidhen me sigurinë). Sipas Linus, specialistët e sigurisë nga ekipet përgjegjëse për mbështetje të pakove me kernel në shpërndarjet Linux duhet të merren me identifikimin e dobësive të mundshme nga rrjedha e zakonshme e korrigjimeve.
Kis Kuk mendon se zgjidhja e vetme për të mbajtur sigurinë e kernelit me kostot e arsyeshme afatgjata është transferimi i inxhinierëve të kompanive, të angazhuar në portimin e rregullimeve në ndërtimet lokale të kernelit, në një punë të përbashkët dhe të koordinuar për mbështetje dhe rregullime të dobësive në kernelin kryesor (upstream). Në formën e tanishme, shumë prodhues përdorin në produktet e tyre versione të vjetra të kernelit dhe bëjnë backport-e të rregullimeve me forcat e tyre, duke e bërë që inxhinierët në kompani të ndryshme të kopjojnë punën e njëri-tjetrit duke zgjidhur të njëjtën problem.
Për shembull, nëse 10 kompani, secila prej të cilave ka një inxhinier të angazhuar në backport-in e të njëjtave rregullime, do t'i ri-orientonin këta inxhinierë në rregullimin e gabimeve në upstream, ata në vend që të portonin një rregullim mund të rregullonin 10 gabime të ndryshme për dobinë e përgjithshme ose të angazhoheshin në rishikimin e ndryshimeve të propozuara dhe të parandalonin përfshirjen e kodit me gabime në kernel. Burimet gjithashtu mund të drejtoheshin në krijimin e mjeteve të reja për testimin dhe analizën e kodit, të cilat do të lejonin të identifikonin automatikisht, në një fazë të hershme, klasat tipike të gabimeve që shfaqen përherë e më shumë.
Kis Kuk gjithashtu propozon të përdoret më aktivisht testimi i automatizuar dhe fuzzing-testi direkt në procesin e zhvillimit të kernelit, të aplikohet sisteme të integrimit të vazhdueshëm dhe të braktiset menaxhimi arkaik i zhvillimit përmes email-it. Aktualisht, testi efikas pengohet nga fakti se proceset kryesore të testimit janë të ndara nga zhvillimi dhe ndodhin pas formimit të lëshimeve. Kis gjithashtu ka rekomanduar që për të reduktuar numrin e gabimeve të përdoren gjuhë që ofrojnë më shumë nivel i lartë sigurie, si Rust.
Burimi: opennet.ru
