SELinux. Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky. Katedra informačního a znalostního inženýrství Obor aplikovaná informatika

Transkript

1 Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky Katedra informačního a znalostního inženýrství Obor aplikovaná informatika Bakalářská práce SELinux Vypracoval: Ondřej Vadinský Vedoucí práce: RNDr. Radomír Palovský Praha, jaro 2009

2 Toto dílo je licencováno pod licencí Creative Commons Uveďte autora-neužívejte dílo komerčně-nezasahujte do díla 3.0 Česká republika. Pro zobrazení kopie této licence, navštivte nebo pošlete dopis na adresu: Creative Commons, 171 Second Street, Suite 300, San Francisco, California, 94105, USA.

3 Prohlášení Prohlašuji, že jsem vypracoval samostatně bakalářskou práci na téma SELinux. Použitou literaturu a další podkladové materiály uvádím v přiloženém seznamu literatury. V Praze dne 3. května podpis

4

5 Abstrakt Cílem této práce je popsat principy, na kterých je založena technologie SELinuxu. Práce dále zkoumá a hodnotí podporu SELinuxu v několika distribucích. Toto se pak uplatňuje při tvorbě bezpečnostní politiky pro vybraný program. Při popisu základních principů SELinuxu práce čerpá informace z dostupných zdrojů. Pro získání informací o úrovni podpory SELinuxu ve vybraných distribucích dochází k instalaci těchto distribucí a SELinuxu v nich. Následně se pak hodnotí míra uživatelské přívětivosti nabízeného řešení. K sepsání bezpečnostní politiky dochází po analýze situace a stanovení bezpečnostních cílů. Přínosem práce je především vytvoření bezpečnostní politiky pro typovou situaci. Kromě toho práce přináší studii podpory SELinuxu ve vybraných distribucích na základě praktických zkušeností a ukazuje kroky potřebné ke zprovoznění SELinuxu. Struktura práce odpovídá jednotlivým cílům. Pro každý cíl je vyčleněna jedna část práce, která se pak dělí podle potřeb daných tímto cílem. Abstract The goal of this thesis is to describe principles of SELinux technology. Thesis examines and comments level of support of SELinux in some Linux distributions. This is than used for building new security policy for chosen program. To describe basic principles of SELinux the thesis draws information out of many available sources. To find out about how much SELinux is supported in chosen distributions, those distributions are installed and tested. After that level of user-friendliness is valued. Policy building is done after situation analysis and specification of security goals. Contribution of the thesis is in the first place a creation of security policy for type situation. In addition to this thesis contains a study of level of SELinux support in chosen distributions based on practical experience and testing. Thesis also shows how to install and set up SELinux. Structure of thesis respects its goal. For each of them there is one part of thesis, which is than structured according given goal.

6 Obsah Úvod 1 I Principy SELinuxu 3 1 Potřeba bezpečnosti 3 2 Řízení přístupu Diskrétní řízení přístupu (DAC) Diskrétní řízení přístupu v Linuxu Povinné řízení přístupu (MAC) Řízení přístupu založené na rolích (RBAC) SELinux jako způsob realizace bezpečnosti Vývoj SELinuxu Linux Security Modules (LSM) Prvky SELinuxu Bezpečnostní kontext Type Enforcement (TE) Víceúrovňová bezpečnost (MLS) Multi-category Security (MCS) SELinux pravidla Přístupová pravidla Přechodová pravidla Constrains Politika Referenční politika II SELinux v distribucích 14 4 SELinux v Arch Linuxu SELinux a Arch Linux Instalace SELinuxu SELinux kernel Referenční politika Přeznačkování systému souborů a spouštění SELinuxu SELinux ve Fedoře SELinux a Fedora SELinux politiky ve Fedoře Cílená politika (Targeted) MLS politika Minimální politika (Minimum) Integrované nástroje pro SELinux Správce SELinuxu (system-config-selinux) Nástroj na generování politik (selinux-polgengui) SETroubleShoot Další aplikace

7 6 SELinux v Ubuntu SELinux a Ubuntu Instalace SELinuxu SELinux napříč distribucemi 21 III Bezpečnostní politika pro typovou situaci 23 8 Tvorba pravidel a použité nástroje 23 9 Zabezpečení aplikací KDE přistupujících k síti Cíle při zabezpečení KDE aplikací Obecný modul pro KDE aplikace Bezpečnostní kontexty SELinux pravidla Rozhraní modulu Modul pro webový prohlížeč Konqueror Bezpečnostní kontexty SELinux pravidla Rozhraní modulu Zhodnocení vytvořené politiky Závěr 30 Seznam zkratek 31 Reference 32 Přílohy 34 I Modul kde.pp 34 I Soubor s kontexty (kde.fc) II Soubor s pravidly (kde.te) III Soubor s rozhraními (kde.if) II Modul konqueror.pp 38 I Soubor s kontexty (konqueror.fc) II Soubor s pravidly (konqueror.te) III Soubor s rozhraními (konqueror.if)

8

