Google'i Kees Cook kutsub üles moderniseerima Linuxi tuuma vigade väljatöötamise protsessi

Kees Cook, endine peamine süsteemiadministraator kernel.org ja Ubuntu Security Team'i juht, kes praegu töötab Google'is Androidi ja ChromeOS-i kaitsmise nimel, väljendas muret praeguse veaparandamise protsessi üle stabiilsetes tuumaversioonides. Iga nädal lisatakse stabiilsetesse harudesse umbes sada parandust, ja pärast muudatusakna sulgemist läheneb järgmise väljaande jaoks nende arv tuhandeni (toimetajad hoiavad parandusi kinni akna sulgemiseni ja pärast „-rc1“ väljalaske loomist avaldavad need korrapäraselt), mis on liiga palju ja nõuab suurte tööjõuressursside kasutamist Linuxi tuumapõhiste toodete hooldamiseks.

Kees usub, et tuuma veade lahendamise protsessile ei pöörata piisavat tähelepanu ning tuumast puuduvad vähemalt 100 täiendavat arendajat koordineeritud tööks selles valdkonnas. Peamised tuumaarendajad lahendavad pidevalt vigu, kuid pole mingeid garantiisid, et need parandused kantakse üle kolmandate osapoolte kasutatavatesse tuumaversioonidesse. Erinevate Linuxi tuumapõhiste toodete kasutajatel pole ka võimalik jälgida, millised vead on parandatud ja millist tuuma nende seadmetes kasutatakse. Lõppkokkuvõttes vastutavad omad toodete turvalisuse eest tootjad, kuid väga intensiivsete veaparanduste avaldamise tingimustes stabiilsetes tuumaversioonides seisavad nad silmitsi valikuga – kas kanda edasi kõik parandused, valida välja kõige olulisemad või ignoreerida kõiki parandusi.

Parim lahendus oleks ümber kanda vaid kõige olulisemad parendused ja haavatavused, kuid nende vigade eristamise peamine probleem seisnebki. Suur hulk esilekerkivaid probleeme tuleneb C keele kasutamisest, mis nõuab mäluhalduse ja näidikute osas suurt täpsust. Olukorda süvendab see, et paljusid potentsiaalseid haavatavuste parandusi ei varustata CVE id-dega või saavad sellise id-i alles mõni aeg pärast paranduste avaldamist. Sellega tingitud olukorras on tootjatel väga keeruline eristada teisejärgulisi parandusi olulistest, mis mõjutavad turvalisust. Statistika kohaselt kõrvaldatakse enam kui 40% haavatavustest enne CVE määramist, ja keskmine viivitus paranduse väljalaskmise ja CVE määramise vahel on kolm kuud (st alguses tuntakse parandust tavalisena, kuid alles mõne kuu pärast selgub, et tegemist oli haavatavuse kõrvaldamisega).

Lõpuks, ilma eraldi haruta haavatavuste parandustega ja saamata teavet, mis seob konkreetse probleemi turvalisusega, peavad Linuxi tuumapõhiste toodete tootjad pidevalt kandma üle kõik parendused uusimmatesse stabiilsetesse hargnendesse. Kuid see töö nõuab suurt teadmiste ja tööjõu mahtu ning ettevõtetes tõrjutakse sageli sellistele tegevustele, kartes regressiivsete muudatuste tekkimist, mis võivad toote tavapärast toimimist häirida.

Tuletame meelde, et Linus Torvalds leiab, et kõik vead on olulised ja haavatavusi ei tohiks eristada teistest vigade liikidest ega tõsta neid eraldi kõrgema prioriteediga kategooriasse. Sellist nägemust selgitab see, et tavalisele arendajale, kes ei spetsialiseeru turvalisuse küsimustele, ei ole parandus ja potentsiaalne haavatavus alati ilmne (paljude paranduste puhul on ainult eraldi auditi teostamine see, mis võimaldab mõista, et need on seotud turvalisusega). Linuse arvates peaksid potentsiaalsete haavatavuste eristamisega hõivatud rühmad olema turbespetsialistid, kes vastutavad Linuxi jaotustes tuuma paketihalduse eest.

Kees Cook usub, et ainus lahendus tuumiku turvalisuse säilitamiseks mõistlike pikaajaliste kuludega on ettevõtete inseneride üleviimine tuumiku paranduste lokaliseerimise koordineeritud koostöösse, et hallata parandusi ja haavatavusi peamises tuumikus (upstream). Praeguses olukorras kasutavad paljud tootjad oma toodetes mitte kõige uuemaid tuumiku versioone ja kohandavad parandusi omal käel, mistõttu insenerid erinevates ettevõtetes dubleerivad oma tööd, lahendades sama probleemi.

Näiteks kui 10 ettevõtet, kus igas on üks insener, tegelevad sama paranduse tagasiviimisega, suunata need insenerid upstream viga kõrvaldamisse, siis nad saaksid ühe paranduse asemel lahendada 10 erinevat viga üldiseks hüvanguks, või liituda ettepanekute ülevaatamisega ja vältida vigase koodi kaasamist tuumikusse. Ressursse saaks suunata ka uute testimis- ja koodi analüüsi tööriistade loomisele, mis võimaldaksid varases etapis automaatselt tuvastada korduvaid vigu.

Kees Cook soovitab ka aktiivsemalt kasutada automatiseeritud ja fuzzing-testimist tuumiku arendamise protsessis, rakendada pideva integreerimise süsteeme ja loobuda arhailisest arenduse haldamisest e-posti teel. Praegusel hetkel häirib efektiivset testimist see, et peamised testimisprotsessid on eraldatud arendamisest ja toimuvad alles pärast versioonide loomist. Kees soovitas ka vigade arvu vähendamiseks kasutada arenduses keeli, mis tagavad rohkem kõrge turvalisuse tase, nagu Rust.

Allikas: opennet.ru