Cara Kerja Keamanan Kernel Linux

 (kroah.com)
1 poin oleh GN⁺ 2026-01-05 | 1 komentar | Bagikan ke WhatsApp
  • Tim keamanan kernel Linux memperbaiki kerentanan yang dilaporkan secepat mungkin dan menggabungkannya ke repositori publik, tanpa membuat pengumuman atau pemberitahuan terpisah
  • Tim ini terpisah dari tim kernel CVE yang menangani penerbitan CVE, dan seluruh anggotanya bekerja dalam kapasitas pribadi, tidak bergantung pada afiliasi perusahaan
  • Bug keamanan diperlakukan sama seperti bug biasa dan setelah diperbaiki tidak diberi penanda khusus sebagai ‘patch keamanan’
  • Embargo lebih dari 7 hari tidak diperbolehkan, dan sebagian besar perbaikan dipublikasikan segera
  • Pendekatan ini mempertimbangkan karakteristik open source dan beragam lingkungan penggunaan, sambil menjaga transparansi dan independensi respons keamanan kernel

Peran tim keamanan kernel Linux

  • Tim keamanan kernel adalah kelompok pengembang yang mengklasifikasikan potensi bug keamanan yang dilaporkan dan memperbaikinya dengan cepat
    • Mereka menangani respons keamanan reaktif secara terpisah dari langkah pencegahan jangka panjang yang dilakukan oleh Kernel Self-Protection Project
  • Prosedur pelaporan dilakukan melalui email teks biasa yang sederhana, dan HTML, lampiran biner, serta enkripsi tidak diizinkan
    • Laporan terenkripsi tidak dapat diproses karena struktur banyak penerima
  • Anggota tim adalah pengembang inti yang mewakili subsistem utama kernel, dan tidak boleh membagikan isi diskusi kepada pemberi kerja atau pihak luar
    • Independensi ini memungkinkan respons yang konsisten terlepas dari berbagai persyaratan hukum di banyak negara, termasuk CRA

Prosedur perbaikan bug

  • Jika bug yang dilaporkan terkait dengan subsistem tertentu, maintainer subsistem tersebut akan dimasukkan ke diskusi email untuk menyelesaikannya
    • Untuk subsistem yang berulang kali mengalami masalah, maintainernya kadang ikut langsung dalam milis tim keamanan
  • Jika pelapor menyediakan patch perbaikan, kontribusinya akan diakui; jika tidak, para pengembang akan menyelesaikannya sendiri
  • Setelah selesai, perbaikan akan digabungkan ke branch kernel utama dan rilis stable

Kebijakan embargo

  • Masa embargo lebih dari 7 hari tidak diizinkan, dan sebagian besar perbaikan dipublikasikan segera
  • Setelah perbaikan, pelapor boleh membuat pengumuman eksternal hanya jika mereka menginginkannya, dan tim keamanan sendiri tidak membuat pengumuman apa pun
  • Penetapan CVE setelah itu dilakukan oleh tim kernel CVE, yang terpisah dari tim keamanan

Prinsip “bug tetaplah bug”

  • Pada 2008, Linus Torvalds menegaskan bahwa bug keamanan tidak boleh diberi penanda terpisah
    • Alasannya, pembedaan sebagai “perbaikan keamanan” justru mendistorsi pentingnya bug lain
  • Semua perbaikan bug dianggap sama pentingnya, dan langsung diterapkan tanpa membedakan keamanan, fungsi, atau performa

Mengapa tidak ada pengumuman keamanan

  • Hampir semua bug di tingkat kernel berpotensi menjadi masalah keamanan
    • Bentuknya beragam, termasuk kebocoran memori, penolakan layanan, dan kebocoran informasi
  • Karena sifat open source, pengembang tidak mengetahui lingkungan nyata pengguna
    • Perbaikan yang tampak sepele bagi satu pengguna bisa menjadi kerentanan fatal bagi pengguna lain
  • Karena itu kebijakannya sederhana
    • Bug yang sudah diketahui segera diperbaiki
    • Rilis yang telah diperbaiki didistribusikan secepat mungkin
  • Pandangannya adalah, dibanding kekhawatiran bahwa perbaikan bisa menimbulkan masalah, membiarkan bug yang sudah diketahui jauh lebih berisiko

Isu keamanan perangkat keras

  • Kasus seperti Spectre dan Meltdown, yang melibatkan OS dan perangkat keras sekaligus, memerlukan prosedur khusus
    • Untuk itu disiapkan ‘Hardware Security Policy’, yang memungkinkan kolaborasi melalui milis terenkripsi terbatas
  • Proses ini lambat dan kompleks, tetapi belakangan banyak bug perangkat keras diselesaikan tanpa prosedur ini
  • Ke depan, persyaratan waktu respons dalam regulasi CRA kemungkinan akan membuat embargo jangka panjang semakin sulit

Latar belakang lahirnya tim keamanan kernel

  • Sebelum 2005, tidak ada saluran kontak keamanan resmi
    • Laporan hanya disampaikan melalui jaringan informal antar pengembang
  • Pada 2005, diskusi dimulai dari usulan lewat email oleh Steve Bergman, dan
    Chris Wright menulis patch yang menambahkan kontak keamanan dan dokumentasi
    • Setelah itu alias email terpusat (security@kernel.org) diresmikan

