AppArmor vs SELinux: praktické srovnání MAC systémů pro Linux v roce 2026

Aktualizováno: 26. května 2026

AppArmor vs SELinux jsou dva nejrozšířenější systémy povinného řízení přístupu (MAC) v jádře Linuxu. SELinux používá typové vynucování s vysokou granularitou (vhodné pro RHEL, CentOS Stream, Fedora a regulovaná prostředí), zatímco AppArmor pracuje s jednoduššími profily vázanými na cestu k binárce a je výchozí volbou na Ubuntu, Debianu a SUSE. Pro většinu serverů v roce 2026 platí jednoduché pravidlo: pokud používáte distribuci rodiny Red Hat, ponechte SELinux v režimu enforcing; pokud běží Ubuntu nebo Debian, vsaďte na AppArmor a doplňte vlastní profily pro aplikace.

• SELinux nabízí jemnozrnnou kontrolu pomocí typů, rolí a kontextů, ale má strmější křivku učení a vyžaduje nástroje jako audit2allow a semanage.
• AppArmor používá profily vázané na cestu (path-based), které lze číst i upravovat běžným textovým editorem a generovat pomocí aa-genprof.
• Oba moduly jsou implementovány jako Linux Security Modules (LSM) v jádře a nemohou běžet současně. Systém zvolí jeden při bootu.
• SELinux je výchozí na RHEL 9/10, Fedora 41+, Rocky Linux a AlmaLinux; AppArmor je výchozí na Ubuntu 24.04 LTS, Debian 12, openSUSE a Tumbleweed.
• Pro kontejnerová prostředí (Podman, Docker, Kubernetes) podporují obě řešení izolaci pracovních zátěží, ale SELinux má hlubší integraci s CRI-O a Kubernetes Pod Security.
• Audit a forenzní analýza je pohodlnější u SELinuxu díky strukturovaným AVC záznamům v /var/log/audit/audit.log.

Co je povinné řízení přístupu (MAC) v Linuxu?

Povinné řízení přístupu (Mandatory Access Control, MAC) je bezpečnostní model, ve kterém o povolení akce nerozhoduje vlastník souboru ani uživatel, ale centrální politika vynucovaná jádrem. Tradiční model Linuxu, tedy Discretionary Access Control (DAC), spoléhá na práva rwx a vlastnictví UID/GID. A v tom je problém: pokud útočník získá privilegia procesu, DAC ho neomezí. MAC přidává druhou vrstvu, takže i root proces smí pracovat jen v rámci své kontextové politiky.

V Linuxu jsou MAC moduly implementovány skrze rozhraní Linux Security Modules (LSM), které bylo do jádra začleněno už ve verzi 2.6. Mezi major LSM moduly patří SELinux, AppArmor, Smack a Tomoyo. Od jádra 5.x lze některé LSM kombinovat (tzv. stacking), ale SELinux a AppArmor se vzájemně vylučují jako primární vynucovatel. Distribuce musí jednu z politik vybrat při kompilaci a bootu.

Bez MAC vrstvy je systém závislý jen na DAC a capabilities. Pokud například webový server běžící pod uživatelem www-data obsahuje RCE zranitelnost, útočník může přečíst libovolný soubor s právy 0644 v celém systému. MAC politika tomu brání: i kompromitovaný nginx má povoleny operace jen v rámci svého kontextu (httpd_t u SELinuxu, profil /usr/sbin/nginx u AppArmoru) a pokus o čtení /etc/shadow skončí odepřením přímo na úrovni jádra.

Srovnávací tabulka SELinux vs AppArmor

Následující tabulka shrnuje hlavní rozdíly mezi oběma systémy z pohledu administrátora, který musí v roce 2026 rozhodnout, jakou MAC vrstvu nasadit na nový server (nebo upravit u stávajícího).

