Belajar SELinux - Sandbox & seunshare

#Pendahuluan

Setelah di episode 18 kalian memastikan SELinux tidak menjadi beban performa, saatnya memakai SELinux sebagai alat isolasi aktif untuk program yang tidak sepenuhnya bisa dipercaya. Pada episode ini kita membongkar dua alat yang dirancang khusus untuk itu: sandbox dan seunshare. Kalian akan belajar menjalankan aplikasi — termasuk aplikasi GUI — di dalam kotak pasir yang terisolasi, memahami cara kerja namespace di baliknya, dan menindaklanjuti dua CVE yang wajib diketahui sebelum memakai seunshare di produksi.

#Pembahasan Utama

#Kenapa Kita Membutuhkan Sandbox

Analogi sederhana: kalian tidak menempatkan orang asing di ruang tamu lalu meninggalkan kunci semua kamar di atas meja. Kalian menempatkannya di kamar terpisah, dengan pintu terkunci, dan hanya kamar itu yang bisa ia akses. Sandbox berbasis SELinux melakukan hal yang sama untuk program: proses dijalankan dalam domain baru yang hanya boleh mengakses sumber daya yang diizinkan — dan setiap penolakannya dicatat oleh policy yang sama yang sudah kalian pelajari sepanjang seri ini.

Yang membedakan sandbox dari sekadar menjalankan proses dengan user terbatas: user terbatas masih mewarisi konteks user tersebut. Domain sandbox_t adalah dunia yang benar-benar berbeda — dengan /tmp sendiri, home directory sendiri, dan (jika diminta) jaringan sendiri.

#sandbox: Kotak Pasir Siap Pakai

Alat sandbox (dari paket policycoreutils-sandbox) membungkus semua kompleksitas itu dalam satu perintah. Bentuk yang paling sering dipakai adalah menjalankan aplikasi GUI seperti Firefox di dalam sandbox X11:

Jalankan Firefox di dalam sandbox X11

sandbox -X firefox

Opsi -X memastikan aplikasi tidak bisa mengintip atau menekan tombol di jendela aplikasi lain: sandbox menyediakan tampilan X yang terisolasi. Untuk mengisolasi lebih jauh — home directory sendiri dan /tmp di atas tmpfs:

Sandbox dengan home dan tmp terpisah

sandbox -H -T -X libreoffice

Sandbox tanpa GUI untuk skrip yang tidak tepercaya

sandbox -M -T bash skrip-tidak-tepercaya.sh

Tabel opsi yang paling sering dipakai:

Opsi	Fungsi
`-X`	Sandbox X11: isolasi tampilan GUI
`-H`	Home directory terpisah
`-T`	/tmp di atas tmpfs (bersih saat proses berakhir)
`-M`	Mount namespace terpisah
`-N`	Network namespace terpisah
`-l`	Level MCS untuk sandbox

Perintah sandbox membutuhkan module policy sandbox yang terpasang — pada distro dengan policy targeted (RHEL, Fedora, dan turunannya) ini sudah default. Kalau belum, pasang dengan semodule -i sandbox.pp.

#seunshare: Namespace dan Policy dalam Satu Perintah

seunshare adalah mesin di balik sandbox. Ia menjalankan sebuah perintah di dalam namespace baru (mount, home, network, dan X11) sambil menerapkan tipe SELinux tertentu. Menariknya, seunshare tidak menuntut policy tambahan — tipe seperti sandbox_t sudah cukup. Pemakaian langsungnya terlihat seperti ini:

Jalankan perintah dengan namespace dan tipe sandbox_t

seunshare -t sandbox_t -T /tmp -H /home/alice/sandbox-home -X firefox

Keterangan opsi:

-t sandbox_t — tipe SELinux yang diterapkan.
-T /tmp — temp directory yang digunakan (ideal tmpfs agar otomatis bersih).
-H /home/alice/sandbox-home — home directory terisolasi.
-X — mode X11.

Nilai seunshare ada pada komposisi: kalian bisa menggabungkan namespace Linux dengan domain SELinux secara eksplisit, yang sulit dicapai hanya dengan unshare atau hanya dengan policy.

#Catatan Keamanan: CVE-2026-59676 dan CVE-2026-59677

Sebelum memakai seunshare di mana pun, ada dua CVE yang wajib diketahui:

