Panduan Keamanan 20 mnt baca

Panduan SELinux dan AppArmor: Hardening Linux dengan MAC di 2026

Panduan praktis mengimplementasikan SELinux dan AppArmor di Linux. Pelajari arsitektur, konfigurasi, troubleshooting, perbandingan mendalam, dan best practices hardening server dengan Mandatory Access Control.

Editorial Team

Pendahuluan: Kenapa Mandatory Access Control Itu Penting Banget untuk Keamanan Linux

Kalau kamu masih mengandalkan model kontrol akses tradisional berbasis Discretionary Access Control (DAC) saja, jujur saja — itu sudah nggak cukup di tahun 2026 ini. DAC memang mekanisme bawaan Linux lewat sistem permission file (read, write, execute), tapi ada kelemahan fundamental yang sering diabaikan: siapa pun yang punya akses ke suatu resource bisa dengan bebas membagikan akses itu ke user lain.

Dan yang lebih kritis lagi? Kalau sebuah proses yang berjalan sebagai root berhasil dieksploitasi penyerang, ya sudah — mereka dapat akses penuh ke seluruh sistem. Game over.

Nah, di sinilah Mandatory Access Control (MAC) masuk sebagai penyelamat. MAC menambahkan lapisan keamanan tambahan yang nggak bisa di-override oleh user biasa — bahkan oleh root sekalipun. Kebijakan keamanan ditentukan oleh administrator dan ditegakkan langsung oleh kernel. Jadi meskipun sebuah aplikasi berhasil di-compromise, dampaknya bisa diisolasi dan diminimalkan.

Linux punya dua implementasi MAC utama yang tersedia sebagai Linux Security Modules (LSM): SELinux (Security-Enhanced Linux) dan AppArmor. Keduanya punya tujuan yang sama — membatasi akses proses terhadap resource sistem — tapi pendekatannya sangat berbeda. Di artikel ini, kita akan bahas kedua sistem ini secara mendalam, lengkap dengan panduan praktis dan tips memilih solusi yang tepat buat lingkungan kamu.

Arsitektur dan Konsep Dasar SELinux

SELinux awalnya dikembangkan oleh National Security Agency (NSA) Amerika Serikat dan kemudian dirilis sebagai proyek open-source. Kalau kamu pakai distribusi keluarga Red Hat — termasuk RHEL, CentOS, Fedora, atau AlmaLinux — SELinux sudah jadi default security module-nya.

Label-Based Access Control

SELinux menggunakan pendekatan label-based access control. Setiap objek dalam sistem — file, direktori, port jaringan, proses — diberikan sebuah security context (atau biasa disebut label) yang terdiri dari empat komponen:

user:role:type:level
# Contoh:
system_u:object_r:httpd_sys_content_t:s0

Komponen-komponennya:

  • User — Identitas SELinux (ini bukan user Linux biasa ya), misalnya system_u, unconfined_u
  • Role — Peran yang menentukan domain apa yang bisa diakses user, misalnya object_r, system_r
  • Type — Ini komponen paling krusial, dipakai dalam Type Enforcement (TE), misalnya httpd_sys_content_t
  • Level — Digunakan untuk Multi-Level Security (MLS) dan Multi-Category Security (MCS), misalnya s0

Type Enforcement: Inti dari SELinux

Mekanisme utama SELinux adalah Type Enforcement. Setiap proses berjalan dalam sebuah domain (tipe untuk proses), dan setiap resource punya type. Policy SELinux kemudian mendefinisikan aturan tentang domain mana yang boleh mengakses type mana, dan dengan operasi apa.

Yang nggak diizinkan secara eksplisit? Otomatis ditolak. Ini yang disebut default deny.

Contohnya gini: proses Apache HTTP Server berjalan dalam domain httpd_t dan cuma diizinkan mengakses file bertipe httpd_sys_content_t. Meskipun penyerang berhasil mengeksploitasi Apache, mereka tetap nggak bisa mengakses file di luar tipe yang diizinkan, seperti /etc/shadow yang punya tipe shadow_t. Cukup keren, kan?

Mode Operasi SELinux

