Kis Cook, ish drejtori i sistemeve nĂ« kernel.org dhe lider i Ekipit tĂ« SigurisĂ« Ubuntu, tani punon nĂ« Google pĂ«r tĂ« siguruar mbrojtjen e Android dhe ChromeOS, shpreh shqetĂ«simin e tij pĂ«r procesin aktual tĂ« korrigjimit tĂ« gabimeve nĂ« degĂ«t stabile tĂ« kernelit. Ădo javĂ«, rreth njĂ«qind ndryshime pĂ«rfshihen nĂ« degĂ«t e qĂ«ndrueshme, ndĂ«rsa pas mbylljes sĂ« pranimit tĂ« ndryshimeve nĂ« versionin e ardhshĂ«m, numri afrohet nĂ« njĂ« mijĂ« (shoqĂ«ruesit mbajnĂ« ndryshimet deri nĂ« mbylljen e dritares, dhe pas formimit tĂ« "-rc1", publikojnĂ« gjithçka njĂ«kohĂ«sisht), qĂ« Ă«shtĂ« shumĂ« dhe kĂ«rkon pĂ«rpjekje tĂ« mĂ«dha pĂ«r mbĂ«shtetje tĂ« produkteve tĂ« bazuara nĂ« kernelin Linux.
Sipas Kisit, procesi i punĂ«s me gabime nĂ« kernel nuk i jepet vĂ«mendja e nevojshme dhe kernelit i mungojnĂ« tĂ« paktĂ«n 100 zhvillues tĂ« tjerĂ« pĂ«r njĂ« punĂ« tĂ« koordinuar nĂ« kĂ«tĂ« fushĂ«. Zhvilluesit kryesorĂ« tĂ« kernelit rregullisht korrigjojnĂ« gabimet, por nuk ka garanci qĂ« kĂ«to korrigjime do tĂ« transferohen nĂ« variantet e kernelit tĂ« pĂ«rdorura nga prodhuesit e tjerĂ«. PĂ«rdoruesit e produkteve tĂ« ndryshme tĂ« bazuara nĂ« kernelin Linux gjithashtu nuk kanĂ« mundĂ«si tĂ« kontrollojnĂ« se cilat gabime janĂ« korrigjuar dhe cilin kernel po pĂ«rdorin nĂ« pajisjet e tyre. NĂ« fund, pĂ«rgjegjĂ«sia pĂ«r sigurinĂ« e produkteve tĂ« tyre i takon prodhuesve, por nĂ«n njĂ« intensitet shumĂ« tĂ« lartĂ« tĂ« publikimit tĂ« ndryshimeve nĂ« degĂ«t stabile tĂ« kernelit, ata janĂ« pĂ«rballur me njĂ« zgjedhje â tĂ« transferojnĂ« tĂ« gjitha korrigjimet, tĂ« portojnĂ« pĂ«rzgjedhjen e mĂ« tĂ« rĂ«ndĂ«sishme ose tĂ« injorojnĂ« tĂ« gjitha korrigjimet.
Në përfundim, pa një degë të veçantë me korrigjime për dobësitë dhe pa marrë informacionin mbi lidhjen me sigurinë e çështjeve të caktuara, prodhuesve të produkteve të bazuara në kernelin Linux u mbetet të vazhdojnë të transferojnë të gjitha korrigjimet nga degët e reja stabile. Por ky punim kërkon përpjekje të mëdha dhe has në rezistencë në kompanitë për shkak të frikës për shfaqjen e ndryshimeve regresive që mund të dëmtojnë funksionimin normal të produktit.
Të 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ë veçohen në një kategori më prioritet. Ky mendim shpjegohet me faktin se për një zhvillues të zakonshëm, që nuk specializohet në çështjet e sigurisë, lidhja e korrigjimit me një dobësi të mundshme nuk është e qartë (për shumë korrigjime, vetëm realizimi i një auditi të veçantë mund të tregojë se ato kanë të bëjnë me sigurinë). Sipas Linus, specializuesit e sigurisë nga ekipet që përgjigjen për mbështetje të paketave me kernelin në distribucione të Linux duhet të merren me ndarjen e dobësive të mundshme nga fluksi i përgjithshëm i ndryshimeve.
Kis Cook beson se zgjidhja e vetme për të ruajtur sigurinë e kernelit me kostot e arsyeshme afatgjata është të transferohen ingjinierët e kompanive që punojnë për portimin e korrigjimeve në ndërtimet lokale të kernelit në një punë të përbashkët dhe të koordinuar për mbështetje të korrigjimeve dhe dobësive në kernelin kryesor (upstream). Në formën aktuale, shumë prodhues përdorin në produktet e tyre versione të kernelit që nuk janë më të reja dhe portojnë korrigjimet me forcat e tyre, dmth, ingjinierët e kompanive të ndryshme po përsërisin punën e njëri-tjetrit, duke zgjidhur të njëjtin problem.
Për shembull, nëse 10 kompani, një inxhinier në secilën prej të cilave merret me riparimin e të njëjtave gabime, do t'i drejtonin këta inxhinierë për të korrigjuar gabimet në upstream, ata në vend se të portonin një korrigjim, do të ishin në gjendje të riparonin 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ë bërthamë. Burimet gjithashtu mund të drejtoheshin në krijimin e mjeteve të reja për testimin dhe analizën e kodit, të cilat do të lejonin identifikimin automatik të klasave tipike të gabimeve që shfaqen vazhdimisht në fazat e hershme.
Kees Cook gjithashtu ofron që të përdoren më aktivisht testimi automatizuar dhe fuzzing direkt në procesin e zhvillimit të bërthamës, të aplikohen sisteme të integrimit të vazhdueshëm dhe të largohet menaxhimi arkaik i zhvillimit përmes emailit. Aktualisht, testi efektiv pengohet nga fakti se proceset kryesore të testimit janë të ndara nga zhvillimi dhe ndodhin pas formimit të lëshimeve. Kees gjithashtu rekomandoi që për të ulur numrin e gabimeve, të aplikohen gjatë zhvillimit gjuhë që ofrojnë më shumë një nivel të lartë sigurie, si Rust.
Burimi: opennet.ru
