SELinux od jádra k politice: labely, moduly a hledání chyb

LSM: kam se SELinux v jádře zapojuje

SELinux není nadstavba nad právy souborů, ale modul Linux Security Modules. Jádro má v cestě k operacím (otevření souboru, exec, socket, IPC) hooky a LSM v nich rozhoduje po tom, co projdou klasická práva. Diskrétní práva (rwx, vlastník) tím nezmizí; SELinux je nemůže rozšířit, jen zúžit. Co DAC zakáže, nepovolí ani politika.

Ve stejné roli stojí AppArmor. Liší se v tom, čeho se rozhodnutí drží: AppArmor váže pravidla na cestu k souboru, SELinux na jeho labely. Cesta se dá přesunout a odkazovat symlinkem, label zůstává na inodu.

Kontext: každý objekt na disku i v paměti má štítek

Kontext má čtyři části: unconfined_u:object_r:httpd_sys_content_t:s0 – SELinux uživatel, role, typ a úroveň (MLS/MCS). Rozhoduje se skoro vždy podle typu; role a uživatel omezují, kdo do jakého typu vůbec smí přejít, úroveň řeší kategorie a víceúrovňové oddělení.

Label leží v rozšířeném atributu security.selinux, tedy na souborovém systému, ne v politice. Z toho plynou dvě věci, které vysvětlují většinu záhad:

• ▸ souborový systém bez rozšířených atributů (NFS, FAT, tmpfs za určitých podmínek) label nést nemůže a kontext mu přiřazuje až připojení (context=) nebo pravidlo genfscon;
• ▸ soubor vytvořený v jednom místě a přesunutý jinam si nese svůj původní label, protože mv atribut zachovává – cp ho naopak odvodí z cíle.

Mapu očekávaných labelů drží semanage fcontext -l a restorecon podle ní štítky vrací do stavu, který politika předpokládá.

Typ unconfined_t je záměrná výjimka: proces v něm běží prakticky bez omezení. Cílená (targeted) politika takhle nechává uživatelské relace a omezuje hlavně služby. Proto „u mě to funguje“ nic nedokazuje, dokud se neví, ve kterém typu ten proces běžel.

Ze zdrojů do modulu

Politika je zdrojový kód. Modul se skládá ze tří druhů souborů:

Rozhraní jsou tu to podstatné. Modul nesahá na cizí typy přímo, ale volá makro, které pro něj napsal autor druhého modulu – apache_read_config() místo pravidla nad httpd_config_t. Makra se rozvinou při překladu (m4), takže co se ve zdroji čte jako jedno volání, je ve výsledné politice několik allow. Když se rozhraní změní, promítne se to do každého modulu, který ho volá, a to je přesně místo, kde vznikají regrese.

Překlad je checkmodule a semodule_package do .pp, novější toolchain používá CIL. Nainstalovaný modul se do jádra nahraje přes semodule -i.

Moduly stejného jména mohou existovat ve víc prioritách (semodule -X, rozsah 1-999). Distribuční politika bývá na 100 a lokálně stavěný modul na 400, na které semodule pracuje bez -X. Vyšší priorita vyhrává, takže se distribuční modul nepřepisuje – jen přebíjí. semodule -lfull ukáže, co je na které prioritě nainstalované, a je to první příkaz, který má smysl pustit, když se politika chová jinak, než říká balík.

Nástroje a hledání chyby

Odepření se zapisuje do auditu jako AVC. Vytáhne ho ausearch -m AVC -ts recent, na systémech bez auditd totéž leží v journalu (journalctl -t audit). Záznam nese zdrojový a cílový kontext, třídu objektu a operaci – tedy všechno, co je potřeba k rozhodnutí.

• ▸ sesearch -A -s httpd_t -t httpd_config_t ukáže, co politika už dovoluje, a odpoví, jestli chybí pravidlo, nebo jen sedí špatný label;
• ▸ seinfo vypíše typy, role a atributy;
• ▸ sepolicy popíše, co se od domény očekává, a umí vygenerovat kostru nového modulu;
• ▸ audit2allow -M nazev z AVC záznamů vyrobí modul.

Poslední jmenovaný je ten, kterým se to nemá řešit. audit2allow pouze přepíše odepření na allow – neví, jestli šlo o chybu politiky, nebo o chybný label, a v druhém případě zabetonuje závadný stav. Ptát se je potřeba v tomhle pořadí. Sedí label (ls -Z, restorecon -n -v)? Pokud ano, chybí pravidlo v politice, a to patří do modulu s rozhraním, ne do plošného allow.

Pravidlo dontaudit na to má ještě jednu past: potlačuje zápis o odepření, které stejně nastane. Když AVC nikde není a přesto to nefunguje, je potřeba pravidla dontaudit dočasně vypnout přes semodule -DB.

Kde se to dá nastudovat

• ▸ SELinux Notebook – referenční text projektu: jádro, knihovny, toolchain i jazyk politiky. Nejúplnější zdroj, jaký k tématu je.
• ▸ fedora-selinux/selinux-policy – politika, kterou reálně používá Fedora, RHEL i CentOS Stream. Číst cizí .te a .if vedle sebe je rychlejší než jakýkoli výklad o rozhraních.
• ▸ Video kurzy a přednášky pomůžou u prvních dvou kapitol (LSM a labely). U politik přestanou stačit, protože rozdíly mezi verzemi selinux-policy jsou větší než rozdíly ve výkladu.