Belajar SELinux - Hardening & Least Privilege

#Pendahuluan

Di episode 13 jaringan kalian sudah berlabel konsisten dari port sampai paket. Tapi ada pertanyaan yang lebih mendasar dan sering tidak nyaman dijawab: berapa banyak proses di host kalian yang benar-benar dikonfinasi SELinux, dan berapa yang masih berjalan bebas? Pada kebijakan targeted default, sebagian besar daemon memang sudah confined — tetapi user biasa, skrip cron, sesi SSH interaktif, dan aplikasi custom sering kali berjalan sebagai unconfined_t: domain yang praktis tidak dibatasi.

Episode ini adalah titik balik dari memahami SELinux menjadi menyusun strategi pertahanan. Kita membahas least privilege secara konkret: memetakan domain yang tidak terkunci, mengonfinasi mereka, memangkas boolean, menganalisis policy dengan sesearch, memahami jaring pengaman neverallow, dan mengunci semuanya dengan baseline OpenSCAP/CIS yang bisa diulang di banyak mesin.

#Pembahasan Utama

#Musuh Utama: Domain unconfined

Sebuah proses unconfined_t pada dasarnya melewati hampir semua pemeriksaan SELinux. Ia bukan "aman" — ia adalah risiko yang tidak dimitigasi. Analoginya: SELinux adalah sistem gerendel pintu, dan unconfined_t adalah penghuni yang diberi master key. Semua gerendel tetap terpasang, tapi bagi dia, pintunya tidak terkunci.

Mulailah hardening dengan memotret kondisi nyata:

ps -eZ | grep unconfined

unconfined_u:system_r:unconfined_t:s0 3101 ?  00:00:00 sshd
unconfined_u:unconfined_r:unconfined_t:s0 5201 pts/0 00:00:00 bash

Dua pola yang harus dibedakan: system_r:unconfined_t adalah service system yang belum punya domain khusus (sinyal merah: periksa apakah ia harusnya confined), sedangkan unconfined_r:unconfined_t adalah sesi user interaktif (kondisi default, bisa dikonfinasi). Target hardening tidak harus menihilkan keduanya — targetnya adalah mengurangi dengan sadar, bukan membiarkan semuanya lewat begitu saja.

#Mengurangi Domain unconfined

Langkah pertama untuk service: pastikan ia dijalankan sebagai daemon dengan domain confined. Di kebijakan targeted, daemon yang terdaftar (sshd, httpd, named, ntpd, mysql) sudah confined secara otomatis. Masalah biasanya ada pada daemon yang tidak terdaftar. Dua opsi untuk mereka:

1. Tulis policy kustom (episode 12) dan jalankan daemon dengan domain baru kalian.
2. Jika daemonnya didistribusikan oleh distro, pastikan paket policy-nya terpasang — misalnya dnf install -y selinux-policy-targeted pada RHEL, yang membawa modul untuk ratusan service.

Verifikasi kondisi saat ini dengan sestatus -v untuk daemon penting, dan sesearch untuk melihat seberapa lebar aturan domainnya:

sesearch --allow -s sshd_t -c tcp_socket

#Confined vs Unconfined: Atur SELinux User

Untuk user interaktif, kunci terbesarnya adalah SELinux user, bukan account Linux. Lihat pemetaannya:

semanage login -l
semanage user -l

Login Name           SELinux User         MLS/MCS Range
__default__          unconfined_u         s0-s0:c0.c1023
root                 unconfined_u         s0-s0:c0.c1023
alice                user_u               s0

__default__ adalah pemetaan untuk semua account yang tidak tercantum. Mengubah seorang user dari unconfined_u ke user_u (atau staff_u untuk yang butuh sudo lebih lebar) membuat sesi login-nya berjalan confined, dan semua proses anaknya mengikuti:

semanage login -m -s user_u alice

Dari sudut pandang SELinux, user_u adalah "penghuni biasa": boleh menjalankan aplikasi user-nya sendiri (user_t), tetapi tidak bisa menulis file milik domain system. Untuk memastikan tidak ada yang "lolos" ke domain tak diinginkan, audit2why pada denial yang muncul akan memberi petunjuk kenapa sebuah proses user ditolak.

#Audit Booleans dan Matikan yang Tidak Perlu

Boolean (episode 7) adalah kenop yang membuka dan menutup perilaku policy tanpa menulis aturan. Sayangnya, kebiasaan "aktifkan boolean sampai aplikasi jalan" meninggalkan kenop menyala yang tidak dibutuhkan. Audit dengan menampilkan boolean beserta perbedaan dari default:

getsebool -a
semanage boolean -l -C

httpd_can_network_connect  -> on

Setiap boolean on yang tidak dibutuhkan adalah permukaan serang. Matikan yang jelas tidak perlu:

setsebool -P httpd_can_network_connect off