SELinux punya tiga mode operasi:

  • Enforcing — Kebijakan ditegakkan penuh; akses yang melanggar akan ditolak dan dicatat di log
  • Permissive — Kebijakan nggak ditegakkan, tapi pelanggaran tetap dicatat. Mode ini berguna banget untuk debugging dan pengembangan policy
  • Disabled — SELinux dinonaktifkan sepenuhnya (tolong jangan lakukan ini di produksi)

Kamu bisa cek status SELinux dengan perintah berikut:

# Melihat status SELinux saat ini
getenforce

# Melihat detail lengkap
sestatus

# Output contoh:
# SELinux status:                 enabled
# SELinuxfs mount:                /sys/fs/selinux
# SELinux root directory:         /etc/selinux
# Loaded policy name:             targeted
# Current mode:                   enforcing
# Mode from config file:          enforcing
# Policy MLS status:              enabled
# Policy deny_unknown status:     allowed
# Memory protection checking:     actual (secure)
# Max kernel policy version:      33

Konfigurasi Praktis SELinux

Mengatur Mode SELinux

Untuk mengubah mode SELinux secara sementara (nggak bertahan setelah reboot):

# Mengatur ke mode Enforcing
sudo setenforce 1

# Mengatur ke mode Permissive
sudo setenforce 0

Untuk perubahan permanen, edit file konfigurasi /etc/selinux/config:

# /etc/selinux/config
SELINUX=enforcing
SELINUXTYPE=targeted

Mengelola Konteks Keamanan File

Salah satu tugas paling umum (dan paling sering bikin pusing) dalam administrasi SELinux adalah mengelola label file. Ketika file dipindahkan — bukan disalin — ke lokasi baru, label aslinya tetap mengikuti. Ini sering jadi sumber masalah akses yang bikin kita garuk-garuk kepala.

# Melihat konteks keamanan file
ls -Z /var/www/html/
# Output: system_u:object_r:httpd_sys_content_t:s0 index.html

# Mengembalikan konteks file ke default berdasarkan policy
sudo restorecon -Rv /var/www/html/

# Menambahkan aturan konteks file baru secara permanen
sudo semanage fcontext -a -t httpd_sys_content_t "/srv/website(/.*)?"

# Menerapkan aturan konteks yang baru ditambahkan
sudo restorecon -Rv /srv/website/

Mengelola SELinux Booleans

SELinux punya fitur yang namanya booleans — semacam saklar on/off yang memungkinkan kamu menyesuaikan kebijakan tanpa harus menulis policy baru dari nol. Menurut saya, ini cara paling praktis untuk menyesuaikan perilaku SELinux:

# Melihat semua boolean yang tersedia (ada ratusan!)
sudo getsebool -a

# Melihat boolean terkait httpd
sudo getsebool -a | grep httpd

# Mengizinkan Apache mengakses jaringan (misalnya untuk reverse proxy)
sudo setsebool -P httpd_can_network_connect on

# Mengizinkan Apache mengakses direktori home user
sudo setsebool -P httpd_enable_homedirs on

# Mengizinkan Apache mengakses database
sudo setsebool -P httpd_can_network_connect_db on

# Flag -P membuat perubahan persisten (bertahan setelah reboot)

Mengelola Port SELinux

SELinux juga mengontrol port jaringan mana yang boleh digunakan oleh sebuah layanan. Ini detail yang sering terlewat oleh banyak admin:

# Melihat port yang diizinkan untuk HTTP
sudo semanage port -l | grep http_port_t
# Output: http_port_t tcp 80, 81, 443, 488, 8008, 8009, 8443, 9000

# Menambahkan port custom untuk HTTP (misalnya port 8888)
sudo semanage port -a -t http_port_t -p tcp 8888

# Jika port sudah dimiliki oleh tipe lain, gunakan -m (modify)
sudo semanage port -m -t http_port_t -p tcp 8888

Troubleshooting SELinux: Dari Log ke Solusi

Jujur, salah satu tantangan terbesar dalam menggunakan SELinux adalah troubleshooting ketika akses ditolak. Tapi tenang, ada alur kerja sistematis yang bisa kamu ikuti supaya prosesnya nggak terlalu menyakitkan.

Langkah 1: Identifikasi Denial

SELinux mencatat semua denial ke /var/log/audit/audit.log. Pesan denial ditandai dengan tipe AVC (Access Vector Cache):

