Kees Cook, kernel.org CSO ohia eta Ubuntu Segurtasun Taldeko liderra, orain Google-n lan egiten duena Android eta ChromeOS ziurtatzeko, kezka agertu zuen nukleoaren adar egonkorretan akatsak konpontzeko egungo prozesuari buruz. Astero, ehun konponketa inguru sartzen dira adar egonkorretan, eta hurrengo bertsioan aldaketak onartzeko leihoa itxi ondoren, milara hurbiltzen da (mantentzaileek konponketak mantentzen dituzte leihoa itxi arte, eta "-rc1" eratu ondoren. metatutakoak aldi berean argitaratu), gehiegizkoa da eta lan handia eskatzen du Linux nukleoan oinarritutako mantentze-produktuetarako.
Keysen arabera, nukleoan akatsekin lan egiteko prozesuari ez zaio behar bezalako arreta ematen eta nukleoari gutxienez 100 garatzaile gehigarri falta zaizkio arlo honetan lan koordinaturako. Nukleoaren garatzaileek aldian-aldian akatsak konpontzen dituzte, baina ez dago bermerik konponketa hauek hirugarrenek erabiltzen dituzten nukleoaren aldaeretara eramango direnik. Linux nukleoan oinarritutako hainbat produkturen erabiltzaileek ere ez dute kontrolatzeko modurik zein akats konpontzen diren eta zein nukleo erabiltzen den beren gailuetan. Saltzaileak dira azken finean beren produktuen segurtasunaren erantzule, baina nukleo-adar egonkorretan adabaki-tasa oso altuarekin, adabaki guztiak atzera eraman, garrantzitsuenak selektiboki eraman edo adabaki guztiak alde batera utzi behar izan zituzten.
Irtenbide optimoa konponketa eta ahultasun garrantzitsuenak soilik migratzea litzateke, baina horrelako akatsak fluxu orokorretik isolatzea da arazo nagusia. Agertzen diren arazo gehienak C lengoaiaren erabilerari dagozkio, eta horrek arreta handia eskatzen du memoria eta erakusleei aurre egiteko. Hori gutxi balitz, ahultasun-konponketa potentzial asko ez dira CVE identifikatzaileekin ematen, edo identifikatzaile hori jasotzen dute adabakia argitaratu eta denbora gutxira. Baldintza horietan, oso zaila da fabrikatzaileentzat konponketa txikiak segurtasun arazo handietatik bereiztea. Estatistiken arabera, ahultasunen % 40 baino gehiago konpontzen dira CVE bat esleitu baino lehen, eta adabaki bat kaleratu eta CVE bat esleitzearen arteko batez besteko atzerapena hiru hilabetekoa da (hau da, hasieran, adabakia ohikoa dela hautematen da). akatsa, baina hilabete gutxiren buruan argi geratzen da ahultasuna konpondu dela).
Ondorioz, ahultasunen konponketak dituen adar bereizirik izan gabe eta arazo jakin baten segurtasun-konexioari buruzko informazioa jaso gabe, Linux nukleoan oinarritutako produktuen fabrikatzaileek etengabe transferitzen dituzte adar egonkor berrietatik konponketa guztiak. Baina lan honek lan handia eskatzen du eta erresistentzia aurkitzen du enpresetan, produktuaren funtzionamendu normala eten dezaketen aldaketa atzerakoiekiko beldurragatik.
Gogoratu, Linus Torvaldsen arabera, akats guztiak garrantzitsuak direla eta ahultasunak ez direla beste akats mota batzuetatik bereizi behar eta lehentasun handiagoko kategoria bereizi batera esleitu behar. Iritzi hau segurtasun arazoetan espezializatua ez den garatzaile arrunt batentzat konponketa eta ahultasun potentzial baten arteko lotura ez dela begi bistakoa da (konponketa askotan, auditoretza bereizi batek soilik aukera ematen du segurtasunarekin zerikusia dutela ulertzea. ). Linusen arabera, Linux banaketetan kernel paketeak mantentzeaz arduratzen diren taldeetako segurtasun-taldeei dagokie adabaki-fluxu orokorretik ahultasun potentzialak isolatzea.
Kees Cook-ek uste du nukleoa epe luzerako arrazoizko kostu batean seguru mantentzeko irtenbide bakarra enpresek adabakiak eramatean parte hartzen duten ingeniariak tokiko nukleoen eraikuntzara eramatea dela, lankidetzan eta koordinatuan lan egiteko, upstream nukleoan adabakiak eta ahuleziak mantentzeko. Gaur egungo forman, fabrikatzaile askok ez dute azken nukleoaren bertsioa erabiltzen beren produktuetan eta backport konponketak beren kabuz, hau da. konturatzen da enpresa ezberdinetako ingeniariek elkarren lana bikoizten dutela, arazo bera konponduz.
Esate baterako, 10 konpainiak, bakoitza ingeniari batek konponketa berdinak babesten dituena, ingeniari horiek birbideratzen badituzte akatsak goran konpontzera, orduan konponketa bat eraman beharrean, 10 akats ezberdin konpondu ditzakete onerako edo proposatutako aldaketen berrikuspenarekin bat egin dezakete. saihestu akatsen kodea nukleoan sartzea. Baliabideak probak egiteko eta kodea aztertzeko tresna berriak sortzeko ere bideratu litezke, hasiera batean behin eta berriro agertzen diren errore-klase tipikoak automatikoki identifikatu ahal izateko.
Kees Cook-ek, halaber, proba automatizatuen eta fuzz-en erabilera aktiboagoa iradokitzen du oinarrizko garapen-prozesuan, etengabeko integrazio-sistemak erabiltzea eta posta elektroniko bidez garapen arkaikoaren kudeaketa baztertzea. Gaur egun, proba eraginkorrak oztopatzen ditu probaren prozesu nagusiak garapenetik bereizten direlako eta kaleratzeen eraketa ondoren gertatzen direlako. Keys-ek hizkuntza seguruagoak erabiltzea gomendatzen du, adibidez, Rust, akatsak murrizteko.
Iturria: opennet.ru