Libseccomp: RFE: Mendukung "versi kernel maksimum"

+1
Itu akan membantu membuat daftar hitam dapat digunakan untuk mitigasi masalah keamanan.

@nmav untuk lebih jelasnya, RFE ini untuk menambahkan informasi ke tabel syscall internal tentang kapan syscall pertama kali diperkenalkan ke kernel Linux, bukan untuk menambahkan logika untuk menentukan apakah kernel yang berjalan saat ini mendukung syscall yang diberikan. Namun, jika Anda mencoba untuk memblokir syscall, Anda dapat melakukannya dengan libseccomp terlepas dari apakah itu didukung pada versi arch/ABI dan kernel tertentu, libseccomp akan melakukan hal yang benar untuk Anda.

RFE ini hampir berusia lima tahun, dan di luar satu diskusi dengan @cgwalters, saya belum pernah melihat atau mendengar banyak minat lain pada fitur semacam itu. Dengan banyak masalah terbuka lainnya, sebagian besar dengan prioritas lebih tinggi, tidak jelas kapan kami akan mengerjakan ini, atau bahkan apakah hal seperti itu akan menjadi tambahan yang berguna.

@cgwalters dan @drakenclimber apa pendapat Anda tentang masalah ini di tahun 2020? Saya tergoda untuk menutup ini sebagai WONTFIX, tetapi saya ingin mendapatkan beberapa komentar dan umpan balik sebelum kita mengambil langkah itu.

@cgwalters dan @drakenclimber apa pendapat Anda tentang masalah ini di tahun 2020? Saya tergoda untuk menutup ini sebagai WONTFIX, tetapi saya ingin mendapatkan beberapa komentar dan umpan balik sebelum kita mengambil langkah itu.

Sejujurnya saya pikir ini adalah ide yang sangat keren. Beberapa pelanggan internal saya menggunakan daftar yang diizinkan karena alasan yang tepat ini. Jika mereka menggunakan daftar tolak dan syscall baru ditambahkan ke kernel, maka syscall itu akan menjadi jalan serangan lain.

Mari kita biarkan terbuka sedikit lebih lama. Saya akan bertanya-tanya di dalam Oracle dan melihat apakah ada pelanggan yang cukup tertarik dengan fitur ini sehingga saya dapat mengambilnya. Tapi @cgwalters (atau siapa pun dalam hal ini) benar-benar diterima untuk memilikinya jika mereka punya waktu dan minat :).

Oke, selama ada minat, saya tidak masalah membiarkan yang ini tetap buka.

Saya masih berpikir itu akan berguna!

Sepertinya masalah #286 adalah masalah konkret untuk membantu mendorong pekerjaan ini ke depan ... meskipun sudah hampir lima tahun ;)

Saya pikir langkah pertama menuju ini adalah menambahkan bidang baru ke file syscalls.csv yang menunjukkan kapan syscall pertama kali diperkenalkan. Itu akan menjadi pekerjaan yang bagus karena saat ini kami memiliki ~469 syscalls yang ditentukan (!). Namun, kami dapat mengamortisasi pekerjaan ini untuk syscalls yang ada dengan nilai "tidak terdefinisi" yang akan kami perlakukan hanya sebagai syscall yang dibuat pada awal waktu. Tentu saja semua tambahan baru pada tabel syscalls.csv perlu ditambahkan dengan versi kernel.

Beberapa pemikiran yang lebih cepat:

• format syscall.csv

#syscall (v5.8.0-rc5 2020-07-14),kver_min,x86,x86_64,...
accept,<version>,PNR,43,...

... di mana <version> dapat berupa "5_8", "UNDEF", atau serupa.

• token versi

enum kernel_version {
    KV_UNDEF = 0,
    KV_1_0,
    KV_1_1,
    KV_1_3,
    KV_2_0,
    ...
    KV_5_8,
    _KV_MAX,
};

Apakah versi kernel adalah hal yang benar untuk dilacak? Apakah dijamin bahwa syscalls yang lebih baru tidak di-backport ke misalnya cabang kernel yang stabil dengan nomor versi yang lebih rendah?

Red Hat akan mem-backport segala macam hal ke kernel mereka, jadi tidak.

Jika RedHat mem-backport syscall ke versi kernel yang lebih lama, mereka juga dapat menambal versi libseccomp mereka agar sesuai. Meskipun untuk bersikap adil ini mungkin lebih penting untuk kasus penggunaan tertentu tetapi sebagai pendekatan untuk memperbaiki #286, saya pikir ini cukup bisa diterapkan. Masalah lainnya adalah saya tidak yakin ada pendekatan yang lebih baik -- syscalls dapat ditambahkan dalam urutan yang tidak berurutan (misalnya openat2 ditambahkan sebelum close_range -- meskipun contoh ini baik dari kesalahan saya).

Jika RedHat mem-backport syscall ke versi kernel yang lebih lama, mereka juga dapat menambal versi libseccomp mereka agar sesuai.

Iya benar sekali. Proyek libseccomp upstream tidak memiliki kendali atas berbagai distribusi Linux perusahaan dan jika distribusi tersebut memutuskan untuk menyimpang dari proyek upstream (baik Kernel Linux atau libseccomp) mereka sendiri untuk mendapatkan dukungan. Meskipun kami akan melakukan yang terbaik untuk membantu, kami tidak dapat mengorbankan proyek hulu demi distribusi perusahaan ini dengan dukungan dan staf teknik mereka sendiri.

Sebagai referensi, halaman manual syscalls(2) memiliki beberapa informasi historis mengenai kapan berbagai syscalls diperkenalkan ke dalam kernel:

• https://www.mankier.com/2/syscalls

Saya dapat melakukan syscall spelunking untuk mengetahui nomor versi untuk setiap syscall -- satu-satunya pertanyaan adalah apakah kita harus memiliki nomor versi per arsitektur karena saya cukup yakin syscalls tertentu ditambahkan ke arsitektur yang berbeda dalam rilis yang berbeda.

... satu-satunya pertanyaan adalah apakah kita harus memiliki nomor versi per arsitektur karena saya cukup yakin syscalls tertentu ditambahkan ke arsitektur yang berbeda dalam rilis yang berbeda.

Mereka pasti, dan masih, sejauh yang saya bisa lihat. Meskipun akan sedikit mengganggu, dan pasti akan meledakkan CSV, melacak penampilan pertama syscall untuk setiap lengkungan/ABI mungkin adalah hal yang benar untuk dilakukan.

Bantuan apa pun yang dapat Anda berikan pada @cyphar ini akan sangat dihargai.