Kees Cook, ish-administratori kryesor i sistemit të kernel.org dhe drejtuesi i Ekipit të Sigurisë së Ubuntu, i cili tani punon në Google për të siguruar Android dhe ChromeOS, shprehu shqetësimin për procesin aktual të rregullimit të gabimeve në degët e qëndrueshme të kernelit. Çdo javë, rreth njëqind rregullime përfshihen në degët e qëndrueshme dhe pasi të mbyllet dritarja për pranimin e ndryshimeve në versionin e ardhshëm, ajo i afrohet një mijë (mirëmbajtësit i mbajnë rregullimet derisa dritarja të mbyllet dhe pas formimit të " -rc1” i publikojnë ato të grumbulluara menjëherë), që është shumë dhe kërkon shumë punë për produktet e mirëmbajtjes bazuar në kernelin Linux.
Sipas Keys, procesit të punës me gabimet në kernel nuk i kushtohet vëmendja e duhur dhe kernelit i mungojnë të paktën 100 zhvillues shtesë për punë të koordinuar në këtë fushë. Zhvilluesit kryesorë të kernelit rregullojnë rregullisht gabimet, por nuk ka asnjë garanci që këto rregullime do të barten në variantet e kernelit të përdorura nga palët e treta. Përdoruesit e produkteve të ndryshme të bazuara në kernel Linux gjithashtu nuk kanë asnjë mënyrë për të kontrolluar se cilat gabime janë rregulluar dhe cili kernel përdoret në pajisjet e tyre. Në fund të fundit, prodhuesit janë përgjegjës për sigurinë e produkteve të tyre, por me intensitetin shumë të lartë të publikimit të korrigjimeve në degët e qëndrueshme të kernelit, ata u përballën me një zgjedhje - të portosh të gjitha rregullimet, të portosh në mënyrë selektive ato më të rëndësishmet ose të shpërfillësh të gjitha rregullimet. .
Zgjidhja optimale do të ishte migrimi i vetëm rregullimeve dhe dobësive më të rëndësishme, por izolimi i gabimeve të tilla nga rrjedha e përgjithshme është problemi kryesor. Numri më i madh i problemeve që shfaqen janë pasojë e përdorimit të gjuhës C, e cila kërkon kujdes të madh gjatë punës me memorie dhe tregues. Për t'i bërë gjërat edhe më keq, shumë arna potenciale të cenueshmërisë nuk pajisen me një identifikues CVE, ose u caktohet një identifikues CVE pak kohë pasi të publikohet patch. Në një mjedis të tillë, është shumë e vështirë për prodhuesit që të ndajnë rregullimet e vogla nga çështjet e rëndësishme të sigurisë. Sipas statistikave, më shumë se 40% e dobësive rregullohen përpara se të caktohet një CVE, dhe mesatarisht vonesa midis lëshimit të një rregullimi dhe caktimit të një CVE është tre muaj (d.m.th., në fillim rregullimi perceptohet si një gabim i rregullt, por vetëm pas disa muajsh bëhet e qartë se cenueshmëria është rregulluar).
Si rezultat, pa një degë të veçantë me rregullime për dobësitë dhe pa marrë informacion në lidhje me lidhjen e sigurisë të një problemi të caktuar, prodhuesit e produkteve të bazuara në kernel Linux lihen të transferojnë vazhdimisht të gjitha rregullimet nga degët më të fundit të qëndrueshme. Por kjo punë kërkon shumë punë dhe përballet me rezistencë në kompani për shkak të frikës nga shfaqja e ndryshimeve regresive që mund të prishin funksionimin normal të produktit.
Le të kujtojmë se sipas Linus Torvalds, të gjitha gabimet janë të rëndësishme dhe dobësitë nuk duhet të ndahen nga llojet e tjera të gabimeve dhe të ndahen në një kategori të veçantë me përparësi më të lartë. Ky opinion shpjegohet me faktin se për një zhvillues të zakonshëm që nuk është i specializuar në çështjet e sigurisë, lidhja midis një rregullimi dhe një cenueshmërie të mundshme nuk është e dukshme (për shumë rregullime, vetëm një auditim i veçantë bën të mundur të kuptohet se ato kanë të bëjnë me sigurinë ). Sipas Linus, specialistët e sigurisë nga ekipet përgjegjëse për mirëmbajtjen e paketave të kernelit në shpërndarjet Linux duhet të përfshihen në identifikimin e dobësive të mundshme nga rrjedha e përgjithshme e arnimeve.
Kees Cook beson se e vetmja zgjidhje për ruajtjen e sigurisë së kernelit me një kosto të arsyeshme afatgjatë është që kompanitë t'i zhvendosin inxhinierët e përfshirë në transferimin e rregullimeve në strukturat lokale të kernelit në një përpjekje të përbashkët, të koordinuar për të ruajtur rregullimet dhe dobësitë në kernelin kryesor (në rrjedhën e sipërme ). Në formën e tij aktuale, shumë prodhues nuk përdorin versionet më të fundit të kernelit në produktet e tyre dhe përcjellin rregullimet në shtëpi, d.m.th. Rezulton se inxhinierët në kompani të ndryshme kopjojnë punën e njëri-tjetrit, duke zgjidhur të njëjtin problem.
Për shembull, nëse 10 kompani, secila me një inxhinier që raporton të njëjtat rregullime, i ricaktojnë ata inxhinierë për të rregulluar defektet në rrjedhën e sipërme, atëherë në vend që të raportojnë një rregullim, ata mund të rregullojnë 10 gabime të ndryshme për përfitimin e përbashkët ose të bashkohen në rishikimin e propozuar. ndryshon dhe parandalon përfshirjen e kodit të gabimeve në kernel. Burimet mund t'i kushtohen gjithashtu krijimit të mjeteve të reja për testimin dhe analizimin e kodit që do të lejonin zbulimin e hershëm të klasave të zakonshme të gabimeve që shfaqen përsëri dhe përsëri.
Kees Cook sugjeron gjithashtu përdorimin më aktiv të testimit të automatizuar dhe të paqartë drejtpërdrejt në procesin e zhvillimit të kernelit, duke përdorur sisteme të vazhdueshme integrimi dhe braktisjen e menaxhimit arkaik të zhvillimit përmes emailit. Aktualisht, testimi efektiv pengohet nga fakti se proceset kryesore të testimit janë të ndara nga zhvillimi dhe ndodhin pas formimit të lëshimeve. Çelësat rekomandojnë gjithashtu përdorimin e gjuhëve që ofrojnë një nivel më të lartë sigurie, si Rust, gjatë zhvillimit për të zvogëluar numrin e gabimeve.
Burimi: opennet.ru