# Mencari denial terbaru di audit log
sudo ausearch -m avc -ts recent

# Contoh output AVC denial:
# type=AVC msg=audit(1707500000.123:456): avc:  denied  { read }
# for  pid=1234 comm="httpd" name="config.php"
# dev="sda1" ino=789012
# scontext=system_u:system_r:httpd_t:s0
# tcontext=unconfined_u:object_r:user_home_t:s0
# tclass=file permissive=0

Langkah 2: Analisis dengan audit2why

Tool audit2why bakal kasih penjelasan kenapa sebuah akses ditolak dan menyarankan solusi:

# Menganalisis denial terbaru
sudo ausearch -m avc -ts recent | audit2why

# Contoh output:
# Was caused by:
#   Missing type enforcement (TE) allow rule.
#   You can use audit2allow to generate a loadable module to allow this access.

Langkah 3: Periksa Solusi Boolean Dulu

Sebelum bikin policy custom, selalu cek dulu apakah ada boolean yang bisa menyelesaikan masalah. Ini langkah yang sering di-skip tapi seharusnya jadi hal pertama yang dicoba:

# Cari boolean yang mungkin relevan
sudo sesearch --allow --source httpd_t --target user_home_t --class file
sudo getsebool -a | grep httpd

Langkah 4: Cek Masalah Labeling

Seringkali masalahnya bukan pada policy, tapi pada label file yang salah. Dari pengalaman saya, ini penyebab paling umum dari denial SELinux:

# Periksa label file yang bermasalah
ls -Z /path/to/problematic/file

# Jika labelnya salah, perbaiki dengan restorecon
sudo restorecon -Rv /path/to/problematic/file

Langkah 5: Membuat Policy Custom (Pilihan Terakhir)

Kalau nggak ada boolean yang cocok dan labeling sudah benar, barulah buat policy custom pakai audit2allow:

# Generate policy module dari denial log
sudo ausearch -m avc -ts recent | audit2allow -M my_custom_policy

# Output:
# ******************** IMPORTANT ***********************
# To make this policy package active, execute:
# semodule -i my_custom_policy.pp

# Instal policy module
sudo semodule -i my_custom_policy.pp

# Verifikasi bahwa module sudah terpasang
sudo semodule -l | grep my_custom_policy

Peringatan penting: Jangan pakai audit2allow secara membabi buta. Selalu review file .te yang dihasilkan sebelum menginstalnya. Memberikan permission yang terlalu luas malah bisa melemahkan keamanan sistem — dan itu bertolak belakang dengan tujuan kita.

Arsitektur dan Konsep Dasar AppArmor

AppArmor (Application Armor) dikembangkan oleh Immunix Inc. dan sekarang dikelola oleh Canonical. AppArmor jadi default security module di distribusi keluarga Debian/Ubuntu, serta SUSE Linux Enterprise dan openSUSE (walaupun beberapa versi terbaru openSUSE sudah mulai beralih ke SELinux).

Path-Based Access Control

Berbeda dengan SELinux yang pakai label, AppArmor menggunakan pendekatan path-based access control. Profil keamanan AppArmor mendefinisikan file dan direktori mana yang boleh diakses oleh sebuah aplikasi berdasarkan path file-nya. Pendekatan ini punya konsekuensi tersendiri:

  • Kelebihan: Jauh lebih mudah dipahami dan ditulis karena menggunakan path file yang sudah familiar
  • Kelebihan: Nggak butuh sistem labeling yang kompleks
  • Kekurangan: Kalau file dipindahkan atau di-hardlink, profil mungkin nggak mengikutinya dengan benar
  • Kekurangan: Tidak mendukung Multi-Level Security (MLS) dan Multi-Category Security (MCS)

Struktur Profil AppArmor

Profil AppArmor disimpan di /etc/apparmor.d/ dan sintaksnya relatif mudah dibaca — ini salah satu selling point utamanya:

# Contoh profil AppArmor untuk Nginx
# File: /etc/apparmor.d/usr.sbin.nginx

#include <tunables/global>

