Saya menyadari ini adalah pertanyaan kuno tetapi saya baru saja menemukannya.
Saya menulis dukungan yang dapat dieksekusi yang ditandatangani untuk kernel Linux (sekitar versi 2.4.3) beberapa waktu lalu, dan menyiapkan seluruh rantai alat untuk menandatangani yang dapat dieksekusi, memeriksa tanda tangan di execve(2)
waktu, menyimpan informasi validasi tanda tangan (menghapus validasi ketika file dibuka untuk ditulis atau dimodifikasi), menyematkan tanda tangan ke dalam program ELF yang sewenang-wenang, dll. Itu memang memperkenalkan beberapa hukuman kinerja pada eksekusi pertama setiap program (karena kernel harus memuat di keseluruhan file, bukan hanya halaman permintaan halaman yang dibutuhkan) tetapi setelah sistem berada dalam kondisi stabil, itu bekerja dengan baik.
Namun kami memutuskan untuk berhenti mengejarnya karena menghadapi beberapa masalah yang terlalu besar untuk membenarkan kerumitannya:
-
Kami belum membuat dukungan untuk perpustakaan bertanda tangan . Pustaka yang ditandatangani juga perlu memodifikasi
ld.so
loader dandlopen(3)
mekanisme. Ini bukan tidak mungkin tetapi memperumit antarmuka:haruskah kita meminta loader meminta kernel untuk memvalidasi tanda tangan atau haruskah perhitungan dilakukan sepenuhnya di ruang pengguna? Bagaimana seseorang melindungi daristrace(2)
d proses jika bagian validasi ini dilakukan di ruang pengguna? Apakah kita akan dipaksa untuk melarangstrace(2)
sepenuhnya pada sistem seperti itu?Apa yang akan kami lakukan tentang program yang menyediakan loader mereka sendiri?
-
Banyak sekali program yang ditulis dalam bahasa yang tidak dapat dikompilasi ke objek ELF. Kami perlu menyediakan khusus bahasa modifikasi pada
bash
,perl
,python
,java
,awk
,sed
, dan seterusnya, agar masing-masing penafsir dapat juga memvalidasi tanda tangan. Karena sebagian besar dari program ini adalah teks biasa format bebas, mereka tidak memiliki struktur yang membuat penyematan tanda tangan digital ke dalam file objek ELF begitu mudah. Di mana tanda tangan akan disimpan? Dalam skrip? Dalam atribut yang diperluas? Dalam basis data tanda tangan eksternal? -
Banyak penerjemah terbuka lebar tentang apa yang mereka izinkan;
bash(1)
dapat berkomunikasi dengan sistem jarak jauh sepenuhnya sendiri menggunakanecho
dan/dev/tcp
, dan dapat dengan mudah diakali untuk mengeksekusi apa pun yang perlu dilakukan penyerang. Ditandatangani atau tidak, Anda tidak dapat mempercayai mereka begitu mereka berada di bawah kendali peretas. -
Motivator utama untuk dukungan yang dapat dieksekusi yang ditandatangani berasal dari rootkit menggantikan
/bin/ps
yang disediakan sistem ,/bin/ps
,/bin/kill
, dan seterusnya. Ya, ada alasan berguna lainnya untuk menandatangani executable. Namun, rootkit menjadi jauh lebih mengesankan dari waktu ke waktu, dengan banyak yang mengandalkan kernel peretasan untuk menyembunyikan aktivitas mereka dari administrator. Setelah kernel diretas, seluruh permainan berakhir. Sebagai hasil dari kecanggihan rootkit, alat yang kami harap dapat dicegah agar tidak digunakan tidak lagi disukai oleh komunitas peretasan. -
Antarmuka pemuatan modul kernel terbuka lebar. Setelah suatu proses memiliki
root
hak istimewa, mudah untuk menyuntikkan modul kernel tanpa pemeriksaan apa pun. Kami juga dapat menulis pemverifikasi lain untuk modul kernel tetapi infrastruktur kernel di sekitar modul sangat primitif.
Model GNU/Linux/FOSS sebenarnya mendorong perusakan -- semacam itu. Pengguna dan pembuat distro harus bebas memodifikasi (mengutak-atik) software agar sesuai dengan kebutuhannya. Bahkan hanya mengkompilasi ulang perangkat lunak (tanpa mengubah kode sumber apa pun) untuk penyesuaian adalah sesuatu yang cukup sering dilakukan, tetapi akan merusak penandatanganan kode biner. Akibatnya, model penandatanganan kode biner tidak terlalu cocok untuk GNU/Linux/FOSS.
Sebaliknya, perangkat lunak semacam ini lebih mengandalkan pembuatan tanda tangan dan/atau hash aman dari paket sumber. Dikombinasikan dengan model distribusi paket yang andal dan tepercaya, ini dapat dibuat seaman (jika tidak lebih, vis-à-vis transparansi ke dalam kode sumber) seperti penandatanganan kode biner.
Modul kernel DigSig mengimplementasikan verifikasi binari yang ditandatangani oleh alat bernama bsign
. Namun, belum ada yang mengerjakannya sejak kernel Linux versi 2.6.21.
Lihat ini:http://linux-ima.sourceforge.net/
Ini belum ditandatangani, tetapi masih mengaktifkan verifikasi.