SELinux v roku 2026: Praktický sprievodca politikami, troubleshootingom a kontajnermi na RHEL 10

Aktualizované: 31. mája 2026

SELinux je povinný systém riadenia prístupu (MAC) v jadre Linuxu, ktorý každému procesu, súboru a sieťovému portu priraďuje bezpečnostný kontext a vynucuje politiku rozhodujúcu, kto môže s čím komunikovať, a to aj v prípade, že je root kompromitovaný. V tomto sprievodcovi pre rok 2026 prejdem od minimálnej konfigurácie na RHEL 10, cez analýzu AVC denials pomocou ausearch a audit2allow, písanie vlastných CIL modulov, až po správnu integráciu so SELinux-aware Podmanom 5.x. Cieľom je, aby ste po prečítaní nevypínali SELinux, ale vedeli ho ladiť.

• SELinux v RHEL 10 beží na jadre 6.12 LTS s vylepšeným LSM stackom; predvolená politika targeted chráni cca 200+ systémových démonov bez zásahu administrátora.
• Vypnúť SELinux (SELINUX=disabled) je v roku 2026 anti-pattern. Namiesto toho používajte permissive režim na ladenie a booleans na granulárne ústupky.
• 95 % denials sa rieši trojicou nástrojov: ausearch -m AVC, sealert a audit2allow -M. Vlastný TE modul píšte len ak boolean alebo file context nestačia.
• Podman 5.x automaticky priraďuje kontajnerom kontext container_t a montovaným zväzkom :Z alebo :z. Bez tohto sufixu sa SELinux a kontajnerové úložisko bijú o súbory.
• CIL (Common Intermediate Language) nahrádza klasický .te/.fc/.if workflow; semodule -i dnes prijíma priamo .cil moduly s rýchlejšou kompiláciou.
• Auditované organizácie (PCI-DSS, ISO 27001) vyžadujú MAC vrstvu. SELinux v enforcing režime je akceptovaný kompenzačný control pre CIS Benchmark sekcie 1.6 a 4.1.

Čo je SELinux a ako funguje v jadre 6.12

SELinux (Security-Enhanced Linux) je implementácia Mandatory Access Control postavená nad rozhraním Linux Security Modules (LSM). V jadre 6.12 LTS, ktoré tvorí základ RHEL 10 a Ubuntu 26.04 LTS, beží SELinux ako jeden z viacerých LSM modulov v rámci tzv. stackable LSM infraštruktúry, popri AppArmore, Landlocku, Yame a BPF LSM. Každé systémové volanie, ktoré pristupuje k objektu (súbor, socket, IPC, capability), prejde cez hooky LSM a SELinux rozhodne na základe troch atribútov: subject context (proces), object context (cieľový zdroj) a class (typ operácie).

Kontext vyzerá takto: system_u:system_r:httpd_t:s0. Štyri polia znamenajú používateľ, rola, typ a úroveň citlivosti. V predvolenej targeted politike, ktorú RHEL používa od verzie 5, je rozhodujúci tretí stĺpec, čiže typ. Politika je v podstate gigantická tabuľka allow rules: napríklad allow httpd_t httpd_log_t:file { read write append };. Ak požiadavka neprejde, jadro vygeneruje AVC (Access Vector Cache) denial do /var/log/audit/audit.log a (ak ste v enforcing režime) operáciu zablokuje. V permissive režime sa denial iba zaloguje. To je váš ladiaci nástroj číslo jeden.

Detaily kernel API nájdete priamo v oficiálnej dokumentácii Linux Kernel LSM/SELinux. Z pohľadu výkonu je overhead AVC lookupu pod 1 % na typickom serverovom workloade. AVC je cache, ktorá si pamätá rozhodnutia, takže opakované rozhodnutia nestoja takmer nič.

Aký je rozdiel medzi SELinux a AppArmor?