9 Úvod Tématem této bakalářské práce je technologie Security Enhanced Linuxu, zkráceně SELinuxu, která přidává podporu povinného řízení přístupu do operačního systému GNU Linux. 1 Výběr tématu ovlivnilo především to, že aktivně používám Linux jako hlavní operační systém a zajímám se o dění okolo svobodného softwaru. Zároveň v dnešním světě internetu a propojených rozsáhlých počítačových sítí je potřeba dbát na zabezpečení těchto počítačů, kterým jsou často svěřena velmi citlivá data, či které se používají k provádění velmi citlivých operací. SELinux se mi tedy jeví jako technologie, pomocí níž je možné dosáhnout zlepšení současné situace na poli počítačové bezpečnosti. Cílem práce je seznámení se s principy, na kterých SELinux stojí a to jak v oblasti teoretické, tak i v oblasti praktické. Po seznámení se s fungováním SELinuxu, pak následuje zkoumání úrovně jeho podpory v jednotlivých Linuxových distribucích. Na toto pak naváže vytvoření bezpečnostní politiky pro vybranou aplikaci a to v duchu oněch obecných principů. Smyslem této práce je také upozornit jak na SELinux, tak na Linux samotný, od čehož si slibuji zvýšení zájmu o oblast počítačové bezpečnosti a alternativních operačních systémů. Pro seznámení se s obecnými principy SELinuxu poslouží především studium literatury a dalších dostupných zdrojů o této problematice. Konkrétní zkušenosti pak nabudeme při zkoušení distribucí s různou úrovní podpory SE- Linuxu. V této části se zaměříme jak na zástupce distribucí, kde vše funguje po výchozí instalaci, tak na zástupce takových distribucí, kde je potřeba absolvovat celý postup přizpůsobení Linuxového systému SELinuxu. Důvodem je především snaha podtrhnout, co všechno instalace SELinuxu obnáší, a také demonstrovat možnost volby, kterou operační systém GNU Linux svým uživatelům nabízí. Na uživateli je pak ponecháno, jakou cestu si vybere s ohledem na své schopnosti. Metoda pro tvorbu vlastní politiky spočívá ve vytvoření základní kostry politiky pomocí dostupných nástrojů. Na toto navazuje proces zkoušení funkčnosti a správnosti této politiky při reálném nasazení a její vylepšování a rozšiřování na základě odhalených nedostatků. Výsledkem by mělo být dosažení stavu relativní kompletnosti a funkčnosti v rámci omezení daných rozsahem této práce. Práce předpokládá od svých čtenářů základní znalosti operačního systému Linux, počítačové bezpečnosti i samotného SELinuxu. Práce v tomto ohledu není příručkou pro práci se SELinuxem, ani jeho manuálovou stránkou. Nevysvětluje tedy například veškeré volby, kterými lze chod SELinuxu ovlivnit, či veškeré úrovně přístupu, které lze v pravidlech nastavit. Zároveň práce nezachází do přílišných technických detailů architektury SELinuxu či jeho implementace. Tyto informace lze dohledat z uváděných zdrojů, ze kterých práce čerpá. U projektů, o kterých práce hovoří, se také uvádí odkaz na jejich domovskou stránku, který se doporučuje zájemci o další informace navštívit. Omezení práce vyplývají především z jejího rozsahu a časového rámce, který byl na její zpracování vyhrazen. Struktura práce odpovídá výše definovaným cílům. V první části práce se rozebírají principy SELinuxu. Pojednává se o rostoucí potřebě bezpečnosti po- 1 Ačkoliv je správný název operačního systému GNU Linux, tato práce se často drží mnohem běžněji používaného názvu Linux. Linux ovšem v užším slova smyslu znamená pouze jádro systému kernel. Linux ve významu celého operačního systému tak rozšiřuje původní pojem. Stejně tak pro samotné jádro systému používá tato práce častěji pojmu kernel, než Linux. 1

10 čítačových systémů, jednotlivých způsobech řízení přístupu v používaných operačních systémech a konečně i samotném SELinuxu a pojmech a technologiích, se kterými pracuje. Ve druhé části práce se zkoumá podpora SELinuxu ve třech zvolených distribucích. Hovoří se jak o distribuci pro pokročilé uživatele, tak o distribucích zaměřených na běžné uživatele, přičemž se bere zřetel i na míru oblíbenosti těchto distribucí. Závěrem této části se práce zmiňuje o dalších distribucích, které SELinux podporují a také hodnotí současný stav podpory SE- Linuxu mezi nimi. Třetí část práce je vyhrazena komentářům k bezpečnostní politice, která byla během tvorby této práce připravena. Samotné zdrojové kódy bezpečnostní politiky jsou pak obsaženy v přílohách. Zdrojové kódy pak obsahují další komentáře i u běžnějších pravidel, které nejsou komentovány samostatně ve třetí části práce. Pro vyšší srozumitelnost používá práce jednotný způsob zvýrazňování textu. Názvy nástrojů a příkazů jsou sázeny písmem s pevnou šířkou (cat). Stejné písmo se používá pro jednotlivé typy v SELinuxu, názvy rozhraní a podobně. Názvy programů a projektů jsou vyznačeny kurzivou (Konqueror). Konečně URL a Linuxové cesty, které se zalamují v řádcích podle specifických pravidel, jsou sázeny skloněným písmem s pevnou šířkou (/home/nik/.kde/share/ apps/konqueror). Zkratky použité v rámci práce jsou vysvětleny v samotném seznamu zkratek. 2