Warning

CVE-2026-59676 dan CVE-2026-59677 adalah kerentanan denial of service pada seunshare yang ada di SELinux userspace 3.10. Keduanya diperbaiki di rilis 3.11. Jika kalian menjalankan userspace 3.10 atau lebih lama, seorang user yang tidak berhak bisa membuat seunshare crash atau berhenti merespons — dan dalam skenario tertentu itu memengaruhi ketersediaan layanan lain yang bergantung pada alat ini. Periksa versi userspace kalian dan pastikan sudah di atas 3.10:

Cek versi libselinux di keluarga RHEL

rpm -q libselinux

Cek versi libselinux di keluarga Debian

dpkg -l libselinux1 | tail -1

Upgrade ke 3.11 atau lebih baru. Rilis 3.11 akan kita bedah detail di episode 21, termasuk bagaimana kerentanan ini masuk dalam daftar perbaikan keamanan userspace. Untuk sekarang cukup tahu: jangan pernah menjalankan seunshare versi 3.10 di produksi.

#Jangan Pasang Setuid Bit Tanpa Kebutuhan

Ada satu detail yang sering diabaikan: agar user tanpa hak istimewa bisa membuat namespace, biner seunshare perlu dijalankan dengan hak setuid root. Periksa bit setuid pada biner kalian:

Periksa bit setuid pada seunshare

ls -l /usr/bin/seunshare

Output untuk biner ber-setuid adalah -rwsr-xr-x (ada huruf s pada posisi execute owner). Kalau kalian tidak benar-benar menjalankan sandbox atau seunshare oleh user biasa — misalnya hanya dipakai oleh admin — pertimbangkan untuk mencabut bit tersebut:

Cabut bit setuid dari seunshare

chmod u-s /usr/bin/seunshare

Important

Setiap bit setuid adalah pintu belakang yang memperbesar permukaan serangan: biner ber-setuid dijalankan dengan hak root tanpa verifikasi ulang. Prinsipnya sama dengan hak akses lain yang pernah kita bahas — berikan hanya yang benar-benar dibutuhkan. Jika seunshare ber-setuid padahal tidak dipakai user biasa, dan muncul kerentanan seperti dua CVE di atas, kalian baru saja memberi amunisi gratis kepada penyerang. Cabut, kecuali ada kebutuhan eksplisit.

#Praktik Aman Memakai Sandbox

Beberapa aturan yang menjaga sandbox tetap menjadi alat pertahanan, bukan sumber masalah:

Jangan campur home asli dengan home sandbox. Selalu beri -H direktori khusus; data dari proses sandbox dianggap "mungkin tercemar".
Gunakan tmpfs untuk -T. Temp yang terhapus otomatis mencegah sampah dan kebocoran data.
Kombinasikan dengan network namespace (-N pada sandbox, atau setingan jaringan pada seunshare) bila aplikasi tidak perlu internet.
Perbarui userspace secara rutin. CVE sekelas CVE-2026-59676/59677 hilang begitu saja setelah upgrade — manfaatkan rilis tahunan 3.11, 3.12, dan seterusnya.
Audit deny dari proses sandbox. Jika proses di dalam sandbox mulai ditolak sesuatu yang tidak diharapkan, periksa dengan ausearch -m avc seperti yang kalian pelajari di episode 15.

#Penutup

Pada episode 19 ini kalian telah belajar bahwa SELinux bukan hanya memperkuat sistem yang dipercaya, tetapi juga bisa mengurung program yang tidak dipercaya: sandbox -X untuk GUI, seunshare untuk kontrol namespace yang eksplisit, plus pengetahuan kritis tentang CVE-2026-59676 dan CVE-2026-59677 serta disiplin setuid. Dengan sandbox, "jalur aman" untuk kode yang meragukan bukan lagi hal yang mustahil — cukup satu perintah dengan isolasi yang terdokumentasi.

Di episode 20 berikutnya kita naik ke tingkat operasional: mengelola semua policy, module, dan konfigurasi SELinux sebagai kode — versioned di git, diuji di CI, dan didistribusikan dengan Ansible. Itulah fondasi yang membuat SELinux bisa dipakai di infrastruktur berskala besar, bukan sekadar di satu server. Sampai jumpa!