Stručne: SELinux pracuje s labelmi inode, AppArmor s cestami v súborovom systéme. Tento konceptuálny rozdiel má hmatateľné dôsledky pre bezpečnosť aj prevádzku. Ak v AppArmori prejmenujete súbor alebo ho presuniete inam, profil ho prestane chrániť, pretože ho viaže k ceste. SELinux má label zapísaný v rozšírených atribútoch (security.selinux xattr) inode samotného, čiže ochrana cestuje so súborom. To je dôvod, prečo NSA pôvodne vyvinul SELinux pre prostredia s povinným tagovaním citlivých dát.

Porovnanie hlavných parametrov:

Vlastnosť	SELinux	AppArmor
Model	Type Enforcement + RBAC + MLS	Path-based profily
Ochrana viazaná na	Inode label (xattr)	Cesta v súborovom systéme
Distribúcie	RHEL, Fedora, CentOS Stream, Oracle Linux	Ubuntu, Debian, SUSE, openSUSE
Krivka učenia	Strmá (CIL, kontexty, booleans)	Mierna (čitateľný profil)
MLS / multi-level security	Áno (Bell-LaPadula model)	Nie
Auto-learning	audit2allow	aa-logprof
Vhodné pre	Vládne a regulované prostredia, kontajnery, multi-tenant	Desktopy, jednoúčelové aplikácie, ľahší tooling

Pre hlbší rozbor MAC vrstvy si pozrite môj kompletný sprievodca AppArmor, porovnanie filozofií oboch systémov je tam podrobné. V praxi: ak prevádzkujete RHEL 10 alebo Rocky Linux 10, ostávate pri SELinuxe. Ak ide o Ubuntu 26.04 server, máte zmysluplnú voľbu, ale stále môžete SELinux nainštalovať z reference policy.

Inštalácia a overenie stavu na RHEL 10 a Fedora 41

Na RHEL 10, AlmaLinux 10 a Rocky Linux 10 je SELinux v enforcing režime predvolený stav. Stačí overiť, či niekto v predchádzajúcom živote inštalácie nezmenil /etc/selinux/config. Začnite kontrolou:

# Stručný status
sestatus

# Očakávaný výstup na čerstvej RHEL 10 inštalácii:
# 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

Ak vidíte disabled, prepnúť rovno do enforcing nestačí. Relabeling celého filesystému trvá rádovo minúty a vyžaduje reboot. Postup:

# 1. Nastavte permissive režim v konfigu
sudo sed -i 's/^SELINUX=.*/SELINUX=permissive/' /etc/selinux/config

# 2. Vyžiadajte autorelabel pri ďalšom boote
sudo fixfiles onboot
# alebo manuálne:
sudo touch /.autorelabel

# 3. Reboot a sledujte konzolu, relabel je viditeľný
sudo systemctl reboot

# 4. Po reboote overte audit log a prepnite na enforcing
sudo ausearch -m AVC -ts recent
sudo setenforce 1
sudo sed -i 's/^SELINUX=.*/SELINUX=enforcing/' /etc/selinux/config

Na Fedora 41+ a CentOS Stream 10 je proces identický. Na Ubuntu 26.04 nainštalujte balíčky selinux-basics, selinux-policy-default a spustite selinux-activate. Canonical naďalej podporuje voliteľnú inštaláciu, no AppArmor zostáva predvolený. Pre Debian 13 (Trixie) je situácia rovnaká.

Užitočné balíčky, ktoré v produkcii vždy doinštalujem: policycoreutils-python-utils (kvôli semanage), setroubleshoot-server (kvôli sealert), setools-console (na introspection politiky) a selinux-policy-doc (manuálové stránky ku všetkým typom).

Bezpečnostné kontexty, booleans a file contexts

Tri triedy zásahov pokrývajú 90 % administrátorskej práce so SELinuxom: booleans (prepínače), file contexts (značky súborov) a port labels (mapovanie typu na TCP/UDP port). Vlastný TE modul je až posledná možnosť.

