Belajar Seccomp - Fitur Modern & Roadmap

#Pendahuluan

Di episode 20 kalian membangun alur policy-as-code yang kokoh — versioning, validasi, dan rollout bertahap. Ada satu asumsi yang selama ini diam-diam kalian pegang: libseccomp di mesin produksi cukup baru. Episode 21 memeriksa asumsi itu. Kita meninjau apa saja yang berubah di libseccomp 2.6.1, mengapa rilis keamanan wajib di-upgrade, dan ke mana arah proyek ini beserta kernel dan ekosistem container.

Sebagai praktisi, kalian tidak perlu menghafal setiap nomor versi — tetapi kalian wajib tahu mengapa versi lama menjadi berbahaya seiring waktu, dan sinyal apa yang menandakan libseccomp kalian tertinggal. Episode ini juga menjelaskan ke mana arah pengembangan seccomp, agar keputusan yang kalian buat hari ini tidak menabrak arus dalam satu atau dua tahun ke depan.

#libseccomp 2.6.1: Rilis Stabilitas dan Keamanan

libseccomp adalah pustaka user space yang menjadi jembatan antara kalian dan filter kernel. Rilis 2.6.0 menandai lompatan besar: dukungan untuk arsitektur baru. Rilis 2.6.1, yang keluar pada Juli 2026, adalah pemolesan yang membawa tiga kelompok perubahan penting.

Pertama, sinkronisasi tabel syscall ke Linux v7.1.0-rc4. Tabel syscall adalah peta yang menghubungkan nama ke nomor untuk tiap arsitektur. Setiap kernel baru menambahkan syscall; tanpa sinkronisasi, syscall baru tidak dikenali oleh nama dan bisa lolos dari filter yang kalian tulis. Memperbarui libseccomp berarti filter kalian memahami kernel yang sedang berjalan.

Mengapa ini isu keamanan, bukan sekadar kenyamanan? Aturan di filter seccomp bekerja per nama syscall. Syscall yang tidak ada di tabel tidak bisa dirujuk dengan nama — dan jika tidak dirujuk, ia jatuh ke defaultAction. Dalam profile minimal dengan defaultAction: SCMP_ACT_ALLOW, syscall baru yang tidak dikenali oleh libseccomp yang usang justru langsung diizinkan tanpa kalian sadari. Artinya, ketertinggalan satu versi bisa membuat celah yang tidak terlihat dalam daftar deny-list kalian.

Kedua, tiga perbaikan keamanan dari GitHub Security Advisory (GHSA). Ketiga advisory ini menutup celah yang dapat dieksploitasi — salah satunya pada jalur parsing, yang merupakan permukaan serangan karena memproses data yang sebagian berasal dari input yang kurang tepercaya. Rincian teknisnya ada di advisory masing-masing; yang wajib kalian lakukan adalah memperbarui versi.

Ketiga, perbaikan penggabungan flag pada user notification. Fitur yang kalian pelajari di episode 6 ini bergantung pada flag seperti SECCOMP_USER_NOTIF_FLAG_CONTINUE. Rilis 2.6.1 memperbaiki cara flag digabungkan saat filter dimodifikasi, sehingga perilaku NOTIFY konsisten dan tidak bisa dieksploitasi untuk melewati verifikasi.

#Kapan Kalian Harus Memperbarui

Keputusan memperbarui tidak harus menunggu audit menyeluruh. Setidaknya ada tiga kondisi yang memicu upgrade:

• Advisory keamanan muncul — seperti tiga GHSA di 2.6.1; perbarui segera di lingkungan yang terpapar, dengan rollout bertahap seperti di episode 20.
• Kernel di-upgrade — tabel syscall kernel yang baru membutuhkan libseccomp yang mengenalinya, agar filter tetap memahami apa yang sedang berjalan.
• Image container dibangun ulang — pin versi libseccomp sebagai bagian dari dependensi, sehingga nomor versinya terekam dan bisa diaudit.

#Dukungan Arsitektur Baru

