Nebojte se SELinuxu – 6 (MLS a MCS)

27. 10. 2009 | Michal Svoboda | Bezpečnost | 12029×

Doposud jsme se zabývali pouze třemi částmi SELinuxového bezpečnostního kontextu: uživatelskou identitou, rolí a typem (doménou). Čtvrtá část kontextu je vyhrazena pro mechanizmus MLS/MCS, tedy úrovním citlivosti a kategoriím dat.

Obsah

• Trochu teorie kolem MLS
  • Model BLP
  • Kategorie
• MLS v SELinuxu
• MCS v SELinuxu
• Závěrem a příště

Trochu teorie kolem MLS

Model BLP

Multilevel security (MLS, víceúrovňová bezpečnost) je bezpečnostní mechanizmus, podobně jako type enforcement (TE). Existuje několik variant MLS, z nichž nejznámější je varianta dle modelu Bell-La Padula. V dalším textu tedy budeme předpokládat MLS dle tohoto modelu.

Zatímco TE rozlišuje u procesů, souborů a dalších objektů typy (domény), MLS rozlišuje úrovně citlivosti (sensitivity). U TE pak máme pravidla jako „typ httpd_t nesmí nic, pouze poslouchat na portu 80 a číst soubory typu web_pages_t“. MLS žádné takovéto specifikace pravidel nepodporuje, má pouze pravidla dvě: Pokud je citlivost procesu X, smí číst z objektů ≤X („no read up“) a zapisovat do objektů ≥X („no write down“). Jinými slovy, informace (data) smí proudit pouze na stejné úrovni citlivosti, případně od zdroje s menší úrovní k cíli s vyšší úrovní.

Klasický příklad použití MLS: Máme úrovně citlivosti „normální“=1 a „tajné“=2. Programy instalované v systému (binární soubory) mají úroveň citlivosti 1. Soubory s tajnými daty mají úroveň 2. Smysl prvního pravidla je klasická ochrana před přímým únikem informací. Uživatel s oprávněním na úrovni 1 nemůže číst tajná data, ale uživatel na úrovni 2 může číst a spouštět nainstalované programy. Smysl druhého pravidla je ochrana před nepřímým únikem. Představme si, že uživatel na úrovni 1 prolomí klasickou bezpečnost systému a přepíše binární soubor textového editoru trojským koněm, který každý otevřený soubor uloží na místo, kde si jej může útočník na úrovni 1 přečíst. V MLS systému tento program spuštěný na úrovni 2 nebude mít právo zapisovat do adresáře na úrovni 1, tudíž nedojde k úniku dat.

Je zjevné, že pravidlo č. 2 (no write down) je podstatně silnější omezení, než poskytuje klasické zabezpečení. Ve světě bezpečnosti ale není nikdy nic zadarmo. Obousměrná komunikace mezi úrovněmi 1 a 2 není možná, což vylučuje použití protokolů jako TCP (ACK packety jsou data proudící v „zakázaném“ směru), ve výsledku je uživatel na úrovni 2 odříznut od normální sítě. Dokumenty, které jsou jednou tajné, zůstávají tajné, a v případě odtajnění se musí systém obejít. Tyto systémy mají tedy využití obvykle pouze v prostředí, kde úrovně jako „tajné“ skutečně mají svůj význam, tj. vláda nebo armáda.

Kategorie

Kategorie jsou rozšířením systému MLS o jednu dimenzi. Kategorie si můžeme představit jako tagy, které jednotlivým datům a procesům dáváme, např. „railgun“ a „ufo“. Kategorie, na rozdíl od úrovní citlivosti, nemají mezi sebou striktně určeno pořadí. Platí ale, že k libovolné dvojici lze vybudovat nejmenší horní a největší dolní mez. Pro zmíněné dvě kategorie bude horní mez kombinace obou, tj. „railgun ufo“ a dolní mez žádná kategorie, tj. „“. Proces pak má přístup pouze k datům, jejichž kategorie je obsažena v kategorii procesu (obdoba pravidla „no read up“):

1. Proces bez kategorie nemá přístup k datům kategorie „railgun“ ani k „ufo“.
2. Proces s jednou z kategorií má přístup k datům dané kategorie.
3. Proces s kategorií „railgun ufo“ má přístup k oběma datům.

V závislosti na použitém systému může být také implementováno pravidlo „no write down“:

1. Proces s kategorií „railgun“ nesmí zapisovat do objektů bez kategorie.
2. Proces s kategorií „railgun ufo“ nesmí zapisovat do objektů, které mají pouze kategorii „railgun“ nebo „ufo“ nebo žádnou.