11 1 Potřeba bezpečnosti Část I Principy SELinuxu Tato část práce se zabývá základy, na kterých SELinux staví. Rozvádí potřebu počítačové bezpečnosti a pojednává o způsobech řízení přístupu. Dále pak rozebírá, jak je SELinux implementován a popisuje důležité pojmy a principy, se kterými se v této oblasti setkáváme. 1 Potřeba bezpečnosti Samotná bezpečnost byla definována v několika uznávaných standardech. Například podle [3] musí bezpečný systém spravovat přístup k informacím tak, aby pouze patřičně autorizovaní jedinci, či procesy pracující v jejich zastoupení, mohly číst, zapisovat, vytvářet a mazat tyto informace. Na bezpečný systém jsou pak kladeny požadavky jako nutnost existence explicitní bezpečnostní politiky, označení objektů přístupovými štítky, 2 identifikace všech zúčastněných subjektů, určení zodpovědnosti na základě logování, 3 ověřitelnost implementace a přetrvávající ochrana. 4 Takovéto pojetí bezpečnosti se však neprosadilo mezi hlavním proudem počítačových systémů, jednak vzhledem k náročnosti implementace a jednak vzhledem k tendenci těchto systémů maximálně usnadnit práci svým uživatelům. Toto se však v současnosti mění. V dnešní době počítače stále více pronikají do různých oblastí lidského života. A to i takových, kdy na nich závisí lidské životy a majetek. Postupně roste množství dat, která počítače spravují, stejně jako jejich závažnost. Dalším důležitým činitelem je vysoká míra propojenosti počítačových systémů. Díky tomu je potřeba tato cenná data chránit a důkladně se zabývat otázkou počítačové bezpečnosti, o čemž se hovořilo již v roce [1] Článek varuje před chybným předpokladem, že bezpečnost může být adekvátně zajištěna aplikacemi bez jistých bezpečnostních funkcí operačního systému a navrhuje povinnou bezpečnost 5 jako řešení problému. Dále [1] podtrhuje nutnost nespoléhat se na jediné technické řešení či mechanizmus, protože bezpečnost je komplexní problém. Tento problém je dodnes patrný a to nejen u běžných domácích uživatelů, ale především ve firemním prostředí. Jednotlivé bezpečností technologie nejsou samy o sobě schopny zajistit potřebnou bezpečnost. Od roku 1998 se problém chybového softwaru stával stále více zřetelným. Stejně tak přibývalo i snah tyto chyby zneužít. [2] 2 Access control labels must be associated with objects. [3] 3 Audit information must be selectively kept and protected so that actions affecting security can be traced to the responsible party. [3] 4 The trusted mechanisms that enforce these basic requirements must be continuously protected against tampering and/or unauthorized changes. [3] 5 Mandatory security 3

12 2 Řízení přístupu 2 Řízení přístupu Řízení přístupu lze obecně chápat jako rozhodování o tom, jaké subjekty smí k danému objektu přistupovat. Řízení přístupu vychází z konceptu referenčního monitoru, 6 které označuje pasivní zdroje operačního systému jako objekty a aktivní zdroje jako subjekty. Objektem je tedy například soubor, subjektem pak běžící proces. Mechanizmus referenčního monitoru pak rozhoduje o přidělení či nepřidělení přístupu danému subjektu k určitému objektu. [2] Podle [4] jde o omezení přístupu ke zdrojům informačního systému pouze na autorizované uživatele, programy, procesy či systémy. Toto omezení přístupu může být řešeno metodami založenými na kvalifikacích 7 nebo na seznamech pro řízení přístupu. 8 [5] Jednotlivé metody řízení přístupu se rozlišují především podle toho, zda jsou diskrétní (volitelné), či povinné. Reálné systémy mohou implementovat víc způsobů řízení přístupu. 2.1 Diskrétní řízení přístupu (DAC) Diskrétním řízením přístupu se rozumí takový způsob omezení přístupu k objektům, který je založený na znalosti identity uživatele (případně i skupiny) a tajné informace pro přístup k objektu. Diskrétnost v tomto případně znamená možnost oprávněného subjektu tato oprávnění přímo či nepřímo předat dalšímu subjektu. [4] Při nasazení v operačním systému nemusí diskrétní řízení přístupu přesně odpovídat výše uvedené definici. Běžně se k diskrétnímu řízení přístupu přidává i prvek vlastníka, který kontroluje udělování přístupových práv. [6] Někdy se také přistupuje k diskrétnímu řízení přístupu pomocí obecnější definice. Diskrétní politikou se pak tedy rozumí taková politika, kde se na tvorbě jejích pravidel či přidělování bezpečnostních atributů podílí přímo běžný uživatel. [1] Diskrétní řízení přístupu je v současnosti implementováno ve většině nejrozšířenějších operačních systémů. Procesy běžící v takovém systému mají tedy stejná oprávnění jako uživatel, který je spustil. Rizikovost této situace je tedy do určité míry ovlivněna návyky uživatele (například tím, jaké procesy spouští pod rootem), přesto je ale v případě kompromitace procesu zranitelná oblast vskutku velká. Problém s diskrétním řízením přístupu spočívá v tom, že staví na principech uživatele, který udělí přístup jinému uživateli, jemuž důvěřuje, ke svému souboru. Ve skutečnosti ale k danému souboru nepřistupuje uživatel přímo, ale prostřednictvím nějakého softwaru. To, že tento software obsahuje chyby, je nesporné. Stejně tak pokud má tedy k danému souboru přístup software, tak k němu má přístup i škodlivý software. Diskrétní řízení přístupu tedy selhává v rozlišení mezi lidským uživatelem počítače a programy, které uživatele zastupují. [2] 6 Reference Monitor Concept 7 Capabilities, Capability-based security 8 ACL, Access Control list 4

