Belajar Seccomp - Modes & Return Actions

#Pendahuluan

Di episode 2 kalian sudah memahami arsitektur seccomp: bagaimana filter dievaluasi di kernel, peran libseccomp, dan cara kerja mode STRICT maupun FILTER. Episode 3 ini masuk ke jantung pengambilan keputusan: apa yang dilakukan kernel ketika sebuah syscall masuk, dan apa yang harus kalian pilih saat menulis filter?

Dua hal akan kita bedah: perbandingan mendalam kedua mode operasi dari sisi keamanan dan performa, lalu seluruh return action (SECCOMP_RET_*) — apa efeknya, kapan menggunakannya, dan mengapa memilih yang tepat itu penting. Ini episode yang paling sering dirujuk ulang di sepanjang series, jadi pahami baik-baik.

#SECCOMP_MODE_STRICT vs SECCOMP_MODE_FILTER

Kedua mode ini menjawab era yang berbeda (episode 1) dan dipasang dengan cara berbeda (episode 2). Mari bandingkan secara sistematis:

Dari sisi performa, keduanya sama-sama murah. Evaluasi BPF seccomp berjalan di jalur syscall paling panas, sehingga desainnya sengaja dibuat sesederhana mungkin: program BPF yang panjangnya dibatasi (maksimal 4096 instruksi), tanpa loop, dan dijamin berhenti. Overhead praktisnya berada di orde puluhan hingga ratusan nanodetik per syscall — jauh lebih kecil daripada ongkos syscall itu sendiri.

Pertimbangan keamanannya lebih menarik. Strict mode memberikan jaminan mutlak dengan cara yang brutal: hanya empat syscall, sisanya bunuh diri proses. Seccomp-bpf lebih halus: kalian memutuskan sendiri seberapa ketat, dan karena deny-list cenderung melupakan syscall berbahaya, praktik terbaik industri justru allow-list (default deny) — hanya syscall yang benar-benar dibutuhkan yang diizinkan. Kita bedah filosofi ini lebih jauh lewat return actions.

#Return Actions: Keputusan Kernel atas Setiap Syscall

Ketika filter dievaluasi, program BPF mengembalikan sebuah return action yang menentukan nasib syscall tersebut. Kernel membandingkan nilai return action dari semua filter yang terpasang (jika berlapis) dan mengambil yang paling restriktif.

#Kapan Memakai yang Mana?

SECCOMP_RET_KILL_PROCESS adalah jawaban untuk "syscall apa yang tidak boleh terjadi dalam kondisi apa pun?". Jika sebuah proses yang tidak pernah memanggil execve tiba-tiba melakukannya, kemungkinan besar proses itu sedang dieksploitasi — tidak ada alasan untuk melanjutkan eksekusi. Membunuh proses adalah respons paling aman dan menghilangkan risiko berikutnya.

SECCOMP_RET_KILL_THREAD berguna ketika hanya satu thread yang melanggar dan kalian ingin thread lain tetap hidup. Praktiknya jarang — mematikan seluruh proses biasanya lebih bersih untuk keamanan — tapi penting untuk memahami perbedaannya saat membaca dokumentasi kernel.

SECCOMP_RET_ERRNO adalah pilihan default action paling umum untuk profil allow-list (seperti profile default Docker dan runc). Dengan SCMP_ACT_ERRNO(EPERM), setiap syscall yang tidak terdaftar gagal dengan "Operation not permitted" — aplikasi menerima error yang jelas, dan kalian bisa mengobservasi syscall mana yang ternyata dibutuhkan tanpa membunuh proses. Ini "mode bertahap" yang ideal untuk men-debug kebutuhan syscall aplikasi.

SECCOMP_RET_TRAP mengirim SIGSYS yang bisa ditangkap handler di user-space. Ia berguna ketika kalian ingin mengamati syscall yang diblokir sambil tetap bisa melanjutkan proses, atau ketika syscall perlu diproses secara manual. Overhead-nya lebih besar karena melibatkan sinyal, jadi bukan pilihan untuk jalur syscall yang panas.

SECCOMP_RET_TRACE menyerahkan keputusan ke tracer ptrace. Ini dipakai oleh sandbox yang terkelola: supervisor memeriksa setiap syscall dan memutuskan izin atau menolak. Konsekuensinya, proses akan bergantung pada tracer — jika tracer mati, perilaku default harus didefinisikan dengan hati-hati.

SECCOMP_RET_ALLOW adalah dasar deny-list maupun allow-list. Dalam profil allow-list, ia menjadi pengecualian yang terdaftar; dalam deny-list, ia menjadi default.

SECCOMP_RET_LOG memungkinkan kalian berlatih: syscall dicatat ke log audit tapi tetap diizinkan. Ini cara terbaik untuk memahami perilaku syscall aplikasi sebelum filter diaktifkan penuh. Kernel yang lebih lama dari 4.14 tidak mendukungnya.

SECCOMP_RET_NOTIFY (kernel 5.0+) membuat syscall menunggu sambil memberi tahu supervisor di user-space melalui notification fd. Ini adalah fitur paling modern: kebijakan bisa dinamis berdasarkan konteks aplikasi, bukan hanya statis. Kita akan bedah penuh di episode 6.

#Mempraktikkan Strict Mode

Sebagai penutup konseptual, mari kembali ke contoh praktis strict mode dari episode 2 — program sederhana yang mengaktifkan SECCOMP_MODE_STRICT:

#define _GNU_SOURCE
#include <stdio.h>
#include <unistd.h>
#include <sys/syscall.h>
#include <sys/prctl.h>
#include <linux/seccomp.h>
 
int main(void) {
    if (prctl(PR_SET_SECCOMP, SECCOMP_MODE_STRICT) == -1) {
        perror("prctl");
        syscall(SYS_exit, 1);
    }
    write(STDOUT_FILENO, "strict mode aktif\n", 18);
    syscall(SYS_exit, 0);
}

gcc -o strict-mode strict_mode.c
./strict-mode
strict mode aktif

#Penutup

Di episode 3 ini kalian sudah menguasai keputusan inti seccomp:

• Strict mode: kaku, murah, tapi tidak praktis; filter mode: fleksibel dan tetap ringan.
• Overhead seccomp sangat kecil — jauh di bawah ongkos syscall itu sendiri.
• Tujuh return action utama: KILL_PROCESS, KILL_THREAD, TRAP, ERRNO, TRACE, ALLOW, LOG, dan NOTIFY.
• Aturan emas prioritas: KILL lebih kuat dari ERRNO, ERRNO lebih kuat dari ALLOW.
• Pilih default action yang tepat dulu (SCMP_ACT_ALLOW untuk deny-list, SCMP_ACT_ERRNO untuk allow-list), lalu aturan-aturannya.

Sekarang kalian sudah punya bahasa dan konsep untuk memahami filter apa pun. Di episode 4 berikutnya kita akan berlatih sungguhan: libseccomp API dasar — seccomp_init, seccomp_rule_add, seccomp_load, seccomp_reset, dan seccomp_export_bpf, lengkap dengan contoh filter C pertama yang memblokir execve. Sampai jumpa!