/usr/sbin/nginx {
  #include <abstractions/base>
  #include <abstractions/nameservice>

  # Akses ke binary dan konfigurasi
  /usr/sbin/nginx mr,
  /etc/nginx/** r,
  /etc/nginx/nginx.conf r,

  # Akses ke file konten web
  /var/www/** r,
  /var/www/html/** r,

  # Akses ke log
  /var/log/nginx/** w,
  /var/log/nginx/access.log w,
  /var/log/nginx/error.log w,

  # Akses ke PID dan socket
  /run/nginx.pid rw,
  /var/lib/nginx/** rw,

  # Kemampuan jaringan
  capability net_bind_service,
  capability setuid,
  capability setgid,
  capability dac_override,

  # Akses network
  network inet stream,
  network inet6 stream,
}

Permission dalam profil AppArmor menggunakan huruf-huruf berikut:

  • r — Read (baca)
  • w — Write (tulis)
  • a — Append (tambahkan ke akhir file)
  • k — Lock (kunci file)
  • l — Link (buat hardlink)
  • m — Memory map executable
  • x — Execute (jalankan)
  • ix — Inherit execute (jalankan dengan profil pemanggil)
  • px — Execute dengan profil terpisah
  • ux — Unconfined execute (jalankan tanpa profil — hati-hati dengan yang satu ini)

Mode Profil AppArmor

Mirip dengan SELinux, AppArmor punya dua mode profil:

  • Enforce — Kebijakan ditegakkan penuh; akses yang melanggar profil akan ditolak dan dicatat
  • Complain — Kebijakan nggak ditegakkan, tapi pelanggaran tetap dicatat. Ini setara dengan mode Permissive di SELinux

Konfigurasi Praktis AppArmor

Memeriksa Status dan Profil AppArmor

# Melihat status AppArmor dan daftar profil
sudo aa-status

# Contoh output:
# apparmor module is loaded.
# 47 profiles are loaded.
# 47 profiles are in enforce mode.
# 0 profiles are in complain mode.
# 4 processes have profiles defined.
# 4 processes are in enforce mode.
# 0 processes are in complain mode.
# 0 processes are unconfined but have a profile defined.

# Melihat profil yang tersedia
ls /etc/apparmor.d/

Mengatur Mode Profil

# Mengatur profil ke mode enforce
sudo aa-enforce /etc/apparmor.d/usr.sbin.nginx
# atau menggunakan nama program
sudo aa-enforce /usr/sbin/nginx

# Mengatur profil ke mode complain (untuk testing)
sudo aa-complain /etc/apparmor.d/usr.sbin.nginx
# atau
sudo aa-complain /usr/sbin/nginx

# Menonaktifkan profil sepenuhnya
sudo aa-disable /etc/apparmor.d/usr.sbin.nginx

# Memuat ulang profil setelah perubahan
sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.nginx

Membuat Profil AppArmor Baru

AppArmor punya tool aa-genprof untuk membuat profil baru secara interaktif. Cara kerjanya: aplikasi dijalankan dalam mode complain, lalu tool ini memantau semua akses yang dilakukan. Cukup intuitif, honestly.

# Langkah 1: Instal paket AppArmor utilities
sudo apt install apparmor-utils

# Langkah 2: Mulai pembuatan profil untuk aplikasi
sudo aa-genprof /usr/bin/myapp

# Tool akan meminta kamu untuk:
# 1. Menjalankan aplikasi di terminal lain
# 2. Menggunakan semua fitur aplikasi
# 3. Kembali ke terminal aa-genprof dan tekan "S" untuk scan
# 4. Menyetujui atau menolak setiap akses yang terdeteksi
# 5. Tekan "F" untuk finish

Alternatifnya, kamu bisa buat profil secara manual dan kemudian sempurnakan pakai aa-logprof:

# Langkah 1: Buat profil kerangka dasar
sudo aa-autodep /usr/bin/myapp

# Langkah 2: Atur profil ke mode complain
sudo aa-complain /usr/bin/myapp

# Langkah 3: Jalankan aplikasi dan gunakan semua fiturnya
# (buka di terminal terpisah)

# Langkah 4: Analisis log dan update profil
sudo aa-logprof

# Langkah 5: Setelah yakin profil sudah benar, enforce
sudo aa-enforce /usr/bin/myapp

Contoh Profil AppArmor untuk Database

Berikut contoh profil AppArmor yang lebih kompleks untuk membatasi akses PostgreSQL. Perhatikan bagaimana kita secara eksplisit deny akses ke file-file sensitif di bagian bawah:

# /etc/apparmor.d/usr.lib.postgresql.bin.postgres

#include <tunables/global>

/usr/lib/postgresql/*/bin/postgres {
  #include <abstractions/base>
  #include <abstractions/nameservice>
  #include <abstractions/ssl_certs>

  # Binary PostgreSQL
  /usr/lib/postgresql/*/bin/* mr,
  /usr/share/postgresql/** r,

  # Konfigurasi
  /etc/postgresql/** r,

  # Data directory
  /var/lib/postgresql/** rwk,

  # Log files
  /var/log/postgresql/** w,

  # Runtime files
  /run/postgresql/** rw,

  # Shared memory dan temporary files
  /dev/shm/** rw,
  /tmp/** rw,

  # Capabilities yang diperlukan
  capability dac_override,
  capability setuid,
  capability setgid,
  capability fowner,
  capability chown,

  # Network
  network inet stream,
  network inet6 stream,
  network unix stream,

  # Deny akses ke file sensitif
  deny /etc/shadow r,
  deny /etc/gshadow r,
  deny /root/** rwx,
  deny /home/*/.ssh/** rwx,
}

Troubleshooting AppArmor

Menganalisis Log Denial

AppArmor mencatat denial ke syslog (/var/log/syslog) atau journal systemd. Cari kata kunci DENIED — gampang kok:

# Mencari denial di syslog
sudo grep "DENIED" /var/log/syslog | tail -20

# Atau menggunakan journalctl
sudo journalctl -k | grep "DENIED"

# Contoh output:
# audit: type=1400 audit(1707500000.123:456):
# apparmor="DENIED" operation="open"
# profile="/usr/sbin/nginx"
# name="/etc/ssl/private/server.key"
# pid=1234 comm="nginx"
# requested_mask="r" denied_mask="r"
# fsuid=33 ouid=0

Menggunakan aa-logprof untuk Memperbaiki Profil

# Analisis log denial dan update profil secara interaktif
sudo aa-logprof

# Tool akan menampilkan setiap denial dan menawarkan opsi:
# (A)llow - Izinkan akses ini
# (D)eny  - Tolak akses ini secara eksplisit
# (I)gnore - Abaikan untuk saat ini
# (G)lob  - Izinkan dengan wildcard path
# (N)ew   - Buat aturan abstraction baru

SELinux vs AppArmor: Mana yang Harus Kamu Pilih?

Ini pertanyaan yang selalu muncul. Jawabannya bergantung pada beberapa faktor, dan honestly, nggak ada jawaban yang universally benar. Tapi mari kita breakdown perbandingannya.

Granularitas Kontrol Akses

SELinux jelas unggul soal granularitas. Dengan sistem label dan Type Enforcement, SELinux bisa mengontrol akses di level yang sangat detail — termasuk kontrol terhadap soket jaringan, IPC (Inter-Process Communication), dan bahkan transisi domain antar-proses. SELinux juga mendukung Multi-Level Security (MLS) yang diperlukan untuk lingkungan dengan klasifikasi data bertingkat, kayak lingkungan militer atau pemerintahan.

AppArmor menyediakan kontrol akses yang memadai untuk kebanyakan use case, tapi nggak punya kemampuan MLS dan MCS. Kalau organisasi kamu butuh compliance dengan standar keamanan tingkat tinggi seperti Common Criteria, SELinux biasanya jadi pilihan yang lebih tepat.

Kemudahan Penggunaan

Di sini AppArmor menang telak. Learning curve-nya jauh lebih rendah dibanding SELinux. Profil AppArmor ditulis dalam format intuitif pakai path file, dan tool seperti aa-genprof memudahkan pembuatan profil baru.

SELinux? Well, reputasinya bicara sendiri. Banyak admin yang lebih memilih menjalankan setenforce 0 daripada belajar mengelolanya. Ini praktik yang sangat buruk, tapi bisa dipahami kenapa banyak yang tergoda — SELinux memang bisa bikin frustrasi di awal.

Performa

AppArmor umumnya punya dampak performa yang lebih rendah dibanding SELinux karena pendekatan path-based-nya yang lebih sederhana. SELinux butuh pemrosesan label untuk setiap operasi file, yang memang menambah sedikit overhead. Tapi jujur, di server modern perbedaan performanya biasanya nggak terasa signifikan.

Distribusi Default

  • SELinux default: RHEL, CentOS, Fedora, AlmaLinux, Rocky Linux, Amazon Linux
  • AppArmor default: Ubuntu, Debian, SUSE Linux Enterprise, openSUSE (versi lama)
  • Catatan: openSUSE versi terbaru sudah mulai beralih ke SELinux sebagai default

Rekomendasi Berdasarkan Skenario

Pilih SELinux kalau:

  • Kamu pakai distribusi keluarga Red Hat
  • Lingkungan kamu butuh MLS/MCS
  • Kamu perlu kontrol akses yang sangat granular
  • Compliance dengan standar seperti DISA STIG, PCI-DSS, atau HIPAA jadi prioritas
  • Kamu menjalankan container (SELinux kasih isolasi container yang lebih kuat)

Pilih AppArmor kalau:

  • Kamu pakai distribusi keluarga Debian/Ubuntu
  • Tim kamu punya pengalaman terbatas dengan MAC
  • Kamu butuh implementasi yang cepat dan mudah dikelola
  • Kebutuhan keamanan nggak memerlukan MLS/MCS
  • Kamu mau dampak performa yang minimal

Hardening Web Server dengan SELinux: Studi Kasus Praktis

So, mari kita langsung ke praktik. Berikut langkah-langkah hardening web server menggunakan SELinux di sistem RHEL/CentOS:

#!/bin/bash
# Script hardening SELinux untuk web server
# Pastikan SELinux dalam mode Enforcing

# 1. Verifikasi SELinux aktif dan enforcing
if [ "$(getenforce)" != "Enforcing" ]; then
    echo "PERINGATAN: SELinux tidak dalam mode Enforcing!"
    echo "Mengaktifkan mode Enforcing..."
    sudo setenforce 1
fi

# 2. Pastikan konteks file benar untuk document root
sudo semanage fcontext -a -t httpd_sys_content_t "/var/www/html(/.*)?"
sudo semanage fcontext -a -t httpd_sys_rw_content_t "/var/www/html/uploads(/.*)?"
sudo restorecon -Rv /var/www/html/

# 3. Konfigurasi boolean yang diperlukan
# Izinkan httpd mengirim email (jika diperlukan)
sudo setsebool -P httpd_can_sendmail on

# Izinkan httpd koneksi ke database
sudo setsebool -P httpd_can_network_connect_db on

# JANGAN izinkan httpd akses jaringan umum (kecuali benar-benar perlu)
sudo setsebool -P httpd_can_network_connect off

# Nonaktifkan eksekusi CGI jika tidak digunakan
sudo setsebool -P httpd_enable_cgi off

# 4. Konfigurasi port custom jika diperlukan
sudo semanage port -a -t http_port_t -p tcp 8443

# 5. Verifikasi konfigurasi
echo "=== Status SELinux ==="
sestatus
echo ""
echo "=== Boolean httpd ==="
getsebool -a | grep httpd
echo ""
echo "=== File Contexts ==="
sudo semanage fcontext -l | grep "/var/www"

Hardening Application Server dengan AppArmor: Studi Kasus Node.js

Sekarang giliran AppArmor. Berikut langkah-langkah hardening application server Node.js di Ubuntu:

# Langkah 1: Buat profil AppArmor untuk aplikasi Node.js
sudo tee /etc/apparmor.d/opt.myapp.server > /dev/null << 'PROFILE'
#include <tunables/global>

profile myapp /opt/myapp/server {
  #include <abstractions/base>
  #include <abstractions/nameservice>

  # Binary Node.js
  /usr/bin/node ix,
  /usr/local/bin/node ix,

  # Aplikasi files (read-only)
  /opt/myapp/** r,
  /opt/myapp/node_modules/** r,

  # Data directory (read-write)
  /opt/myapp/data/** rw,

  # Log files
  /var/log/myapp/** w,
  /var/log/myapp/ r,

  # Temporary files
  /tmp/myapp-* rw,

  # Network access
  network inet stream,
  network inet6 stream,

  # Capabilities minimal
  capability net_bind_service,

  # Deny akses ke file sensitif sistem
  deny /etc/shadow r,
  deny /etc/gshadow r,
  deny /root/** rwx,
  deny /home/** rwx,
  deny /proc/*/mem r,
  deny /sys/firmware/** r,

  # Deny akses ke tool yang berpotensi berbahaya
  deny /usr/bin/gcc x,
  deny /usr/bin/cc x,
  deny /usr/bin/curl x,
  deny /usr/bin/wget x,
  deny /usr/bin/nc x,
  deny /usr/bin/ncat x,
  deny /usr/sbin/iptables x,
}
'PROFILE'

# Langkah 2: Load profil dalam mode complain untuk testing
sudo apparmor_parser -r /etc/apparmor.d/opt.myapp.server
sudo aa-complain /opt/myapp/server

# Langkah 3: Jalankan aplikasi dan test semua fitur
# (monitoring log untuk denial)
sudo journalctl -f -k | grep myapp &

# Langkah 4: Setelah testing selesai, enforce profil
sudo aa-enforce /opt/myapp/server

# Langkah 5: Verifikasi
sudo aa-status | grep myapp

Integrasi MAC dengan Keamanan Container

Baik SELinux maupun AppArmor punya peran penting dalam keamanan container. Ini area yang makin relevan seiring meningkatnya adopsi containerization.

SELinux dan Container

SELinux secara otomatis memberikan label berbeda pada setiap container saat dijalankan di platform seperti Podman atau Docker pada sistem RHEL/Fedora. Fitur ini memanfaatkan Multi-Category Security (MCS) untuk memastikan satu container nggak bisa mengakses resource container lain:

# Menjalankan container dengan SELinux enforcement
podman run --security-opt label=type:container_t myimage

# Melihat label SELinux pada proses container
ps -eZ | grep container

# Mount volume dengan label SELinux yang benar
# :z = shared label (multi-container)
# :Z = private label (single container)
podman run -v /data:/app/data:Z myimage

# Membuat policy SELinux custom untuk container
sudo udica -j container_inspect.json my_container_policy

AppArmor dan Container

Docker di Ubuntu menggunakan profil AppArmor default (docker-default) untuk setiap container. Kamu juga bisa bikin profil custom kalau perlu:

# Melihat profil AppArmor default Docker
sudo cat /etc/apparmor.d/containers/docker-default

# Menjalankan container dengan profil custom
docker run --security-opt apparmor=my-custom-profile myimage

# Menjalankan container tanpa profil AppArmor (TIDAK DISARANKAN!)
docker run --security-opt apparmor=unconfined myimage

Best Practices dan Checklist Hardening MAC

Setelah membahas teori dan praktik, berikut checklist yang bisa kamu pakai untuk memastikan implementasi MAC yang solid di lingkungan produksi.

Checklist Umum

  1. Jangan pernah menonaktifkan MAC. Kalau ada masalah, pakai mode Permissive/Complain untuk debugging — bukan matikan sepenuhnya
  2. Mulai dengan mode Permissive/Complain saat menerapkan profil baru, baru beralih ke Enforce setelah testing menyeluruh
  3. Monitor log secara teratur. Gunakan ausearch (SELinux) atau aa-logprof (AppArmor) untuk identifikasi dan selesaikan denial
  4. Terapkan prinsip least privilege. Kasih cuma permission minimum yang diperlukan aplikasi
  5. Dokumentasikan setiap perubahan policy. Boolean, konteks file, profil — semua harus terdokumentasi
  6. Integrasikan dengan CI/CD. Validasi profil MAC sebagai bagian dari pipeline deployment
  7. Audit berkala. Periksa apakah ada profil yang masih dalam mode Complain/Permissive di produksi

Checklist Khusus SELinux

  1. Pastikan SELINUX=enforcing di /etc/selinux/config
  2. Selalu pakai flag -P dengan setsebool supaya perubahan persisten
  3. Jalankan restorecon setelah memindahkan file atau mengubah konfigurasi
  4. Gunakan semanage untuk mengelola konteks file dan port secara permanen
  5. Hindari audit2allow secara sembarangan — selalu review policy yang dihasilkan
  6. Pasang setroubleshoot-server untuk analisis denial yang lebih mudah dipahami

Checklist Khusus AppArmor

  1. Pastikan semua layanan yang terekspos ke jaringan punya profil AppArmor dalam mode Enforce
  2. Pakai aa-genprof atau aa-autodep untuk profil awal, lalu sempurnakan
  3. Gunakan aturan deny secara eksplisit untuk file sensitif seperti /etc/shadow
  4. Manfaatkan abstraction (#include <abstractions/...>) untuk reusability profil
  5. Test profil menyeluruh di staging sebelum deploy ke produksi
  6. Cek rutin apakah ada profil yang nggak loaded atau dalam mode unconfined

Monitoring dan Automasi MAC di Pipeline DevSecOps

Buat kamu yang menerapkan DevSecOps, integrasi MAC ke pipeline CI/CD itu esensial. Berikut contoh script monitoring yang bisa dijalankan otomatis (sebagai cron job atau bagian dari monitoring stack):

#!/bin/bash
# Script monitoring status MAC untuk pipeline CI/CD

ALERT_EMAIL="[email protected]"
HOSTNAME=$(hostname)
TIMESTAMP=$(date -u +"%Y-%m-%dT%H:%M:%SZ")

# Deteksi MAC yang digunakan
if command -v getenforce >/dev/null 2>&1; then
    MAC_TYPE="SELinux"
    MAC_STATUS=$(getenforce)
    DENIAL_COUNT=$(ausearch -m avc -ts today 2>/dev/null | grep -c "denied" || echo 0)

    if [ "$MAC_STATUS" != "Enforcing" ]; then
        echo "[$TIMESTAMP] ALERT: SELinux tidak dalam mode Enforcing pada $HOSTNAME (Status: $MAC_STATUS)"
    fi

elif command -v aa-status >/dev/null 2>&1; then
    MAC_TYPE="AppArmor"
    ENFORCE_COUNT=$(aa-status 2>/dev/null | grep "profiles are in enforce" | awk '{print $1}')
    COMPLAIN_COUNT=$(aa-status 2>/dev/null | grep "profiles are in complain" | awk '{print $1}')
    DENIAL_COUNT=$(grep -c "DENIED" /var/log/syslog 2>/dev/null || echo 0)

    if [ "$COMPLAIN_COUNT" -gt 0 ]; then
        echo "[$TIMESTAMP] PERINGATAN: $COMPLAIN_COUNT profil AppArmor dalam mode Complain pada $HOSTNAME"
    fi
else
    echo "[$TIMESTAMP] KRITIS: Tidak ada MAC (SELinux/AppArmor) yang terdeteksi pada $HOSTNAME"
fi

# Laporan denial
if [ "$DENIAL_COUNT" -gt 0 ]; then
    echo "[$TIMESTAMP] INFO: $DENIAL_COUNT denial $MAC_TYPE terdeteksi hari ini pada $HOSTNAME"
fi

echo "[$TIMESTAMP] $MAC_TYPE monitoring selesai pada $HOSTNAME"

Kesimpulan

Mandatory Access Control bukan lagi fitur opsional di tahun 2026 ini — ini kebutuhan fundamental dalam strategi keamanan Linux. Baik SELinux maupun AppArmor menyediakan lapisan pertahanan yang sangat berharga, melindungi sistem kamu bahkan saat mekanisme keamanan lain gagal.

Kunci suksesnya ada di pendekatan bertahap: mulai dengan memahami konsep dasar, aktifkan dalam mode Permissive/Complain untuk mempelajari pola akses aplikasi, dan baru terapkan Enforce setelah profil keamanan sudah divalidasi. Jangan ambil jalan pintas dengan menonaktifkan MAC — investasikan waktu untuk memahami dan mengelolanya dengan benar. Trust me, itu worth it.

Dengan panduan yang sudah kita bahas di artikel ini, kamu sekarang punya bekal yang cukup untuk mengimplementasikan dan mengelola SELinux maupun AppArmor di lingkungan produksi. Mulailah dengan distribusi yang kamu pakai — SELinux untuk Red Hat family, AppArmor untuk Debian/Ubuntu — dan tingkatkan secara bertahap sesuai kebutuhan keamanan organisasi kamu.

Tentang Penulis Editorial Team

Our team of expert writers and editors.

Artikel Terkait