Belajar Seccomp - Sejarah, Latar Belakang & Mengapa Membutuhkan Seccomp

#Pendahuluan

Di episode 0 kalian sudah menyiapkan environment: kernel Linux modern, compiler C, strace, bpftool, dan seccomp-tools. Sekarang waktunya menjawab pertanyaan paling mendasar: kenapa dunia modern sangat membutuhkan seccomp?

Seccomp tidak lahir dalam semalam. Ia hasil dari evolusi panjang keamanan Linux — dari sebuah mekanisme yang sangat kaku di tahun 2005, menjadi fondasi sandboxing yang dipakai hampir seluruh industri container di 2026. Untuk memahami mengapa ia dirancang seperti sekarang, kita harus memahami dulu masalah yang ia pecahkan, lalu menelusuri sejarahnya. Episode ini akan membawa kalian pada dua hal: cerita di balik kelahiran seccomp dan alasan rasional mengapa membatasi syscall adalah pertahanan paling efektif.

#Setiap Syscall Adalah Pintu Masuk

Bayangkan sebuah aplikasi web server. Sebuah web server yang sehat cukup membutuhkan beberapa lusin syscall: membaca file, membuka socket, mengirim data, mengelola memori, dan membuat thread. Tapi proses tersebut bisa memanggil ratusan syscall lainnya — dan justru syscall yang tidak dibutuhkan itulah yang dieksploitasi attacker.

Begini alurnya secara praktis. Ketika sebuah aplikasi berhasil di-exploit (misalnya melalui bug buffer overflow), attacker biasanya menjalankan chain seperti ini:

1. Mendapatkan kendali alur eksekusi (RCE).
2. Memanggil execve untuk menjalankan shell (/bin/sh).
3. Memanggil openat / read untuk membaca file sensitif.
4. Memanggil socket untuk membangun koneksi keluar dan mencuri data.

Sekarang bayangkan jika sejak awal kita bilang ke kernel: "proses ini TIDAK BOLEH memanggil execve, TIDAK BOLEH membuat socket, TIDAK BOLEH membuka file selain yang diperlukan." Apa yang terjadi ketika attacker berhasil mengeksploitasi? Ia mendapat kendali eksekusi — tapi setiap pintu keluar sudah terkunci. Inilah konsep mengurangi attack surface.

#Sejarah Singkat Seccomp

#2005: Kernel 2.6.12 dan Strict Mode

Latar belakangnya: di awal tahun 2000-an, sandboxing user-space masih sangat primitif. Model umumnya adalah privilege separation manual dan chroot — keduanya rapuh terhadap syscall yang terlalu permisif. Kernel 2.6.12 (2005) memperkenalkan mekanisme pertama yang disebut cukup sederhana: seccomp strict mode.

Aturannya sangat kaku: begitu mode ini diaktifkan, proses hanya boleh memanggil empat syscall:

• read
• write
• _exit
• sigreturn

Syscall lain apa pun akan langsung membuat proses di-kill oleh kernel. Mekanisme ini diaktifkan melalui prctl(PR_SET_SECCOMP, SECCOMP_MODE_STRICT) dan bersifat tidak bisa dibatalkan.

Kekuatannya adalah prediktabilitas — satu-satunya cara agar aman. Tapi kelemahannya fatal: hampir tidak ada aplikasi nyata yang bisa berjalan hanya dengan empat syscall. Proses butuh mmap, butuh brk, butuh clone. Strict mode praktis hanya berguna untuk kode yang sangat sempit — misalnya honeypot dan alat-alat keamanan khusus. Karena terlalu sempit, adopsinya sangat terbatas.

#2012: Kernel 3.5 dan Seccomp-bpf (SECCOMP_MODE_FILTER)

Kebutuhan akan filter yang fleksibel datang dari Chromium. Browser perlu menyandbox kode halaman web yang tidak dipercaya — proses renderer harus berjalan dengan syscall sesedikit mungkin, tapi tetap harus bisa menjalankan tugas browser yang kompleks. Mode empat-syscall tidak cukup.

Solusinya: kernel 3.5 (2012) menambahkan seccomp-bpf, mode SECCOMP_MODE_FILTER. Ide utamanya cerdas dan sederhana:

• Filter dinyatakan sebagai program BPF — bahasa bytecode yang sudah terbukti di dunia packet filtering.
• Setiap kali proses memanggil syscall, kernel menjalankan program BPF tersebut dengan data syscall sebagai input.
• Program BPF mengembalikan return action: izinkan, tolak, kill, dan lain-lain (kita bedah detailnya di episode 3).

Seccomp-bpf mempertahankan keamanan strict mode (keputusan ada di kernel, bukan di user-space yang bisa dirusak) sekaligus menawarkan fleksibilitas tanpa batas. Inilah titik balik sejarah: dari mekanisme niche menjadi platform sandboxing universal.

#Adopsi Luas: Dari Chromium ke Seluruh Ekosistem

Kelahiran seccomp-bpf langsung diikuti adopsi besar-besaran:

