{"id":100924,"date":"2021-08-05T22:22:35","date_gmt":"2021-08-05T20:22:36","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/kis-kuk-iz-google-prizval-modernizirovat-proczess-raboty-nad-oshibkami-v-yadre-linux"},"modified":"2026-02-08T16:56:03","modified_gmt":"2026-02-08T14:56:03","slug":"kis-kuk-iz-google-prizval-modernizirovat-proczess-raboty-nad-oshibkami-v-yadre-linux","status":"publish","type":"post","link":"https:\/\/prohoster.info\/et\/blog\/news\/kis-kuk-iz-google-prizval-modernizirovat-proczess-raboty-nad-oshibkami-v-yadre-linux","title":{"rendered":"Google'i Kees Cook kutsub \u00fcles moderniseerima Linuxi tuuma vigade v\u00e4ljat\u00f6\u00f6tamise protsessi","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Kees Cook, endine peamine s\u00fcsteemihaldur kernel.org ja Ubuntu turvameeskonna juht, kes praegu t\u00f6\u00f6tab Google'is Androidi ja ChromeOSi turvamise kallal, v\u00e4ljendas muret praeguse vigade parandamise protsessi \u00fcle stabiilsetes kerneli harudes. Iga n\u00e4dal lisatakse stabiilsetesse harudesse umbes sada parandust, ja p\u00e4rast muutuste vastuv\u00f5tmisakna sulgemist l\u00e4heneb j\u00e4rgmise v\u00e4ljaande jaoks see arv tuhandetele (arendajad hoiduvad paranduste avaldamisest kuni akna sulgemiseni ja p\u00e4rast -rc1 v\u00e4ljalaske koostatakse need k\u00f5ik kokku), mis on liiga palju ja n\u00f5uab suurenenud t\u00f6\u00f6mahtu Linuxi kerneli p\u00f5hjal p\u00f5hinevate toodete hooldamiseks.<\/p>\n
Keesi arvates ei p\u00f6\u00f6rata kerneli vigade k\u00e4sitlemise protsessile piisavalt t\u00e4helepanu ning kernelist puuduvad v\u00e4hemalt 100 t\u00e4iendavat arendajat, et selles valdkonnas koordineeritult t\u00f6\u00f6tada. Kerneli p\u00f5hiarendajad parandavad pidevalt vigu, kuid pole mingit muid garantiisid, et need parandused kantakse \u00fcle kolmandate osapoolte tootjate kasutatavatesse kerneli versioonidesse. Erinevate Linuxi algkoodiga toodete kasutajatel pole samuti v\u00f5imalik j\u00e4lgida, milliseid vigu on parandatud ja millist kerneli nende seadmed kasutavad. L\u00f5ppkokkuv\u00f5ttes vastutavad oma toodete turvalisuse eest tootjad, kuid suure intensiivsusega paranduste avaldamise tingimustes stabiilsetes kerneli harudes on nad sattunud olukorda, kus peavad valima - kas kanda \u00fcle k\u00f5ik parandused, valida v\u00e4lja k\u00f5ige olulisemad v\u00f5i ignoreerida k\u00f5iki parandusi.<\/p>\n
<\/center>Parim lahendus oleks \u00fcmber kanda vaid k\u00f5ige olulisemad parendused ja haavatavused, kuid nende vigade eristamise peamine probleem seisnebki. Suur hulk esilekerkivaid probleeme tuleneb C keele kasutamisest, mis n\u00f5uab m\u00e4luhalduse ja n\u00e4idikute osas suurt t\u00e4psust. Olukorda s\u00fcvendab see, et paljusid potentsiaalseid haavatavuste parandusi ei varustata CVE id-dega v\u00f5i saavad sellise id-i alles m\u00f5ni aeg p\u00e4rast paranduste avaldamist. Sellega tingitud olukorras on tootjatel v\u00e4ga keeruline eristada teisej\u00e4rgulisi parandusi olulistest, mis m\u00f5jutavad turvalisust. Statistika kohaselt k\u00f5rvaldatakse enam kui 40% haavatavustest enne CVE m\u00e4\u00e4ramist, ja keskmine viivitus paranduse v\u00e4ljalaskmise ja CVE m\u00e4\u00e4ramise vahel on kolm kuud (st alguses tuntakse parandust tavalisena, kuid alles m\u00f5ne kuu p\u00e4rast selgub, et tegemist oli haavatavuse k\u00f5rvaldamisega).<\/p>\n
L\u00f5puks, ilma eraldi haruta haavatavuste parandustega ja saamata teavet, mis seob konkreetse probleemi turvalisusega, peavad Linuxi tuumap\u00f5histe toodete tootjad pidevalt kandma \u00fcle k\u00f5ik parendused uusimmatesse stabiilsetesse hargnendesse. Kuid see t\u00f6\u00f6 n\u00f5uab suurt teadmiste ja t\u00f6\u00f6j\u00f5u mahtu ning ettev\u00f5tetes t\u00f5rjutakse sageli sellistele tegevustele, kartes regressiivsete muudatuste tekkimist, mis v\u00f5ivad toote tavap\u00e4rast toimimist h\u00e4irida.<\/p>\n
Tuletame meelde, et Linus Torvalds leiab, et k\u00f5ik vead on olulised ja haavatavusi ei tohiks eristada teistest vigade liikidest ega t\u00f5sta neid eraldi k\u00f5rgema prioriteediga kategooriasse. Sellist n\u00e4gemust selgitab see, et tavalisele arendajale, kes ei spetsialiseeru turvalisuse k\u00fcsimustele, ei ole parandus ja potentsiaalne haavatavus alati ilmne (paljude paranduste puhul on ainult eraldi auditi teostamine see, mis v\u00f5imaldab m\u00f5ista, et need on seotud turvalisusega). Linuse arvates peaksid potentsiaalsete haavatavuste eristamisega h\u00f5ivatud r\u00fchmad olema turbespetsialistid, kes vastutavad Linuxi jaotustes tuuma paketihalduse eest.<\/p>\n
Kees Cook usub, et ainus lahendus tuumiku turvalisuse s\u00e4ilitamiseks m\u00f5istlike pikaajaliste kuludega on ettev\u00f5tete inseneride \u00fcleviimine tuumiku paranduste lokaliseerimise koordineeritud koost\u00f6\u00f6sse, et hallata parandusi ja haavatavusi peamises tuumikus (upstream). Praeguses olukorras kasutavad paljud tootjad oma toodetes mitte k\u00f5ige uuemaid tuumiku versioone ja kohandavad parandusi omal k\u00e4el, mist\u00f5ttu insenerid erinevates ettev\u00f5tetes dubleerivad oma t\u00f6\u00f6d, lahendades sama probleemi.<\/p>\n
N\u00e4iteks kui 10 ettev\u00f5tet, kus igas on \u00fcks insener, tegelevad sama paranduse tagasiviimisega, suunata need insenerid upstream viga k\u00f5rvaldamisse, siis nad saaksid \u00fche paranduse asemel lahendada 10 erinevat viga \u00fcldiseks h\u00fcvanguks, v\u00f5i liituda ettepanekute \u00fclevaatamisega ja v\u00e4ltida vigase koodi kaasamist tuumikusse. Ressursse saaks suunata ka uute testimis- ja koodi anal\u00fc\u00fcsi t\u00f6\u00f6riistade loomisele, mis v\u00f5imaldaksid varases etapis automaatselt tuvastada korduvaid vigu.<\/p>\n
Kees Cook soovitab ka aktiivsemalt kasutada automatiseeritud ja fuzzing-testimist tuumiku arendamise protsessis, rakendada pideva integreerimise s\u00fcsteeme ja loobuda arhailisest arenduse haldamisest e-posti teel. Praegusel hetkel h\u00e4irib efektiivset testimist see, et peamised testimisprotsessid on eraldatud arendamisest ja toimuvad alles p\u00e4rast versioonide loomist. Kees soovitas ka vigade arvu v\u00e4hendamiseks kasutada arenduses keeli, mis tagavad rohkem k\u00f5rge turvalisuse tase<\/a>, nagu Rust.<\/p>\n
![\"Google'i](\"\/wp-content\/uploads\/2021\/08\/3e472a24f4fd9a6b434c706b3dfe3a35.png\")
<\/center>Parim lahendus oleks \u00fcmber kanda vaid k\u00f5ige olulisemad parendused ja haavatavused, kuid nende vigade eristamise peamine probleem seisnebki. Suur hulk esilekerkivaid probleeme tuleneb C keele kasutamisest, mis n\u00f5uab m\u00e4luhalduse ja n\u00e4idikute osas suurt t\u00e4psust. Olukorda s\u00fcvendab see, et paljusid potentsiaalseid haavatavuste parandusi ei varustata CVE id-dega v\u00f5i saavad sellise id-i alles m\u00f5ni aeg p\u00e4rast paranduste avaldamist. Sellega tingitud olukorras on tootjatel v\u00e4ga keeruline eristada teisej\u00e4rgulisi parandusi olulistest, mis m\u00f5jutavad turvalisust. Statistika kohaselt k\u00f5rvaldatakse enam kui 40% haavatavustest enne CVE m\u00e4\u00e4ramist, ja keskmine viivitus paranduse v\u00e4ljalaskmise ja CVE m\u00e4\u00e4ramise vahel on kolm kuud (st alguses tuntakse parandust tavalisena, kuid alles m\u00f5ne kuu p\u00e4rast selgub, et tegemist oli haavatavuse k\u00f5rvaldamisega).<\/p>\n