Belajar Seccomp - Seccomp di Sandboxing Projects

#Pendahuluan

Di episode 18 kalian mengukur biaya seccomp dan menemukan bahwa untuk profile yang baik, overhead-nya nyaris tidak terlihat. Itulah alasan mengapa seccomp menjadi lapisan favorit di proyek sandboxing paling serius di dunia. Episode 19 ini adalah tur lapangan: kita membongkar bagaimana Chromium, gVisor, Firecracker, Landlock, dan QEMU memakai seccomp — lalu menutup dengan panduan praktis memilih antara seccomp, sandbox penuh, atau virtual machine.

Satu benang merah akan kalian lihat di semua kasus: tidak ada proyek yang mengandalkan seccomp sendirian. Seccomp selalu menjadi satu lapis di antara banyak lapis, dan kekuatan sebenarnya justru lahir dari kombinasi itu.

#Chromium: Seccomp dalam Piramida Sandbox

Chromium adalah contoh paling masif penggunaan seccomp-bpf di dunia nyata. Proses renderer — yang memproses HTML, JavaScript, dan konten web yang tidak tepercaya — dijalankan di dalam sandbox berlapis:

• Seccomp-bpf membatasi syscall yang boleh dilakukan proses renderer menjadi subset sangat kecil yang dibutuhkan untuk rendering dan komunikasi IPC.
• Namespaces memisahkan filesystem dan proses, sehingga renderer tidak melihat host.
• Rlimit dan cgroups membatasi konsumsi memori dan CPU.
• IPC channel yang sempit menjadi satu-satunya jalur komunikasi dengan proses induk.

Gagasan desainnya jitu: setiap lapis menangkap apa yang mungkin lolos dari lapis lain. Seccomp di sini bekerja sebagai gerbang paling dalam — jika sebuah exploit berhasil, ia tetap berhadapan dengan dinding syscall yang hanya berisi segelintir pintu. Chromium memelihara daftar syscall yang diizinkan per platform dan terus memperbaruinya dari laporan crash dan bug — pola yang kelak kalian temui lagi di episode 20 sebagai policy-as-code.

#gVisor: Kernel di User Space

gVisor, yang dijalankan melalui runtime OCI runsc, mengambil pendekatan yang berbeda. Aplikasi di dalamnya tidak memanggil kernel host sama sekali: setiap syscall diintersepsi dan diimplementasikan ulang oleh Sentry, sebuah "kernel" yang ditulis dalam Go dan berjalan di user space. Aplikasi mendapat ilusi kernel normal, tetapi permukaan serangan kernel host tidak pernah tersentuh.

Yang menarik untuk cerita kita: seccomp tetap ada, tetapi di lapisan berbeda. Sentry sendiri dibatasi oleh seccomp ke sejumlah kecil syscall host yang benar-benar dibutuhkannya. Dengan kata lain, seccomp mengurung kernel user-space itu sendiri — pertahanan terakhir jika ada bug di implementasi Sentry.

Kapan memakai gVisor? Ketika kode tidak tepercaya harus berjalan di mesin multi-tenant tanpa overhead virtual machine. Harganya adalah performa: untuk beberapa workload, overhead bisa mencapai 10–40 persen — trade-off yang wajar untuk isolasi sekuat ini.

#Firecracker: VMM Kecil yang Ketat

Firecracker adalah virtual machine monitor (VMM) yang didesain untuk microVM tanpa memori dan tanpa beban startup yang besar. Setiap microVM memiliki proses VMM sendiri, dan proses itulah yang menjadi target seccomp.

Firecracker menerapkan filter seccomp yang sangat ketat: hanya beberapa lusin syscall host yang diizinkan, jauh lebih sedikit dari yang dibutuhkan sistem operasi normal. Tujuannya sederhana — jika terjadi bug di emulasi perangkat virtual, syscall berbahaya di host sudah terblokir lebih dulu. Firecracker juga menambahkan jailer yang mengunci direktori, user, dan cgroup, sehingga seccomp menjadi satu bagian dari "kotak di dalam kotak".

#Landlock dan Seccomp: Melengkapi, Bukan Bersaing

Landlock adalah Linux Security Module berbasis path yang tersedia sejak kernel 5.13. Ia membatasi akses filesystem — misalnya "proses ini hanya boleh membaca /var/www dan menulis /var/log/myapp" — tanpa membutuhkan root dan tanpa konfigurasi label yang rumit.