13 2 Řízení přístupu Diskrétní řízení přístupu v Linuxu Linux používá pro subjekty identifikátory takzvaného skutečného 9 a efektivního 10 uživatele a skupiny. Skutečný uživatel je ten, který proces spustil, efektivní je ten, jehož práva proces používá. Obvykle jsou pro proces oba dva stejní, v případě procesu se SUID bitem je efektivní uživatel vlastník spustitelného souboru, který už nemusí být totožný s uživatelem, jenž jej spustil. Přiřazení identifikátorů je chráněno kernelem a zajišťováno procesy jako login a setuid. [2] U objektů existuje v inodě souboru skupina přístupových bitů spolu s identifikátory vlastníka a skupiny. Přístupové bity povolují čtení, zápis a spuštění souboru pro vlastníka, členy skupiny a všechny ostatní. [2] Pro případ důvěryhodných aplikací existuje SUID bit, který mění efektivního uživatele na vlastníka, obvykle roota, jehož práva potřebuje k vykonání důvěřované změny (například změny hesla uživatele). Taková aplikace pak získává plná přístupová práva k celému systému, což přináší velká bezpečnostní rizika související s nevyhnutelnou existencí nepředvídané chyby. [2] 2.2 Povinné řízení přístupu (MAC) Povinným řízením přístupu se chápe takový způsob omezení přístupu k objektům, který je založený na citlivosti informace obsažené v objektu, a formální autorizaci subjektu, která mu umožňuje přistupovat k takto citlivé informaci. [4] Povinné řízení přístupu je ze své definice i vzhledem ke svému vývoji propojené s MLS. 11 MLS je pro běžné nasazení přeci jen poněkud striktní, proto se někdy přistupuje k obecnější definici. Povinným řízením přístupu se pak chápe takové omezení přístupu, které je založené na bezpečnostní politice, jejíž logiku i přidělení bezpečnostních atributů spravuje bezpečnostní administrátor. [1] Subjekty i objekty v tomto systému mají přiřazeny množinu bezpečnostních atributů. V okamžiku, kdy se subjekt pokouší přistoupit k objektu, dojde na základě bezpečnostních pravidel (tzv. politiky), která vynucuje kernel operačního systému, k prozkoumání těchto atributů a následnému rozhodnutí, zda udělit požadovaný přístup. [7] Politika v systému s povinným řízením přístupu je ve správě bezpečnostního administrátora, který ji jediný může upravovat. Uživatelé tedy nemají možnost předávat svá práva dál. Bezpečnostním administrátorem nasazená politika je tak principiálně vynutitelná pro všechny uživatele a to i v rozsahu celé organizace. [7] V systému s povinným řízením přístupu musí existovat aplikace, které vyžadují zvláštní privilegia, aby mohly vykonávat funkce ovlivňující bezpečnost systému. Protože tyto privilegované aplikace mohou představovat pro systém bezpečnostní hrozbu, aplikuje se na ně často princip minimálních privilegií. Příkladem mechanizmu, který slouží k vynucování minimálních privilegií je type enforcement. 12 [1] Povinné řízení přístupu lze využít k uzavření jednotlivých aplikací do jedinečných bezpečnostních domén, které jsou navzájem od sebe odděleny. Kompromitace takto uzavřené aplikace pak může vést pouze ke kompromitaci její domény, zbytek systému zůstává chráněný. Tato výhoda zůstává patrnou i na 9 Real user 10 Effective user 11 Viz sekce MLS 12 Viz sekce Type Enforcement 5

