Kees Cook, tilas administrator sistem lulugu kernel.org sareng pamimpin Tim Kaamanan Ubuntu anu ayeuna damel di Google pikeun ngamankeun Android sareng ChromeOS, nyatakeun prihatin ngeunaan prosés ngalereskeun bug dina cabang kernel anu stabil. Unggal minggu, sakitar saratus perbaikan kalebet dina cabang anu stabil, sareng saatos jandela pikeun nampi parobihan dina sékrési salajengna ditutup, éta ngadeukeutan sarébu (para pangropéa nahan perbaikan dugi ka jandela ditutup, sareng saatos formasi " -rc1" aranjeunna nyebarkeun akumulasi sakaligus), anu seueur teuing sareng peryogi seueur tenaga kerja pikeun produk pangropéa dumasar kana kernel Linux.
Numutkeun kana Keys, prosés damel sareng kasalahan dina kernel henteu dipasihan perhatian sareng kernel kurangna sahenteuna 100 pamekar tambahan pikeun padamelan anu ngagabung di daérah ieu. Pamekar kernel utama rutin ngalereskeun bug, tapi teu aya jaminan yén perbaikan ieu bakal dibawa ka varian kernel dipaké ku pihak katilu. Pamaké rupa-rupa produk dumasar kana kernel Linux ogé teu boga cara pikeun ngadalikeun bug mana anu dibereskeun jeung kernel mana anu dipaké dina alat maranéhanana. Pamustunganana, produsén tanggung jawab pikeun kaamanan produkna, tapi kalayan inténsitas penerbitan anu luhur pisan dina dahan kernel anu stabil, aranjeunna disanghareupan pilihan - port sadaya perbaikan, selektif port anu paling penting, atanapi teu malire sadaya perbaikan. .
Solusi anu optimal nyaéta ngan ukur migrasi perbaikan sareng kerentanan anu paling penting, tapi ngasingkeun kasalahan sapertos tina aliran umum mangrupikeun masalah utama. Jumlah pangbadagna masalah anu pop up mangrupakeun konsekuensi tina ngagunakeun basa C, nu merlukeun perawatan hébat nalika gawé bareng memori sareng pointers. Anu langkung parah, seueur patch kerentanan poténsial henteu disayogikeun ku identifier CVE, atanapi ditugaskeun identifier CVE sababaraha waktos saatos patch diterbitkeun. Dina lingkungan sapertos kitu, sesah pisan pikeun produsén pikeun misahkeun perbaikan minor tina masalah kaamanan anu penting. Numutkeun statistik, langkung ti 40% kerentanan dibereskeun sateuacan CVE ditugaskeun, sareng rata-rata telat antara sékrési perbaikan sareng penugasan CVE nyaéta tilu bulan (nyaéta, mimitina perbaikan dianggap salaku bug biasa, tapi ngan saatos sababaraha bulan janten jelas yén kerentanan parantos dibenerkeun).
Hasilna, tanpa cabang anu misah sareng perbaikan pikeun kerentanan sareng tanpa nampi inpormasi ngeunaan sambungan kaamanan tina masalah anu khusus, produsén produk dumasar kana kernel Linux ditinggalkeun pikeun terus-terusan nransferkeun sadaya perbaikan tina cabang stabil panganyarna. Tapi karya ieu merlukeun loba kuli sarta nyanghareupan lalawanan di pausahaan alatan sieun mecenghulna parobahan regressive nu bisa ngaganggu operasi normal produk.
Hayu urang émut yén nurutkeun Linus Torvalds, sadaya kasalahan penting sareng kerentanan henteu kedah dipisahkeun tina jinis kasalahan anu sanés sareng dialokasikeun kana kategori prioritas anu langkung luhur. Pendapat ieu dijelaskeun ku kanyataan yén pikeun pamekar biasa anu henteu ngahususkeun dina masalah kaamanan, sambungan antara perbaikan sareng kerentanan poténsial henteu écés (pikeun seueur perbaikan, ngan ukur pamariksaan anu misah anu ngamungkinkeun anjeun ngartos yén aranjeunna prihatin ngeunaan kaamanan. ). Numutkeun Linus, spesialis kaamanan ti tim anu tanggung jawab pikeun ngajaga bungkusan kernel dina distribusi Linux kedah kalibet dina ngaidentipikasi kerentanan poténsial tina aliran umum patch.
Kees Cook percaya yén hiji-hijina solusi pikeun ngajaga kaamanan kernel dina biaya jangka panjang anu lumrah nyaéta pikeun pausahaan pikeun mindahkeun insinyur anu kalibet dina porting perbaikan ka kernel lokal ngawangun kana usaha gabungan, koordinasi pikeun ngajaga perbaikan sarta kerentanan dina kernel utama (hulu). ). Dina bentuk ayeuna, seueur pabrik anu henteu nganggo versi kernel panganyarna dina produkna sareng ngadukung perbaikan di-imah, nyaéta. Tétéla yén insinyur di pausahaan béda duplikat karya silih, ngarengsekeun masalah anu sarua.
Salaku conto, upami 10 perusahaan, masing-masing sareng hiji insinyur ngadukung perbaikan anu sami, napelkeun deui insinyur éta pikeun ngalereskeun bug di hulu, teras tinimbang ngadukung hiji perbaikan, aranjeunna tiasa ngalereskeun 10 bug anu béda pikeun kapentingan umum atanapi gabung dina ulasan ngeunaan usulan. parobahan sarta nyegah kode Buggy tina kaasup kana kernel. Sumberdaya ogé tiasa dikhususkeun pikeun nyiptakeun alat énggal pikeun nguji sareng nganalisa kode anu ngamungkinkeun deteksi awal kasalahan umum anu sering muncul deui.
Kees Cook ogé nyarankeun leuwih aktip ngagunakeun nguji otomatis tur fuzzing langsung dina prosés ngembangkeun kernel, ngagunakeun sistem integrasi kontinyu sarta abandoning manajemén ngembangkeun kolot via email. Ayeuna, tés anu épéktip dihambat ku kanyataan yén prosés tés utama dipisahkeun tina pamekaran sareng lumangsung saatos sékrési kabentuk. Tombol ogé nyarankeun ngagunakeun basa anu nyayogikeun tingkat kaamanan anu langkung luhur, sapertos Rust, nalika ngembangkeun pikeun ngirangan jumlah kasalahan.
sumber: opennet.ru