Rilis 2.6.0 memperkenalkan dukungan untuk SuperH, LoongArch, dan m68k 32-bit. Ini bukan berita yang menarik bagi pengguna x86 — tetapi penting secara strategis: seccomp kini bisa di-generate untuk perangkat tertanam dan arsitektur non-utama yang selama ini tidak punya akses ke filtering syscall yang sama matangnya.

Implikasinya untuk kalian kembali ke episode 5: filter yang sama dapat di-generate untuk arsitektur berbeda, dan keputusan harus selalu mempertimbangkan seccomp_data.arch. Dukungan arsitektur baru berarti tabel syscall per arsitektur menjadi lebih kaya — dan validasi di CI (episode 20) menjadi semakin penting untuk memastikan nama syscall memang valid di arsitektur target.

#Memeriksa Versi dan Tabel Syscall di Mesin Kalian

Sebelum memutuskan apakah mesin kalian tertinggal, periksa dua hal: versi libseccomp yang terpasang dan seberapa baik ia mengenali syscall kernel yang sedang berjalan. Keduanya mudah diperiksa:

pkg-config --modversion libseccomp
scmp_sys_resolver -t | tail -n 20

pkg-config --modversion libseccomp' menampilkan versi pustaka; scmp_sys_resolver -t mencetak tabel syscall yang dikenal untuk arsitektur saat ini. Jika tabel berhenti jauh di bawah nomor syscall yang dikenali kernel — misalnya keluarga io_uring atau pidfd tidak muncul — itu sinyal bahwa libseccomp perlu diperbarui.

Pada distro dengan manajemen paket, versi rilis mengikuti kebijakan masing-masing; pada image container, perbarui layer libseccomp secara berkala dan catat nomor versinya sebagai bagian artifact saat build — konsisten dengan semangat policy-as-code di episode 20. Sinkronisasi tabel syscall juga menjadi alasan mengapa validasi nama syscall di CI (dengan scmp_sys_resolver) harus berjalan di environment dengan libseccomp yang sama dengan produksi.

#Keamanan di Parser dan Iterasi Roadmap

Satu arah yang ditegaskan tim libseccomp adalah iterasi keamanan pada parser dan filter. Parser adalah komponen yang menerima input eksternal — daftar syscall, aturan, dan konfigurasi — dan mengubahnya menjadi program BPF. Ini menjadikannya target utama pengujian fuzzing dan audit. Roadmap ke depan berfokus pada penguatan bagian ini: parser yang lebih aman, batasan input yang lebih ketat, dan lebih banyak pengujian terhadap input yang dimusuhi.

Pelajaran operasionalnya: jangan pernah mempercayai profile dari sumber tidak tepercaya tanpa validasi, dan selalu jalankan libseccomp versi terbaru di lingkungan yang terpapar.

Ada satu kebiasaan yang patut dibangun: jangan menunggu CVE diumumkan untuk memperbarui. Karena libseccomp berada di rantai kepercayaan container — dipakai oleh runc, crun, containerd, dan podman — satu celah di parser bisa diterjemahkan menjadi risiko di seluruh stack. Jadwalkan upgrade sebagai pekerjaan rutin, misalnya bersamaan dengan upgrade kernel, lalu verifikasi dengan pengujian filter yang sudah kalian bangun di episode 20.

#seccomp_transaction_start dan Python Bindings

libseccomp 2.6.1 juga memperjelas dokumentasi seccomp_transaction_start — API yang membungkus sekumpulan operasi filter dalam satu transaksi, sehingga modifikasi bisa dibatalkan secara atomik bila terjadi kesalahan. Ini berguna ketika filter dibangun secara dinamis dari beberapa sumber dan ingin dipasang hanya jika seluruh rangkaian valid.

Bagi kalian yang mengotomatiskan filter dengan Python, binding resmi terus diperbarui. Contoh pembuatan filter sederhana:

Filter dasar dengan Python bindings

import seccomp
 
f = seccomp.SyscallFilter(defaction=seccomp.ERRNO)
f.add_rule(seccomp.ALLOW, "read")
f.add_rule(seccomp.ALLOW, "write")
f.add_rule(seccomp.ALLOW, "futex")
f.load()