Docker menjadi pembawa massal seccomp ke seluruh dunia. Sejak Docker 1.10, setiap container yang dijalankan tanpa konfigurasi khusus otomatis mendapat default profile seccomp yang memblokir puluhan syscall berbahaya — tanpa diminta, tanpa konfigurasi tambahan:

# Container ini otomatis memakai default profile seccomp Docker
docker run --rm alpine uname -a
Linux 6.8.0-45-generic #1 SMP x86_64 Linux

# Ganti profile default dengan file JSON kustom
docker run --rm --security-opt seccomp=my-profile.json alpine uname -a

systemd juga mengintegrasikan seccomp ke dalam service units. Administrator bisa langsung membatasi syscall sebuah daemon tanpa menulis kode C sama sekali:

service unit systemd dengan filter seccomp

[Service]
ExecStart=/usr/bin/my-daemon
NoNewPrivileges=yes
SystemCallFilter=@system-service
SystemCallErrorNumber=EPERM

Di balik layar, SystemCallFilter diterjemahkan systemd menjadi filter seccomp yang sama persis dengan yang dibangun libseccomp. Dan runc/libcontainer — runtime OCI yang menjalankan container di mesin kalian — memuat profile seccomp yang tertulis di config.json setiap kali sebuah container dimulai. Seccomp bukan lagi fitur eksperimental; ia sudah menjadi infrastruktur.

#libseccomp 2.6.x (2024–2026)

Library yang mengabstraksi pembuatan filter, libseccomp, terus berevolusi. Rilis jalur 2.6.x membawa dukungan arsitektur baru (termasuk LoongArch dan RISC-V 32/64-bit), perbaikan handling arsitektur yang lebih presisi, serta sejumlah perbaikan keamanan pada generator BPF itu sendiri.

Mengapa update penting? Filter seccomp yang salah disusun bisa menjadi lubang keamanan baru — misalnya bug di generator BPF yang menghasilkan filter tidak sesuai yang diminta. Karena itu, untuk produksi selalu gunakan libseccomp versi terbaru, dan pantau changelog untuk CVE awareness. Verifikasi versi kalian dengan pkg-config --modversion libseccomp.

#Masalah yang Dipecahkan Seccomp

Setelah melihat sejarahnya, mari rangkum secara tegas empat masalah konkret yang dipecahkan seccomp:

1. Menutup attack surface. Proses hanya perlu subset kecil dari ratusan syscall yang tersedia. Seccomp memastikan sisanya tidak bisa dipanggil, sehingga exploit chain terputus di langkah paling awal.

2. Mencegah privilege escalation dan eksploitasi. Mem-blocir syscall seperti execve dan socket memotong kemampuan attacker menjalankan payload, membaca file sensitif, atau membangun komunikasi keluar — bahkan jika kendali eksekusi sudah berhasil direbut.

3. Mengurangi blast radius. Ketika sebuah komponen dikompromikan, seccomp membatasi kerusakan pada komponen itu saja. Satu service yang ditembus tidak otomatis memberi akses ke seluruh mesin atau jaringan internal.

4. Enforce kebijakan "least privilege" di level kernel. Seccomp adalah salah satu dari sedikit mekanisme di mana keputusan keamanan dieksekusi di kernel, bukan di user-space — sehingga tidak bisa di-bypass oleh proses yang sudah dikompromikan.

Yang penting dipahami: seccomp bukan pengganti mekanisme keamanan lain. Ia adalah defense in depth — satu lapisan di antara banyak lapisan. Namespaces membatasi pandangan proses, cgroups membatasi sumber daya, dan seccomp membatasi aksi proses terhadap kernel. Ketiganya saling melengkapi, bukan saling menggantikan.

#Penutup

Inilah inti dari episode 1:

• Seccomp lahir dari masalah nyata: setiap syscall adalah potensi pintu masuk eksploitasi.
• Kernel 2.6.12 (2005) memperkenalkan strict mode — hanya 4 syscall, terlalu sempit untuk adopsi luas.
• Kernel 3.5 (2012) memperkenalkan seccomp-bpf — filter BPF yang fleksibel, dan inilah titik baliknya.
• Chromium, Docker/runc, systemd, dan libcontainer menjadikan seccomp infrastruktur standar.
• libseccomp 2.6.x (2024–2026) terus diperbarui dengan arsitektur baru dan perbaikan keamanan.
• Seccomp menutup attack surface, mencegah eksploitasi, mengurangi blast radius, dan menegakkan least privilege di level kernel.

Di episode 2 berikutnya kita akan membedah konsep dasar dan arsitektur utama seccomp — dari mode SECCOMP_MODE_STRICT dan SECCOMP_MODE_FILTER, peran prctl dan syscall seccomp, komponen kernel versus libseccomp, hingga bagaimana filter diterapkan oleh runc/crun, systemd, dan OpenSSH. Di sana kalian akan melihat bagaimana semua sejarah tadi bekerja secara teknis di dalam sistem. Sampai jumpa!