Kees Cook, bekas CSO kernel.org dan ketua Pasukan Keselamatan Ubuntu, yang kini bekerja untuk Google untuk melindungi Android dan ChromeOS, menyatakan kebimbangan tentang proses semasa membetulkan pepijat dalam cawangan stabil kernel. Setiap minggu, kira-kira seratus pembaikan dimasukkan ke dalam cawangan yang stabil, dan selepas menutup tetingkap untuk menerima perubahan pada keluaran seterusnya, ia menghampiri seribu (penyelenggara mengadakan pembaikan sehingga tetingkap ditutup, dan selepas pembentukan "-rc1" mereka menerbitkan yang terkumpul sekaligus), yang terlalu banyak dan memerlukan banyak tenaga kerja untuk produk penyelenggaraan berdasarkan kernel Linux.
Menurut Keys, proses bekerja dengan ralat dalam kernel tidak diberi perhatian yang sewajarnya dan kernel tidak mempunyai sekurang-kurangnya 100 pembangun tambahan untuk kerja yang diselaraskan di kawasan ini. Pembangun inti inti membetulkan pepijat secara tetap, tetapi tiada jaminan bahawa pembetulan ini akan dialihkan ke varian kernel yang digunakan oleh pihak ketiga. Pengguna pelbagai produk berdasarkan kernel Linux juga tidak mempunyai cara untuk mengawal pepijat mana yang diperbaiki dan kernel mana yang digunakan dalam peranti mereka. Vendor akhirnya bertanggungjawab ke atas keselamatan produk mereka, tetapi dengan kadar tampalan yang sangat tinggi di cawangan kernel yang stabil, mereka berhadapan dengan pilihan antara membalikkan semua tampalan, mengalihkan yang paling penting secara selektif, atau mengabaikan semua tampalan.
Penyelesaian yang optimum adalah dengan memindahkan hanya pembaikan dan kelemahan yang paling penting, tetapi mengasingkan ralat tersebut daripada aliran umum adalah masalah utama. Kebanyakan masalah yang timbul adalah disebabkan oleh penggunaan bahasa C, yang memerlukan perhatian yang tinggi apabila berurusan dengan ingatan dan penunjuk. Lebih memburukkan keadaan, banyak kemungkinan pembetulan kerentanan tidak disediakan dengan pengecam CVE, atau menerima pengecam sedemikian beberapa lama selepas tampung diterbitkan. Di bawah keadaan sedemikian, amat sukar bagi pengeluar untuk memisahkan pembetulan kecil daripada isu keselamatan utama. Menurut statistik, lebih daripada 40% kerentanan diperbaiki sebelum CVE ditetapkan, dan kelewatan purata antara pelepasan patch dan penugasan CVE ialah tiga bulan (iaitu, pada mulanya, patch itu dianggap sebagai perkara biasa. pepijat, tetapi hanya selepas beberapa bulan ia menjadi jelas bahawa kelemahan telah diperbaiki).
Akibatnya, tanpa mempunyai cawangan berasingan dengan pembetulan untuk kelemahan dan tanpa menerima maklumat tentang sambungan keselamatan masalah tertentu, pengeluar produk berdasarkan kernel Linux dibiarkan untuk terus memindahkan semua pembaikan daripada cawangan stabil yang baru. Tetapi kerja ini memerlukan banyak tenaga kerja dan menghadapi rintangan dalam syarikat kerana takut akan perubahan regresif yang boleh mengganggu operasi normal produk.
Ingat bahawa, menurut Linus Torvalds, semua ralat adalah penting dan kelemahan tidak boleh dipisahkan daripada jenis ralat lain dan diperuntukkan kepada kategori keutamaan yang lebih tinggi yang berasingan. Pendapat ini dijelaskan oleh fakta bahawa bagi pembangun biasa yang tidak pakar dalam isu keselamatan, hubungan antara pembetulan dan potensi kelemahan tidak jelas (untuk banyak pembetulan, hanya audit berasingan membolehkan anda memahami bahawa ia berkaitan dengan keselamatan ). Menurut Linus, terpulang kepada pasukan keselamatan dalam pasukan yang bertanggungjawab untuk mengekalkan pakej kernel pada pengedaran Linux untuk mengasingkan potensi kelemahan daripada aliran patch umum.
Kees Cook percaya bahawa satu-satunya penyelesaian untuk memastikan kernel selamat pada kos jangka panjang yang munasabah adalah untuk syarikat memindahkan jurutera yang terlibat dalam mengalihkan patch ke binaan kernel tempatan untuk bekerja secara kolaboratif dan menyelaras untuk mengekalkan patch dan kelemahan dalam kernel huluan. Dalam bentuk semasanya, banyak pengeluar tidak menggunakan versi kernel terkini dalam produk mereka dan pembetulan backport mereka sendiri, i.e. ternyata jurutera di syarikat yang berbeza menduplikasi kerja masing-masing, menyelesaikan masalah yang sama.
Contohnya, jika 10 syarikat, masing-masing dengan seorang jurutera yang menyokong pembaikan yang sama, mengubah hala jurutera tersebut untuk membetulkan pepijat ke hulu, maka daripada mengalihkan satu pembetulan, mereka boleh membetulkan 10 pepijat berbeza untuk kebaikan bersama atau menyertai semakan perubahan yang dicadangkan. dan menghalang kod buggy daripada dimasukkan ke dalam kernel. Sumber juga boleh ditumpukan untuk mencipta alat baharu untuk ujian dan analisis kod, yang akan membolehkan pada peringkat awal mengenal pasti secara automatik kelas ralat biasa yang muncul berulang kali.
Kees Cook juga mencadangkan penggunaan ujian automatik dan kabur yang lebih aktif secara langsung dalam proses pembangunan teras, penggunaan sistem penyepaduan berterusan dan pengabaian pengurusan pembangunan kuno melalui e-mel. Pada masa ini, ujian yang berkesan dihalang oleh fakta bahawa proses ujian utama dipisahkan daripada pembangunan dan berlaku selepas pembentukan keluaran. Kunci juga mengesyorkan menggunakan bahasa yang lebih selamat, seperti Rust, untuk mengurangkan pepijat.
Sumber: opennet.ru