Skrip semacam ini bisa diintegrasikan ke tooling deployment untuk menghasilkan filter dari konfigurasi terpusat — fondasi yang sama dengan policy-as-code di episode 20, hanya dengan ekspresi yang lebih kaya.

seccomp_transaction_start paling berguna saat filter dibangun dari konfigurasi yang bisa berubah saat runtime — misalnya daemon yang menambah aturan berdasarkan kebijakan yang dimuat dari file. Dengan transaksi, kegagalan di tengah tidak meninggalkan filter setengah terpasang, dan daemon bisa memutuskan membatalkan seluruh perubahan secara atomik.

#Roadmap: Parser, Kernel, dan Runtime

Melihat ke depan, tiga arena yang bergerak bersamaan.

Pustaka dan parser. Iterasi keamanan berlanjut: fuzzing, batasan input, dan kompatibilitas dengan kernel baru. Perhatikan changelog setiap rilis dan jadikan upgrade libseccomp bagian dari ritual pemeliharaan. Khusus untuk parser, arah yang paling kentara adalah penguatan terhadap input yang dimusuhi: penolakan lebih awal pada konfigurasi yang ambigu, kesalahan yang lebih eksplisit, dan lebih sedikit jalan pintas yang memuat filter sebagian. Implikasinya, perilaku profile lama bisa berubah secara halus — alasan lain untuk selalu menguji ulang profile setelah upgrade libseccomp.

Kernel. Dua wilayah kernel yang paling memengaruhi seccomp adalah io_uring dan user namespaces. io_uring menjalankan operasi I/O secara asinkron di kernel; seccomp hanya memfilter syscall pintunya — bukan setiap opcode operasi. Artinya, syscall io_uring_enter dan io_uring_setup harus diperlakukan sebagai gerbang besar yang memerlukan pertimbangan khusus, misalnya dengan NOTIFY atau pemblokiran langsung bila tidak dibutuhkan. Sementara itu, perluasan user namespaces tanpa privilege mengubah apa yang bisa dilakukan proses unprivileged — dan membuat keputusan blokir terhadap syscall pembuat namespace (unshare, clone dengan flag tertentu) menjadi semakin relevan.

Runtime container. Ekosistem runc, crun, containerd, dan podman terus mengintegrasikan seccomp lebih dalam, sementara Kubernetes menjadikan profile RuntimeDefault sebagai standar. Arahnya jelas: konfigurasi seccomp menjadi bagian normal dari spesifikasi container, bukan anomali yang harus diaktifkan manual. Bagi kalian sebagai operator, ini berarti keterampilan mengkurasi dan memvalidasi profile tidak akan usang — justru semakin dibutuhkan karena seccomp kini menjadi gerbang yang dipakai jauh lebih banyak runtime.

#Penutup

Pada episode 21 ini kalian meninjau keadaan terkini: libseccomp 2.6.1 menyinkronkan tabel syscall ke Linux v7.1.0-rc4, menutup tiga celah keamanan GHSA, memperbaiki merge flag user notification, dan memperbarui dokumentasi seccomp_transaction_start beserta binding Python. Dukungan SuperH, LoongArch, dan m68k 32-bit memperluas jangkauan seccomp ke arsitektur tertanam.

Poin kunci yang perlu kalian bawa:

• Tabel syscall yang usang berarti syscall baru bisa lolos dari filter — perbarui libseccomp.
• Tiga GHSA di 2.6.1 menekankan bahwa libseccomp adalah komponen keamanan, bukan utilitas biasa.
• Arsitektur baru dan iterasi keamanan parser adalah arah roadmap jangka panjang.
• io_uring dan user namespaces adalah dua wilayah kernel yang paling membentuk masa depan seccomp.
• Runtime container terus menjadikan seccomp sebagai bagian standar dari siklus hidup container.

Di episode 22, episode pamungkas, kita meletakkan semuanya dalam peta besar: seccomp dibandingkan dengan AppArmor, SELinux, capabilities, Landlock, dan virtual machine; rekap perjalanan dari episode 0; dan checklist produksi untuk menutup seri ini. Sampai jumpa!