Vlastnost	SELinux	AppArmor
Model politiky	Typové vynucování (TE), RBAC, MLS	Profily vázané na cestu k binárce
Granularita	Velmi vysoká: kontexty, typy, role, kategorie	Střední: povolené cesty, capabilities, sítě
Křivka učení	Strmá; vyžaduje pochopení kontextů a domén	Mírná; profily čitelné jako prostý text
Výchozí distribuce	RHEL 9/10, Rocky, Alma, Fedora 41+, CentOS Stream	Ubuntu 24.04 LTS, Debian 12, openSUSE Leap 15.6
Nástroje pro ladění	audit2allow, semanage, sealert, setroubleshoot	aa-genprof, aa-logprof, aa-status, aa-complain
Logy	/var/log/audit/audit.log (AVC záznamy)	/var/log/syslog nebo journalctl (DENIED zprávy)
Integrace s kontejnery	Hluboká s CRI-O, Podman, OpenShift	Standardní s Docker a containerd
Vhodné pro	Regulovaná prostředí, vládní sítě, finance	Cloudové VM, vývojové servery, edge zařízení

Jak funguje SELinux a kdy ho zvolit

SELinux byl původně vyvinut agenturou NSA a do hlavní linie jádra Linuxu se dostal v roce 2003. Pracuje na principu Type Enforcement. Každému procesu, souboru, soketu a portu je přiřazen bezpečnostní kontext ve tvaru user:role:type:level, například system_u:object_r:httpd_sys_content_t:s0. Politika definuje povolené přechody mezi typy. Když proces s typem httpd_t čte soubor typu httpd_sys_content_t, je akce povolena; pokus o čtení shadow_t skončí AVC denialem.

SELinux má tři režimy: enforcing (vynucuje a loguje), permissive (jen loguje, neblokuje) a disabled (vypnuto). Od RHEL 9 už není žádná zkratka: přechod z disabled do enforcing vyžaduje kompletní relabel souborového systému příkazem fixfiles onboot, protože disabled nezachovává kontexty. Při zavádění SELinuxu na produkční server začněte vždy v režimu permissive, sesbírejte denials po dobu 7 až 14 dnů, vygenerujte vlastní moduly pomocí audit2allow -M mymodul < denials.log a teprve poté přepněte do enforcing. Já jsem si tenhle postup zafixoval po jedné nepříjemné noci, kdy mi zapnutí SELinuxu na nové databázi shodilo replikaci, protože pomocný skript končil v doméně init_t a chtěl psát do /var/lib/mysql.

SELinux zvolte v případech, kdy potřebujete prokazatelně oddělit pracovní zátěže s různými klasifikačními úrovněmi (Multi-Level Security), splnit požadavky DISA STIG nebo CIS Benchmark Level 2, případně provozujete OpenShift či Red Hat OpenStack. SELinux také lépe spolupracuje s postupy popsanými v článku hardening systemd služeb, kde lze každé službě přidělit dedikovanou doménu a omezit její kontext na minimum potřebných oprávnění.

Klíčové příkazy pro SELinux

# Zobrazit aktuální stav
sestatus

# Dočasně přepnout do permissive (do rebootu)
setenforce 0

# Trvale nastavit enforcing v /etc/selinux/config
sed -i 's/^SELINUX=.*/SELINUX=enforcing/' /etc/selinux/config

# Zobrazit kontext souboru a procesu
ls -Z /var/www/html/index.html
ps -eZ | grep nginx

# Změnit kontext souboru perzistentně
semanage fcontext -a -t httpd_sys_content_t "/srv/web(/.*)?"
restorecon -Rv /srv/web

# Vygenerovat vlastní modul z denials
ausearch -m AVC -ts recent | audit2allow -M mynginx
semodule -i mynginx.pp

Jak funguje AppArmor a kdy ho zvolit

AppArmor vznikl ve společnosti Immunix v roce 1998 a později jej převzal Novell pro SUSE. Do hlavní linie jádra byl začleněn ve verzi 2.6.36. Na rozdíl od SELinuxu nepoužívá kontextové štítky uložené v rozšířených atributech souborového systému, ale identifikuje procesy podle absolutní cesty k binárce. Profil pro /usr/sbin/nginx tedy popisuje pravidla pouze pro tento konkrétní spustitelný soubor.

Profily AppArmoru jsou uloženy v /etc/apparmor.d/ jako čitelné textové soubory. Každé pravidlo má jasnou strukturu: cesta, povolené operace a volitelně capabilities či síťové operace. Profil může běžet v režimu enforce (blokuje a loguje) nebo complain (jen loguje). Přechod mezi režimy je rychlý, bez nutnosti relabel celého souborového systému, což ocení administrátoři na cloudových instancích, kde čas náběhu hraje roli.