A samozřejmě je možné kategorie a úrovně citlivosti kombinovat: data „citlivost=2 ufo“ může otevřít proces, který má alespoň „citlivost=2“ a alespoň kategorii „ufo“, např. „citlivost=3 ufo railgun“ ano, „citlivost=2“ ne, „citlivost=1 ufo“ také ne.

MLS v SELinuxu

Mechanizmus MLS je implementován pomocí tzv. constraints, což jsou dodatečná omezení, která se na danou operaci aplikují až po úspěšné kontrole mechanizmem TE. Constraints jsou použity i mimo MLS, například celý systém rolí je definován pomocí několika omezení ve stylu „proces nesmí změnit svou roli, až na výjimky (program newrole)“ a „proces smí nabýt pouze takové typy, jaké mu dovoluje jeho role“.

V podobném duchu je implementována sada omezení pro MLS. Pravidla „no read up“ a „no write down“ platí jak pro úrovně citlivosti, tak pro kategorie. Čtvrté a páté pole bezpečnostního kontextu identifikují rozsah úrovní citlivosti a kategorií, který může daný proces nabýt. Za aktuální úroveň se bere spodní hranice rozsahu; pomocí patřičných syscallů lze pak úroveň měnit podobně, jako bychom měnili celý kontext. Citlivosti se označují písmenem s a je jich obvykle 16, kategorie písmenem c a je jich 1024. Rozsah pro kategorie je značen tečkou, seznam kategorií čárkou a rozsah citlivostí pomlčkou. Příkladně:

1. s0:c2,c4-s3:c0.c1023 označuje objekt, který má nejméně nultou úroveň citlivosti a nejméně kategorie 2 a 4, a nejvýše třetí úroveň citlivosti a nejvýše všechny kategorie v rozmezí 0 až 1023. Tj.:

   • s0:c2,c3,c4 (tj. s0:c2.c4) ano,
   • s1:c2,c4,c50 ano,
   • s0 ne,
   • s3:c1 ne,
   • s2:c2 ne.

   Oprávnění, která se použije pro přístup k objektům je spodní mez, tj. s0:c2,c4. Můžeme tedy číst objekty s označeními:

   • s0,
   • s0:c2,
   • s0:c4
   • a s0:c2,c4.

   Podobně, zapisovat můžeme nejníže s0:c2,c4. Pomocí změny kontextu jsme schopni posunout spodní hranici na vyšší citlivost nebo přidat kategorie, a to až do úrovně horní hranice.

2. s0-s0:c0 má nejméně s0 bez kategorie a nejvýše s0 s kategorií c0. Pravidla pro čtení, zápis a změnu úrovně jsou podobná jako výše.
3. s1 má nejméně i nejvýše citlivost s1. Tady je situace nejjednodušší, je dána jen jedna úroveň, kterou nelze měnit.

Pokud si chceme vyzkoušet MLS v praxi, můžeme tak učinit pomocí instalace balíčku selinux-policy-mls a nastavením politiky mls v /etc/selinux/config, ale v závislosti na použité distribuci budeme muset tuto politiku více nebo méně doladit. Případné experimenty nechám na čtenáře.

MCS v SELinuxu

MCS („multi category security“) je slabší odvar politiky MLS, kde platí vše, co bylo dosud řečeno, se dvěma rozdíly. Za prvé, používá se pouze jedna úroveň citlivosti (s0) a za druhé je z omezení odstraněno pravidlo „no write down“. Dále je trochu jinak vyřešeno používání rozsahů kategorií: Proces může číst a zapisovat vše až po svou horní hranici kategorií. Spodní úroveň má význam pouze při vytváření nových souborů, soubor se vytvoří implicitně s touto úrovní, ale pomocí syscallu (ne změny kontextu) lze před vytvořením tuto úroveň změnit. Výše uvedené příklady by se tedy změnily např. takto: Proces s s0:c2-s0:c0.c5 může číst a zapisovat do libovolné kombinace kategorií c0 až c5 a žádné kategorie. Nové soubory budou mít implicitně c2.

Těmito úpravami se v MCS z kategorií stává napůl dobrovolný systém: Aplikace si může dobrovolně určit kategorie v rámci svých mezí, případně je může přímo odstranit. Tato úprava z něj dělá ale systém poněkud více použitelný v „normálním“ světě: Na rozdíl od „čistého“ MLS je MCS přítomno snad ve všech distribucích ve výchozí politice. Jeho přítomnost rozeznáme podle přítomnosti s0 a kategorie v libovolném bezpečnostním kontextu, např. výstup programu id.

