Google'i Kic Cook kutsus üles moderniseerima Linuxi kernelis veaprotsessi

Kees Cook, endine kernel.org peamine süsteemihaldur ja Ubuntu turvameeskonna juht, kes praegu töötab Google'is Androidi ja ChromeOSi turvalisuse tagamise nimel, väljendas muret tuuma stabiilsete harude vigade parandamise protsessi üle. Igal nädalal lisatakse stabiilsetesse harudesse umbes sada parandust, ja pärast muutuste vastuvõtmise akna sulgemist läheneb järgmise väljaande ettevalmistamisel täiendavate paranduste arv tuhandele (toetavad inimesed hoiduvad paranduste avaldamisest kuni akna sulgemiseni, ja pärast „-rc1” genereerimist avaldatakse kõik kogutud korraga), mis on liiga palju ja nõuab suuri ressursse Linuxi tuumal põhinevate toodete hooldamiseks.

Keesi arvates ei pöörata tuumavigade töötlusprotsessile piisavat tähelepanu ja tuumale on minimaalset 100 lisaarendajat, et seda valdkonda korralikult hallata. Peamised tuumaarendajad parandavad pidevalt tõrkeid, kuid pole guaranteesid, et need parandused viiakse üle kolmandate tootjate kasutatavatesse tuumaversioonidesse. Linuxi tuumal põhinevate toodete kasutajatel puudub samuti võimalus jälgida, millised vead on parandatud ja milline tuum nende seadmetes on kasutusel. Lõppkokkuvõttes vastutavad tootjad oma toodete turvalisuse eest, kuid väga intensiivse paranduste avaldamise korral stabiilsetes tuuma harudes seisavad nad silmitsi valikuga - kanda kõik parandused edasi, valida välja kõige olulisemad või ignoreerida kõiki parandusi.

Optimaalne lahendus oleks kanda edasi vaid kõige olulisemad parandused ja haavatavused, kuid selliste vigade eristamine üldisest voost on peamine probleem. Kõige rohkem esinevaid probleeme põhjustab C-keele kasutamine, mis nõuab mälu ja näidikute käsitlemisel suurt tähelepanu. Probleemi süvendab see, et paljud võimalike haavatavuste parandused ei ole varustatud CVE-identifikaatoritega või saavad sellise identifikaatori alles pärast paranduse avaldamist. Sellistes tingimustes on tootjatel väga keeruline eristada teisejärgulisi parandusi olulistest probleemidest, mis mõjutavad turvalisust. Statistika kohaselt kõrvaldatakse rohkem kui 40% haavatavustest enne CVE määramist, ja keskmine viivitus paranduse avaldamise ja CVE määramise vahel on kolm kuud (ehkki alguses tajutakse parandust tavalise veana, selgub alles paar kuud hiljem, et on toimunud haavatavuse kõrvaldamine).

Lõppkokkuvõttes, puudumisel eraldi harudest haavatavuste paranduste jaoks ja teabe puudumisel konkreetse probleemiga seotud turvalisusest, peavad Linuxi tuumal põhinevate toodete tootjad pidevalt kandma kõik parandused värsketesse stabiilsetesse harudesse. Kuid see töö nõuab suuremaid ressursse ja ettevõtetes koheldakse seda vastupanu tõttu hirmu regresseerivate muudatuste tekkimise ees, mis võivad kahjustada toote normaalset toimimist.

Tuletame meelde, et Linus Torvalds arvab, et kõik vead on olulised ja haavatavusi ei tohiks eraldada teistest vigadest ning seada neid kõrgema prioriteediga kategooriasse. Seda seisukohta põhjendatakse sellega, et tavaliseks arendajaks, kes ei spetsialiseeru turvalisuse küsimustele, ei ole ilmselge seos paranduse ja võimaliku haavatavusega (paljude paranduste puhul aitab eraldi auditi läbiviimine mõista, et need on seotud turvalisusega). Linuse arvates peaksid potentsiaalsete haavatavuste eristamisega tegelema turvaspetsialistid, kes kuuluvad nende rühmade koosseisu, kes vastutavad Linuxi distributsioonide tuuma pakettide hoidmise eest.

Kees Cook usub, et ainus lahendus tuuma turvalisuse säilitamiseks mõistlike pikaajaliste kuludega on ettevõtete inseneride suunamine, kes tegelevad paranduste portleerimisega kohandatud tuumakogude, et töötada koos koordineeritud viisil põhisisu (upstream) hooldamise. Praeguses olukorras kasutavad paljud tootjad oma toodetes mitte kõige uuemaid tuumaversioone ja bckportivad parandused ise, mille tulemusena dubleerivad erinevate ettevõtete insenerid üksteise tööd, lahendades sama probleemi.

Näiteks kui 10 ettevõtet, kus igas ettevõttes tegeleb üks insener samade paranduste tagasiviimisega, suunaks need insenerid vigu parandama upstream, siis oleks nad võinud ühe paranduse portimise asemel parandada 10 erinevat viga ühise hüvena või liituda pakutud muudatuste ülevaatamisega, et vältida vigase koodi kaasamist tuuma. Ressursse oleks samuti saanud suunata uute testimise ja koodi analüüsi tööriistade loomisse, mis võimaldaksid automaatselt avastada tüüpilisi vigu varases etapis, mis jälle ja jälle pinnale tulevad.

Kees Cook kutsub üles kasutama automatiseeritud ja fuzzing-teste aktiivsemalt tuuma arendamise protsessi, rakendama pideva integreerimise süsteeme ning loobuma vananenud arenduse juhtimisest e-posti teel. Praegu takistab tõhusat testimist see, et peamised testimisprotsessid on eraldatud arendamisest ja toimuvad alles pärast versioonide loomist. Kees soovitas samuti veakoguse vähendamiseks arendamisel kasutada keeli, mis tagavad rohkem kõrget turvataset, nagu Rust.

Allikas: opennet.ru