AppArmor zvolte v případech, kdy spravujete flotilu Ubuntu serverů, nasazujete edge zařízení s omezenými prostředky nebo potřebujete rychle ohraničit specifickou aplikaci bez přepisu globální politiky. AppArmor je také výchozí volba pro Snap balíčky a runtime izolaci v Ubuntu Core. Pro doplnění obrany na úrovni sítě se hodí kombinovat AppArmor s postupem popsaným v článku moderní konfigurace firewallu nftables.

Klíčové příkazy pro AppArmor

# Zobrazit stav modulu a načtené profily
aa-status

# Generovat profil pro novou aplikaci interaktivně
aa-genprof /usr/local/bin/myapp

# Přepnout profil do permissive (complain) režimu
aa-complain /etc/apparmor.d/usr.sbin.nginx

# Přepnout zpět do enforce
aa-enforce /etc/apparmor.d/usr.sbin.nginx

# Aktualizovat profil podle posledních denials
aa-logprof

# Ručně načíst profil bez rebootu
apparmor_parser -r /etc/apparmor.d/usr.sbin.nginx

MAC v kontejnerech a Kubernetes prostředí

Kontejnerové runtimy se na MAC vrstvu spoléhají jako na druhou linii obrany za namespaces a cgroups. SELinux i AppArmor v této oblasti hrají odlišnou roli a podpora se liší podle runtime. Docker historicky preferoval AppArmor (na Ubuntu hostitelích automaticky aplikuje profil docker-default), zatímco Podman a CRI-O používané v Red Hat ekosystému kladou důraz na SELinux a typ container_t.

V Kubernetes lze MAC profil specifikovat v poli securityContext pod manifestem podu. Pro SELinux použijete seLinuxOptions s definicí level: "s0:c123,c456", čímž každému podu přidělíte jedinečnou kategorii. Dva kompromitované kontejnery se pak navzájem nedostanou ke svým souborům. Pro AppArmor od Kubernetes 1.30 platí stabilní API přes pole appArmorProfile, které nahrazuje dřívější anotace.

Při návrhu runtime bezpečnosti pro Kubernetes je rozumné MAC kombinovat s eBPF nástroji pro detekci anomálií, viz náš průvodce runtime bezpečností Linuxu s Falco a Tetragon. MAC zastaví útok, eBPF ho zviditelní. Kombinace obou vrstev tvoří defense-in-depth strategii odpovídající doporučením Kubernetes Security konceptů pro produkční nasazení v roce 2026.

Je možné přejít mezi SELinux a AppArmor?

Technicky ano, prakticky to nedoporučujeme. Distribuce kompilují jádro s podporou jednoho primárního MAC modulu a userspace nástroje (init systém, balíčkovací manažer, předinstalované politiky) jsou navržené pro tento modul. Pokud se rozhodnete na Ubuntu nahradit AppArmor SELinuxem, musíte:

1. Nainstalovat balíčky selinux-basics, selinux-policy-default a auditd.
2. Vypnout AppArmor (systemctl disable --now apparmor) a odebrat všechny jeho profily.
3. Upravit boot parametry GRUB o security=selinux selinux=1.
4. Spustit relabel celého souborového systému, což u větších disků trvá hodiny.
5. Rezignovat na výchozí podporu komunity. Žádný oficiální Ubuntu manuál nepokrývá troubleshooting tohoto setupu.

Stejné varování platí opačně: instalace AppArmoru na RHEL 10 znamená rekompilaci jádra, protože oficiální balíček neobsahuje příslušný LSM modul. Pro většinu organizací je správným postupem zvolit distribuci podle preferovaného MAC systému (a ostatních faktorů jako podpora vendora, životní cyklus, ekosystém), nikoliv distribuci upravovat.

Praktické příkazy pro správu obou systémů

Následující úryvky zachycují každodenní operace, kterým administrátor v roce 2026 čelí: od ověření stavu přes řešení blokovaných operací až po dočasné vypnutí konkrétního profilu při ladění.

Diagnostika denials

