Nebojte se SELinuxu – 6 (MLS a MCS)

27. 10. 2009 | Michal Svoboda

Články - Nebojte se SELinuxu – 6 (MLS a MCS)  

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.

Seriál SELinux – nebojte se (dílů: 6)

První díl: Nebojte se SELinuxu – 1 (úvod, první spuštění), poslední díl: Nebojte se SELinuxu – 6 (MLS a MCS).
Předchozí díl: Nebojte se SELinuxu – 5 (psaní modulů politiky)