Úprimne, keď som prvýkrát ladil starý PHP projekt, ktorý zápasil so SELinuxom, strávil som dve hodiny písaním vlastného modulu, kým som si všimol, že existuje boolean, ktorý rieši presne tento prípad. Vždy sa pozrite na getsebool -a ako prvé.

Booleans sú vopred pripravené prepínače definované samotnou politikou. Napríklad ak chcete povoliť, aby Apache čítal používateľské domovské adresáre:

# Vypíš všetky boolany pre httpd s popisom
getsebool -a | grep httpd | head

# Trvale zapni jeden boolean (-P = persistentné cez reboot)
sudo setsebool -P httpd_enable_homedirs on

# Pozri pomoc k boolanu
sepolicy booleans -b httpd_enable_homedirs

File contexts sú pravidlá, ktoré priraďujú label cestám pri operáciách restorecon a matchpathcon. Klasický príklad, chcete spúšťať webový obsah z neštandardnej cesty:

# Pridaj pravidlo pre nový adresár
sudo semanage fcontext -a -t httpd_sys_content_t '/srv/app(/.*)?'

# Aplikuj pravidlo na existujúce súbory
sudo restorecon -Rv /srv/app

# Overenie, tretí stĺpec musí byť httpd_sys_content_t
ls -Z /srv/app

Pravidlo s (/.*)? regex elegantne pokryje adresár aj všetko v ňom. Bez restorecon sa nové pravidlo na už existujúce súbory neaplikuje. Pravidlá platia pre budúce operácie a pre explicitný relabel.

Port labels: ak presúvate démona na neštandardný port, SELinux ho štandardne nepustí. Pre webový server na porte 8443:

# Zobraz aktuálne porty pre typ
sudo semanage port -l | grep http_port_t

# Pridaj nový port
sudo semanage port -a -t http_port_t -p tcp 8443

Ako odstrániť SELinux denials krok za krokom

Toto je miesto, kde sa väčšina administrátorov vzdá a vypne SELinux. Nerobte to. Proces je deterministický a AVC denial je textová stopa, ktorá presne hovorí, kto, čo a kde nesmel. Najprv si overte, či vôbec ide o SELinux problém:

# Pozri posledných 10 minút AVC denials
sudo ausearch -m AVC,USER_AVC,SELINUX_ERR -ts recent

# Príklad výstupu (skrátené):
# type=AVC msg=audit(1716545432.789:1234): avc:  denied  { read }
#   for  pid=4321 comm="nginx" name="data.json"
#   dev="dm-0" ino=1234567
#   scontext=system_u:system_r:httpd_t:s0
#   tcontext=unconfined_u:object_r:user_home_t:s0
#   tclass=file permissive=0

Z tejto jedinej riadky viete: proces nginx v kontexte httpd_t sa pokúšal čítať súbor s kontextom user_home_t, čo politika nepovoľuje. Riešenie podľa hierarchie:

1. Skontrolujte boolean. Niekedy stačí prepnúť. sepolicy booleans -b httpd_read_user_content.
2. Skontrolujte file context. Možno súbor má jednoducho zlú značku. Ak je pravidlo už v politike, pomôže restorecon.
3. Použite sealert pre čitateľný popis: sealert -l "*" vám prečíta audit log a navrhne riešenie ľudskou rečou.
4. Generujte modul z denials ako poslednú možnosť: audit2allow.

# Vygeneruj a hneď nainštaluj politiku pre konkrétny denial
sudo ausearch -m AVC -ts recent | audit2allow -M nginx_data_access
sudo semodule -i nginx_data_access.pp

# audit2allow vytvorí .te + .pp; .te si VŽDY otvorte v editore a skontrolujte,
# či navrhnuté pravidlá nie sú príliš široké (napr. neudeľujú celej doméne
# httpd_t právo zapisovať do /etc, to by ste nechceli).

Pre detailný audit pipeline so SELinux a auditd politikami sa pozrite na sprievodcu auditd a MITRE ATT&CK detekciou hrozieb, ktorý mapuje AVC na konkrétne TTP techniky.

