Belajar SELinux - Performance & Scalability

#Pendahuluan

Setelah di episode 17 kalian menulis policy dengan CIL — bahasa intermediate yang membongkar cara SELinux merakit aturan — dan sebelumnya di episode 16 memeriksa runtime lewat selinuxfs, kini saatnya pertanyaan yang selalu diajukan seorang engineer produksi: "Berapa besar overhead yang SELinux tambahkan ke sistem saya, dan bagaimana menjaga policy tetap sehat ketika jumlah host mulai puluhan?"

SELinux bekerja pada setiap akses: setiap kali sebuah proses membuka file, menyambungkan socket, atau mengirim sinyal, kernel memeriksa kebijakan. Kalau setiap pemeriksaan harus menelusuri seluruh pohon rule dari nol, overhead-nya tidak masuk akal. Di situlah AVC (Access Vector Cache) berperan — kernel menyimpan hasil pemeriksaan dalam cache sehingga pemeriksaan berikutnya untuk kombinasi yang sama menjadi sangat murah. Statistik cache ini bahkan bisa kalian baca langsung dari selinuxfs yang sudah kalian kenal di episode 16.

Episode 18 ini fokus pada dua hal: membuat SELinux sekecil mungkin bebannya (tuning cache, mengukur overhead, memangkas kebisingan log) dan menjadikan policy SELinux sesuatu yang bisa diskalakan ke banyak host secara seragam. Mari kita mulai dari komponen yang paling sering disalahpahami: cache.

#Pembahasan Utama

#Overhead yang Sebenarnya Kecil

Analogi paling jujur untuk AVC adalah pustakawan yang sudah hafal letak bukunya. Kunjungan pertama ke rak memakan waktu — pustakawan harus mencari. Kunjungan berikutnya untuk buku yang sama hanya butuh satu detik karena hasilnya sudah ada di kepalanya. Begitu juga SELinux: akses pertama terhadap sebuah kombinasi source context, target context, class, dan permission adalah cache miss yang mahal; akses-akses berikutnya adalah cache hit yang hampir tidak terlihat.

Inilah alasan mengapa overhead SELinux di produksi umumnya kecil: aplikasi produksi mengakses objek yang itu-itu saja secara berulang — file konfigurasi, socket, direktori. Setelah beberapa menit "pemanasan", hampir semua pemeriksaan menjadi cache hit. Overhead terbesar justru terjadi saat cold cache dan pada sistem dengan jumlah domain yang sangat besar.

#Memantau Kinerja AVC dengan avcstat

Alat pertama yang harus kalian kenal adalah avcstat. Ia membaca data langsung dari selinuxfs:

avcstat

   lookups          hits        misses      allocs  reclaims        frees
  1584002        1571892         12110       12110         0         240

Mari kita baca bersama: dari 1.584.002 pemeriksaan, 1.571.892 di antaranya adalah cache hit — rasio di atas 99%. Hanya 12.110 yang merupakan miss. Selama rasio ini tetap setinggi itu, cache bekerja dengan baik dan tidak ada yang perlu diutak-atik. Perhatikan pula bagaimana kolom reclaims yang kosong menandakan cache tidak pernah dipangkas paksa karena selalu ada ruang.

Cache SELinux memiliki batas ukuran yang diatur lewat avc_cache_threshold:

cat /proc/sys/fs/selinux/avc_cache_threshold

echo 1024 > /proc/sys/fs/selinux/avc_cache_threshold

Nilai ini adalah ambang jumlah entry yang memicu pruning (pembersihan) cache. Nilai default umumnya sudah memadai. Menambahnya bisa mengurangi miss pada sistem dengan domain yang sangat banyak, tetapi dengan imbalan memori. Seperti semua tuning: ukur dulu, ubah setelah ada bukti.

#Mengukur Overhead Secara Langsung

Cara paling sederhana mengukur overhead SELinux: jalankan beban kerja yang representatif dalam mode enforcing, lalu bandingkan dengan mode permissive. Pengukuran ini hanya boleh dilakukan di lingkungan yang tidak kritikal:

time ./workload.sh

setenforce 0
time ./workload.sh
setenforce 1

