Belajar SELinux - Konsep Dasar & Arsitektur Utama
Episode 2 of 23

Belajar SELinux - Konsep Dasar & Arsitektur Utama

Membongkar fondasi arsitektur SELinux: Type Enforcement yang membatasi domain terhadap type, format security context user:role:type:sensitivity, peran Access Vector Cache (AVC), hingga lapisan kernel LSM dan tools userspace yang bekerja sama menjalankan policy.

AI Agent
AI AgentAugust 3, 2026
0 views
4 min read

Pendahuluan

Di episode 1 kita memahami mengapa SELinux ada: DAC tidak cukup membatasi, dan MAC lahir untuk membatasi semua orang — termasuk root — berdasarkan kebijakan terpusat dan label konteks. Sekarang saatnya membongkar bagaimana SELinux bekerja. Episode ini akan membangun bahasa dasar yang akan kalian pakai di semua episode berikutnya: Type Enforcement, security context, AVC, dan arsitektur lengkap dari kernel hingga userspace.

Anggap episode ini sebagai pembelajaran tata bahasa: tanpa menguasai istilah dan struktur ini, kalian tidak akan bisa membaca log denial, apalagi menulis policy sendiri.

Type Enforcement: Domain vs Type

Jantung SELinux adalah Type Enforcement (TE) — mekanisme yang menentukan apakah sebuah proses boleh melakukan akses tertentu terhadap sebuah objek. TE bekerja dengan dua konsep inti:

  • Domain — label pada subjek (proses yang berjalan). Setiap proses service berjalan dalam sebuah domain, misalnya httpd_t untuk web server.
  • Type — label pada objek (file, direktori, port, soket). Misalnya httpd_sys_content_t untuk file yang boleh dibaca web server, atau etc_t untuk file konfigurasi di /etc.

Policy SELinux adalah kumpulan aturan yang menentukan pasangan domain → type mana yang boleh berinteraksi, beserta operasi apa saja (baca, tulis, eksekusi, buka port, dan seterusnya). Tanpa aturan eksplisit yang mengizinkan, akses ditolak — ini prinsip default deny yang menjadi kekuatan utama SELinux.

Analogi terbaik: domain adalah kartu akses pegawai, type adalah label pintu ruangan. Web server (httpd_t) boleh masuk ruangan httpd_sys_content_t, tapi tidak boleh masuk ruangan shadow_t yang berisi file password. Meski kartunya dipegang root sekalipun — karena aturan dipegang kebijakan, bukan pemegang kartu.

Security Context: Format Lengkap

Setiap proses dan objek di sistem SELinux membawa label bernama security context dengan format:

Format security context
user:role:type:sensitivity[:category]

Contoh nyata yang sudah sempat kita lihat di episode 1:

text
unconfined_u:object_r:etc_t:s0

Mari bedah satu per satu komponennya:

  • unconfined_u — SELinux user. Bukan user Linux, melainkan user dalam domain policy yang menentukan tingkat kepercayaan. unconfined_u berarti user biasa tanpa batasan khusus.
  • object_r — role. Pada objek, peran hampir selalu object_r; pada proses, role menentukan domain mana yang boleh digunakan.
  • etc_t — type. Ini bagian yang paling sering kalian perhatikan: label objek yang dicocokkan dengan aturan TE.
  • s0 — sensitivity, level keamanan. Untuk policy targeted tanpa MLS, hampir selalu s0. Bagian :category (MCS) ditambahkan jika kalian perlu memisahkan data lebih lanjut, misalnya s0:c0,c1.

Untuk melihat context di sistem nyata, coba ps -eZ untuk proses dan ls -Z untuk file:

Melihat konteks proses dan file
ps -eZ | head -5
ls -Z /etc
Contoh output
LABEL                             PID TTY          TIME CMD
system_u:system_r:init_t:s0         1 ?        00:00:02 systemd
system_u:system_r:sshd_t:s0       980 ?        00:00:00 sshd
 
/etc:
system_u:object_r:etc_t:s0   aliases
system_u:object_r:etc_t:s0   chrony

Perhatikan pola s0 di semua baris dan perbedaan antara role system_r (proses) dan object_r (file). Keterbiasaan membaca format ini akan sangat membantu di episode 3 saat kalian membaca log denial.

Access Vector Cache (AVC)

Menghitung izin berdasarkan ribuan aturan policy setiap kali sebuah proses menyentuh file akan sangat lambat. Di sinilah Access Vector Cache (AVC) berperan: SELinux menyimpan hasil keputusan di dalam cache agar permintaan akses berikutnya bisa dijawab langsung tanpa mengevaluasi policy lagi.

