Belajar OpenBSD - Security Architecture: pledge & unveil

#Pendahuluan

Di episode 14 sebelumnya, kalian mengamankan pintu masuk ke sistem dengan hardening SSH. Sekarang kita masuk ke ranah yang membuat OpenBSD benar-benar unik: mengamankan proses dari dalam. Jika firewall dan SSH melindungi dari luar, maka pledge dan unveil melindungi dari dalam — bahkan jika sebuah proses berhasil di-bug.

Bayangkan sebuah aplikasi web yang di-exploit. Di sistem lain, penyerang mendapat akses penuh seperti proses itu: bisa membaca semua file, membuka semua koneksi. Di OpenBSD, aplikasi sudah "berjanji" sejak awal hanya akan memakai kemampuan tertentu — dan jika ia mencoba lebih, sistem langsung mematikannya.

#pledge: Janji atas Syscall

pledge(2) adalah syscall yang memungkinkan proses menetapkan promise — daftar kemampuan syscall yang diizinkan. Begitu di-pledge, pemanggilan syscall di luar janji akan menghentikan proses dengan cepat. Ini sandboxing yang berbeda dari mekanisme lain: ia bekerja dari "siapa pemilik proses" dan "syscall apa yang boleh".

Contoh paling dasar:

#include <unistd.h>
 
pledge("stdio rpath", NULL);

Setelah baris ini, program hanya boleh memakai I/O standar (stdio) dan membaca file (rpath). Buka koneksi jaringan, tulis file, atau jalankan proses lain — semua ditolak.

#Promise yang Umum Dipakai

Praktiknya, proses menetapkan promise luas di awal, lalu menyempitkannya setelah inisialisasi selesai. Contohnya: httpd membuka kunci, membaca konfigurasi, lalu menetapkan promise yang lebih sempit sebelum melayani permintaan.

#unveil: Janji atas Filesystem

unveil(2) adalah pendamping pledge: membatasi akses filesystem per-proses. Dengan unveil(path, perms), proses hanya bisa melihat path yang di-unveil, dengan izin tertentu:

#include <unistd.h>
 
unveil("/var/www/htdocs", "r");
unveil("/etc/ssl", "r");
unveil(NULL, NULL);

Pemanggilan unveil(NULL, NULL) mengunci — setelah itu tidak ada path baru yang bisa di-unveil. Proses hanya bisa membaca /var/www/htdocs dan /etc/ssl; akses ke /etc/passwd, home directory, atau path lain ditolak oleh kernel.

Kombinasi pledge + unveil menghasilkan least privilege yang ditegakkan oleh kernel, bukan sekadar janji baik programmer.

#Penerapan di Base System

Kekuatan pendekatan ini terlihat dari kenyataan bahwa hampir semua program di base system sudah di-pledge dan di-unveil. Beberapa contoh:

• httpd: setelah membaca konfigurasi, di-unveil hanya ke direktori root dan /etc/ssl.
• sshd: membatasi akses filesystem untuk sesi login.
• OpenSMTPD, relayd, smtpd: semua menerapkan pledge/unveil.
• Program kecil seperti cat dan ls pun memakainya.

Verifikasi dengan ktrace atau dengan memeriksa source. Contoh praktis: jalankan sebuah program yang seharusnya bisa membaca banyak file, tapi karena unveil, aksesnya gagal:

doas httpd -n
tail -f /var/log/httpd.error.log

Kegagalan akses akibat unveil biasanya muncul sebagai EACCES atau pesan serupa — penanda bahwa sandboxing bekerja.

#Lapisan Keamanan Pendukung

pledge dan unveil hidup di tengah ekosistem mitigasi yang lebih luas:

#W^X (Write XOR Execute)

Memori tidak pernah bisa writable dan executable pada waktu bersamaan. Ini memblokir banyak teknik exploit klasik: menulis shellcode ke memori lalu mengeksekusinya. Periksa dengan:

sysctl kern.wxabort
readelf -l /bin/ls | grep GNU_STACK

Jika GNU_STACK berisi RW, binary tidak memakai W^X — sesuatu yang harus dihindari.

#KARL (Kernel Address Randomization Link)

Sejak episode 2, kalian tahu KARL me-relink kernel secara acak setiap boot. Lihat bahwa kernel berubah:

sysctl kern.osrelease
ls -la /bsd

Setiap reboot menghasilkan /bsd dengan tata letak alamat yang berbeda — membuat eksploitasi bug kernel jauh lebih sulit.

#sysctl Keamanan

Beberapa parameter keamanan bisa ditinjau lewat sysctl:

sysctl kern.randompid
sysctl net.inet.ip.redirect
sysctl net.inet.tcp.syncookies

kern.randompid menambah PID acak pada proses, syncookies melindungi dari SYN flood. Nilai default OpenBSD sudah aman; tugas kalian adalah tidak melemahkannya.

#WITNESS dan Pemeriksaan MALLOC

Kernel OpenBSD dapat dibangun dengan pemeriksaan tambahan untuk menemukan bug:

• WITNESS: deteksi deadlock pada lock kernel.
• MALLOC_ options*: deteksi overrun buffer dan use-after-free saat development.

Fitur ini aktif di kernel development, bukan di produksi — menegaskan filosofi "uji keras, rilis bersih".

#Syarat Pertama: Aplikasi yang Bekerja Sama

Penting untuk jujur: pledge dan unveil hanya sekuat aplikasi yang memakainya. Program pihak ketiga yang tidak di-pledge tetap berjalan dengan hak normalnya. Karena itu, di OpenBSD:

• Prefer daemon base system (httpd, smtpd, relayd) yang sudah di-pledge.
• Untuk package pihak ketiga, periksa apakah aplikasi tersebut sudah menerapkan pledge/unveil.
• Ketika memilih software, anggap dukungan sandboxing ini sebagai kriteria.

#Penutup

Di episode 15 ini kalian membongkar arsitektur keamanan khas OpenBSD: syscall sandboxing dengan pledge yang membatasi syscall, unveil yang membatasi filesystem, penerapannya di base tools, serta lapisan pendukung W^X, KARL, sysctl keamanan, dan pemeriksaan WITNESS serta MALLOC.

Inti yang harus dibawa pulang:

• pledge("stdio rpath", NULL) membatasi syscall; unveil(path, "r") membatasi filesystem.
• unveil(NULL, NULL) mengunci daftar akses — tidak ada lagi setelahnya.
• Hampir semua program base system sudah menerapkan keduanya.
• W^X, KARL, dan default sysctl adalah fondasi di belakang pledge/unveil.

Di episode 16 selanjutnya, kita akan membangun relayd & load balancing — relay dan load balancer layer 4/7, menyusun /etc/relayd.conf, melakukan health checks, TLS termination, dan membangun reverse proxy untuk web services.