Bedanya dengan seccomp jelas: seccomp membatasi syscall, Landlock membatasi objek filesystem yang dapat dijangkau. Kombinasi keduanya sangat kuat: seccomp memblokir syscall berbahaya, Landlock mengunci area filesystem yang boleh diakses. Contoh kasus nyata: server web yang boleh membaca direktori tertentu saja, menulis ke log miliknya sendiri, dan tidak menyentuh apa pun di luar itu — semuanya tanpa menjalankan aplikasi sebagai root.

grep Seccomp /proc/<pid>/status

Perintah di atas — grep Seccomp /proc/<pid>/status' — adalah cara tercepat memastikan filter benar-benar terpasang pada proses produksi kalian.

#QEMU: Sandbox untuk Virtual Machine Monitor

QEMU juga menerapkan seccomp, tetapi untuk alasan yang sama seperti Firecracker: melindungi host dari proses VMM itu sendiri. Opsi -sandbox mengaktifkan filter yang membatasi syscall yang dapat dipanggil oleh proses QEMU:

qemu-system-x86_64 -sandbox on,obsolete=deny -m 1024 -hda disk.img

Jika sebuah exploit di emulasi perangkat berhasil mengambil alih proses QEMU, ia hanya menemukan daftar syscall yang sangat pendek — bukan seluruh permukaan kernel host. Pendekatan yang sama, konteks yang berbeda: VMM sekecil Firecracker atau sebesar QEMU sama-sama menganggap seccomp sebagai biaya yang layak.

#Praktik: Memilih Lapisan yang Tepat

Seperti halnya memilih alat transportasi, pilihan sandbox tergantung pada apa yang diangkut dan seberapa berbahaya penumpangnya.

Pedoman singkatnya:

• Gunakan seccomp saat aplikasi sudah dikenal baik dan kalian hanya ingin memangkas permukaan serangan — ini pola default di container.
• Tambahkan Landlock atau capabilities saat aplikasi tepercaya sebagian, misalnya server yang memproses input pengguna.
• Naik ke gVisor saat kode benar-benar tidak tepercaya, seperti plugin atau kode dari pengguna lain.
• Pilih virtual machine saat isolasi harus mutlak, memori dan startup bukan masalah, atau regulasi menuntut batas tegas antar tenant.

#Kombinasi Lapisan: Defense in Depth

Lapisan terbaik bukan salah satu mekanisme, melainkan semuanya secara berurutan:

kernel host
  -> seccomp          memblokir syscall berbahaya
  -> capabilities     memangkas hak root
  -> Landlock/AppArmor mengunci akses filesystem
  -> namespaces       memisahkan resource
  -> read-only filesystem  menyulitkan persistensi
  -> aplikasi

Setiap lapis menangkap kesalahan yang mungkin dilewatkan lapis di bawahnya. Inilah inti defense in depth yang sudah kalian lihat sejak episode 12 tentang kombinasi seccomp dan capabilities — episode 19 memperluasnya ke seluruh ekosistem.

#Penutup

Pada episode 19 ini kalian melihat seccomp bekerja di medan perang yang sesungguhnya. Chromium menggunakannya sebagai gerbang terdalam piramida sandbox; gVisor mengurung kernel user-space miliknya sendiri; Firecracker membatasi VMM ke beberapa lusin syscall; Landlock melengkapinya di ranah filesystem; dan QEMU memakai pola yang sama untuk melindungi host.

Poin kunci yang perlu kalian bawa:

• Seccomp selalu menjadi bagian dari kombinasi, bukan satu-satunya benteng.
• Chromium: daftar syscall dikurasi dari laporan nyata dan diperbarui terus.
• gVisor: syscall diinterupsi di user space, dan seccomp mengurung Sentry.
• Firecracker dan QEMU: seccomp melindungi host dari VMM yang terkompromi.
• Landlock membatasi filesystem, seccomp membatasi syscall — keduanya saling melengkapi.
• Pilihan seccomp, sandbox penuh, atau VM mengikuti derajat ketidakpercayaan terhadap kode.

Di episode 20 berikutnya kita mengotomatiskan semuanya: seccomp sebagai policy-as-code, generator berbasis strace, validasi di CI, hingga rollout bertahap dari LOG ke ENFORCE. Sampai jumpa!