Kees Cook, mantan administrator sistem kernel.org lan pimpinan Tim Keamanan Ubuntu sing saiki kerja ing Google kanggo ngamanake Android lan ChromeOS, nyatakake keprihatinan babagan proses ndandani bug ing cabang kernel sing stabil. Saben minggu, kira-kira satus koreksi kalebu ing cabang sing stabil, lan sawise jendhela kanggo nrima owah-owahan ing rilis sabanjure ditutup, nyedhaki sewu (pemelihara terus ndandani nganti jendhela ditutup, lan sawise pambentukan " -rc1 "padha nerbitake akumulasi bebarengan), sing akeh banget lan mbutuhake tenaga kerja kanggo produk pangopènan adhedhasar kernel Linux.
Miturut Keys, proses nggarap kesalahan ing kernel ora digatekake lan kernel kurang paling ora 100 pangembang tambahan kanggo kerja terkoordinasi ing wilayah iki. Pangembang kernel utama ajeg ndandani kewan omo, nanging ora ana jaminan manawa perbaikan kasebut bakal digawa menyang varian kernel sing digunakake dening pihak katelu. Pangguna saka macem-macem produk adhedhasar kernel Linux uga ora duwe cara kanggo ngontrol kewan omo sing didandani lan kernel sing digunakake ing piranti kasebut. Pungkasane, produsen tanggung jawab kanggo keamanan produke, nanging kanthi intensitas penerbitan sing dhuwur banget ing cabang kernel sing stabil, dheweke ngadhepi pilihan - port kabeh koreksi, milih port sing paling penting, utawa ora nglirwakake kabeh perbaikan. .
Solusi sing paling optimal yaiku migrasi mung perbaikan lan kerentanan sing paling penting, nanging ngisolasi kesalahan kasebut saka aliran umum minangka masalah utama. Jumlah paling gedhe saka masalah sing muncul minangka akibat saka nggunakake basa C, kang mbutuhake care banget nalika nggarap memori lan penunjuk. Sing luwih elek, akeh patch kerentanan sing ora kasedhiya karo pengenal CVE, utawa diwenehi pengenal CVE sawetara wektu sawise patch kasebut diterbitake. Ing lingkungan kaya mengkono, iku angel banget kanggo manufaktur kanggo misahake mbecike cilik saka masalah keamanan penting. Miturut statistik, luwih saka 40% kerentanan didandani sadurunge CVE ditugasake, lan rata-rata wektu tundha antarane rilis fix lan penugasan CVE yaiku telung sasi (yaiku, ing wiwitan, perbaikan kasebut dianggep minangka bug biasa, nanging mung sawise sawetara sasi dadi cetha yen kerentanan wis didandani).
AkibatΓ©, tanpa cabang kapisah kanthi ndandani kerentanan lan tanpa nampa informasi babagan sambungan keamanan masalah tartamtu, pabrikan produk adhedhasar kernel Linux ditinggalake kanggo terus-terusan nransfer kabeh perbaikan saka cabang stabil paling anyar. Nanging karya iki mbutuhake tenaga kerja sing akeh lan ngadhepi resistensi ing perusahaan amarga wedi karo owah-owahan regresif sing bisa ngganggu operasi normal produk kasebut.
Elinga yen miturut Linus Torvalds, kabeh kesalahan penting lan kerentanan ora kudu dipisahake saka jinis kesalahan liyane lan dialokasikan menyang kategori prioritas sing luwih dhuwur. Panemu iki diterangake kanthi kasunyatan manawa kanggo pangembang biasa sing ora duwe spesialisasi ing masalah keamanan, sambungan antarane fix lan kerentanan potensial ora jelas (kanggo akeh perbaikan, mung audit sing kapisah sing bisa dingerteni manawa ana masalah keamanan. ). Miturut Linus, spesialis keamanan saka tim sing tanggung jawab kanggo njaga paket kernel ing distribusi Linux kudu melu ngenali kerentanan potensial saka aliran patch umum.
Kees Cook percaya yen siji-sijine solusi kanggo njaga keamanan kernel kanthi biaya jangka panjang sing cukup yaiku kanggo perusahaan mindhah para insinyur sing melu porting koreksi kanggo mbangun kernel lokal dadi upaya gabungan lan terkoordinasi kanggo njaga perbaikan lan kerentanan ing kernel utama (upstream). ). Ing wangun saiki, akeh manufaktur ora nggunakake versi kernel paling anyar ing produk lan backport mbecike ing-house, i.e. Pranyata insinyur ing perusahaan beda duplikat karya saben liyane, ngrampungake masalah sing padha.
Contone, yen 10 perusahaan, saben karo insinyur siji backporting mbenakake padha, reassigned sing engineers kanggo ndandani kewan omo ing hulu, banjur tinimbang backporting siji fix, padha bisa ndandani 10 kewan omo beda kanggo entuk manfaat umum utawa gabung ing review ngajokaken. owah-owahan lan nyegah kode buggy saka kalebu ing kernel. Sumber daya uga bisa dikhususake kanggo nggawe alat anyar kanggo nguji lan nganalisa kode sing bakal ngidini deteksi awal saka kesalahan umum sing muncul maneh lan maneh.
Kees Cook uga nyaranake luwih aktif nggunakake tes otomatis lan fuzzing langsung ing proses pangembangan kernel, nggunakake sistem integrasi terus-terusan lan ninggalake manajemen pangembangan kuna liwat email. Saiki, tes efektif diganggu amarga proses tes utama dipisahake saka pangembangan lan kedadeyan sawise rilis dibentuk. Tombol uga dianjurake nggunakake basa sing nyedhiyakake tingkat keamanan sing luwih dhuwur, kayata Rust, nalika ngembangake kanggo nyuda jumlah kesalahan.
Source: opennet.ru