Google-ko Kees Cook-ek Linux nukleoko akatsak lantzeko prozesua modernizatzeko eskatu zuen

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.

Kees-en arabera, kernel-akatsekin lan egiteko prozesuari ez zaio merezi duen arreta ematen eta kernelak gutxienez 100 garatzaile gehiago behar ditu arlo honetan modu koordinatuan lan egiteko. Nukleoaren garatzaileek aldian-aldian akatsak konpontzen dituzte, baina ez dago bermerik konponketa hauek hirugarrenen saltzaileek erabiltzen dituzten nukleoaren aldaeretara atzera eramango direnik. Linux nukleoan oinarritutako hainbat produkturen erabiltzaileek ere ez dute kontrolatzeko modurik zer akats konpondu diren eta zer nukleo erabiltzen den euren gailuetan. Azken finean, saltzaileak dira beren produktuen segurtasunaren erantzule, baina kernel-adar egonkorretan argitaratzen diren hainbeste adabaki, aukera baten aurrean daude: adabaki guztiak atzera eraman, garrantzitsuenak modu selektiboan atzera eraman edo adabaki guztiak alde batera utzi.

Irtenbide optimoa konponketa eta ahultasun garrantzitsuenak soilik migratzea litzateke, baina arazo nagusia akats horiek fluxu orokorretik isolatzea da. Sortzen diren arazo-kopuru handiena C lengoaia erabiltzearen ondorio da, eta horrek arreta handia eskatzen du memoria eta erakusleekin lan egitean. Hori gutxi balitz, ahultasun-konponketa potentzial askori ez zaie CVE identifikatzailerik esleitzen edo konponketa argitaratu eta denbora batera esleitzen zaie. Baldintza horietan, oso zaila da fabrikatzaileek segurtasunari eragiten dioten arazo garrantzitsuetatik konponketa txikiak bereiztea. Estatistiken arabera, ahultasunen % 40 baino gehiago konpontzen dira CVE bat esleitu baino lehen, eta, batez beste, adabaki bat askatu eta CVE bat esleitzen den arteko atzerapena hiru hilabetekoa da (hau da, hasieran adabakia ohiko akats gisa hautematen da, baina zenbait hilabeteren buruan argi geratzen da ahultasuna ezabatu dela).

Ondorioz, ahultasun-konponketak dituen adar bereizirik gabe eta arazo jakin baten segurtasun-konexioari buruzko informaziorik jaso gabe, Linux nukleoan oinarritutako produktuen fabrikatzaileek azken adar egonkorretatik konponketa guztiak etengabe migratu behar dituzte. Baina lan honek lan handia eskatzen du eta erresistentzia aurkitzen du enpresetan, produktuaren funtzionamendu normala oztopatu dezaketen aldaketa atzerakoien beldurragatik.

Gogora dezagun, Linus Torvaldsen arabera, akats guztiak garrantzitsuak direla eta ahultasunak ez direla beste akats mota batzuetatik bereizi behar eta lehentasunezko kategoria bereizi batean jarri behar. Iritzi hau segurtasun gaietan espezializatua ez den garatzaile arrunt batentzat konponketa eta ahultasun potentzial baten arteko lotura ez dela begi bistakoa da (konponketa askotan, auditoretza bereizi batek bakarrik ulertzea ahalbidetzen du segurtasunarekin zerikusia dutela). Linusek uste du adabakien fluxu orokorretik ahultasun potentzialak identifikatzeko gaia Linux banaketetan kernel-paketeak mantentzeaz arduratzen diren taldeetako segurtasun-espezialistek kudeatu beharko luketela.

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 backportatzen dituena, ingeniari horiek berriro esleitzen badituzte akatsak konpontzera igotzeko, orduan konponketa bat atzera eraman beharrean, 10 akats ezberdin konpondu ditzakete onerako, edo proposatutako aldaketak berrikusten eta akatsen kodea nukleoan sartzea ekiditeko. Baliabideak proba eta kodea aztertzeko tresna berriak sortzera bideratu daitezke, behin eta berriro agertzen diren errore-klase tipikoak automatikoki detektatzeko aukera emango dutenak.

Keith Cook-ek ere iradokitzen du proba automatizatuak eta fuzz probak aktiboago erabiltzea kernelen garapenean zehar, integrazio sistema jarraituak erabiltzea eta posta elektroniko bidezko garapen kudeaketa arkaikoa alde batera uztea. Gaur egun, probak eraginkorrak izatea oztopatzen du proba-prozesu nagusiak garapenetik bereizita daudelako eta bertsioen ondoren gertatzen direlako. Keith-ek ere gomendatu zuen garapenean zehar laguntza sendoagoa eskaintzen duten hizkuntzak erabiltzea errore kopurua murrizteko. segurtasun maila altua, hala nola, Herdoila.

Iturria: opennet.ru