14 3 SELinux jako způsob realizace bezpečnosti běžných systémech, kde je pouze jeden uživatel vystupující jak ve své roli uživatele, tak v roli bezpečnostního administrátora. V takovém případě může chránit systém před kompromitací škodlivým kódem, ať už se jedná přímo o malware, nebo jen o chybně naprogramovanou aplikaci. [1] Příkladem současných implementací povinného řízení přístupu může být: [7] NSA SELinux, který je součástí Linuxu 2.6 a vyššího. Novell AppArmor, který se používá v opensuse 13 a Ubuntu. 14 Mandatory Integrity Control, který je součástí Windows od verze Vista a Windows Server od verze TrustedBSD, který je dostupný pro FreeBSD 15 od verze 5.0. Trusted Solaris Tyto implementace se liší jak podporovanými platformami, tak i svými vlastnostmi a především svou robustností. 2.3 Řízení přístupu založené na rolích (RBAC) Řízení přístupu založené na rolích přiřazuje jednotlivým uživatelům systému role. Tyto role mohou například odpovídat funkcím těchto uživatelů v organizaci. Práva pro vykonání určitých operací se pak přiřazují jednotlivým rolím, nikoliv přímo uživatelům. [8] Tento přístup je alternativou k diskrétnímu a povinnému řízení přístupu, přičemž může obě dvě alternativy simulovat. Pomocí povinného řízení přístupu je pak možné vytvořit řízení přístupu založené na rolích. [8] Vzhledem k použití rolí je snazší spravovat uživatelské účty a jim přidělená práva. Tato práva se zpravidla nevztahují k jednotlivým souborům v systému, ale spíše ke specifickým operacím, které mají pro organizaci nějaký význam. [8] 3 SELinux jako způsob realizace bezpečnosti SELinux, plným názvem Security Enhanced Linux, je technologie sloužící k zabezpečení počítačových systémů, která má za sebou kolem čtyřiceti let výzkumu na poli bezpečnosti operačních systémů. Přináší mocný a flexibilní mechanizmus povinného řízení přístupu zakomponovaný do široce dostupného operačního systému. [2] Jak již bylo zmíněno v sekci 1 Potřeba bezpečnosti, software, který používáme, obsahuje chyby a sítě, které propojují počítače, jsou nebezpečným prostředím. SELinux dokáže ochránit systém jak před vnějším útokem, tak před chybně napsanou aplikací. Jeví se tedy jako vhodné řešení této situace. Zároveň bylo poznamenáno, že bezpečnost systému se musí řešit na úrovni operačního systému, nikoliv až na úrovni vlastní aplikace. I toto SELinux, který je zakomponovaný do jádra operačního systému, řeší. 13 Více viz domovská stránka projektu: 14 Více viz domovská stránka projektu: 15 Více viz domovská stránka projektu: 6

15 3 SELinux jako způsob realizace bezpečnosti Cílem projektu je vytvořit bezpečnější počítačový systém. Tuto situaci pak udržet a to hlavně v oblasti široce dostupných operačních systémů. Konkrétně SELinux nabízí type enforcement spolu s druhem řízení přístupu založeného na rolích a volitelnou tradiční víceúrovňovou bezpečnost. Jednotlivé mechanizmy nabízené SELinuxem fungují jako nadstavby nad tradičním diskrétním přístupem. K získání přístupu musí tedy být splněny požadavky všech použitých mechanizmů pro řízení přístupu. [2] 3.1 Vývoj SELinuxu SELinux vychází z výzkumů bezpečných systémů v osmdesátých letech dvacátého století. Konkrétně šlo o projekt LOCK přinášející type enforcement 16 a projekt Trusted Mach přinášející zakomponování víceúrovňové bezpečnosti 17 do jádra. Tyto projekty se sloučily do projektu DTMach, kterého se účastnila americká NSA. Výstupem jejího výzkumu byla nová bezpečnostní architektura označená jako Flask, která přinesla flexibilnější a dynamickou verzi mechanizmu type enforcement. [2] NSA dále rozpoznala nutnost vystavit vzniklou bezpečnostní architekturu širší komunitě a proto začalo v roce 1999 implementovat Flask do Linuxového kernelu. Koncem roku 2000 došlo k prvnímu veřejnému vydání ve formě jaderných patchů s názvem SELinux. S rostoucím zájmem o SELinux došlo ke vzniku projektu LSM, 18 jehož cílem bylo vytvořit flexibilní framework pro Linuxový kernel, který by umožnil využití různých bezpečnostních rozšíření. LSM byl zařazen do jádra 2.6 následovaný v roce 2003 i SELinuxem tentokrát ve formě LSM jaderného modulu. [2] Po začlenění do jádra začaly distribuce do různé míry používat SELinux. Největší přínos má na tomto poli společnost Red Hat, která SELinux začlenila do své komunitní distribuce Fedora Core. 19 Spolu s NSA a komunitou se pak podílela na vytvoření nástrojů pro uživatelský prostor a dalším začlení do distribuce určené pro široké nasazení. Toto úsilí vyvrcholilo vydáním Red Hat Linux Enterprise 4 20 v roce 2005, který měl ve výchozí instalaci plně povolen SELinux. [2] V současné době probíhá vývoj SELinuxu a spjatých projektů na několika místech. Jaderný kód je spravován komunitou v rámci vývoje jádra. 21 Nástroje uživatelského prostoru (projekt SELinux Userspace) 22 a referenční politiku (projekt SELinux Refpolicy) 23 vyvíjí komunita zaštítěná firmou Tresys Technology. 3.2 Linux Security Modules (LSM) Linux Security Modules je projekt, který přidává obecný framework pro řízení přístupu do Linuxového kernelu. Framework je dostupný pod licencí GPL a je součástí jádra od verze 2.6. [9, 10] 16 Viz sekce Type Enforcement 17 Viz sekce Víceúrovňová bezpečnost 18 Viz sekce 3.2 LSM 19 Více viz domovská stránka projektu: 20 Distribuce Red Hat Linux Enterprise se také někdy označuje jako RHEL 21 Více viz domovská stránka: 22 Více viz domovská stránka: 23 Více viz domovská stránka: 7

