Dalam sebuah kertas putih baru, Kernel Vendor, Bug, dan Stabilitas, perusahaan perangkat lunak infrastruktur dan Rocky Linux CIQ menyajikan argumen yang meyakinkan bahwa kernel vendor Linux terganggu oleh kerentanan keamanan karena proses rekayasa yang cacat yang membackport perbaikan. Ini bisa mengejutkan beberapa orang, tetapi ini adalah rahasia terbuka di komunitas Linux. Seperti yang baru-baru ini dikatakan oleh Greg Kroah-Hartman, pengelola kernel stabil Linux dan anggota penting tim keamanan kernel, untuk menjadi aman, Anda harus selalu menggunakan kernel stabil jangka panjang terbaru. Kata kuncinya di sini adalah “terbaru”. Tidak cukup hanya menggunakan LTS. Anda harus menggunakan rilis terbaru untuk menjadi seaman mungkin. Namun demikian, hampir tidak ada yang melakukannya. Meskipun demikian, seperti yang dijelaskan oleh insinyur kernel Linux Google Kees Cook, “Jadi apa yang harus dilakukan oleh vendor? Jawabannya sederhana: terus memperbarui ke rilis kernel terbaru, baik mayor atau stabil.” Mengapa? Seperti yang dijelaskan oleh Kroah-Hartman, “Setiap bug berpotensi menjadi masalah keamanan di level kernel.” Jonathan Corbet, pengembang kernel Linux dan editor-in-chief LWN, setuju: “Di kernel, hampir setiap bug, jika Anda cukup cerdas, dapat dieksploitasi untuk mengompromikan sistem. Kernel berada di posisi unik dalam sistem… itu mengubah banyak bug biasa menjadi kerentanan.” Apa yang dilakukan insinyur CIQ Ronnie Sahlberg, Jonathan Maple, dan Jeremy Allison adalah memberikan angka-angka keras di balik posisi ini. Paper mereka menunjukkan bahwa – dengan praktik rekayasa saat ini – hampir semua kernel vendor secara inheren tidak aman dan mengamankan kernel itu tidak mungkin. Itu karena kernel vendor Linux dibuat dengan mengambil snapshot dari rilis Linux tertentu dan kemudian membackport perbaikan yang dipilih saat perubahan terjadi di pohon git hulu. Metode ini, dirancang pada era di mana driver perangkat out-of-tree menjadi umum, bertujuan untuk meningkatkan stabilitas dan keamanan dengan memilih perubahan untuk dibackport. Makalah ini mengeksplorasi bagaimana cara kerja metode ini dalam praktek dengan menganalisis tingkat perubahan dan jumlah bug di Red Hat Enterprise Linux (RHEL) 8.8, versi kernel 4.18.0-477.27.1, membandingkannya dengan kernel upstream dari kernel.org. Meskipun para programer menguji secara khusus RHEL 8.8, ini adalah masalah umum. Mereka akan menemukan hasil yang sama jika mereka menguji SUSE, Ubuntu, atau Debian Linux. Distro Linux berbasis rolling-release seperti Arch, Gentoo, dan OpenSUSE Tumbleweed terus merilis pembaruan terbaru, tetapi tidak digunakan dalam bisnis. Analisis mereka terhadap kernel RHEL 8.8 mengungkapkan 111.750 komit individu dalam log perubahan. Data ini, meskipun tidak mendetailkan konten atau ukuran komit, memberikan pemahaman umum tentang proses backporting. Awalnya, ada tingkat backporting yang stabil, tetapi penurunan ini terjadi sekitar November 2021 dan kemudian signifikan lagi pada November 2022, sesuai dengan rilis RHEL 8.5 dan RHEL 8.7, masing-masing. Pola ini, menurut para penulis, mencerminkan pergeseran menuju backporting yang lebih konservatif untuk meningkatkan stabilitas saat siklus rilis utama berlangsung. Pemeriksaan mereka menemukan 5.034 bug yang belum diperbaiki di RHEL 8.6; 4.767 bug yang belum diperbaiki di RHEL 8.7; dan 4.594 bug yang belum diperbaiki di RHEL 8.8. Angka-angka ini mewakili bug yang diketahui dengan perbaikan upstream yang belum dibackport ke RHEL. Penghentian backporting lebih awal dalam RHEL 8.6 dan 8.7 telah menyebabkan lebih banyak bug yang belum diperbaiki dibandingkan dengan RHEL 8.8. Praktik Red Hat yang tidak menerbitkan perubahan kode sumber lengkap menambah kompleksitas, menghasilkan kemungkinan positif dan negatif palsu dalam data yang harus dikerjakan oleh CIQ. Meskipun ada batasan ini, CIQ melaporkan bahwa pemeriksaan manual menunjukkan akurasi tinggi dalam mengidentifikasi perbaikan yang hilang. Berbeda dengan asumsi bahwa bug segera diperbaiki upstream, banyak bug tetap ada untuk periode yang lama sebelum penyelesaian. Keterlambatan ini memengaruhi kualitas kernel, karena proses backporting yang melambat menghasilkan peningkatan jumlah bug yang diketahui, belum diperbaiki, yang merusak stabilitas dan keamanan kernel dari waktu ke waktu. Karena pengembang kernel Linux telah mengambil alih pengelolaan Common Vulnerabilities dan Exposures (CVE) Linux, 270 CVE baru pada Maret 2024 dan 342 pada April 2024 telah dilaporkan. CVE tersebut sudah diperbaiki di cabang git kernel Linux yang stabil. Namun, jumlahnya menunjukkan pentingnya menggunakan kernel upstream stabil untuk keamanan yang ditingkatkan. Jumlah CVE baru dan kurangnya periode embargo untuk perbaikan menuntut pendekatan proaktif dari organisasi dalam mengevaluasi dan mengatasi kerentanan ini. Selain itu, meskipun RHEL 8.8 tidak dikembangkan secara aktif sejak akhir 2022, sekitar 10% dari semua bug yang baru ditemukan masih mempengaruhinya. Sekumpulan bug terakhir RHEL 8.8 datang pada Mei 2023. Hal yang sama berlaku untuk distro Linux enterprise lainnya yang lebih lama (namun masih didukung). Lebih mengkhawatirkan lagi, menurut CIQ: “Beberapa perbaikan yang hilang yang kami periksa dengan jelas diungkapkan sebagai dapat dieksploitasi dari ruang pengguna.” Oleh karena itu, tim CIQ menyimpulkan model kernel vendor tradisional, yang ditandai dengan backporting yang selektif, cacat. Jumlah yang semakin meningkat dari bug yang diketahui dan belum diperbaiki menunjukkan bahwa kernel vendor kurang aman dibandingkan dengan kernel stabil upstream. Tim menganjurkan untuk beralih menggunakan cabang kernel stabil dari kernel.org untuk keamanan dan manajemen bug yang lebih baik. Menurut para penulis, “ini menciptakan insentif yang kuat” bagi pelanggan yang peduli dengan keamanan untuk beralih ke kernel stabil daripada yang khusus vendor. Mereka menegaskan, “Kami percaya bahwa satu-satunya cara realistis bagi pelanggan untuk mengetahui bahwa mereka menjalankan kernel yang aman mungkin adalah beralih ke cabang kernel stabil.” Kertas ini bukanlah kritik terhadap insinyur kernel vendor Linux yang berdedikasi. Sebaliknya, ini adalah undangan bagi industri untuk bersatu di belakang kernel stabil kernel.org sebagai solusi jangka panjang yang optimal. Pergeseran semacam itu akan memungkinkan insinyur untuk lebih fokus pada memperbaiki bug yang spesifik pelanggan dan meningkatkan fitur daripada pada proses backporting yang memakan waktu. Oleh karena itu, mereka memiliki empat kesimpulan kritis: Model kernel vendor rusak dan tidak dapat diperbaiki. Kernel vendor secara inheren tidak aman, dengan kernel vendor yang distabilkan di akhir siklus menjadi rentan. Jumlah bug terbuka yang diketahui membuat menganalisis atau mengklasifikasikan semuanya tidak praktis. Kernel upstream stabil menawarkan perlindungan yang jauh lebih baik terhadap kerentanan keamanan dan bug dalam kode kernel. Jadi, apakah vendor akan melakukannya? Untuk semua alasan keamanan yang baik untuk beralih ke kernel upstream stabil, ada argumen yang menentang, yang pada intinya adalah: Jika Anda selalu memperbarui kernel terbaru, Anda mungkin juga mengalami masalah stabilitas. Program yang berfungsi dengan baik dengan kernel 4.18.0-477.27.1 mungkin tidak berfungsi dengan 4.18.0-477.27.1.el8_8. Tentu saja, dalam kasus spesifik itu, kernel terbaru memperbaiki bug keamanan penting. Semuanya bergantung pada keseimbangan yang halus antara keamanan dan stabilitas. Beberapa pengembang kernel Linux teratas dan CIQ berada di pihak keamanan. Kita akan lihat apa yang dikatakan oleh komunitas vendor Linux lainnya.