Hasil pengukuran hampir selalu masuk akal: untuk beban I/O yang realistis, overhead biasanya di bawah beberapa persen. Ini adalah biaya asuransi yang kecil dibanding harga sebuah kompromi keamanan. Kalau kalian melihat angka yang jauh lebih besar, jangan langsung menyalahkan SELinux — periksa label, periksa audit, baru simpulkan.

#dontaudit: Memangkas Kebisingan dan Biaya

Banyak deny bersifat "diketahui dan disengaja" — misalnya sebuah proses mencoba membaca file yang memang tidak seharusnya ia akses, dan aplikasi tetap berjalan normal setelah deny itu. Jika semuanya masuk log audit, I/O log membengkak dan log menjadi tidak terbaca. Untuk itu ada rule dontaudit, yang menyuruh kernel tidak mencatat deny tertentu.

Dalam operasi normal, biarkan dontaudit aktif. Saat kalian sedang memburu deny yang "hilang" — masalah aplikasi tidak bekerja tetapi log kosong — matikan dulu dontaudit, periksa, lalu nyalakan kembali:

semodule -DB

semodule -B

#Scaling ke Banyak Host: Satu Policy, Banyak Mesin

Sekarang bagian yang paling sering dilupakan saat SELinux mulai dipakai di infrastruktur besar: menjaga policy tetap seragam. Kalau setiap admin "menambal" policy di mesin masing-masing dengan semanage langsung, dalam hitungan bulan akan muncul drift: host A punya boolean yang berbeda dengan host B, dan insiden yang sama berperilaku berbeda di dua mesin.

Pendekatan yang benar adalah policy-as-code: satu sumber kebenaran di git, dibangun, diuji, lalu didistribusikan ke seluruh fleet dengan alat otomasi — detailnya akan kalian temukan di episode 20. Baseline enforcement berarti setiap host harus bisa diverifikasi berada di kondisi yang sama. Verifikasi itu dimulai dari hal sederhana:

sestatus

semodule -l

md5sum /etc/selinux/targeted/policy/policy.33

Dengan membandingkan output semodule -l dan hash file policy di setiap host terhadap nilai baseline, drift langsung terlihat. Perbandingan seperti ini mudah diotomatiskan — misalnya lewat satu playbook Ansible yang memastikan daftar module identik — dan menjadi salah satu dari checklist kesehatan yang akan kalian temui lagi di episode 22.

#Jangan Tuning Sebelum Mengukur

Satu pola pikir yang ingin kami tanamkan di episode ini: cache SELinux dan overhead jarang menjadi bottleneck yang nyata. Setiap kali insting kalian berkata "SELinux bikin lambat", tahan dulu. Ukur dengan avcstat, ukur waktu eksekusi beban kerja, lalu putuskan. Sembilan dari sepuluh kali, biang keladinya bukan SELinux — melainkan loop audit yang boros, aplikasi yang di-restart terlalu sering sehingga cache selalu dingin, atau deny yang tidak teroptimasi.

#Penutup

Pada episode 18 ini kalian telah memahami bahwa overhead SELinux di produksi umumnya kecil berkat AVC cache, dan kinerja itu bisa dipantau (avcstat) serta diukur secara langsung. Kalian juga belajar memangkas kebisingan log dengan dontaudit, dan — yang sama pentingnya — bahwa skala itu masalah manajemen, bukan sekadar konfigurasi: satu policy yang seragam, ber-version, dan didistribusikan secara otomatis adalah kunci untuk fleet dengan puluhan bahkan ratusan host.

Poin kunci yang perlu kalian bawa pulang:

• AVC cache membuat pemeriksaan berulang menjadi sangat murah; perhatikan rasio hit di avcstat.
• Ukur overhead dulu (setenforce 0 hanya untuk diagnosa singkat) sebelum men-tuning apa pun.
• semodule -DB untuk debugging deny, semodule -B untuk kembali normal.
• Policy harus seragam: satu sumber kebenaran, verifikasi baseline di setiap host.
• Jangan tuning tanpa bukti — kebanyakan masalah kinerja bukan berasal dari SELinux.

Setelah memastikan SELinux tidak membebani sistem, saatnya memanfaatkannya sebagai alat isolasi aktif. Di episode 19 kita masuk ke Sandbox & seunshare — cara menjalankan program yang tidak kita percaya di dalam kotak pasir berbasis SELinux, lengkap dengan catatan keamanan CVE-2026-59676 dan CVE-2026-59677. Sampai jumpa!