Písanie vlastného CIL politického modulu

Tradičné .te/.fc/.if moduly stále fungujú, no od policycoreutils 3.6 (RHEL 10, Fedora 41) je preferovaný formát CIL (Common Intermediate Language). CIL je čitateľnejší S-expression formát, kompiluje sa rýchlejšie a semodule ho prijíma priamo bez medzistupňa cez checkmodule. Príklad, vlastná doména pre interný skript, ktorý má čítať /etc/myapp/:

; /var/lib/selinux/custom/myapp.cil
(block myapp
  (type myapp_t)
  (type myapp_exec_t)
  (roletype system_r myapp_t)

  ; Domain transition zo systemd
  (typetransition init_t myapp_exec_t process myapp_t)

  ; Povolenie spúšťania
  (allow init_t myapp_exec_t (file (execute getattr open read)))
  (allow myapp_t myapp_exec_t (file (entrypoint execute getattr open read)))

  ; Doména si môže čítať vlastné konfiguračné súbory
  (allow myapp_t etc_t (file (getattr open read))))

Inštalácia a aktivácia:

# Inštalácia CIL modulu
sudo semodule -i /var/lib/selinux/custom/myapp.cil

# Označ binárku správnym typom
sudo semanage fcontext -a -t myapp_exec_t '/usr/local/bin/myapp'
sudo restorecon -v /usr/local/bin/myapp

# Reštart démona, proces by mal mať nový kontext
sudo systemctl restart myapp
ps -eZ | grep myapp
# Očakávame: system_u:system_r:myapp_t:s0 ... /usr/local/bin/myapp

Pre rozsiahlejšie projekty odporúčam štúdium SELinux Notebook na GitHube, je to autoritatívny referenčný materiál od upstream tímu. Tam nájdete formálnu gramatiku CIL aj príklady prechodov pre MLS a RBAC.

SELinux a kontajnery: Podman, container_t a zväzky

Podman 5.x na RHEL 10 spúšťa kontajnery v doméne container_t izolovanej od hostiteľa. Každý kontajner má naviac unikátny MCS label (Multi-Category Security), napríklad s0:c123,c456, ktorý zabraňuje, aby jeden kompromitovaný kontajner mohol čítať súbory iného kontajnera, hoci by mali rovnaký typ. Toto je vrstva, ktorú namespaces nepokrývajú.

Najčastejší úskalí je montovanie hostiteľského adresára do kontajnera. Bez korektného sufixu SELinux denial zaručene príde:

# ZLE: kontajner nebude vidieť obsah, AVC denial
podman run -v /srv/data:/data:ro alpine ls /data

# DOBRE: :Z prelabeluje obsah s privátnym MCS label pre tento kontajner
podman run -v /srv/data:/data:Z alpine ls /data

# Alebo :z (malé z) pre zdieľaný label, ak chcete viac kontajnerov pristupovať
podman run -v /srv/data:/data:z alpine ls /data

Rozdiel medzi :Z a :z je zásadný. Veľké Z nastaví privátny MCS label, takže k súborom môže pristúpiť len tento konkrétny kontajner. Po jeho ukončení label ostane a iný kontajner sa naň nedostane. Malé z nastaví zdieľaný label container_file_t:s0, čo sa hodí pre service mesh alebo CI runnery, kde viacero kontajnerov musí zdieľať volume.

Praktické booleany pre kontajnerové workloady na hostiteľoch s Podmanom:

# Povolenie sieťovej komunikácie zo všetkých kontajnerových domén
sudo setsebool -P container_connect_any on

# Povolenie čítania CIFS/NFS zdieľaných diskov
sudo setsebool -P virt_use_nfs on
sudo setsebool -P virt_use_samba on

# Audit, ktoré boolany sú aktívne v container politike
getsebool -a | grep container

Pre rootless Podman, seccomp profily a obranu proti úniku z kontajnera si pozrite môj predchádzajúci článok zabezpečenie kontajnerov na Linuxe 2026, SELinux je tam jedna z piatich obranných vrstiev.