Tidak adanya pengumuman keamanan dan notifikasi awal

  • Tim keamanan kernel tidak mengelola pengumuman keamanan dalam bentuk apa pun maupun daftar notifikasi awal
    • Penetapan ID CVE ditangani oleh tim kernel CVE, dan tim keamanan tidak terlibat
  • Permintaan untuk daftar notifikasi awal memang banyak, tetapi tidak ada karena risiko kebocoran dan prinsip keterbukaan untuk publik
    • Pandangannya adalah, “jika pemerintah mengizinkan itu, kemungkinan proyek tersebut sebenarnya tidak dipakai di dunia nyata”

Bacaan terkait

1 komentar

 
GN⁺ 2026-01-05
Opini Hacker News

  • Belakangan ini, teknologi yang membuat pengalaman virtualisasi di desktop Linux menjadi mulus berkembang sangat cepat
    Driver GPU mendukung konteks native melalui Mesa, dan fitur berbagi antara tamu–host di Wayland juga terus membaik
    Dulu diperlukan parsing protokol yang rumit seperti sommelier atau wayland-proxy-virtwl, tetapi sekarang proyek wl-cross-domain-proxy sedang mengimplementasikan ini dengan benar
    VMM yang memanfaatkan fitur-fitur ini antara lain muvm, dan solusi yang mengintegrasikan semuanya adalah munix

    • Sangat menarik. Saya penasaran apakah mungkin melakukan live migration aplikasi antar mesin yang menggunakan munix
      Akan keren jika mesin virtual bisa dipindahkan dengan cara dijeda, ditransfer, lalu dilanjutkan kembali

  • Karena alasan inilah Red Hat tetap penting bahkan pada 2025
    Pekerjaan infrastruktur semacam ini akan selalu dibutuhkan

    • Justru bisa juga dikatakan sebaliknya
      Saat Red Hat memilih commit terkait keamanan dengan cherry-pick, bagaimana mereka bisa tahu commit mana di upstream yang terkait keamanan jika tidak diberi tahu?

  • Kadang saya memimpikan OS yang 100% aman
    Mungkin formal verification atau Rust adalah kuncinya
    Saya ingin punya keyakinan bahwa sistem tidak bisa diretas

    • “OS yang tidak bisa diretas” memang terdengar keren. Tapi pada akhirnya serangan rekayasa sosial tetap ada
      Pada akhirnya manusia sendiri adalah kerentanan terbesar
    • Upaya seperti ini sebenarnya sudah ada berkali-kali. Contoh paling terkenal adalah Verve OS dari Microsoft
      Bahkan sampai assembly pun diverifikasi, dan Dafny juga lahir dari sana
      Namun di pasar, ‘rilis cepat’ lebih diprioritaskan daripada ‘kualitas yang baik’, jadi butuh puluhan tahun sebelum ide seperti ini bisa menjadi arus utama
    • Dalam banyak kasus, fitur isolasi yang jebol karena bug keamanan sebenarnya hanya dipakai demi kemudahan administrasi
      Untuk isolasi yang sungguh-sungguh, dibutuhkan virtualisasi atau pemisahan fisik
      Karena itu, sulit mengumpulkan banyak kontributor untuk “OS yang 100% aman”
      Meski begitu, kalau tertarik pada topik ini, ada berbagai proyek pengembangan OS
    • Kalau begitu, gunakan saja Qubes OS
    • Apa yang dibuat manusia bisa dirusak manusia
      Keamanan adalah perlombaan tanpa akhir

  • Sementara itu, meskipun sudah 2026, situs web pribadi Greg masih belum mendukung TLS

    • Sejujurnya, saya rasa tidak terlalu perlu sampai Encrypted Client Hello didukung luas
      Mengaturnya dengan Caddy memang mudah, tetapi untuk situs statis seperti blog pribadi, manfaat praktis dari enkripsi hampir tidak ada
      Toh domain dan IP tetap terekspos dalam teks biasa, jadi bedanya tidak terlalu besar

  • Jika mereka benar-benar berpikir begitu, bukankah seharusnya mereka menghapus CNA?

    • Itu artinya “setiap peneliti keamanan bisa mendefinisikan kerentanan kernel sesuka hati”
      Namun sebagian peneliti cenderung hanya ingin menambah jumlah CVE, sehingga berusaha memberi prioritas tinggi bahkan pada bug yang sebenarnya tidak berbahaya

  • “Jika pelaporan masalah keamanan mewajibkan enkripsi, maka kebijakan ini harus dipertimbangkan ulang (maksudnya pemerintah UK)”
    Bagian ini lucu sekali

  • Ungkapan “bug ya cuma bug” itu terlalu menyederhanakan
    DoS yang butuh hak akses root dan pengambilalihan sistem oleh pengguna tanpa hak istimewa adalah hal yang sama sekali berbeda
    Beberapa bug jelas menyebabkan pelanggaran batas keamanan, dan yang seperti ini harus diklasifikasikan sebagai bug keamanan
    Hal ini sudah dijelaskan ke Greg selama puluhan tahun
    Kesimpulannya, kalau tidak menjalankan versi terbaru, kernel berada dalam keadaan belum sepenuhnya ditambal
    CVE dihindari, perbaikan kerentanan disembunyikan dalam log commit, dan penyerang mengetahuinya dari sana

    • “Bukankah fakta bahwa hanya versi terbaru yang ditambal juga berlaku untuk sebagian besar software?”
      Saya tidak mengerti kenapa hal ini perlu ditekankan secara khusus

  • Pelanggan meminta patch terkait kernel di image Docker
    Padahal Docker tidak menyertakan kernel
    Seharusnya ada cara untuk mendistribusikan image tanpa kernel

    • Apakah kernel Linux bisa ikut masuk ke image container secara tidak sengaja?
      Base image pada umumnya tidak menyertakan kernel
    • Sebagai proyek terkait, wolfi-dev layak dilihat