Uplatnění MCS je všude tam, kde je potřeba separovat přístup k různým datům v rámci jednoho programu. V minulém díle jsme si uvedli politiku pro SVN a jako jedno z možných rozšíření možnost mít několik repozitářů pro několik projektů a selektivně povolovat uživatelům přístup k projektům. V čistém TE systému bychom nejspíše duplikovali typ svndata_t jako svndata_1_t a svndata_2_t, dále bychom museli rozdělit typy pro běžící svnserve na svn_1_t a svn_2_t, duplikovat jejich pravidla a nakonec nějak zařídit přístup různých uživatelů k různým typům. V klasickém UNIXu bychom separovali pomocí skupin, což je ale náchylné na kompromitaci přes roota, který může číst vše (viz zákeřné getty z dílu číslo 2).

S pomocí MCS můžeme vyřešit problém elegantněji, jednoduše jednomu repozitáři přiřadíme kategorii c0, dalšímu c1, atd. a pak pomocí semanage login přidělíme jednotlivé rozsahy MCS jednotlivým uživatelům (přičemž jejich selinuxová identita a role může zůstat stejná). Jelikož lze kategorie kombinovat, lze jednomu uživateli udělit přístup k několika projektům najednou, což při separaci pomocí TE jde jen s obtížemi. Podobně můžeme jednomu projektu přiřadit více kategorií. Například pokud projekt „app“ používá data z projektů „lib1“ a „lib2“, můžeme projektu „app“ přiřadit kategorie „app lib1 lib2“, čímž se pojistíme proti neautorizovanému přístupu k souborům „lib1“ a „lib2“ přes pouze „app“.

Další možnosti MCS ze stejného soudku jsou:

1. Separace virtuálních mašin při použití KVM. Každé VM přidáme jednu kategorii, čímž je od sebe izolujeme, byť běží pod stejným uživatelem i typem.
2. Separace webových aplikací. Každé aplikaci přiřadíme jinou kategorii, a tudíž napadená aplikace nebude moci ohrozit běh ostatních. Kategorie web serveru lze pak nastavit staticky (více web serverů), nebo dynamicky pomocí selinuxového modulu pro Apache.

Jediná vada na kráse je implicitní kategorie při vytváření nových souborů. Pokud např. přes SVN provedeme commit, vznikne nový soubor, jehož kategorie je momentálně dána spodní úrovní procesu, který jej vytvořil, a nikoli kategorií nadřazeného adresáře, tj. repozitáře. Tuto situaci lze řešit různými hacky od cron úlohy, která nastavuje kategorie, přes patch dané aplikace (např. svnserve) až po patch SELinuxu. Je pravděpodobné, že v budoucnu se tento problém odstraní.

Závěrem a příště

MLS v SELinuxu je implementace modelu Bell-La Padula na operačním systému Linux. Politiku MLS lze využít všude tam, kde je potřeba striktně kontrolovat tok informací. Politika MCS je odvozenina tohoto modelu, kde zejména chybí pravidlo „no write down“. Lze ji využít pro separaci různých dat stejného typu (např. repozitáře patřící různým projektům). MCS je na rozdíl od MLS poměrně nový koncept, je tedy možné, že jeho vlastnosti se do budoucna budou měnit.

V příštím díle se podíváme, co umí SECMARK, spojovací můstek mezi SELinuxem a systémem netfilter (neboli iptables).

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

[Bedňa]

Každý diel si rád prečítam, ale vždy zabudnem to čo bolo v minulom Ako dlho si sa to učil a stretol si sa už z niekym iným čo by mal SELinux na servery bojím sa povedať desktope Ale aj tak je to zaujímavé, raz sa to môže hodiť.

[pht]

Setkal, proto jsem se rozhodl se to naučit. Zabralo asi 1 až 2 týdny než jsem se dostal z nuly k systému, který byl použitelný jako server. Odtud pak už vede cesta tudy, kudy si zvolíte. Pokud se to chcete opravdu naučit, doporučuju vzít nějakou distribuci a zkusit si ji nainstalovat do virtuálu a trochu si s tím pohrát.

Fedora je příklad toho, že SELinux může fungovat i na desktopu (případně hardened gentoo a hardened ubuntu). Mluvit s lidma, kteří SELinux aktivně používají, případně vyvíjejí můžete na freenode #selinux.

[Zdenek]

Proč bych se měl bát něčeho, co nepotřebuji a co nepoužívám?

[alkoholik]

Protoze jisty pan Murphy rika, ze cim vic se necemu vyhybate, tim drive a silneji na to narazite.

[sombreroTX]

Jak to tak sleduji, tak jsem fakt rád za Solarisí TX, je to nesrovnatelne jednodussi, prehlednejsi a dovolim si tvrdit i bezpecnejsi, nejen kvuli implicitní izolaci zón, ale linux je zkrátka bastl, nevěřím tomu, a ještě se s tím takhle srát. Pokud se jedná o nějakou secure architekturu/deployment, tak bych se ani neodvažoval slovo Linux vypustit z úst :)