16 3 SELinux jako způsob realizace bezpečnosti Idea Linux Security Modules Frameworku spočívá ve vložení jaderného modulu, který upřesní výchozí diskrétní řízení přístupu, do Linuxového jádra. [2] Cílem projektu bylo vytvořit skutečně obecný framework, který nebude závislý na zvoleném bezpečnostním modelu a zároveň přinese minimum zásahů do jádra systému. Výsledkem je přidání systémového volání pro LSM v okamžiku, kdy je povolen přístup standardními kontrolními mechanizmy kernelu, zejména diskrétním řízením přístupu. Na základě odpovědi LSM, zda je takovýto přístup v pořádku či ne, pak dojde k finálními povolení, nebo zamítnutí přístupu. [9] Výsledkem takové implementace jsou zanedbatelné dopady na výkonnost systému v reálném použití a pouze minimální zhruba pětiprocentní zpomalení v syntetických testech. [9] Linux Security Modules Framework byl vyvíjen, jako rámec potřebný pro začlenění SELinuxu, o kterém se předpokládalo, že nebude jediným možným řešením bezpečného řízení přístupu v Linuxu. Přesto však byl velkou část své doby existence používán především SELinuxem, a proto jsou i jeho funkce SELinuxu nejvíce přizpůsobeny. [10] Ačkoliv se situace s využitím LSM jiným projekty neustále zlepšuje, tak z pohledu některých specifičtějších bezpečnostních projektů zůstávají v LSM některé nedostatky v implementaci. V současné době není zcela uspokojivě řešeno využívání více různých bezpečnostních modulů současně. [10] SELinux byl po vzniku LSM upraven do podoby bezpečnostního modulu, který je s LSM kompatibilní. Zjednodušeně řečeno tento modul obsahuje část bezpečnostního serveru, která se stará o vlastní vyhodnocování politiky. Prostřednictvím další části, SELinuxového systému souborů, je možné měnit některá nastavení a zjišťovat stav SELinuxu. Pokud je modul SELinuxu dotázán na povolení přístupu, konzultuje nejprve vlastní vyrovnávací paměť. Do té totiž bezpečnostní server ukládá svá předchozí rozhodnutí. [2] 3.3 Prvky SELinuxu V této sekci následuje výčet některých důležitých prvků a principů, na kterých je SELinux založen, případně se kterými pracuje Bezpečnostní kontext Řízení přístupu v operačních systémech spoléhá na přiřazení přístupových atributů jednotlivým subjektům a objektům. SELinux nazývá tyto atributy bezpečnostní kontext. V SELinux může mít každý objekt či subjekt pouze jeden bezpečnostní kontext, který se však skládá z více částí. Minimálně jde o trojici názvů pro uživatele, roli a typ, ke kterým může přibýt označení úrovně citlivosti, případně označení jedné či více kategorií. 24 [2] Základní kontext může vypadat například takto: user_u:object_r:user_home_t V takovém případě user u označuje SELinux uživatele (konkrétně jde o výchozího neprivilegovaného uživatele), object r určuje roli (jde tedy o objekt například soubor) a user home t znamená typ (ze kterého lze vyvozovat, že se nachází v domovském adresáři uživatele). 24 Více viz sekce Víceúrovňová bezpečnost (MLS) a Multi-category Security (MCS) 8

17 3 SELinux jako způsob realizace bezpečnosti Názvy identifikátorů určuje tvůrce politiky a je možné mít jeden název jak pro typ, tak i roli či uživatele, ačkoliv se toto kvůli přehlednosti nedoporučuje. V praxi se dodržuje konvence, která přidává za označení SELinux uživatele u, za označení role r a za označení typu t. [2] SELinux používá k rozhodování o udělení přístupu bezpečnostní kontext subjektu a objektu. Reálně jde především o identifikátor typu. [2] Vzhledem k používání type enforcement, 25 mají SELinux uživatelé a role pro objekt mizivý vliv na udělení přístupu. U subjektů rozhoduje SELinux uživatel a role o asociaci povolených typů pro Linuxové uživatele. [2] SELinux uživatel a Linuxový uživatel jsou na sobě zcela nezávislé identifikátory, jejichž jména mohou být shodná. Jakákoliv souvislost ale musí být explicitně určena mimo oblast vynucovanou SELinux politikou. Nastavení se provádí v konfiguračních souborech v adresáři /etc/selinux/refpolicy/ users/. [2] Příklad pokročilého kontextu, který obsahuje i úrovně citlivosti a kategorie následuje: user_u:object_r:user_home_t:s0:c24.c25 Přidané označení úrovně citlivosti s0 říká, že jde o data nejméně citlivá, která dále spadají do kategorie c24 a c25. Pro uživatelskou srozumitelnost budou tyto obecné názvy bezpečnostním administrátorem přeloženy do běžného jazyka, jak zmiňují části Víceúrovňová bezpečnost (MLS) a Multicategory Security (MCS) Type Enforcement (TE) Type enforcement je flexibilní mechanizmus povinného řízení přístupu. Poskytuje robustní povinnou bezpečnost, kterou lze přizpůsobit velkému množství bezpečnostních cílů. Umožňuje řídit přístup na úrovni jednotlivých programů. Type enforcement přiřazuje všem subjektům a objektům takzvaný typ. Aby mohl subjekt přistoupit k objektu, musí být typ toho subjektu autorizován pro přístup k typu daného objektu. [2] Type enforcement stojí na principu minimálních privilegií, 26 který říká, že každá vrstva či modul (například proces, uživatel, či program) smí mít povolený přístup pouze k takovým informacím a zdrojům, které jsou nezbytně nutné pro jeho legitimní účel. 27 V praxi vede použití toho principu k omezení přístupu subjektů jen na ty objekty, které nezbytně potřebují. Toto snižuje riziko poškození systému kompromitovaným subjektem, i riziko samotné kompromitace subjektu. [11] SELinux pak jednotlivým typům přiřazuje konkrétní práva. Tato práva jsou oproti Linuxovým mnohem jemnější. Nevybírá se tedy z pouhého čtení, zápisu a spustitelnosti, ale například i čtení atributů souboru a dalších. [2] Na type enforcement je založen celý SELinux. Všechny dostupné politiky přiřazují typ subjektům i objektům. V případě subjektů se také hovoří o doménách. 28 SELinux nakládá stejně se všemi subjekty či objekty ze stejné domény, 25 Viz sekce Type Enforcement (TE) 26 Principle of least privilege 27 Legitimate purpose 28 Pojem doména a typ jsou však volně zaměnitelné. 9