# SELinux: zobraz lidsky čitelné vysvětlení posledního AVC
sealert -a /var/log/audit/audit.log | head -50

# AppArmor: vypiš denials od posledního bootu
journalctl -k --since today | grep "apparmor=\"DENIED\""

# SELinux: zjisti, který boolean by mohl problém vyřešit
getsebool -a | grep httpd

Dočasné zákazy a výjimky

# SELinux: dovol httpd procesům naslouchat na vlastním portu 8443
semanage port -a -t http_port_t -p tcp 8443

# AppArmor: dočasně přepni jeden profil do complain bez restartu služby
aa-complain /etc/apparmor.d/usr.bin.firefox

# AppArmor: úplně zakaž jeden profil
ln -s /etc/apparmor.d/usr.sbin.nginx /etc/apparmor.d/disable/
apparmor_parser -R /etc/apparmor.d/usr.sbin.nginx

Nejčastější chyby a jak jim předejít

Trvale vypnutý SELinux je v korporátních prostředích pravděpodobně nejčastější bezpečnostní antipattern. Mnozí administrátoři jej deaktivovali při instalaci legacy aplikace někdy v roce 2015 a od té doby na to nikdo nesáhl. Audit nálezu typu „SELinux=disabled na produkční databázi" se objevuje skoro v každém třetím compliance reportu, který jsem v posledním roce viděl. Řešením je postupný přechod: nejprve permissive, sběr denials, generování modulu, teprve poté enforcing.

U AppArmoru je častou chybou ruční úprava profilu bez následného apparmor_parser -r, takže změny v souborech /etc/apparmor.d/ nevstoupí v platnost až do dalšího rebootu. Druhým problémem je generování profilu pomocí aa-genprof v izolovaném testovacím prostředí, kde aplikace nikdy nedosáhne všech svých provozních cest. Výsledný profil pak v produkci blokuje legitimní operace a v půl třetí ráno řešíte, proč CRON job neprošel.

Pro oba systémy platí stejné pravidlo: nikdy nevytvářejte výjimku, kterou neumíte vysvětlit. Příkaz setenforce 0 spuštěný „dočasně" se snadno stane permanentním a první útočník, který se do systému dostane, této díry využije. Kvalitní MAC politika je živý dokument, takže ji udržujte ve verzovacím systému společně s ostatními konfiguracemi serveru.

Často kladené otázky

Co je lepší, AppArmor nebo SELinux?

Záleží na kontextu. SELinux nabízí jemnější kontrolu a je výchozí volbou pro vysoce regulovaná prostředí (finance, vláda, zdravotnictví), zatímco AppArmor má jednodušší syntaxi profilů a je vhodnější pro cloudové VM a edge zařízení s omezenými zdroji administrátorského času.

Mohou SELinux a AppArmor běžet současně?

Ne, oba moduly jsou implementovány jako primární LSM a vzájemně se vylučují. Linux jádro zvolí jeden při bootu na základě konfigurace distribuce a parametrů GRUB. Stacking je možný pouze pro některé sekundární LSM moduly jako Yama nebo Landlock.

Jak rychle zjistím, zda SELinux nebo AppArmor běží?

Pro SELinux spusťte sestatus nebo getenforce. Výstup ukáže Enforcing, Permissive nebo Disabled. Pro AppArmor použijte aa-status, který vypíše počet načtených profilů a jejich režimy. Oba příkazy fungují bez root oprávnění pro čtení stavu.

Je bezpečné vypnout SELinux?

Není to bezpečné a od RHEL 9 je proces deaktivace destruktivní: kontexty souborů se ztratí a opětovné zapnutí vyžaduje úplný relabel. Pokud SELinux blokuje legitimní aplikaci, správným řešením je přepnout do permissive, sebrat denials a vygenerovat vlastní politiku, nikoliv MAC úplně vypnout.

Funguje AppArmor v Docker kontejnerech?

Ano. Na hostitelích s AppArmorem (Ubuntu, Debian) Docker automaticky aplikuje výchozí profil docker-default na každý kontejner. Vlastní profil lze předat parametrem --security-opt apparmor=mujprofil při spuštění nebo polem appArmorProfile v Kubernetes manifestu od verze 1.30.