Setiap kali keputusan menghasilkan denied, AVC mencatatnya ke log audit — dan log inilah yang disebut denial AVC, seperti yang sudah kalian lihat di episode 1. Istilah "AVC denied" yang sering kalian jumpai di forum adalah hasil catatan cache ini. Dengan memahami bahwa AVC adalah lapisan performa sekaligus sumber log, kalian akan lebih mudah menavigasi file /var/log/audit/audit.log nanti.

Arsitektur: Kernel LSM + Userspace

SELinux dibangun dari dua dunia yang berjalan bersama.

Kernel: LSM Hook & selinuxfs

Di dalam kernel, SELinux terpasang sebagai Linux Security Module (LSM) — kerangka kerja yang menyediakan hook ke titik-titik pengambilan keputusan akses. Setiap kali ada syscall yang menyentuh objek, hook LSM dipanggil, label dicek terhadap policy, dan hasilnya di-cache di AVC. Antarmuka untuk berkomunikasi dengan kernel tersedia lewat filesystem virtual selinuxfs yang di-mount di /sys/fs/selinux.

Userspace: Tools & Library

Di luar kernel, lapisan userspace menyediakan tools dan library yang akan kalian gunakan setiap hari:

KomponenPeran
policycoreutilsTools inti: restorecon, setsebool, chcon
libselinuxLibrary C untuk interaksi aplikasi dengan SELinux
libsepolCompiler dan parser policy binary
setoolsTools analisis: sesearch, seinfo untuk membaca policy
semanageManajemen konfigurasi runtime: fcontext, port, user, boolean

Alur kerjanya: admin mengubah konfigurasi lewat tools userspace → policy dikompilasi ke format binary oleh libsepol → dimuat ke kernel → hook LSM menegakkannya berdasarkan label dan AVC. Satu sistem besar yang semua lapisannya bisa kita observasi.

Policy: Targeted vs Strict

Policy SELinux hadir dalam beberapa varian, dan dua yang paling sering dibahas adalah:

  • targeted — policy default di RHEL/Fedora/Rocky. Hanya melindungi proses yang ditargetkan (daemon seperti httpd_t, sshd_t, named_t); sisanya berjalan dalam domain unconfined_t yang nyaris tanpa batasan. Pilihan yang paling seimbang antara keamanan dan kenyamanan.
  • strict — seluruh proses dibatasi ketat, tanpa domain unconfined_t. Jauh lebih aman secara teori, tapi sangat berat untuk dioperasikan sehari-hari — karena itu jarang dipakai di produksi.

Varian lain yang perlu kalian kenal namanya saja: minimum (turunan targeted yang lebih kecil) dan mls (menambahkan Multi-Level Security dengan sensitivity bertingkat). Kapan pun kalian melihat SELINUXTYPE=targeted di /etc/selinux/config, itulah policy yang sedang berjalan.

Note

Untuk series ini, semua contoh dan praktik berasumsi policy targeted — default di hampir semua instalasi keluarga Red Hat. Konsep Type Enforcement, context, dan denial yang kalian pelajari berlaku sama di semua varian policy; yang berbeda hanya seberapa banyak proses yang dilindungi.

Penutup

Pada episode 2 ini kita telah membangun bahasa dasar SELinux: Type Enforcement yang membatasi domain (subjek) terhadap type (objek), format security context user:role:type:sensitivity[:category], peran AVC sebagai cache keputusan sekaligus sumber log denial, arsitektur kernel LSM + userspace yang bekerja bersama, hingga perbedaan policy targeted dan strict.

Inti yang harus kalian bawa:

  • Domain adalah label proses; type adalah label objek — keduanya dicocokkan oleh aturan TE.
  • Security context lengkap: user:role:type:sensitivity[:category] — contoh unconfined_u:object_r:etc_t:s0.
  • AVC mempercepat keputusan sekaligus mencatat denial ke log audit.
  • SELinux berjalan sebagai LSM di kernel dengan tools userspace (libselinux, libsepol, setools, semanage) sebagai pengendali.
  • Policy targeted melindungi proses terpilih; strict membatasi semuanya.

Dengan tata bahasa ini di tangan, kalian siap berlatih. Di episode 3 selanjutnya, kita akan membahas mode, status & troubleshooting dasar — perbedaan enforcing, permissive, dan disabled, cara berpindah antar mode dengan aman, membaca getenforce dan sestatus, hingga mendiagnosis denial pertama kalian dari /var/log/audit/audit.log menggunakan ausearch. Pastikan tetap semangat, karena mulai episode ini kalian akan sering berdiri di terminal!