18 3 SELinux jako způsob realizace bezpečnosti tedy s těmi, které mají stejný typ. To, jak se bude se subjekty a objekty nakládat, určují dva základní typy pravidel a sice přechodová (umožňující změnit doménu, ve které proces běží po splnění podmínek) 29 a přístupová (umožňující procesu přistupovat k prvkům systému). 30 [16] Základní myšlenkou type enforcement je rozdělení celého systému na menší části, takzvaná pískoviště, 31 kde bude mít patřičný proces povolen pouze specifikované a nastavené operace. Protože ale existují komplexní procesy jako třeba init, mohly by být vytvořená pískoviště příliš velká, což by výrazně oslabilo jejich přínos. Z toho důvodu existují přechodová pravidla, která umožní procesu přejít mezi více malými doménami s různými oprávněními vytvořenými namísto jedné velké domény s rozsáhlými oprávněními. [16] Víceúrovňová bezpečnost (MLS) Víceúrovňovou bezpečností se rozumí koncept zpracování informací, jenž jsou rozdílně klasifikované a mají rozdílné kategorie, který současně povoluje přístup uživatelům s různým bezpečnostním prověřením a zakazuje přístup neautorizovaným uživatelům. [4] Víceúrovňová bezpečnost zavádí úroveň citlivosti informací. Uživatel s vyšším bezpečnostním prověřením může přistupovat k citlivějším informacím. Zároveň také může přistoupit k informacím méně citlivým, než je jeho prověření. Citlivý dokument může být po sanaci, 32 tj. očištění o citlivé informace, nasdílen uživatelům s menší úrovní prověření. Toto ovšem není jednoduché a záleží na konkrétní implementaci, zda je to možné. [14] Bell-La Padulův model, na kterém jsou většinou implementace víceúrovňové bezpečnosti založeny, zavádí principy no read-up a no write-down, tedy striktně zakazuje čtení informací s vyšší citlivostí stejně jako striktně zakazuje zapisovat informace s nižší citlivostí, než jaké je prověření uživatele. [13] V SELinuxu se implementuje obvykle šestnáct úrovní citlivosti, obecně označených jako s0-s Jako s0 se označují nejméně citlivá data, s15 pak slouží pro data nejcitlivější. Pokud je citlivost přiřazena objektu, pak se chápe jako prověření, u subjektu jde o klasifikaci. [16] Data s jednotlivou úrovní citlivosti je dále možné členit do kategorií v rozmezí c0-c1023. Těchto kategorií může být jedné úrovni citlivosti přiřazeno více, nebo také žádná. K prosazení víceúrovňové bezpečnosti se v rámci SELinuxu používají constrains, konkrétně mlsconstrains. 34 [16] Podpora víceúrovňové bezpečnosti v SELinuxu je volitelná. Jí uložená omezení se vyhodnocují po ostatních částech politiky a systémovém diskrétním řízení přístupu. Obecně se považuje za méně důležitý mechanizmus povinné bezpečnosti. [2] 29 Viz sekce Přechodová pravidla 30 Viz sekce Přístupová pravidla 31 Sandbox 32 Sanitization 33 Je na aplikacích uživatelského prostoru či bezpečnostním administrátorovi, aby v nastavení přiřadili obecným názvům úrovně citlivosti a kategorií jejich srozumitelné konkrétní slovní vyjádření. [2] 34 Viz sekce Constrains 10

