Nebojte se SELinuxu – 4 (reference policy)

10. 9. 2009 | Michal Svoboda | Bezpečnost | 11969×

Při dostatečné znalosti principů, na kterých funguje SELinux, se můžeme bez obav pustit do studia instalované bezpečnostní politiky - konkrétně „reference policy“ – na kterou narazíme téměř u každé instalace SELinuxu. Jako obvykle si ukážeme, jak to funguje uvnitř, a výklad doplníme praktickými příklady.

Obsah

• Principy referenční politiky
  • Makrojazyk m4
  • Modularita
• Soubor if – interface
• Soubor te – pravidla pro type enforcement (TE)
• Soubor fc – kontexty souborů
• Moduly politiky
• Modul local z prvního dílu
• Příště

Principy referenční politiky

V předchozích dvou dílech jsme se naučili rozumět principům TE a RBAC tak, jak je používá SELinux. Tyto znalosti nám postačují k tomu, abychom uměli analyzovat stávající pravidla, případně tvořit nová. Soubor pravidel, které jsou do systému zavedeny, se nazývá politika (policy). V současné době zabírá takřka monopolní postavení takzvaná referenční politika. Tuto politiku používají v různých verzích a s různými patchi všechny distribuce, které podporují SELinux.

Největším problémem, se kterým se musí jakákoliv politika vypořádat, je množství pravidel a typů, které jsou v klasickém systému potřeba. Základní představu o tom si můžeme udělat opět pomocí programu apol: Počet typů je v řádu tisíců, počet pravidel v řádu desetitisíců. Na rozdíl od normálních UNIXových oprávnění, která si více méně tahá každý instalovaný balíček (např. DNS server, web server) s sebou, je u SELinuxových oprávněních vše v rukách dodavatele politiky. Referenční politika si ke svému úkolu bere na pomoc několik principů.

Makrojazyk m4

Prvním principem je automatizace práce pomocí makrojazyka m4. Pokud vám to připomíná staré zlaté časy sendmailu, jste naladěni na správnou notu. Politika psaná ve stylu referenční politiky je směs volání maker a AV pravidel. Puritáni dokonce tvrdí, že optimální stav je pouze volání maker. Jazyk m4 sice neobsahuje mnoho možností, ale je to jazyk, a lze v něm dosáhnout poměrně velké strukturovanosti kódu.

Modularita

Tím se dostáváme k druhému principu, a tím je modularita, potažmo rádoby zapouzdřenost modulů. První stupeň modularity je ve zdrojových souborech politiky. V adresáři policy/modules ve zdrojovém balíku najdeme hromadu modulů, roztříděných podle zařazení v systému (systémové služby, aplikace, …). Toto rozřazení je pouze pro vývojáře, jinak nemá na politiku vliv. Jeden modul se pak věnuje části politiky, která pracuje s vybranou částí systému. Pro konkrétnější představu se můžeme podívat na modul bind pro DNS server. Tento modul se nachází mezi službami, a tedy v adresáři services. Každý modul je typicky rozdělen na tři části, a bind není výjimkou.

Soubor if – interface

Soubor bind.if obsahuje interface neboli definice maker, která smí používat všechny ostatní moduly. Zde se soustřeďuje většina automatizace pomocí m4. Každé makro by také mělo mít u sebe krátkou dokumentaci v XML. Dokumentaci k interfacům všech stávajících modulů lze nalézt v sekci Interface Reference na webu referenční politiky. V našem modulu bind je například definováno toto makro:

########################################
## <summary>
##      Send BIND the kill signal
## </summary>
## <param name="domain">
##      <summary>
##      Domain allowed access.
##      </summary>
## </param>
#
interface(`bind_kill',`
        gen_require(`
                type named_t;
        ')

        allow $1 named_t:process sigkill;
')

Výše uvedený kód vytváří makro bind_kill, které očekává jeden parametr, jež má určovat typ (doménu, chlívek, …), který v tomto případě bude mít dovoleno provést kill -9 na běžící proces bind. Makro bychom volali takto:

bind_kill(mujtyp_t)

A výsledkem by bylo pravidlo:

allow mujtyp_t named_t:process sigkill;

Část gen_require bude vysvětlena později. Makro samozřejmě může být složitější a může také volat další makra. To je velká výhoda, ale také zdroj potíží, protože chyba v definici nebo volání makra se obvykle projeví až po výsledné expanzi a načtení celé politiky do systému, a to je fáze, ve které se nelehce poznává, kde vlastně k chybě došlo. To je ale bohužel dáno vlastnostmi použitého jazyka m4.

Jak již bylo zmíněno, takto zadefinované makro lze volat ze všech modulů politiky. Zmíněné bind_kill není možná z nejužitečnějších, ale například pomocí bind_admin lze zadefinovat nějaké roli všechna oprávnění, která potřebuje na správu DNS serveru. Lze tedy na velmi málo řádcích vytvořit modul, který popisuje roli správce DNS serveru, kterou pak můžeme přiřadit uživatelům.

Soubor te – pravidla pro type enforcement (TE)

Pravidla, která nemusí nutně být součástí nějakého makra, modulu volatelného zvenčí a vůbec celou kostru modulu tvoří soubor bind.te. Lze říci, že tento soubor je pro kompilaci politiky podstatný, a makra definovaná v interfacech dalších modulů se do něj vkládají podle potřeby. V souboru bind.te je vidět směs volání maker z různých dalších modulů a pravidel v jazyce pro politiku SELinuxu (AV pravidla, definice typů, rolí, …). Co je co lze poznat podle ukončujícího středníku: Makra jej nemají. Strukturu tohoto souboru, jakož i obvyklou metodiku používání maker, si rozvedeme podrobněji na příkladech níže a v dalším díle.

Soubor fc – kontexty souborů

Posledním souborem modulu je bind.fc, neboli definice výchozích kontextů souborů. Výchozí kontext se použije v případě vytvoření nového souboru a v případě manuálního obnovení výchozích kontextů pomocí restorecon nebo fixfiles relabel. Formát souboru je celkem jednoznačný: Regulární výraz (který je automaticky ohraničen ^ a $), typ souboru (viz nápověda k příkazu semanage, volba -f) a nakonec buď řetězec <<none>>, nebo volání makra gen_context() s příslušným kontextem. Například řádek

/usr/sbin/named         --      gen_context(system_u:object_r:named_exec_t,s0)

určuje, že obyčejný soubor (--) podléhající danému regulárnímu výrazu (což je zde pouze jeden soubor) bude mít ten a ten kontext, z něhož je důležitá část named_exec_t, která označuje spustitelný soubor démona named. Pokud bychom někdy přestěhovali named jinam, můžeme správný kontext souboru nastavit ručně pomocí chcon, což ale nepřežije obnovu implicitních kontextů. Trvalejší metodou je použití příkazu semanage fcontext, který daný kontext zapíše do souboru file_contexts.local a bude ekvivalentní kontextu v politice. Všimněme si, že jelikož se referenční politika snaží být univerzální a linuxové distribuce se někdy v umístění souborů liší, v souboru bind.fc najdeme konstrukce jazyka m4 jako ifdef(`distro_debian',`sada_kontextů').

Moduly politiky

Posledním důležitým principem referenční politiky je modularita z hlediska nastavení za běhu systému. Dříve se jednotlivé moduly ve zdrojovém formátu slepily dohromady a vznikla jedna monolitická politika, která se musela při každé změně ve smyslu odebrání/přidání modulu přeložit a načíst znovu. Dnes lze z jednotlivých zdrojových modulů vytvořit moduly binární, které obvykle sídlí v adresáři /usr/share/selinux a které lze programem semodule za běhu odebírat a přidávat bez nutnosti překladu. Pokud používáme DNS server, načteme modul bind, pokud ne, tak ho necháme ležet.

S tímto principem přichází možnost výroby vlastních modulů, aniž bychom museli modifikovat původní politiku. Podrobný popis výroby netriviálního modulu si uvedeme v příštím díle. Dnes se pouze podíváme na dva jednoduché moduly. Prvním z nich je modul, který zpřístupňuje socket vytvořený příkazem ssh_agent (respektive ssh -A). V politice, která je nainstalována v distribuci Debian Lenny, se na něj zřejmě zapomnělo.

Nejprve vytvoříme soubor sshagent.if:

## <summary>sshagent policy</summary>
## <desc>
##      <p>
##              policy for accessing ssh agent sockets in /tmp
##      </p>
## </desc>
#

########################################
## <summary>
##      Access ssh agent sockets.
## </summary>
## <param name="domain">
##      Domain allowed access.
## </param>
interface(`sshagent_access',`
        gen_require(`
                class sock_file { read write };
                type $1;
                type sshd_tmp_t;
        ')

        allow $1 sshd_tmp_t:sock_file { read write };
')

Definujeme pouze jedno makro, které generuje jedno pravidlo, povolující danému typu přístup k socketům typu sshd_tmp_t (tj. v adresáři /tmp). Makro gen_require vloží dané řádky do sekce require v souboru, odkud je naše makro zavoláno. Co je to sekce require? Každý typ, roli, přístupové právo, atd., které chceme použít, musíme předem oznámit v sekci require. Při zavedení modulu do jádra se nejprve ověří, zda všechny tyto entity existují. Tím vlastně zavádíme závislost našeho modulu na modulu ssh, bez kterého neexistuje typ sshd_tmp_t.

Dále vyrobíme soubor sshagent.te, který triviálně použije právě definované makro:

policy_module(sshagent,1.0.0)

sshagent_access(staff_ssh_t)
sshagent_access(sysadm_ssh_t)

V prvním řádku deklarujeme (voláním makra), že vyrábíme modul s názvem sshagent a verzí 1.0.0. Dále už jen voláme naše makro pro zpřístupnění socketů daným typům (co jsou zač, jsme rozebírali minule).

Konexty souborů zde nepotřebujeme, soubor sshagent.fc tedy vytvoříme prázdný. Zbývá přeložit modul. K tomu potřebujeme nainstalovat devel balíček od naší politiky (v Debianu je to selinux-policy-dev). Dále už je to jen:

make -f /usr/share/selinux/default/include/Makefile

Výsledkem bude soubor sshagent.pp v aktuálním adresáři. Pro jeho nahrání stačí semodule -i sshagent.pp, případně výše uvedeným make vyrobit cíl load (make -f … load). A vida, autentizace pomocí SSH agenta začne fungovat. Příkazem semodule -l se můžeme pokochat, případně zjistit, jaké další moduly jsou nataženy. Nahrání modulu jej taky zkopíruje do adresáře /etc/selinux/default/modules/active/modules, odkud se nahraje při rebootu. Podobně semodule -r sshagent modul z tohoto adresáře smaže a odinstaluje z jádra.

Modul local z prvního dílu

Druhým příkladem je modul local, který vznikl při prvotní instalaci v prvním díle použitím příkazu audit2allow -M local. Jak bylo řečeno, použití audit2allow bylo sice funkční řešení, ale bez dalšího auditu výsledné politiky může přinejmenším zanášet nepořádek a přinejhorším otevírat bezpečnostní díry. V této chvíli již rozumíme pravidlům, kontextům a dalším principům SELinuxu, umíme použít auditovací nástroje apol a sesearch a umíme si dohledat informace na webových stránkách referenční politiky a dalších webech. Jako správní rootové s bezpečnostním uvažováním rozumíme také svému operačnímu systému, své distribuci a instalovaným službám a programům. Přišla tedy ta správná chvíle splatit dluh z prvotní instalace SELinuxu a podívat se, co v souboru local.te vzniklo, a zamyslet se nad tím, jestli nelze daný problém vyřešit jinak. Konkrétní postup necháme zatím jako „domácí úkol“ pro čtenáře a vrátíme se k němu v příštím díle.

Příště

Povíme si podrobněji, kudy by se mělo naše uvažování ubírat při tvorbě nebo validaci modulu bezpečnostní politiky. Ukážeme si, jak se tvoří složitější moduly pro nějakou vlastní nebo nepodporovanou aplikaci, případně pro uživatelskou roli. Při tom budeme vážit důsledné používání maker a principů referenční politiky s principem nejmenšího odporu.

Poděkování

Článek vznikl za podpory ČVUT FEL, Katedra kybernetiky, kde jsou k dispozici, mimo jiné, studijní programy Otevřená informatika a Kybernetika a robotika.

       

Komentáře

Diskuse byla administrátory uzamčena

[alblaho]

Celý tenhle systém byl pravděpodobně zčásti vymyšlen proto, aby si admini mohli říct o víc peněz. Budou zasloužené. Ještě že se živím programováním.

[Bedňa]

Po tomto diele sa fakt už SElinuxu bojím :)

 

[pht]

Proč to? Sice to není tak jednoduché jako "nainstalujte si e-shop v pěti jednoduchých krocích" (a ani nemůže být, protože tu jde o bezpečnost), ale zas to není o nic náročnější než se naučit například to programování.

[TM]

Právě proto, že jde o bezpečnost je to v tomto stavu spíš nebezpečné. 99% administrátorů SE Linux prostě vypne, protože co bývá zdrojem záhadných problémů? Právě špatné nastavení SE Linuxu. Co ty problémy mávnutím kouzelného proutku odstraní? Vypnutí SE Linuxu. Takto se na to lidi často dívají a moc se tomu nedivím. Míra zbytečné komplikovanosti a nesrozumitelnosti v tomto případě byla překročena.

[pht]

99% uživatelů windows pracuje pod administrátorem, protože co bývá zdrojem záhadných problémů?

Vy nemusíte být takový ignorant jako těch Vašich 99%... jděte a nainstalujte si to, vykoušejte si to a pak vynášejte soudy. Pokud Vám něco nebude fungovat, tak se zeptejte.

[alblaho]

Většina Wokeníků pracuje pod administrátorem, protože je to jednodušší. Fungují i špatně napsané aplikace (jsou takové ještě), systém vás nebuzeruje že na to a to nemáte oprávnění.

Nedovedu si představit, že bych spravoval SELinux, protože nikdy nebudu mít tak přesné informace o vnitřnostech systému, abych věděl kdo k čemu kdy přistupuje. Špičkový profesionální admin, to je pochopitelně jiná liga.

Druhá možnost je, že celou konfiguraci připraví distributor, takže běžný uživatel o SELinuxu vůbec nemusí vědět. V práci máme jeden RHEL5 a SELinuxu ničemu nevadí, je neviditelný (ale ten stroj jsem neinstaloval, takže nevím, co se tam řešilo).

[pht]

Většina Wokeníků pracuje pod administrátorem, protože je to jednodušší. Fungují i špatně napsané aplikace (jsou takové ještě), systém vás nebuzeruje že na to a to nemáte oprávnění.

Pochopitelně je vždy jednodušší se bezpečnosti vzdát, než ji navrhnout dobře, a bohužel jsou i případy, kde platí, že žádné zabezpečení je lepší, než špatné. Mimochodem systém bezpečnosti ve Windows NT je metodicky mnohem propracovanější, než ten v UNIXu (ale zase ne tak dobrý jako v SELinuxu, protože stále patří do kategorie DAC, tedy až na ten pokus s UAC ve vistě).

Nedovedu si představit, že bych spravoval SELinux, protože nikdy nebudu mít tak přesné informace o vnitřnostech systému, abych věděl kdo k čemu kdy přistupuje. Špičkový profesionální admin, to je pochopitelně jiná liga.

To je samozřejmě přípustný postoj, narozdíl od ignorance typu "je to moc složité, tak to radši hned vypnu". Bohužel v bezpečnosti je to tak, že čím víc chcete zabezpečovat, tim víc musíte znát jednotlivé procesy, které zabezpečujete. A procesama v operačním systému to jen začíná.

A můžete taky dojít k závěru, že tuto úroveň zabezpečení pro svoje procesy nepotřebujete. Každopádně bych ale doporučil všem těm adminům typu "mám tři weby a poštovní server a pár kamarádů přes ssh", aby se alespoň zkusili podívat na defaultní nastavení targeted politiky pro SELinux (viz níže), která přesně tento případ adresuje.

Druhá možnost je, že celou konfiguraci připraví distributor, takže běžný uživatel o SELinuxu vůbec nemusí vědět. V práci máme jeden RHEL5 a SELinuxu ničemu nevadí, je neviditelný (ale ten stroj jsem neinstaloval, takže nevím, co se tam řešilo).

Připraví to distributor a administrátor, takže uživatel neví o SELinuxu, ale už ví o personální politice která by měla být spjatá s tou počítačovou (např.: heslo si udělej jen jedno, ale dlouhý, nebo: tady máš přístupovou kartu, nenechávej ji na stole).

Pokud máte RHEL5 tak IMHO používáte "targeted" politiku, kde jsou omezeny alespoň služby s přístupem na síť (web server, ...), ale už ne uživatelé, kteří se přihlašují. Nebo ji nemáte a pak máte buď schopného administrátora, a nebo zapracovaly Vaše peníze za subskripci RHEL. :)

[Nicky726]

Co jsem zkoušel poslední dvě Fedory, tak jsem na problém s SELinuxem nenarazil. SELinux tam je velmi dobře integrovaný, uživatel o tom v podstatě ani neví a přitom je chráněný. Podle mě ideální stav. Rozchodit SELinux bez nějaké větší podpory distribuce je jaksi vyšší dívčí. A to jak v Archu, tak třeba v Ubuntu (alespoň ve verzi co jsem zkoušel).

[pht]

uživatel o tom v podstatě ani neví a přitom je chráněný

Pokud se to nezměnilo, tak implicitně máte jako uživatel identitu unconfined_u, což zas taková ochrana není. Je ale poměrně jednoduché se toho zbavit.

Rozchodit SELinux bez nějaké větší podpory distribuce je jaksi vyšší dívčí.

Jeden z dílů chci věnovat i tomuto tématu.

[Nicky726]

Uživatel je unconfined_u, ale mnoho procesů je hezky zavřených ve svém chlívečku. Ano, GUI aplikací minimum, ale většina daemonů například chráněna je, stejně jako dost věcí kolem roota. Rozsah škod, které lze po proniknutí zvenčí napáchat, by to mělo afaik snižovat.

[pht]

No ale neměl by být problém se "degradovat" na user_u nebo něco takového. Asi si to napíšu jako téma na jeden díl :)

[filbar]

A dostane se někdy na mcs, nebo mls politiku?

[pht]

Dostane, ale až tak za 2-3 díly.

[Nicky726]

Čím dál zajímavější, jen tak dál.

[cgi]

k SELinuxu: Cheddar Bay Exploit...

[michich]

Chyba s nerespektováním mmap_min_addr byla opravena a nyní je možno se zapnutým SELinuxem dokonce i povolovat mapování dolní paměti selektivně pro typy, které to vyžadují. Je to i v dnešních Jaderných novinách.

[pht]

A co tím chcete říct?