SELinux vs AppArmor: Usporedba Linux MAC sustava u 2026.
SELinux vs AppArmor u 2026.: kada birati koji Linux MAC sustav, kako pišete profile i politike, što donose Landlock i BPF LSM, i kako sigurno pokrenuti kontejnere s Podmanom ili Dockerom u produkciji.
SELinux i AppArmor su dva glavna Linux Security Module (LSM) sustava za obveznu kontrolu pristupa (Mandatory Access Control, MAC). SELinux koristi model temeljen na oznakama (labels) i sustavu tipova te je zadan na RHEL-u, Fedori i Rocky Linuxu, dok AppArmor koristi profile temeljene na stazama datoteka i zadan je na Ubuntuu, SUSE-u i Debianu. U kernelu 6.19 SELinux pokriva 217 LSM hookova naspram AppArmorovih 80, ali AppArmor je jednostavniji za autoriranje politika i ima manji režijski trošak. Odabir između SELinuxa i AppArmora u 2026. gotovo uvijek se svodi na to koju distribuciju već koristite i koliko dubine u modeliranju povjerenja stvarno trebate.
SELinux i AppArmor su međusobno isključivi primarni LSM-ovi. U praksi se bira onaj koji distribucija podržava po defaultu.
SELinux nudi Multi-Level Security (MLS) i Multi-Category Security (MCS); AppArmor ne implementira niti jedno.
AppArmor politike su path-based i ranjive na napade preko hardlinkova i bind mountova, dok su SELinuxove label-based i otporne na tu klasu obilaznica.
Landlock (uveden u kernel 5.13) i BPF LSM (kernel 5.7) su komplementarni slojevi. Ne zamjenjuju primarni MAC, već proširuju sandboxing na razini procesa.
Za kontejnerske radne opterećenja Podman i CRI-O na RHEL-u koriste SELinux MCS oznake (u obliku system_u:system_r:container_t:s0:c123,c456) za izolaciju; Docker na Ubuntuu koristi AppArmor profile.
Ako gradite novu politiku od nule, izbjegavajte pokretati oba LSM-a paralelno, jer otklanjanje uskraćenja tada postaje kombinatorno neriješivo.
Što je SELinux, a što AppArmor?
SELinux (Security-Enhanced Linux) je Linux Security Module koji je NSA doprinio jezgri još u seriji 2.6 (mainline od kernela 2.6.0, prosinac 2003.). Implementira Type Enforcement (TE), Role-Based Access Control (RBAC), Multi-Level Security (MLS) po Bell-LaPadula modelu i Multi-Category Security (MCS). Svaki proces, datoteka, socket i IPC objekt na sustavu s aktivnim SELinuxom nosi security context (najčešće user:role:type:sensitivity), a politika opisuje koje kombinacije tipova smiju međusobno komunicirati kojim operacijama.
AppArmor je izvorno dio Immunix distribucije, prošao kroz SUSE i Canonical, a mainline mu je stigao u kernelu 2.6.36 (listopad 2010.). Za razliku od SELinuxa, AppArmor ne oslikava kontekst na inode oznake nego se veže uz staze datoteka. Politika (koja se u AppArmoru zove profil) opisuje što jedan konkretni program smije čitati, pisati, izvršavati i preko koje socket obitelji smije komunicirati. Kada jezgra pokrene binarni izvršni objekt čije ime odgovara zaglavlju profila (npr. /usr/sbin/nginx), taj proces postaje zatvoren (confined) tim profilom sve do exec()-a.
Ono što oba dijele je da se ubacuju preko LSM (Linux Security Modules) frameworka, arhitekture hookova u jezgri koju je Chris Wright integrirao u seriju 2.5. Svaki poziv sustava koji dotakne resurs prolazi kroz LSM hook koji aktivni MAC modul može odbiti čak i kada bi klasična DAC (discretionary access control, tj. Unix permissions) dopustila operaciju. To znači da MAC vrijedi i za root-a, što je razlog zašto se SELinux ili AppArmor smatraju obveznim slojem u svakom ozbiljnom otvrdnjivanju Linux sustava, uključujući ono koje sam opisala u vodiču OpenSSH Hardening na Linuxu 2026.
SELinux vs AppArmor: usporedna tablica značajki
Prije nego se bacimo na pojedine dimenzije, ovdje je sažetak koji svakodnevno koristim kada me netko pita "koji da biram". Tablica se odnosi na stanje u jezgri 6.19 (LTS grana iz svibnja 2026.).
Značajka
SELinux
AppArmor
Model politike
Oznake (labels) i tipovi
Staze datoteka (profili)
Mainline od
Kernel 2.6.0 (2003.)
Kernel 2.6.36 (2010.)
LSM hookova (6.19)
217
80
MLS / MCS
Da (oba)
Ne
Overhead (macro benchmark)
3–7 %
1–3 %
Krivulja učenja
Strma
Blaga
Zadano na
RHEL, Fedora, Rocky, AlmaLinux
Ubuntu, Debian, SUSE, openSUSE
Kontejnerska integracija
Podman, CRI-O, Docker (RHEL)
Docker, LXC, snap (Ubuntu)
Otpornost na hardlink bypass
Da (oznake putuju s inodeom)
Ne bez dodatnih mjera
Alati za autoring
audit2allow, semodule, sepolicy
aa-genprof, aa-logprof, aa-complain
Ključne razlike u modelu politike
Najveća razlika između SELinuxa i AppArmora nije u alatima nego u perspektivi. SELinux gleda sustav objektno-centrično: svaki resurs ima persistent oznaku koja se čuva u xattr-u datotečnog sustava (security.selinux), a politika je globalni graf dopuštenja koji definira interakcije između tipova. Kada premjestim /etc/nginx/nginx.conf na drugu particiju, oznaka httpd_config_t ide s inodeom.
AppArmor gleda sustav aplikacijski-centrično: politika ne postoji za resurse nego za binaryje. Kada napišem profil za /usr/sbin/nginx, taj profil opisuje čime nginx smije baratati na razini staza. Ako netko premjesti /etc/nginx/nginx.conf preko bind mounta na drugu lokaciju, profil koji dopušta samo /etc/nginx/** ne pokriva novu stazu. To ide u oba smjera i može stvoriti footgun s hardlinkovima ako profil nije eksplicitno zabranio l pravilo.
U praksi to znači: SELinux je bolji u okruženjima gdje treba modelirati povjerenje između mnogih klasa objekata (multi-tenant serveri, high-assurance workloadi, sustavi za obradu klasificiranih podataka). AppArmor je bolji tamo gdje želim brzo zatvoriti jednu problematičnu aplikaciju bez utjecaja na ostatak sustava. Kada pišem BPF LSM programe koji dopunjuju MAC (kroz KRSI, kernel 5.7+), oslanjam se na iste hookove koji napajaju SELinuxove i AppArmorove odluke. Više detalja o toj arhitekturi pokrila sam u članku eBPF kao moderna sigurnosna platforma za Linux.
Performanse, LSM hookovi i overhead
Zhang et al. (SP 2021, mjereno na 5.10-ish kernelu, ali brojke se u međuvremenu nisu bitno promijenile) i noviji phoronix-test-suite benchmarci na jezgri 6.11 i 6.19 ponavljaju isti nalaz: mediation overhead za oba LSM-a je pod 5 % u makro benchmarcima, a jasno je vidljiv tek u sintetičkim mikro-testovima poput openssl speed, pgbench ili fio s ekstremno malim I/O jedinicama.
Trenutačno u jezgri 6.19 SELinux implementira 217 LSM hookova, dok AppArmor pokriva 80. Razlika ne znači automatski "SELinux je 2,7 puta skuplji". Većina hookova okida rijetko (npr. ptrace_access_check, bpf_prog_alloc_security). Ono što se stvarno mjeri je koliko puta AVC (Access Vector Cache kod SELinuxa) i profile matcher (kod AppArmora) donese odluku po sekundi.
Iskreno, iz mog iskustva na produkcijskim RHEL 9.6 sustavima s enforcing SELinuxom i tipičnim web/app workloadom, overhead je unutar margine šuma NUMA rasporeda. Na Ubuntuu 24.04 LTS s aktivnim AppArmorom brojke su blago bolje, oko 1–2 % u throughput testovima, ali razlika je toliko mala da mi nikada nije bila argument u izboru MAC-a. Argument je uvijek bio tko će održavati politiku.
Je li AppArmor jednostavniji od SELinuxa?
Da, i to nije diskutabilno. Osnovni AppArmor profil za jednostavan servis stane u dvadesetak redaka i piše se u sintaksi bliskoj shell globovima:
Ekvivalentna SELinux politika zahtijeva definirati novi tip (metrics_agent_exec_t, metrics_agent_t), tranziciju procesa (type_transition), pristupe (allow pravila po klasi objekata) i najčešće File Context (fc) pravila kako bi restorecon postavio oznake. Cijeli modul zna imati stotinjak redaka, a u praksi se najviše piše kroz audit2allow -a -M mymod i iterativno.
Za operativce koji ne žele učiti Reference Policy jezik, reference policy distribucija RHEL-a je uglavnom dovoljna. 95 % politike koju treba trebaju ionako pokriva container-selinux, selinux-policy-targeted i modularni policy paketi. AppArmor pak zahtijeva ručno pisanje profila za svaki custom servis, ali svaki od tih profila je čitljiv bilo kojem sysadminu s dvije minute uvoda.
Koji je sigurniji, SELinux ili AppArmor?
Na papiru SELinux nudi jaču garanciju: 217 LSM hookova protiv 80, oznake koje se ne mogu obići preko bind mountova ili hardlinkova, MLS/MCS za obradu klasificiranih podataka, i mnogo veći aktivni ekosustav sigurnosnih revizija (SELinux je predmet formalnih verifikacija još od NSA doprinosa). AppArmor je namjerno napravljen tako da bude čitljiv, a čitljivost nosi svoju cijenu u strogosti.
U praksi razlike nisu toliko dramatične. Nekoliko CVE-ova iz posljednjih godina, primjerice CVE-2023-1998 (AppArmor policy bypass kroz mount namespace), CVE-2022-0185 (namespace confusion koji je omogućavao MAC obilazak) i CVE-2024-1086 (nftables use-after-free s eskalacijom preko user namespaceova), pogađali su oba LSM-a jednako, jer je root cause bio dublje u jezgri. Ono što doista mijenja odnos snaga je nedostatak pisanog profila. AppArmor u enforce modu ali bez profila za sshd, docker i nginx pruža manje zaštite od SELinuxa u targeted modu koji dolazi sa RHEL-om iz kutije.
Moj heuristik: SELinux u targeted enforcing modu, s netaknutim distribucijskim politikama, otvrdnjuje sustav više nego AppArmor bez custom profila. Ali AppArmor s pomno pisanim profilima za sve mrežno izložene daemone jednako je otporan na tipične remote-code-execution scenarije. Kompromisi pucaju samo kada napadač već ima lokalni pristup.
Mogu li istovremeno koristiti SELinux i AppArmor?
Tehnički, od kernela 5.1 LSM framework podržava stacking, tako da više modula može biti aktivno paralelno. Praktički, SELinux i AppArmor su oba označeni kao major exclusive LSM-ovi i međusobno se isključuju za većinu odluka. Na svakom bootu jezgra bira jedan kao primarni i drugi ostaje neaktivan.
Čak i kada biste ih uspjeli oba aktivirati (potrebna je CONFIG_LSM lista koja uključuje oba i prekid s distribucijskim defaultima), rezultat je operativni košmar. Kada aplikacija dobije EACCES, morate provjeriti audit log oba sustava, znati oba jezika politike i razumjeti kombinatoriku dviju MAC odluka. Debug jednog denial-a lako naraste na sat vremena. Isprobala sam to jednom u laboratoriju i vratila se natrag u istoj sesiji.
Preporuka: koristite ono što distribucija zadano nudi. Ako se selite između RHEL-a i Ubuntua, prihvatite da ćete voditi dvije skupine politika, ali ni na jednom sustavu ne miješajte. Landlock i BPF LSM su druga priča i o njima niže.
MAC za kontejnere: Podman, Docker i Kubernetes
Ako pokrećete kontejnere u produkciji, MAC nije opcionalan sloj. On je razlika između "kompromitirani kontejner ostaje u svojoj mrežnoj i storage domeni" i "kompromitirani kontejner dohvaća druge kontejnere na istom hostu". Detaljnije sam to razlagala u vodiču Sigurnost Linux kontejnera.
Na SELinux distribucijama (RHEL 9, Fedora 41+, Rocky 9), Podman i CRI-O automatski dodjeljuju MCS oznake. Svaki kontejner dobiva par kategorija (npr. s0:c123,c456) tako da procesi jednog kontejnera ne mogu čitati/pisati u kontekst drugog kontejnera, čak i kada bi Unix permissions to dopuštale. Sve to bez ijedne konfiguracije osim aktivnog SELinuxa.
# Provjera SELinux konteksta pokrenutog Podman kontejnera
ps -eZ | grep container_t
system_u:system_r:container_t:s0:c123,c456 12345 pts/0 00:00:01 nginx
# Ručno labeliranje volumena za sharing između hosta i kontejnera
podman run -d \
--name web \
-v /srv/web-content:/usr/share/nginx/html:Z \
nginx:1.27-alpine
Sufiks :Z govori Podmanu da relabelira volumen s per-container MCS oznakom (isključivi pristup); :z koristi dijeljenu oznaku za više kontejnera. Bez toga volumen se montira s originalnim unlabeled_t ili host-file oznakom i kontejner neće imati pristup. Prvi put kad sam to zaboravila u produkciji, pola sata sam tražila zašto nginx vraća 403 na potpuno ispravan HTML.
Na Ubuntuu Docker koristi generički AppArmor profil docker-default (učitan iz /etc/apparmor.d/docker) koji ograničava kontejnere na sigurnu bazu, ali ne pruža izolaciju između kontejnera. Za per-container profile potrebno je pisati custom AppArmor profile i pokretati kontejner s --security-opt apparmor=my-profile. Kubernetes to podržava kroz container.apparmor.security.beta.kubernetes.io/<container> anotaciju, a od 1.30 kroz stabilan appArmorProfile field u PodSpec-u.
Landlock i BPF LSM: novi slojevi u LSM stogu
Suvremeni Linux više nije "SELinux ili AppArmor". LSM stog na Ubuntuu 24.04 s kernelom 6.11 tipično čita: lockdown, capability, landlock, yama, bpf, apparmor. Na RHEL-u 9.6 s kernelom 5.14 (backportane značajke): capability, lockdown, yama, integrity, selinux, bpf. Svaki od tih dodataka rješava problem koji SELinux/AppArmor ne pokrivaju elegantno.
Landlock (mainline od kernela 5.13, srpanj 2021., zreo od 6.7) je jedini LSM koji dopušta neprivilegiranom procesu da sam sebi (i svojoj djeci) nametne restrikcije. Aplikacija poziva niz syscallova landlock_create_ruleset(), landlock_add_rule() i landlock_restrict_self(). Nakon toga proces gubi mogućnost da napusti definirani skup dopuštenja, čak i ako je root. Za CLI alate koji obrađuju nepovjerljive fajlove (parseri, transkoderi), Landlock je jednostavniji i portabilniji od cijele SELinux/AppArmor kabaže.
BPF LSM (KRSI, Kernel Runtime Security Instrumentation), dostupan od kernela 5.7 (svibanj 2020.), omogućuje da napišete LSM hook u eBPF-u i učitate ga u letu, bez ponovnog kompiliranja jezgre. Falco, Tetragon i drugi runtime security alati oslanjaju se na BPF LSM za detekciju anomalija. On ne zamjenjuje primarni MAC. Može samo dodatno odbiti pristup koji je SELinux/AppArmor već dopustio.
Praktični primjeri: pisanje i debug pravila
SELinux: audit2allow workflow
Kada aplikacija radi u SELinux enforcing modu i dobije neočekivani EACCES, prva stvar je pogledati /var/log/audit/audit.log ili ausearch -m AVC -ts recent. Denial će izgledati ovako:
# 1) Privremeno prebaci u permissive samo taj domain (ne cijeli sustav!)
semanage permissive -a metrics_agent_t
# 2) Prošeći aplikaciju kroz stvarne scenarije
# 3) Iz audit loga generiraj kandidat pravila
ausearch -m AVC -c metrics-agent | audit2allow -M metrics_agent_local
# 4) Pregledaj generirani .te fajl PRIJE učitavanja
cat metrics_agent_local.te
# 5) Učitaj i vrati enforcing
semodule -i metrics_agent_local.pp
semanage permissive -d metrics_agent_t
AppArmor: aa-genprof i complain workflow
AppArmor workflow je konceptualno jednostavniji jer alat vodi kroz interaktivnu sesiju:
# Instaliraj apparmor-utils ako već nisu
sudo apt install -y apparmor-utils
# Pokreni generator profila (druga sesija: pokreni aplikaciju kroz stvarni scenarij)
sudo aa-genprof /usr/local/bin/metrics-agent
# aa-genprof će pitati o svakom accessu koji nije u profilu.
# Odaberite (A)llow, (D)eny, (I)nherit ili (G)lob za wildcard staze.
# Ručno prebaci profil u complain mod (loguje umjesto blokiranja)
sudo aa-complain /usr/local/bin/metrics-agent
# Nakon perioda praćenja, koristi aa-logprof za apsorbiranje novih događaja
sudo aa-logprof
# Kada je profil stabilan, vrati u enforce
sudo aa-enforce /usr/local/bin/metrics-agent
# Provjera statusa
sudo aa-status | grep metrics-agent
Preporuke za produkciju u 2026.
Nakon što sam u posljednjih par godina otvrdnjivala i RHEL i Ubuntu flotu, evo pravila koja slijedim:
Uvijek koristite distribucijski default. Migracija s SELinuxa na AppArmor ili obrnuto na već postavljenom sustavu ne isplati se. Svaka minuta ide u ponovno pisanje politika koje distribucija održava besplatno.
Ne pokrećite produkciju u permissive / complain modu. Log-only mod je dijagnostika, ne konfiguracija. Ako "nemate vremena riješiti denialse", nemate ni sigurnost.
Kontejneri su gdje MAC daje najveći ROI. Podman + SELinux MCS ili Docker + per-app AppArmor profili. U oba slučaja izolacija kontejner-od-kontejnera vrijedi vjerojatno više nego bilo koja druga jedinica truda koju uložite u OS hardening.
Slojevi. Landlock za user-space alate koji parseraju nepovjerljive ulaze, BPF LSM za runtime detekciju, primarni MAC za sve ostalo. Kompozicija je jače od bilo kojeg pojedinog sloja.
Redovito auditajte kontekste. Na SELinux sustavima restorecon -Rnv / jednom mjesečno; na AppArmoru aa-status i grep /var/log/kern.log za DENIED zapise. Neispravno labelirani fajl ili nedostajući profil je češći uzrok incidenta od zero-day CVE-a.
Ubuntu koristi AppArmor po defaultu od verzije 7.10 (2007.). SELinux se može instalirati kao paket, ali nije podržan način rada i ne preporučuje se za produkciju. Canonical održava AppArmor profile za sve glavne servise (nginx, MySQL, snapd) izvan kutije.
Trebam li isključiti SELinux ako aplikacija ne radi?
Ne. Isključivanje SELinuxa (setenforce 0 ili SELINUX=disabled) uklanja cijeli sloj obrane i najčešće se koristi kao izgovor. Umjesto toga prebacite pogođeni domain u permissive (semanage permissive -a moja_aplikacija_t), pokupite AVC-ove i izgradite lokalni policy modul kroz audit2allow.
Je li Landlock zamjena za SELinux?
Nije. Landlock je opt-in sandbox koji sami procesi primjenjuju na sebe. Ne pokriva sve LSM hookove i ne može odbaciti pristup ako aplikacija ne pozove landlock syscallove. SELinux i AppArmor rade odozgo, sustavski, bez suradnje aplikacije. Landlock je komplement, koristan za restrikciju CLI alata i user-space servisa.
Koliko performansi gubim aktivacijom SELinuxa?
U tipičnim macro benchmarcima 3–7 % za SELinux i 1–3 % za AppArmor. U mikro-benchmarcima s intenzivnim I/O ili syscall pozivanjem overhead može doći do 10 %. Za većinu web, database i API workloadova gubitak je unutar margine šuma raspoređivanja i NUMA lokalnosti.
Kako mogu vidjeti koji je LSM aktivan na mom sustavu?
Pročitajte /sys/kernel/security/lsm. Vraća zarezom odvojenu listu aktivnih modula (npr. capability,landlock,yama,apparmor). Za primarni MAC, getenforce kaže je li SELinux aktivan i u kojem modu, a aa-status pokazuje broj učitanih AppArmor profila i njihova stanja.