19 3 SELinux jako způsob realizace bezpečnosti Multi-category Security (MCS) Multi-category Security neboli MCS se rozumí úprava víceúrovňové bezpečnosti, která umožňuje uživateli označkovat soubory nehierarchickými kategoriemi. Z technického hlediska jde o změnu politiky a několik souvisejících změn v uživatelském prostoru a kernelu, které skrývají nevyužité části víceúrovňové bezpečnosti a usnadňují přechod na MCS. [15] MCS vychází z víceúrovňové bezpečnosti a jako taková používá její podporu v SELinuxu. Nepoužívá ale Bell-La Padulův model a všechna data v systému souborů značkuje stejnou citlivostí s0. Díky tomu odpadají problémy spjaté s Bell-La Padulovým modelem, například problém s přenosem informací od uživatele s vyšším prověřením k uživateli s nižším prověřením. [16] MCS tedy reálně používá pouze rozdělení subjektů a objektů do kategorií. Přístup k objektu je povolen pouze těm subjektům, které mají stejnou kategorii jako objekt. MCS se vyhodnocuje až po ostatních řízeních přístupu v systému. [16] 3.4 SELinux pravidla Následuje popis a ukázky některých typů type enforcement pravidel, která se v SELinuxu používají. Další pravidla pak obsahuje část III Bezpečnostní politika pro typovou situaci Přístupová pravidla Jediným způsobem, který v SELinuxu umožňuje povolit přístup subjektů k objektům, jsou přístupová pravidla. Situace je o to komplikovanější, že cílem není povolit veškerý přístup subjektů k objektům, ale pouze ten žádoucí. Jak již bylo zmíněno v sekci Type Enforcement (TE), mělo by se při návrhu pravidel vycházet z principu minimálních privilegií, tudíž by měl tvůrce politiky povolit pouze nezbytně nutný přístup. [2] Příkladem přístupového pravidla může být: allow konqueror_t user_konqueror_home_t : file \ {read getattr write create rename unlink lock}; Subjektu s typem konqueror t se povoluje číst, získávat atributy, zapisovat, vytvářet, přejmenovat, rušit odkazy a zamykat objekt třídy soubor s typem user konqueror home t. Formálně se přístupové pravidlo skládá ze zdrojového a cílového typu či typů, třídy objektu či objektů a množiny práv. [2] Zdrojovým typem je typ přistupujícího subjektu (konqueror t). Cílovým typem je typ přistupovaného objektu (user konqueror home t). Třídou objektu je soubor (file) a množinou práv jsou jednotlivé operace se souborem. Pro celkovou funkčnost je samozřejmě nutné, aby byl přístup povolen jak standardním Linuxovým diskrétním řízením přístupu tak i SELinux přístupovým pravidlem. [2] Přechodová pravidla Problém doménového přechodu spočívá v nutnosti zajistit, že pouze určité pověřené programy budou moci přistupovat k určitým oprávněným doménám. Zá- 11

20 3 SELinux jako způsob realizace bezpečnosti roveň musí být tento proces přechodu zajištěn před zneužitím. Situace a opodstatnění existence doménového přechodu je analogická situaci se SUID bitem v klasickém Linuxu, jak byla nastíněna v sekci Diskrétní řízení přístupu v Linuxu. [2] Oproti přístupovým pravidlům se přechodové pravidlo skládá z několika dílčích pravidel, která dohromady umožňují výskyt doménového přechodu: [2] Nová doména procesu má oprávnění přístupového bodu 35 k doméně spustitelného souboru. Současná doména procesu musí mít právo na spuštění souboru označeného v předchozím bodě jako přístupový bod. Současná doména procesu má právo přechodu do nové domény. Příkladem celého přechodového pravidla může být: allow konqueror_t konqueror_exec_t : file entrypoint; allow user_t konqueror_exec_t : file {getattr execute}; allow user_t konqueror_t : process transition; Typ konqueror exec t (spustitelný soubor prohlížeče Konqueror) může vstoupit do domény konqueror t. Subjekt s typem user t smí získávat atributy a spouštět soubor s typem konqueror exec t. A konečně subjekt s typem user t smí přejít do domény konqueror t. Ve výchozí situaci je doménový přechod možný, nikoliv nutný a uživatel si tedy musí o přechod požádat. Toto je v mnoha případech nepraktické (viz příklad s prohlížečem). Z toho důvodu se přidává ještě takzvané výchozí přechodové pravidlo, které je vykonáno pokud uživatel neurčí jinak. [2] Výchozí přechodové pravidlo může vypadat následovně: type_transition user_t konqueror_exec_t : \ process konqueror_t; Typ user t přejde ve výchozím stavu prostřednictvím typu spustitelného souboru konqueror exec t do domény konqueror t Constrains Constrains pravidla nadále zpřísňují ostatní SELinuxová pravidla. SELinux je implementuje pomocí newerallow pravidel, jejich konstrukce odpovídá běžným if-then-else výrazům. Rozhodování probíhá na základě vztahů ve dvojici zdrojového a cílového SELinux uživatele, role, typu či jejich atributu. [16] Účelem constrains pravidel je prosazení globálních pravidel a omezení pro určitá práva bez ohledu na přístupová práva, která jsou součástí politiky. Constrains se vyhodnocují před finálním udělením přístupu v rámci bezpečnostního serveru. [2] Využití constrains pravidel spočívá v provedení pokročilých kontrol, které udrží konzistenci politiky. Je tak možné například zamezit procesu, aby přešel do typu, který není určený pro proces, či naopak, aby byl souboru přiřazen typ, který není určený pro soubor. [16] Příkladem constrains pravidla může být následující, které bylo přejato z [2]: 35 Entrypoint 12