Autore, znáš TX? Co na to říkáš? (Používají to v US Army :) )

[Bedňa]

somarobreroTX ukáž kde máš ty nasadené tvoje riešenie v super ultra kua bezpečnom Solarise nech Ti ho dáme dole

[pht]

Máte pro takové tvrzení nějaká faktická oddůvodnění, nebo jste jen ukojen pocitem bezpečnosti z něčeho, do čeho sice moc nevidíte, ale tváří se to důvěryhodně?

[snehuliak]

SElinux pouzivam aj ked vacsinou nechavam default nastavenia ktore su vo Fedore/CENT OS a do hlbky som sa este nedostal, ale hadam sa mi to vdaka tomuto serialu podari. Chcel by som sa autora clanku spytat na nazor na RSBAC (www.rsbac.org). Bol vytvoreny skor ako SElinux, ale nikdy nebol zaradeny priamo do kernelu (ak tomu dobre chapem tak z dovodu poklesu vykonnosti). Ak teda poznate aj RSBAC - aky je vas nazor na neho? Pripadne v com je vyhoda SElinuxu (okrem toho ze je v kerneli)?

[pht]

RSBAC jsem nikdy nepoužíval (tj. neznám). Podle informací z jejich webu to může být užitečné, ale taky ne úplně bezbolestné. Vzhledem ke komentářům na stranu LSM se nedivím, že se do jádra nedostal. Ale to nevadí, spousta jiných dobrých věcí v jádře není nebo dlouho nebyla.

Obecná výhoda SELinuxu je v jeho možnostech. Vhodnou konfigurací jste schopen dosáhnout opravdu velmi různorodé nastavení. Hodně lidem to může vadit, ale bohužel zabezpečení počítačů nejde nakupovat na kila v krabicích.

[TM]

Linux jako takový dnes bastl určitě není a troufám si po dlouholeté praxi říci, že proti Solarisu má dnes řadu výhod. Ovšem co se týče SE Linuxu, to je vskutku pozoruhodný příklad toho, jak se dají věci z těžko pochopitelných důvodů uměle zkomplikovat a zamotat - zlaté řešení, používané na Solarisu a zlatý AppArmor, který, nevím proč, umírá.
SE Linux má výhodu v tom, že vám dá pocit úspěšného zdolání překážky. Nesmíte ale řešit, kolik drahocenného času to stálo, protože pak máte vedle rozšířené bezpečnosti na Solarisu pocit provinění.

[pht]

SELinux není komplikovaný ani zamotaný. Jenom Vás staví do pozice kde musíte rozumět všemu co se v systému děje. Překážka, kterou pak překonáváte je spíše tahle. Apparmor umírá, protože při své jednoduchosti nebyl schopen uživatelům dodat, co se po něm žádalo a pokročilí uživatelé narazili na zeď.

[TM]

To ani ne. Problém není v tom rozumět co se v systému děje. Unixoví administrátoři z praxe nejsou takoví blbci, jak si možná myslíte. Největší překážkou je těžko zapamatovatelná změť příkazů, scriptů... a jejich parametrů, pro nováčka zpočátku kryptické výstupy, poněkud zmatená dokumentace atd.
Prostě ten frontend, to je IMHO tragédie. Odpusťte si prosím povýšené poznámky o jakýchsi klikačích, to je pod vaši úroveň.

[pht]

Unixoví administrátoři z praxe nejsou takoví blbci, jak si možná myslíte.

Nevím jestli jste to dobře pochopil, jde o znalost nejen obecných principů, ale i chování konkrétního software na konkrétní distribuci. Kde má uložen apache nebo named konfiguráky, co všechno potřebuje číst, kde jsou init skripty a co všechno spouští, jak se chová hotplug, jaký konkrétní syslog/MTA se používá, jaké všechny NSS/PAM moduly jsou aktivní, ... všechno tohle při psaní politiky může být podstatné.

Největší překážkou je těžko zapamatovatelná změť příkazů, scriptů... a jejich parametrů, pro nováčka zpočátku kryptické výstupy, poněkud zmatená dokumentace atd.

Tak to nevím zase já o čem mluvíte. Takhle se chovají obecně všechny unixové příkazy a těch 5 nebo kolik pro administraci SELinuxu se ničím neliší.

Odpusťte si prosím povýšené poznámky o jakýchsi klikačích, to je pod vaši úroveň.

Nevzpomínám si, že bych nějaké měl.

BTW, téma článku je MLS a jeho pořadové číslo je ⑥. Oceňuji Váš "zájem" o SELinux, ale debatu "SELinux ano nebo ne" bych očekával někde v jedničce.