Prečo by ste SELinux nemali zakázať

Posledných desať rokov potvrdených CVE ukazuje, že SELinux v enforcing režime opakovane zablokoval exploity, ktoré by inak viedli k privilege escalation alebo container escape. Tri konkrétne príklady, na ktoré sa odvolávam: CVE-2022-0492 (cgroup v1 escape v runc), kde SELinux container_t doména zabránila zápisu do release_agent; CVE-2024-1086 (use-after-free v nf_tables), kde defaultná politika obmedzila escalation pathy; a CVE-2024-21626 ("Leaky Vessels" v runc 1.1.11), kde MCS labeling zabránil čítaniu súborov z iných kontajnerov.

Vypnutie SELinux je v roku 2026 pre regulované prostredia auditný nález. CIS Benchmark RHEL 10 v sekcii 1.6 vyžaduje SELinux v enforcing stave s politikou targeted alebo mls. PCI-DSS 4.0 požaduje MAC vrstvu ako kompenzačný control pre Requirement 7. ISO 27001:2022 control A.8.4 (Access to source code) sa typicky audituje cez prítomnosť SELinux/AppArmor.

Ak vás na vypnutie tlačí jediný neposlušný balík softvéru (typicky proprietárna ERP alebo monitoring agent), správna odpoveď je permissive doména pre tento jeden proces, nie vypnutie celého systému. Príkaz semanage permissive -a myapp_t spraví doménu permissive pri zachovaní enforcement pre zvyšok systému. Audit log naďalej zbiera AVC denials, ktoré viete neskôr vyriešiť modulom.

Pre konfiguráciu CI/CD pipeliny so SELinux skenovaním si pozrite oficiálnu dokumentáciu projektu SELinux Reference Policy, kde nájdete príklady GitHub Actions, ktoré buildujú a testujú politiky v izolovaných VM. Pre kontext o širšom audite servera odporúčam aj sprievodcu OpenSCAP a CIS benchmarkami, kde sa SELinux objavuje ako jeden z hlavných kontrolných bodov.

Často kladené otázky

Spomalí SELinux môj server?

V praxi nie. Benchmark overhead AVC lookupu je pod 1 % na typickom serverovom workloade vďaka tomu, že AVC funguje ako cache rozhodnutí. Najväčší dopad uvidíte počas plného restorecon celého filesystému, čo je jednorazová operácia.

Ako zistím, či konkrétny problém spôsobuje SELinux?

Dočasne prepnite na permissive: sudo setenforce 0. Ak problém zmizne, je to SELinux. Vráťte sa do enforcing pomocou setenforce 1 a riešte cez ausearch a audit2allow. Nikdy nenechávajte permissive natrvalo, je to falošný pocit istoty bez ochrany.

Čo robí príkaz setenforce 1?

Prepne SELinux z permissive do enforcing režimu za behu, bez rebootu. Zmena nie je trvalá, po reštarte sa vráti do stavu definovaného v /etc/selinux/config. Pre permanentnú zmenu upravte direktívu SELINUX=enforcing v tomto súbore.

Dá sa SELinux nainštalovať na Ubuntu alebo Debian?

Áno. Na Ubuntu 26.04 a Debian 13 (Trixie) nainštalujte selinux-basics, selinux-policy-default a aktivujte príkazom selinux-activate. Vyžiada sa autorelabel a reboot. AppArmor pri tom musíte deaktivovať, dva path/label MAC systémy bežiace súčasne sa nepodporujú.

Ako napíšem vlastnú SELinux politiku najjednoduchšie?

Najjednoduchší workflow je vygenerovať TE pravidlá z AVC denials: ausearch -m AVC -ts recent | audit2allow -M mymodule. Modul si pred inštaláciou otvorte v editore, prečítajte navrhnuté pravidlá a vyhoďte tie, ktoré sú príliš široké. Až potom semodule -i mymodule.pp.