Belajar Firecracker - Jailer & Security Isolation

#Pendahuluan

Sejauh ini kita menjalankan Firecracker sebagai proses biasa — root, tanpa pembatasan. Di dunia nyata, itu tidak pernah cukup. Episode 7 memperkenalkan jailer: pembungkus keamanan yang mengurung proses Firecracker sehingga bila microVM di-tembus, penyerang hanya menemukan dinding kosong.

Mengapa episode ini penting? Karena seluruh klaim keamanan Firecracker — isolasi multi-tenant, workload untrusted — berdiri di atas jailer. KVM melindungi host dari guest, tapi siapakah yang melindungi host dari VMM itu sendiri? Jawabannya: jailer, dengan mekanisme isolasi Linux yang mendalam: namespace, cgroup, seccomp, rootfs read-only, dan drop privilege.

#Filosofi: Defense-in-Depth

Threat model Firecracker berlapis:

1. KVM — memisahkan guest dari proses host di level hardware.
2. Proses Firecracker minimal — sedikit kode, sedikit bug.
3. Jailer — jika lapis 2 gagal (ada bug di VMM), penyerang yang berhasil mengeksekusi kode di dalam proses Firecracker masih dikurung: tidak bisa menulis filesystem, tidak bisa memanggil syscall berbahaya, tidak punya privilege.

Jailer adalah response yang berasumsi bahwa VMM bisa ditembus. Dengan asumsi itu, ia memastikan bahwa penetrasi VMM tidak berarti penetrasi host. Ini pola yang sama dengan container sandbox: jangan percaya bahwa bug tidak akan terjadi — desain supaya bug tidak berbahaya.

#Apa yang Dikerjakan Jailer

Ketika kalian menjalankan jailer --exec-file ./firecracker, jailer melakukan beberapa hal berurutan sebelum mengeksekusi Firecracker:

1. Network namespace — memisahkan jaringan VMM dari jaringan host.
2. cgroup — membatasi CPU, memori, dan device yang bisa diakses proses.
3. Drop privilege — berpindah ke UID/GID non-root.
4. Chroot — memindahkan proses ke root filesystem sendiri yang terisolasi.
5. Seccomp filter — membatasi syscall yang boleh dipanggil ke whitelist sempit.
6. Read-only rootfs — mencegah modifikasi filesystem setelah start.

Hasil akhirnya: proses Firecracker hidup di dunia kecil yang tidak bisa keluar — persis tujuan jailer.

#Memakai Jailer

Pola dasar menjalankan microVM lewat jailer:

sudo jailer \
  --id 1001 \
  --exec-file /usr/local/bin/firecracker \
  --uid 123 \
  --gid 100 \
  --chroot-base-dir /srv/jailer \
  --netns /var/run/netns/fcns \
  --node 0

Memahami flag penting:

• --id <uid> — identitas unik microVM. Jailer menggunakannya untuk membuat direktori chroot-base-dir/<id> sebagai rumah proses. Setiap VM harus punya --id berbeda.
• --chroot-base-dir — direktori tempat jailer membangun root baru (/srv/jailer/<id>/). File kernel, rootfs, dan socket API harus di-copy ke dalamnya agar terlihat proses.
• --exec-file — binary yang akan dieksekusi setelah jail (Firecracker).
• --uid / --gid — UID/GID non-root yang menjalankan proses. Firecracker tidak perlu root; hanya perlu akses ke /dev/kvm dan file-nya sendiri.
• --netns — pindahkan proses ke network namespace tertentu, memberi isolasi jaringan per VM.
• --node — NUMA node untuk menjepit vCPU.

Setelah jailer jalan, socket API berada di /srv/jailer/<id>/run/firecracker.socket — bukan di /tmp lagi. Semua interaksi selanjutnya lewat socket di dalam chroot:

curl --unix-socket /srv/jailer/1001/run/firecracker.socket http://localhost/

#Menyiapkan Chroot untuk Jailer

Jailer mengubah perspektif filesystem proses. Semua yang dibutuhkan Firecracker harus ada di dalam chroot:

sudo mkdir -p /srv/jailer/1001
sudo cp /home/user/fc-demo/vmlinux.bin /srv/jailer/1001/vmlinux.bin
sudo cp /home/user/fc-demo/rootfs.ext4 /srv/jailer/1001/rootfs.ext4

Kemudian semua path di payload API memakai path relatif chroot:

{
  "kernel_image_path": "/vmlinux.bin",
  "boot_args": "console=ttyS0 reboot=k panic=1 pci=off"
}

Polanya: host cp file ke chroot, API merujuk path di dalamnya. Ini juga keuntungan keamanan — proses di dalam chroot tidak bisa melihat file di luar, jadi kernel dan rootfs VM lain tidak terjangkau.

#Seccomp: Whitelist Syscall

Seccomp filter Firecracker membuat whitelist syscall yang diizinkan proses. Syscall berbahaya seperti mount, ptrace, kexec, atau userfaultfd ditolak dengan error — bahkan jika penyerang berhasil mengeksekusi kode arbitrer di dalam proses.

Jailer memuat seccomp profile sesuai arsitektur host. Untuk kebutuhan khusus, profil bisa dikustomisasi, tapi prinsipnya selalu: semakin sempit whitelist, semakin kecil jangkauan penyerang. Syscall tambahan hanya ditambahkan bila benar-benar dibutuhkan workload — misalnya untuk device baru atau fitur baru.

#Praktik Terbaik Isolasi

Beberapa kebiasaan yang harus menjadi refleks:

• Satu VM, satu jailer, satu --id: jangan pernah berbagi chroot antar VM.
• cgroup per VM: pasang memory.max dan cpu.max di cgroup khusus, sehingga satu VM yang bocor memori tidak mematikan tetangganya (detail di episode 10).
• Network namespace per VM: isolasi jaringan di level namespace, bukan hanya TAP berbeda.
• Rootfs read-only: setelah boot, tidak ada alasan guest menulis sistem operasinya.
• Jangan jalankan sebagai root: --uid/--gid non-root adalah prasyarat, bukan opsional.
• Patroli versi: jailer dan firecracker harus versi yang sama — mencampur versi bisa menimbulkan perilaku tak terduga.

#Common Pitfalls

• Path host di API: lupa bahwa di dalam jail path menjadi relatif chroot → 400 Bad Request atau file not found.
• --id duplikat: dua VM memakai --id sama → jailer menolak atau chroot bentrok.
• Socket di /tmp: setelah jailer, socket tidak lagi di /tmp; ia ada di chroot-base-dir/<id>/run/firecracker.socket.
• File tidak di-copy ke chroot: kernel/rootfs tidak terlihat proses → boot gagal.
• TAP dibuat di namespace host: jika memakai --netns, TAP harus ada di namespace tersebut — buat TAP setelah masuk namespace atau dengan ip netns exec.
• UID/GID tidak punya akses /dev/kvm: pastikan user non-root punya izin baca/tulis ke /dev/kvm (via group kvm misalnya).

#Penutup

Inti yang harus dibawa pulang:

• Jailer berasumsi VMM bisa ditembus dan mendesain supaya penetrasi tidak berbahaya.
• Lapisan isolasi: namespace, cgroup, drop privilege, chroot, seccomp, rootfs read-only.
• --id, --chroot-base-dir, --exec-file, --uid/--gid, --netns adalah flag inti.
• Di dalam jail, path API menjadi relatif chroot; file harus di-copy ke chroot dulu.
• Satu jailer per VM, cgroup per VM, network namespace per VM.
• Firecracker dan jailer harus versi yang sama.

Di episode 8 selanjutnya kita akan menyiapkan bekal yang tepat untuk setiap microVM: MicroVM Images — Build & Optimasi Kernel — membangun rootfs minimal dengan Alpine/musl, mengonfigurasi kernel agar hanya memuat driver yang diperlukan, memilih boot params yang tepat, dan mengenal tooling seperti firectl, firecracker-containerd, NixOS microvm.nix, serta mkosi.