-P membuat perubahan persisten di store policy. Tanpa -P, boolean kembali ke nilai default saat reboot — itu sering menjadi "perubahan ajaib" yang membuat konfigurasi kalian tidak reproducible. Untuk boolean spesifik per layanan, cek juga yang terkait jaringan (misal httpd_can_connect_ftp), virtualisasi (virt_use_nfs), dan NFS/Samba (nfs_export_all_rw) — tanyakan ke diri kalian: fitur apa di mesin ini yang benar-benar membutuhkan ini?

#Analisis Policy dengan sesearch

Hardening tanpa analisis adalah tebakan. sesearch (bagian dari setools) membaca policy aktif dan menjawab pertanyaan seperti "apa saja yang bisa dilakukan domain X?". Tiga variasi yang paling berguna:

sesearch --allow -s httpd_t -t http_port_t -c tcp_socket
sesearch --allow -s httpd_t -c file
sesearch --allow -s httpd_t -c tcp_socket -p name_bind

Bentuk umumnya: sesearch --allow -s <source> -t <target> -c <class> -p <permission>. Kombinasi ketiganya memungkinkan kalian merekonstruksi "permukaan" sebuah domain: port apa yang boleh di-bind, file jenis apa yang boleh dibaca, dan kelas apa saja yang terjangkau. Menjalankan sesearch --allow -s httpd_t -c file dan menemukan aturan ke etc_t adalah temuan yang layak dibahas dalam review keamanan — bukan sekadar trivia.

#neverallow: Jaring Pengaman Kompilasi

Aturan neverallow adalah kebalikan dari allow: pernyataan "ini tidak akan pernah diizinkan" yang diverifikasi pada saat policy dikompilasi. Ia bukan keputusan runtime — ia garansi struktur. Refpolicy memuat ribuan aturan neverallow yang mencegah domain tertentu menyentuh class sensitif (misalnya domain user tidak boleh mengakses security class). Lihatlah dengan sesearch:

sesearch --neverallow -s httpd_t

Jika modul kalian secara tidak sengaja menambahkan allow httpd_t ... yang melanggar neverallow, kompilasi modul akan gagal dengan pesan yang menunjukkan konflik — inilah yang membuat neverallow menjadi jaring pengaman untuk semua orang yang menulis policy, termasuk kalian di episode 12. Saat menulis modul kustom, selalu jalankan sesearch --neverallow pada domain baru sebagai pemeriksaan terakhir sebelum load.

#Baseline: OpenSCAP dan Benchmark CIS

Prinsip terakhir: hardening harus terukur dan berulang, bukan kenangan. OpenSCAP adalah scanner compliance yang membawa profil hardening resmi, termasuk CIS dan STIG. Di RHEL 9:

dnf install -y openscap-scanner scap-security-guide

oscap xccdf eval \
  --profile xccdf_org.ssgproject.content_profile_cis \
  --report /tmp/cis-report.html \
  /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

Laporan HTML yang dihasilkan memuat status per kontrol CIS — dan beberapa kontrol itu persis tentang SELinux: memastikan SELinux enforcing, kebijakan targeted, dan tidak ada boolean berbahaya yang menyala. Untuk menutup celah yang terdeteksi secara otomatis, OpenSCAP bisa membangkitkan script perbaikan:

oscap xccdf generate fix --fix-type bash \
  --profile xccdf_org.ssgproject.content_profile_cis \
  --output /tmp/cis-fix.sh \
  /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

#Penutup

Pada episode 14 ini kalian telah menyusun strategi least privilege yang terukur: mengaudit proses unconfined_t dengan ps -eZ, mengurangi domain unconfined dengan policy kustom atau paket policy distro, mengonfinasi user lewat semanage login dan semanage user, memangkas boolean dengan getsebool -a dan setsebool -P, membaca permukaan domain dengan sesearch --allow, memahami garansi struktur dari neverallow, serta mengunci semuanya dengan baseline OpenSCAP dan profil CIS yang menghasilkan laporan dan script remediasi.

Inti yang harus kalian bawa:

• Hardening SELinux dimulai dari memotret: berapa proses yang masih unconfined_t.
• User interaktif dikonfinasi lewat SELinux user, bukan lewat akun Linux.
• Setiap boolean on adalah permukaan serang — audit dan matikan yang tidak perlu.
• sesearch mengubah tebakan menjadi fakta; neverallow menjaga fakta itu tetap konsisten.
• Baseline CIS/OpenSCAP membuat hardening reproducible dan bisa diaudit.

Sekarang sistem kalian terkunci dan terukur. Tapi pertahanan tanpa observasi adalah harapan kosong: denial yang tidak pernah dilihat sama dengan izin yang tidak pernah diperiksa. Di episode 15 berikutnya kita masuk ke Audit, Monitoring & Incident Response: mengonfigurasi auditd, membaca jejak dengan ausearch dan aureport, membangun alert denial real-time, hingga alur lengkap incident response — analisis rantai denial, forensik konteks yang berubah, dan mitigasi cepat yang tidak merusak produksi. Sampai jumpa di episode 15!