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

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

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 http://creativecommons.org/licenses/by-nc-nd/3.0/cz/ nebo pošlete dopis na adresu: Creative Commons, 171 Second Street, Suite 300, San Francisco, California, 94105, USA.

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 2009

................................... podpis

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.

Obsah Úvod

1

I

3

Principy SELinuxu

1 Potřeba bezpečnosti

3

2 Řízení přístupu 2.1 Diskrétní řízení přístupu (DAC) . . . . . . . 2.1.1 Diskrétní řízení přístupu v Linuxu . 2.2 Povinné řízení přístupu (MAC) . . . . . . . 2.3 Řízení přístupu založené na rolích (RBAC)

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

4 4 5 5 6

3 SELinux jako způsob realizace bezpečnosti 3.1 Vývoj SELinuxu . . . . . . . . . . . . . . . 3.2 Linux Security Modules (LSM) . . . . . . . 3.3 Prvky SELinuxu . . . . . . . . . . . . . . . 3.3.1 Bezpečnostní kontext . . . . . . . . 3.3.2 Type Enforcement (TE) . . . . . . . 3.3.3 Víceúrovňová bezpečnost (MLS) . . 3.3.4 Multi-category Security (MCS) . . . 3.4 SELinux pravidla . . . . . . . . . . . . . . . 3.4.1 Přístupová pravidla . . . . . . . . . 3.4.2 Přechodová pravidla . . . . . . . . . 3.4.3 Constrains . . . . . . . . . . . . . . 3.5 Politika . . . . . . . . . . . . . . . . . . . . 3.5.1 Referenční politika . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

6 7 7 8 8 9 10 11 11 11 11 12 13 13

II

SELinux v distribucích

4 SELinux v Arch Linuxu 4.1 SELinux a Arch Linux . . . . . . . . . 4.2 Instalace SELinuxu . . . . . . . . . . . 4.2.1 SELinux kernel . . . . . . . . . 4.2.2 Referenční politika . . . . . . . 4.2.3 Přeznačkování systému souborů

14 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a spouštění SELinuxu

5 SELinux ve Fedoře 10 5.1 SELinux a Fedora . . . . . . . . . . . . . . . . . . . . . 5.2 SELinux politiky ve Fedoře . . . . . . . . . . . . . . . . 5.2.1 Cílená politika (Targeted) . . . . . . . . . . . . . 5.2.2 MLS politika . . . . . . . . . . . . . . . . . . . . 5.2.3 Minimální politika (Minimum) . . . . . . . . . . 5.3 Integrované nástroje pro SELinux . . . . . . . . . . . . . 5.3.1 Správce SELinuxu (system-config-selinux) . . . . 5.3.2 Nástroj na generování politik (selinux-polgengui) 5.3.3 SETroubleShoot . . . . . . . . . . . . . . . . . . 5.3.4 Další aplikace . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . .

. . . . .

14 14 14 15 16 16

. . . . . . . . . .

. . . . . . . . . .

18 18 18 18 19 19 19 19 19 19 20

6 SELinux v Ubuntu 8.10 20 6.1 SELinux a Ubuntu . . . . . . . . . . . . . . . . . . . . . . . . . . 20 6.2 Instalace SELinuxu . . . . . . . . . . . . . . . . . . . . . . . . . . 20 7 SELinux napříč distribucemi

21

III

23

Bezpečnostní politika pro typovou situaci

8 Tvorba pravidel a použité nástroje 9 Zabezpečení aplikací KDE přistupujících k 9.1 Cíle při zabezpečení KDE aplikací . . . . . 9.2 Obecný modul pro KDE aplikace . . . . . . 9.2.1 Bezpečnostní kontexty . . . . . . . . 9.2.2 SELinux pravidla . . . . . . . . . . . 9.2.3 Rozhraní modulu . . . . . . . . . . . 9.3 Modul pro webový prohlížeč Konqueror . . 9.3.1 Bezpečnostní kontexty . . . . . . . . 9.3.2 SELinux pravidla . . . . . . . . . . . 9.3.3 Rozhraní modulu . . . . . . . . . . . 9.4 Zhodnocení vytvořené politiky . . . . . . .

23 síti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

24 24 25 25 25 26 27 27 27 28 29

Závěr

30

Seznam zkratek

31

Reference

32

Přílohy

34

I

Modul kde.pp 34 I Soubor s kontexty (kde.fc) . . . . . . . . . . . . . . . . . . . . . . 34 II Soubor s pravidly (kde.te) . . . . . . . . . . . . . . . . . . . . . . 34 III Soubor s rozhraními (kde.if) . . . . . . . . . . . . . . . . . . . . . 35

II Modul konqueror.pp 38 I Soubor s kontexty (konqueror.fc) . . . . . . . . . . . . . . . . . . 38 II Soubor s pravidly (konqueror.te) . . . . . . . . . . . . . . . . . . 39 III Soubor s rozhraními (konqueror.if) . . . . . . . . . . . . . . . . . 42

Ú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 SELinuxu. 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 po1 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

čí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 SELinuxu 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

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 1998. [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] 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 ”Audit

3

2

Řízení přístupu

2


Ří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 Capability-based security 8 ACL, Access Control list 7 Capabilities,

4

2

2.1.1


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 sekce 3.3.3 MLS 12 Viz sekce 3.3.2 Type Enforcement 11 Viz

5

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 2008. • 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, 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: http://www.opensuse.org/ viz domovská stránka projektu: http://www.ubuntu.com/ 15 Více viz domovská stránka projektu: http://www.freebsd.org/ 14 Více

6

3


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 3.3.2 Type Enforcement sekce 3.3.3 Víceúrovňová bezpečnost 18 Viz sekce 3.2 LSM 19 Více viz domovská stránka projektu: http://fedoraproject.org/ 20 Distribuce Red Hat Linux Enterprise se také někdy označuje jako RHEL 21 Více viz domovská stránka: http://www.kernel.org/ 22 Více viz domovská stránka: http://userspace.selinuxproject.org/ 23 Více viz domovská stránka: http://oss.tresys.com/projects/refpolicy 17 Viz

7

3


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. 3.3.1

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 3.3.3 Víceúrovňová bezpečnost (MLS) a 3.3.4 Multi-category Security (MCS)

8

3


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 3.3.3 Víceúrovňová bezpečnost (MLS) a 3.3.4 Multicategory Security (MCS). 3.3.2

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 3.3.2 Type Enforcement (TE) of least privilege 27 Legitimate purpose 28 Pojem doména a typ jsou však volně zaměnitelné. 26 Principle

9

3


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]

3.3.3

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-s15. 33 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 3.4.2 Přechodová pravidla sekce 3.4.1 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 3.4.3 Constrains 30 Viz

10

3

3.3.4


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. 3.4.1

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 3.3.2 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] 3.4.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

3


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 2.1.1 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. 3.4.3

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

3


constrain process transition (u1 == u2 and r1 == r2); Toto pravidlo dovolí procesu uskutečnit doménový přechod pouze pokud se nezmění jeho SELinux uživatel ani jeho role. Zápis říká, že zdrojový SELinux uživatel se musí shodovat s cílovým (u1 == u2) a současně se zdrojová role musí shodovat s cílovou (r1 == r2). [2]

3.5

Politika

SELinux nepředdefinuje žádná bezpečnostní přístupová pravidla, ani je nijak nekóduje do svého jádra. Ve výchozím stavu nepovoluje SELinux vůbec nic. K tomuto účelu používá takzvanou politiku. [2] SELinux politikou se rozumí sbírka jednotlivých bezpečnostních pravidel, která povolují přístup k jednotlivým částem systému. Fyzicky jde o zvláštní soubor, případně skupinu souborů, kompilovaný ze zdrojových souborů. Tento soubor je načten při startu systému do jádra a na jeho základě se pak dělají jednotlivá rozhodnutí o povolení či zamítnutí přístupu. [2] 3.5.1

Referenční politika

Projekt referenční politiky restrukturalizoval vzorovou politiku NSA a stal se tak novým základem pro většinu bezpečnostních politik v distribucích používajících SELinux. Za tímto projektem stojí komunita sponzorovaná a podporovaná firmou Tresys Technology. [17] Vyvíjená politika si klade několik bezpečnostních cílů. Jednak jde o ochranu samotného systému a jednotlivých programů, dále pak důvěryhodnost celé politiky a všech jejích komponent. Důležitým cílem je také bezpečná rozšiřitelnost o pravidla pro další aplikace a služby. [17] Vlastní návrh politiky využívá principy vrstev, modulárnosti, zapouzdření a abstrakce. Kromě toho také každý modul používá rozhraní pro komunikaci s ostatními. [17]

13

4

SELinux v Arch Linuxu

Část II

SELinux v distribucích V této části se zaměříme na implementaci SELinuxu v některých distribucích. V jedné z nich podrobně popíšeme kroky potřebné ke zprovoznění SELinuxu. Úroveň podpory a způsob implementace SELinuxu v této distribuci pak srovnáme s několika dalšími distribucemi.

4


Arch Linux 36 je Linuxová distribuce, která si klade za cíl jednoduchost návrhu (princip KISS) 37 a vysokou přizpůsobivost systému. Distribuce je tzv. Rolling Release (neustále aktuální) a Bleeding Edge (obsahuje nejnovější stabilní verze softwaru). Cílena je spíše na pokročilé uživatele nebo začátečníky, kteří mají vůli se učit. Vzhledem k výše zmíněnému se jeví jako vhodná distribuce, která umožní proniknout do oblasti SELinuxu. Nedá se totiž očekávat, že by většinu potřebných nastavení provedl za uživatele distributor a tak je před ním skryl. Na Arch Linuxu tedy lze dobře nasimulovat proces instalace, o který se většinou postará sám distributor.

4.1

SELinux a Arch Linux

Arch Linux je takový, jaký si ho jeho uživatelé udělají. Podpora tedy záleží na tom, kolik uživatelů se pokoušelo SELinux v Arch Linuxu zprovoznit, nakolik uspěli a jak se o své zkušenosti podělili s komunitou. V době psaní této práce byla oblast SELinux v Arch Linuxu spíše z těch hůře zmapovaných, o čemž svědčí i WIKI stránka v kategorii pahýl. [19] Pro testování SELinuxu byl využit aktualizovaný Arch Linux. Verze jednotlivých balíků se v průběhu práce měnily v duchu Rolling Upgrades.

4.2

Instalace SELinuxu

Podle [18] jsou kromě Linuxu zkompilovaného s podporou SELinuxu dále potřeba knihovny a nástroje z uživatelského prostoru (projekt SELinux Userspace), politika (projekt SELinux Refpolicy) a některé další Linuxové nástroje opatchované pro podporu SELinuxu: např. PAM 38 a GNU-Coreutils. 39 Potřeba je také souborový systém s podporou rozšířených atributů a bezpečnostních štítků 40 jako je ext2, ext3, jfs a xfs. Souborový systém ext4 je také podporován, ovšem v souvislosti se SELinuxem byly hlášeny chyby. 41 Při použití tohoto systému souborů bude tedy vhodné sledovat situaci a kombinovat ho s nejnovějším dostupným jádrem, kde je největší šance na opravu těchto chyb. Výpis dostupných balíčků odhalí následující: 36 Více

viz domovská stránka: http://www.archlinux.org it Simple, Stupid 38 Více viz domovská stránka: http://www.kernel.org/pub/linux/libs/pam/ 39 Více viz domovská stránka: http://www.gnu.org/software/coreutils/ 40 Security labels 41 Např. https://bugzilla.redhat.com/show\_bug.cgi?id=483212 37 Keep

14

4


[nik@newcastle ˜]$ yaourt -Ss selinux community/selinux-coreutils 6.12-1 coreutils (needed for selinux) community/selinux-flex 2.5.4a-2 A tool for generating text-scanning programs community/selinux-kernel26 2.6.28.5-1 The Linux Kernel and modules community/selinux-pam 1.0.1-1 PAM (Pluggable Authentication Modules) library community/selinux-refpolicy-src 20080702-1 SELinux reference policy community/selinux-sysvinit 2.86-1 Linux System V Init community/selinux-usr-checkpolicy 1.34.7-1 selinux userspace (checkpolicy) community/selinux-usr-libselinux 1.34.15-1 selinux userspace (libselinux) community/selinux-usr-libsemanage 1.10.9-1 selinux userspace (libsemanage) community/selinux-usr-libsepol 1.16.14-1 selinux userspace (libsepol) community/selinux-usr-policycoreutils 1.34.16-1 selinux userspace (policycoreutils)

Během této práce byly vytvořeny skripty pro sestavení balíčků s vazbami knihoven SELinuxu na jazyk Python: selinux-usr-libselinux-python a selinux-usr-libsemanage-python. Tyto balíčky umožňují spuštění nástroje semanage, a selinux-setools. který obsahuje CLI a GUI nástroje projektu SELinux SETools. 42 V začátku doporučuji nainstalovat všechny dostupné balíčky s podporou SELinuxu až na selinux-sysvinit, který by mohl způsobit problémy při startu systému, pokud nebude vše správně připraveno. 4.2.1

SELinux kernel

Od verze 2.6 je v kernelu dostupná podpora SELinuxu. Kernel musí být zkompilován i s podporou LSM, devpts a rozšířených atributů. [20] V Arch Linuxu je dostupný balíček selinux-kernel26. Vzhledem k tomu, že nejde o výchozí kernel, mohou nastat problémy s proprietárními moduly, například proprietárními ovladači grafických karet NVidia, které bude potřeba přeinstalovat. Se svobodnými ovladači žádné problémy nenastanou. Po instalaci jádra je potřeba přidat záznam do menu zavaděče, například: /boot/grub/menu.lst ”# (1) Arch Linux title Arch Linux (SELinux) root (hd0,4) 42 Více

viz domovská stránka: http://oss.tresys.com/projects/setools

15

4


kernel /boot/vmlinuz26-selinux root=/dev/sda5 ro vga=775 initrd /boot/kernel26-selinux.img” A nastavit připojování selinuxfs do výchozího adresáře /selinux: [root@newcastle ˜]# mkdir /selinux /etc/fstab none

/selinux

selinuxfs

4.2.2

Referenční politika

defaults

0

0

Po instalaci všech potřebných balíčků a nastavení zavaděče a selinuxfs zbývá sestavit bezpečnostní politiku a zapnout SELinux. Pro distribuci Arch Linux nejsou v současné době dostupné žádné upravené politiky, pouze zdrojové kódy referenční politiky. Před použitím bude potřeba politiku zkompilovat, nainstalovat a zavést, například takto: [root@newcastle [root@newcastle [root@newcastle [root@newcastle

˜]# cd /etc/selinux/refpolicy/src/policy ../refpolicy/src/policy]# make bare ../refpolicy/src/policy]# make conf ../refpolicy/src/policy]# make load

Využít lze ale i nástroj semodule. Nyní je potřeba vytvořit konfigurační soubor s následujícím obsahem: [root@newcastle ˜]# cat /etc/selinux/config # This file controls the state of SELinux on the system. # SELINUX= can take one of these three values: # enforcing - SELinux security policy is enforced. # permissive - SELinux prints warnings # instead of enforcing. # disabled - No SELinux policy is loaded. SELINUX=permissive # SELINUXTYPE= can take one of these two values: # targeted - Only targeted network daemons # are protected. # strict - Full SELinux protection. SELINUXTYPE=refpolicy Nastavený mód permissive je vhodný pro dokončení konfigurace systému a psaní rozsáhlých pravidel, protože se bezpečnostní politika nevynucuje, pouze se logují prohřešky. 4.2.3

Přeznačkování systému souborů a spouštění SELinuxu

Po instalaci a nastavení nemají soubory na disku stále ještě žádný bezpečnostní kontext. Proto je potřeba systém souborů přeznačkovat například: [root@newcastle ../refpolicy/src/policy]# make relabel 16

4


Nyní je vhodné systém restartovat a přeznačkování provést znovu, aby se zajistilo, že budou označkovány opravdu všechny soubory. Dále můžeme zjistit status SELinuxu, který by měl ideálně vypadat následovně: [root@newcastle ˜]# sestatus SELinux status: SELinuxfs mount: Current mode: Mode from config file: Policy version: Policy from config file:

enabled /selinux permissive enforcing 24 refpolicy

Protože jsme zatím nenastavili automatické spouštění SELinuxu při startu systému, bude se nám SELinux hlásit jako disabled. Pro zjednání nápravy využijeme balíček selinux-sysvinit, který nyní nainstalujeme. Aby správně fungoval musíme nalinkovat dříve zkompilovanou politiku tam, kde ji očekává: [root@newcastle ˜]# ln -s \ /etc/selinux/refpolicy/policy/policy.21 \ /etc/policy.bin Pokud by patchovaný sysvinit nenašel soubor /etc/policy.bin, skončil by start systému zpanikařením kernelu, jak varuje [19]. Aby si soubory na disku udržely správný kontext je dobré použít démon restorecond. Vytvoříme tedy soubor /etc/rc.d/restorecond, učiníme ho spustitelným a přidáme záznam do řádky démonů v souboru /etc/rc.conf: /etc/rc.d/restorecond #!/bin/sh restorecond [root@newcastle ˜]# chmod ugo+x /etc/rc.d/restorecond Poslední krok umožní přepnout SELinux při startu systému do enforcing módu. Opět jde o vytvoření souboru /etc/rc.d/selinux-enforce, jeho prohlášení za spustitelný a přidání záznamu do řádky démonů v souboru /etc/ rc.conf: /etc/rc.d/selinux-enforce #!/bin/sh echo 1 > /selinux/enforce [root@newcastle ˜]# chmod ugo+x /etc/rc.d/selinux-enforce Nyní můžeme zkusit zavést systém s podporou SELinuxu a začít zjišťovat, které aplikace kvůli nenastaveným pravidlům nefungují. Pro účely testování je vhodné spouštět vynucování SELinuxu ručně a záznam selinux-enforce v /etc/rc.conf zakomentovat vykřičníkem. 17

5

SELinux ve Fedoře 10

5


Fedora je komunitní odnož Red Hat Linuxu. Za jejím vývojem stojí jak široká komunita, tak vývojáři zaštítění firmou Red Hat. Distribuce se zaměřuje na použití na osobních počítačích a z distribucí s pevným vývojovým cyklem patří k těm inovativnějším. Tato distribuce byla vůbec první, která přinesla podporu SELinuxu a jeho zapnutí po výchozí instalaci. Vzhledem k trvale dobré podpoře SELinuxu je vhodné ji vyzkoušet. Umožní nám nahlédnout, jak by měl vypadat systém s dobře integrovaným SELinuxem.

5.1

SELinux a Fedora

Pro účely této práce byla použita Fedora 10 s nainstalovanými všemi dostupnými aktualizacemi. Vývojová verze Fedory 11 zkoušena nebyla, měla by přinést další vylepšení pro SELinux týkající se virtualizace. [21] Po instalaci distribuce je SELinux zapnutý a plně funkční, jak ostatně hlásí i příkaz sestatus: [root@newcastle ˜]# sestatus SELinux status: SELinuxfs mount: Current mode: Mode from config file: Policy version: Policy from config file:

5.2

enabled /selinux enforcing enforcing 23 targeted

SELinux politiky ve Fedoře

Program sestatus také odhalí, že se používá targeted politika. Pohled do správce balíků naznačí, že Fedora navíc dodává volitelnou MLS politiku (selinuxpolicy-mls) a minimální politiku (selinux-policy-minimum). Kromě těchto tří komplexních politik dodává Fedora ještě další volitelné politiky pro vybrané jednotlivé aplikace. 5.2.1

Cílená politika (Targeted)

Cílená politika je výchozí SELinux politikou ve Fedoře. Původně vychází z referenční politiky, jejíž vývoj pokračoval přes cílenou a striktní politiku v komerční distribuci Red Hat Enterprise Linux 5. Původní cílená politika pak byla sloučena se striktní, přičemž se zachoval název cílená (targeted). [22] Cílená politika se zaměřuje na uzavření všech procesů, které přistupují k síti a také procesů, které jsou spouštěny při startu systému. Procesy spuštěné uživatelem zůstávají v doméně unconfined t. Stejně jako sám uživatel jsou tedy neuzavřené. Spojení s původní striktní politikou umožňuje na vyžádání uzavřít některé uživatele a jimi spouštěné procesy. [22] Podobným způsobem jako cílená politika fungují i nynější verze referenční politiky. 18

5

5.2.2


MLS politika

MLS politika přináší víceúrovňovou bezpečnost a vychází z původní striktní politiky, kterou obohacuje o úrovně citlivosti a kategorie dat. Domény, které nabízí, jsou shodné jako v současné cílené politice. [22] 5.2.3

Minimální politika (Minimum)

Minimální politika je novinkou ve Fedoře 10. Její balíček obsahuje stejné části jako cílená politika, ovšem instaluje pouze nezbytný základ politiky a modul unconfined.pp, zbývající moduly nejsou instalovány ani překládány. [22] Je tedy na uživateli, které moduly si vybere a jak je upraví. Minimální politika je vhodná pro minimalistické systémy, mobilní zařízení a pro uživatele, kteří chtějí s SELinuxem experimentovat, či zkoušet jen provoz několika málo modulů. [22]

5.3

Integrované nástroje pro SELinux

Lepší podpora SELinuxu je znát především na integraci existujících grafických nástrojů pro konfiguraci SELinuxu, automatizovanou tvorbu politik a analýzu AVC zpráv o zakázání přístupu. 5.3.1

Správce SELinuxu (system-config-selinux)

Jde o grafický nástroj pro správu SELinuxu, který umožňuje prohlížet a měnit status, boleans, značkování souborů, mapování uživatelů, porty, moduly politiky a domény procesů. Nástroj je součástí projektu SELinux Userspace a zaměřuje se především na vytvoření grafické nadstavby pro ostatní konzolové SELinux nástroje. Jeho výhodou je, že relativně přehledně sdružuje nastavení dostupná z několika různých souborů. 5.3.2

Nástroj na generování politik (selinux-polgengui)

Grafický nástroj pro generování SELinuxových politik má podobu průvodce, který uživatele naviguje tvorbou bezpečnostní politiky pro vybranou aplikaci. Uživatel odpovídá na otázky týkající se typu aplikace, určuje její spustitelný soubor, porty na kterých poslouchá a vybírá, kteří SELinux uživatelé ji budou smět spouštět. Výsledkem jsou pak okomentované soubory se SELinuxovými pravidly (.te), vzory pro generování kontextů (.fc), rozhraním pro komunikaci s ostatními moduly politiky (.if) a skript pro kompilaci modulu. Vytvořené soubory jsou použitelným základem pro další úpravy politiky založené především na debugování aplikace z AVC zpráv zakazujících přístup. 5.3.3

SETroubleShoot

Tento nástroj běží jako démon na pozadí a v případě zachycení AVC zprávy zakazující přístup upozorní uživatele na její obsah. Zároveň navrhuje možná řešení zaznamenaného problému. 19

6

SELinux v Ubuntu 8.10

SETroubleShoot je výsledkem projektu SELinux Usability iniciovaného firmou Red Hat. Cílem nástroje je umožnit uživateli porozumět AVC zákazům a pomoci mu rozeznat ty, které jsou důsledkem nedokonale napsané politiky (těch je dnes většina protože SELinux je stále novou technologií) od těch, které jsou důsledkem bezpečnostní hrozby. [23] 5.3.4

Další aplikace

Další aplikace, které usnadní práci s SELinuxem jsou dostupné v repozitářích distribuce. Nainstalovat tak můžeme balík grafických a konzolových nástrojů SETools nebo plugin pro Eclipse 43 sloužící k vývoji politik – SLIDE. 44

6

SELinux v Ubuntu 8.10

Ubuntu je distribuce cílená především na začínající běžné uživatele, kteří nechtějí do systému zasahovat a ocení, pokud věci prostě fungují. Distribuce dodržuje půlroční vývojový cyklus a rozumně vyvažuje aktuálnost softwaru s jeho odzkoušeností a distribuční podporou. Distribuce byla vybrána do srovnání především vzhledem ke svému vysokému rozšíření na Linuxových desktopech mezi začínajícími uživateli.

6.1

SELinux a Ubuntu

Z dostupných bezpečnostních technologií dává Ubuntu přednost konkurenčnímu AppArmor, které je ve výchozím stavu zapnuté. To však neznamená, že by SELinux nešel v Ubuntu zprovoznit. Zaměření na AppArmor se však projevuje úrovní podpory SELinux v distribuci. Pro účely práce byla použita distribuce Ubuntu 8.10 se všemi dostupnými aktualizacemi. V době psaní práce vrcholily přípravy na vydání jarní verze 9.04, která ale nebyla z časových důvodů zkoušena.

6.2

Instalace SELinuxu

Vzhledem k filozofii Ubuntu je instalace SELinuxu poněkud nestandardní. Přeci jen bych kvůli zaměření distribuce na běžné uživatele čekal, že se distributor o některá nastavení více postará sám. Nejprve je nutné vypnout AppArmor a povolit SELinux pro distribuční jádro. Docílit toho lze předáním patřičných parametrů zavádějícímu se jádru: apparmor.enabled=0 selinux=1 enforcing=0 Tyto volby je vhodné přidat na konec řádky kernel v záznamu pro aktuální jádro souboru /boot/grub/menu.lst. Po restartu systému lze přikročit k samotného instalaci SELinuxu: sudo apt-get install selinux Tento příkaz nainstaluje pouze nezbytné minimum pro SELinux, politiku je pak potřeba nainstalovat zvlášť. 43 Více 44 Více

20

viz. domovská stránka projektu: http://www.eclipse.org/ viz. domovská stránka projektu: http://oss.tresys.com/projects/slide

7

SELinux napříč distribucemi

sudo apt-get install selinux-basics V tomto případě dojde i k instalaci výchozí politiky, která je založena na referenční politice. Nyní je také možné instalovat další nástroje usnadňující práci s SELinuxem, další politiky nebo jejich zdrojové kódy. Posledním krokem je nastavení zavádění SELinuxu při startu systému. Vzhledem k tomu, že výchozí inicializační program Ubuntu toto neumožňuje, je potřeba nainstalovat sysvinit: sudo apt-get install sysvinit Po restartu by měl SELinux již fungovat v permisivním módu: nik@newcastle:˜$ sestatus SELinux status: SELinuxfs mount: Current mode: Mode from config file: Policy version: Policy from config file:

enabled /selinux permissive permissive 23 default

Pro start SELinuxu v enforcing režimu stačí změnit hodnotu parametru enforcing na 1. V takovém případě se ovšem naplno projeví úroveň podpory SELinuxu v Ubuntu 8.10, kdy se nelze přihlásit do X11 ani do konzole. Lepší situace by měla být ve verzi Ubuntu s dlouhodobou podporou 8.04, kde se některé problémy neprojevují. 45

7


Podpora SELinuxu mezi různými distribucemi se liší a to i dost výrazně. Mnoho distribucí nenabízí žádnou podporu, či tato podpora plně leží na komunitě uživatelů kolem dané distribuce. Některé distribuce však SELinux podporují velmi dobře, nebo jej rovnou začleňují na instalační média a aktivují při výchozí instalaci. Samozřejmě lze nainstalovat SELinux na téměř libovolné distribuci, ovšem v takovém případě to bude nejspíše znamenat nutnost překompilovat kernel, některé moduly a řadu základních nástrojů. Dále pak zkompilovat SELinuxové knihovny, nástroje a vzorovou politiku a tu pak upravit podle požadavků. Toto rozhodně není nic triviálního a uživatel by měl v takové situaci důkladně zvážit, zda to chce opravdu podstoupit. Daleko lepší volbou je použít některou z distribucí, která SELinux podporuje alespoň do té míry, že není problém ho vůbec rozchodit. V takové situaci se může uživatel již plně soustředit na napsání či pouhé přizpůsobení bezpečnostní politiky svým požadavkům. Podporu SELinuxu v rámci distribuce obsahuje například Debian. Doporučuje se používat aktuální verze Unstable či Testing. 46 Zde zmiňované Ubuntu může být také použitelné v aktuální verzi s dlouhou podporou 8.04. Pokročilá 45 Další

informace o SELinuxu a různých verzích Ubuntu se nachází například v tomto vlákně na fóru: http://ubuntuforums.org/showthread.php?t=1015967 46 Více viz WIKI projektu: http://wiki.debian.org/SELinux

21

7


distribuce Gentoo má také projekt přinášející podporu SELinuxu. 47 openSUSE také nabízí SELinux jako volitelný, výchozím způsobem zabezpečení ale zůstává AppArmor. Nejsnazší cestou je použití distribuce, která SELinux integruje do výchozí instalace. V takovém případě zcela odpadá jakékoliv zaobírání se instalací a i konfigurace bývá na úrovni, kdy není potřeba přidávat mnoho pravidel. Toto samozřejmě záleží na konkrétních požadavcích uživatele. K takovým distribucím patří především Fedora, případně její sesterská komerční distribuce Red Hat Enterprise Linux, které jsou obě úzce spojené s firmou Red Hat i s SELinuxem.

47 Více viz domovská stránka projektu Hardened Gentoo: http://www.gentoo.org/ proj/en/hardened/selinux/index.xml

22

8

Tvorba pravidel a použité nástroje

Část III

Bezpečnostní politika pro typovou situaci Tato část se zabývá tvorbou bezpečnostní SELinuxové politiky pro vybranou aplikaci. Dochází tu k aplikaci pravidel a zásad shrnutých v části I Principy SELinuxu. Vzhledem k nejlepší podpoře SELinuxu a také provázanosti s referenční politikou, byla pro tuto část vybraná jako výchozí distribuce Fedora 10.

8

Tvorba pravidel a použité nástroje

Nejprve pár postřehů k samotné tvorbě SELinuxových pravidel. Použitá metodika byla již obecně zmíněna v úvodu práce, teď si ji rozebereme konkrétněji. Jako zdroj pro tuto metodiku byl použit článek [24]. Případné komplikace při jejím nasazení jsou pak komentovány spolu s jednotlivými pravidly. Při psaní SELinuxové politiky pro vybranou aplikaci je nejprve vhodné vytvořit základní fungující kostru. Tato kostra bývá v určitých situacích velmi podobná, protože především určuje kontexty pro soubory, se kterými aplikace pracuje, definuje jednotlivé typy a určuje přístup k nim. Stejně tak je u Linuxových systémů běžné, že programy přistupují ke sdíleným knihovnám a paměti, určitým portům a podobně. Tato pravidla lze napsat ručně, ovšem je vhodné použít nástroj pro generování politik, o kterém se hovořilo ve stejnojmenné sekci 5.3.2. Po vytvoření základní kostry politiky následuje proces odstraňování chyb v politice a její rozšiřování. Postup spočívá ve snaze spustit program, pro který se píše politika a sledovat v logu AVC zprávy o zamítnutí přístupu. Ke sledování logů lze použít nástroj SETroubleShoot zmíněný ve stejnojmenné sekci 5.3.3, ovšem dá se v celku dobře vystačit s vhodnou kombinací nástrojů cat a grep. Po zachycení AVC zpráv o zakázání přístupu je možné psát pravidla ručně, nebo je generovat pomocí nástroje audit2allow. Při této práci je třeba zvažovat, zda je povolení zablokovaného přístupu skutečně žádoucí. Toto se v některých případech může lišit podle preferencí bezpečnostního administrátora. Samotné psaní SELinuxových pravidel může probíhat v libovolném textovém editoru. Je ovšem žádoucí, aby docházelo ke zvýraznění syntaxe případně napovídání platných příkazů, což omezí problémy při překladu zdrojových kódů. K tomuto účelu lze použít dříve zmíněný plugin pro všestranné vývojové prostředí Eclipse – SLIDE. Plugin SLIDE mimo jiné průběžně kompiluje zdrojové kódy a doplňuje i dostupná rozhraní modulů referenční či distribucí dodávané politiky a makra. Politiku lze považovat za vhodnou pro zveřejnění v okamžiku, když uzavíraný program funguje a negeneruje neošetřená AVC hlášení o zamítnutí přístupu při běžném provozu. Vývoj by tím samozřejmě neměl skončit, kód je potřeba udržovat, dále ladit a zdokonalovat. 23

9

Zabezpečení aplikací KDE přistupujících k síti

9


Linuxová platforma má dvě široce rozšířená pracovní prostředí. Jde o GNOME 48 založené na GTK toolkitu a KDE 49 založené na Qt toolkitu. Každé z těchto prostředí nabízí kompletní sadu aplikací pro mnoho oblastí práce s počítačem. Ačkoliv se běžně stává, že uživatelé používají aplikace z více prostředí, respektive napsané ve více toolkitech, většinou jedno z nich na daném počítači převládá. Z hlediska podpory těchto dvou pracovních prostředí je v referenční politice lepší situace u prostředí GNOME či obecně u GTK aplikací. Vlastní modul má například konfigurační nástroj gconf, emailové klienty Epiphany a Thunderbird a prohlížeč Mozilla Firefox. Na druhou stranu situace s ochranou KDE či Qt aplikací je poměrně špatná. Z výše uvedených důvodů a proto, že se pohybuji především v prostředí KDE, jsem se rozhodl v rámci této práce zaměřit tvorbu bezpečnostní politiky pro programy prostředí KDE.

9.1

Cíle při zabezpečení KDE aplikací

Prostředí KDE je velmi komplexní a obsahuje mnoho provázaných aplikací. Z tohoto důvodu hrozí jakýsi lavinový efekt, kdy si uzavření jedné aplikace přes její interakce s dalšími KDE aplikacemi bude vynucovat uzavírání dalších aplikací případně použití poměrně nebezpečných pravidel, jako je povolení spouštění jakéhokoliv programu z domény, bin t či právo zápisu do uživatelského adresáře. Vzhledem k rozsahu celého prostředí však při tvorbě této práce nejde vytvořit politika pro každou KDE aplikaci. Zároveň však není moudré povolovat například webovému prohlížeči, aby mohl spustit jakoukoliv aplikaci z bin t, protože by tím došlo k otevření bezpečnostní díry do systému. Vzhledem k omezenému množství času by se tedy mohlo jevit jako rozumné uzavřít všechny KDE aplikace do jedné domény. To by ovšem odporovalo základnímu požadavku na vytvoření pokud možno malých domén. Po důkladném uvážení tedy byl vybrán kompromisní postup, jehož výsledkem bude vytvoření politik pro pracovní prostředí KDE v jakémsi pracovním stádiu, které bude doufejme vhodné pro další rozvinutí v budoucnu či dalšími zájemci o tuto oblast. Toto řešení počítá s vytvořením modulu kde.pp, který bude sdružovat typy pro sdílené adresáře s nastavením KDE aplikací a adresáře pro dočasné soubory KDE aplikací. Tento modul bude zároveň deklarovat rozhraní pro různé způsoby přístupu k těmto typům. Kromě modulu kde.pp pak bude možné vytvořit další modul pro každou uzavřenou aplikaci. Primárně by měly být cílem aplikace přistupující k síti. Modul aplikace přidá specifický typ pro její konfigurační soubory a data v domovském adresáři. Dále pak pomocí specifického typu pro její spustitelný soubor umožní její uzavření do vlastní domény. Aplikace bude mít přístup do sdílené domény KDE aplikací, jehož rozsah však bude podléhat snaze o minimalizaci na nezbytně nutná oprávnění. Se vznikem domén pro další aplikace pak bude možné řešit přístup k jejich sdíleným souborům přímo a omezit tak rozsah sdílené domény všech KDE aplikací, což zvýší její bezpečnost v případě kompromitace některé z KDE aplikací. 48 Více 49 Více

24

viz. domovská stránka projektu: http://www.gnome.org/ viz. domovská stránka projektu: http://kde.org/

9


Dosažení takového stavu je však jen těžko v rukou jednoho člověka s omezenými zdroji znalostí a volného času, tudíž je zapojení širší komunity podmínkou pro další rozvoj výsledků této práce. Přímým výsledkem této práce tedy bude napsání SELinuxového modulu pro webový prohlížeč Konqueror a základního modulu s podporou pro KDE aplikace, danou především požadavky modulu pro Konqueror a obecnými znalostmi o fungování KDE aplikací. Tyto moduly pak mohou být základem a inspirací při uzavírání dalších KDE aplikací tentokrát již mimo rámec této práce.

9.2

Obecný modul pro KDE aplikace

Modul kde.pp je kompilován ze tří souborů: kde.fc (vzory pro generování kontextů sdílených souborů KDE aplikací), kde.te (především definice jednotlivých typů společných pro KDE aplikace) a kde.if (rozhraní pro přístup k těmto typům). Ucelený výpis obsahu těchto souborů se nachází v příloze I Modul kde.pp. V následujících sekcích se podíváme na důležitá pravidla a vysvětlíme si, proč byla použita. 9.2.1

Bezpečnostní kontexty

Pro všechny KDE aplikace se zavádí kontext kde shared home t, který slouží k označení souborů s nastavením v celém domovském adresáři ˜/.kde a také konfiguračního souboru Qt ˜/.config/Trolltech.conf. Druhý typ, který se zavádí jako společný pro všechny KDE aplikace, je kde shared tmp t, který označuje všechny dočasné soubory. Jde tedy o soubory, které se nacházejí v adresářích /tmp/kde-USER, /tmp/ksocket-USER, /var/tmp/kdecache-USER a odkazy na ně z domovského adresáře. V případě souborů v adresáři /tmp zde narážíme na problém, protože se tento adresář při startu systému maže a vlastní adresáře pro dočasné soubory KDE se tak vytvářejí při startu KDE znovu. Vytváří je proces kde-init a protože jsou vytvářeny ve složce s typem usr tmp t, tento typ také dědí. Tuto situaci lze řešit uzavřením procesu kde-init do vlastní domény, ke které se připojí pravidlo na přechod typů. 50 Při definování vzorů pro kontexty je třeba být opatrný na syntaxi regulárních výrazů, kterými se označují cesty: HOME_DIR/\.kde(/.*)? \ gen_context(system_u:object_r:kde_shared_home_t,s0) Výrazu HOME_DIR/\.kde(/.*)? odpovídají všechny soubory v ˜/.kde včetně adresáře .kde. Zde je například vidět, že znak pro tečku má specifický význam a proto je ho potřeba předcházet zpětným lomítkem. 9.2.2

SELinux pravidla

V části SELinux pravidel modulu kde.pp se oba výše zmíněné typy deklarují. O typu kde shared home t se pomocí makra files type() z referenční politiky říká, že je to typ určený pro soubory na disku. O typu kde shared tmp t se pak obdobně říká, že jde o typ pro dočasné soubory: 50 Type

transition rule

25

9


type kde_shared_tmp_t; files_tmp_file(kde_shared_tmp_t) 9.2.3

Rozhraní modulu

Nejdůležitější část modulu kde.pp představují definice rozhraní. Tato rozhraní umožní jiným modulům přistupovat s různou mírou oprávnění k výše definovaným typům. Vlastnímu rozhraní předchází jeho popis v jednoduchém XML formátu. Popis shrnuje, k čemu rozhraní slouží, a jaké má parametry: ## ## ## ## ## ## ## ##

<summary> Allow domain to read, kde tmp files, links and sockets <param name=”domain”> <summary> Domain to allowed access.

Poté už následuje vlastní rozhraní zapsané v jazyce m4, který se používá pro definici SELinux maker. Rozhraní modulu kde.pp lze tedy chápat jako uživatelské makro. Rozhraní definuje svůj název a pak část s vlastními pravidly. Každý použitý typ musí být vyžádán v části gen require jako závislost. Pravidla odpovídají syntaxi SELinux pravidel, jejich volitelné části jsou zastoupeny parametry označenými $1, $2 a tak dále: interface(‘kde_read_tmp’,‘ gen_require(‘ type kde_shared_tmp_t; ’) allow $1 kde_shared_tmp_t:dir search_dir_perms; allow $1 kde_shared_tmp_t:file read_file_perms; allow $1 kde_shared_tmp_t:lnk_file read_lnk_file_perms; allow $1 kde_shared_tmp_t:sock_file read_sock_file_perms; ’) Toto rozhraní tedy umožňuje číst soubory, odkazy na ně a sockety s typem kde shared tmp t. Zároveň umožňuje prohledávat adresáře daného typu. Toto je důležité, protože jsou v nich dané soubory uloženy. Bez práv na prohledávání adresáře nemůže aplikace přistupovat k souborům v nich. V případě klasického linuxového diskrétního řízení přístupu se toto řeší pouze právem ke čtení. SELinux tedy rozeznává mnohem více úrovní přístupu než linuxové diskrétní řízení přístupu. Podobných rozhraní je více, protože k typům je také potřeba povolit zápisová a další práva. Při jejich tvorbě nemusí být využita pouze přístupová pravidla, ale používají se i již definovaná rozhraní a makra poskytnutá referenční politikou. Jazyk m4 je syntakticky poněkud záludný, ovšem dostupné nástroje pro vývoj politik ze zadaných údajů rozhraní také generují. Tato rozhraní lze pak vzít jako vzor při tvorbě dalších a vyhnout se tak náročnému hledání a odstraňování chyb v syntaxi. 26

9

9.3


Modul pro webový prohlížeč Konqueror

Jako u modulu kde.pp i modul konqueror.pp vzniká ze souborů s kontexty, pravidly a rozhraními. Jednotlivé výpisy se nachází v příloze II Modul konqueror.pp. Protože modul pro Konqueror používá rozhraní obecného modulu pro KDE aplikace, je tedy na něm závislý a nejde bez něj přeložit. Následují již komentáře důležitých částí politiky. 9.3.1

Bezpečnostní kontexty

Modul zavádí nový typ konqueror t, který se používá pro proces konqueror. Pro soubory uvnitř domovského adresáře se zavádí typ konqueror home t a pro spustitelný soubor /usr/bin/konqueror se vytváří speciální typ označený jako konqueror exec t. Tento typ slouží jako vstupní bod do domény konqueror t v rámci doménového přechodu. 9.3.2

SELinux pravidla

Při konstrukci SELinuxových pravidel byla snaha používat existující makra a rozhraní referenční politiky stejně jako rozhraní definovaná v rámci obou vytvářených modulů kde.pp a konqueror.pp. Využití maker a rozhraní dokáže usnadnit práci při tvorbě pravidel, ale i další správu vytvořeného modulu. Rizikem však může být neúmyslné přidělení větších práv, než je ve skutečnosti nezbytně nutné. Jedním z prvních kroků je opět deklarace typů, které modul zavádí. Na tomto místě se také poprvé objevuje výše zmíněný typ konqueror t, který se pomocí makra application domain() spolu s typem konqueror exec t prohlašuje za typ pro proces, čili doménu: type konqueror_t; type konqueror_exec_t; application_domain(konqueror_t, konqueror_exec_t) Některá pravidla byla generována automaticky nástrojem pro generování politik, který je součástí Fedory. Jde především o výchozí kostru pravidel pro přístup k typům konqueror home t, pojmenovaným portům, sdíleným knihovnám a doménové přechody. Zde je potřeba poznamenat, že generovaný kód nebyl bez chyb a před jeho zprovozněním bylo potřeba odstranit některé podivnosti. Například šlo o použití typu unconfined u t namísto unconfined t a podobně. Další pravidla byla odvozena z chybových hlášek o zamítnutí přístupu při pokusu o spouštění Konqueroru. Jako základ posloužil nástroj audit2allow: [root@newcastle nik]# grep konqueror \ /var/log/audit/audit.log | audit2allow -R Nemalou část pravidel vygenerovaných tímto nástrojem však nelze použít a všechna pravidla je potřeba zkontrolovat, zda je jejich použití opravdu žádoucí. Nástroj neprovádí žádné analýzy bezpečnosti povolení daného přístupu, pouze generuje přístupová pravidla pro všechny zakázané operace, které byly zalogovány. 27

9


Mezi generovanými pravidly se tak nacházela dost nebezpečná pravidla povolující plný přístup k typu uživatelského adresáře, či umožňující spuštění jakéhokoliv programu s typem bin t. Existence takových pravidel ukazuje většinou na to, že některý soubor nebyl zahrnut mezi soubory označené typem konqueror home t respektive, že je nutnost uzavřít nějaký další program, který je prohlížečem spouštěn. Důležité pravidlo řešící problémy se zachováním správného kontextu souborů v rámci sdíleného adresáře s typem kde shared home t umožňuje přechod vytvořených souborů a adresářů do typu konqueror home t: files_kde_home_filetrans(konqueror_t, konqueror_home_t) Toto pravidlo je realizováno pomocí rozhraní modulu kde.pp, které využívá pravidla pro přechod typů: type_transition $1 kde_shared_home_t:{ file lnk_file \ sock_file dir } $2; Provázanost KDE aplikací se při uzavírání Konqueroru projevila při automatickém spouštění nástroje drkonqi. Tento nástroj umožňuje hlásit uživateli pád aplikace a je spouštěn přímo Konquerorem během jeho vlastního startu. Protože tento nástroj zatím není uzavřený, přiřazuje se mu obecný typ bin t. Rozhodně není žádoucí povolit Konqueroru jeho spouštění. Aby se neplnily logy hlášeními o zamítnutí přístupu, bylo použito pravidlo potlačující logování: dontaudit konqueror_t bin_t:file exec_file_perms; Pro vlastní spuštění Konqueroru byl naopak nutný přístup ke sběrnici dbus. Nástroj pro generování politik v tomto případě příliš nezabodoval, takže bylo potřeba najít příslušná rozhraní modulů referenční politiky ručně a ještě k nim přidat pravidla navrhovaná nástrojem audit2allow: allow konqueror_t unconfined_dbusd_t:unix_stream_socket \ connectto; allow konqueror_t unconfined_t:unix_stream_socket \ { read write connectto }; dbus_system_bus_unconfined(konqueror_t) dbus_unconfined(konqueror_t) Tímto by končil komentovaný výčet SELinuxových pravidel použitých při tvorbě modulu konqueror.pp. Úplný zdrojový kód se nalézá v příslušné příloze včetně komentářů, které byly ve snaze o kompatibilitu s referenční politikou psané anglicky. 9.3.3

Rozhraní modulu

Jednotlivá rozhraní opět povolují různé úrovně přístupu zvolených domén k typu konqueror home t. Další rozhraní umožňují komunikaci se sběrnicí dbus. Samostatné rozhraní bylo také nutné pro korektní spuštění Konqueroru v doméně konqueror t: 28

9


interface(‘konqueror_run’,‘ gen_require(‘ type konqueror_t; ’) konqueror_domtrans($1) role $2 types konqueror_t; dontaudit konqueror_t $3:chr_file rw_term_perms; ’) Rozhraní přijímá parametr typu, role a typu terminálu. Použitý typ označuje typ, který bude přecházet do domény konqueror t. Role udává roli, pro kterou je přechod možný. Typ terminálu se předává kvůli potlačení logování. Rozhraní konqueror run používá další rozhraní pro vlastní doménový přechod: interface(‘konqueror_domtrans’,‘ gen_require(‘ type konqueror_t; type konqueror_exec_t; ’) domtrans_pattern($1,konqueror_exec_t,konqueror_t) ’) Rozhraní konqueror domtrans povoluje typu, který je zadán jako parametr, přejít prostřednictvím spustitelného souboru s typem konqueror exec t do domény konqueror t.

9.4

Zhodnocení vytvořené politiky

Vytvořená politika pro webový prohlížeč Konqueror a základní modul pro KDE aplikace jsou úzce provázány. Prohlížeč Konqueror je uzavřen do své domény konqueror t a jeho soubory uvnitř uživatelského adresáře jsou označeny typem konqueror home t. Další soubory, ke kterým přistupuje jsou uzavřeny do typů navržených modulem pro KDE aplikace. Jde tedy o konfigurační soubory dalších KDE aplikací (typ kde shared home t) a dočasné soubory (typ kde tmp t). Mimo výše zmíněné typy smí prohlížeč vykonávat jen nezbytně nutné akce například práci s porty a dalším. Konqueror by tak měl být poměrně dobře oddělený od zbytku systému a při jeho kompromitaci by neměly být napáchány výraznější škody. Uvnitř typu pro KDE aplikace má Konqueror udělený plný přístup vzhledem k potřebě vytvářet tam své soubory a adresáře. Toto může být potenciálně nebezpečné. Jde ale o řešení, které umožňuje správné fungování aplikace a minimalizuje riziko oproti původní situaci. Ve výchozím stavu se totiž Konqueror spouští v nezabezpečené doméně unconfined t a má tedy plný přístup do uživatelova domovského adresáře. Při použití modulu konqueror.pp má Konqueror plný přístup pouze ke konfiguračním souborům KDE aplikací. Úplné zabezpečení KDE aplikací bude vyžadovat vytvoření bezpečnostních modulů pro každou aplikaci přistupující k síti, nebo pracující s důležitými daty. V té chvíli pak bude plně využit potenciál základu navrženého touto prací.

29

Závěr Tato práce si kladla za cíl shrnout principy, na kterých SELinux stojí, a nabídnout tak čtenáři možnost proniknout do jeho základů. Dále práce rozebrala současnou situaci kolem podpory SELinuxu v distribucích a ukázala postupy spjaté s jeho instalací a nastavením. Konečně pak práce navrhla způsob, jak pomocí SELinuxu zabezpečit aplikace pracovního prostředí KDE, což názorně demonstrovala vytvořením obecného modulu pro KDE aplikace a modulu zabezpečujícího webový prohlížeč Konqueror. V průběhu práce došlo k upřesnění zatím neúplného návodu na instalaci SELinuxu v distribuci Arch Linux. V rámci procesu instalace bylo připraveno několik skriptů pro sestavení balíčků potřebných pro korektní chod některých aplikací a rozšíření množství nástrojů pro správu SELinuxu, které jsou v rámci Arch Linuxu dostupné. Konkrétně jde o balíčky obsahující vazby knihoven libselinux a libsemanage na jazyk Python. Ty jsou potřeba pro chod nástroje semanage. Dalším balíčkem byla pak přidána skupina nástrojů SETools. Všechny balíčky byly zveřejněny v uživatelském repozitáři AUR 51 a jsou v současné době spravovány autorem této práce. Dalším původním přínosem práce je vypracování bezpečnostní politiky pro webový prohlížeč Konqueror, která je dále provázána s obecným modulem pro KDE aplikace. Kromě samotných zdrojových souborů, které jsou obsaženy v příloze této práce, dochází také k nastínění strategie, jak zabezpečit ostatní KDE aplikace, což by měl usnadnit právě obecný modul pro KDE aplikace. Balíčky pro Arch Linux jsou okamžitě použitelné případnými zájemci, stejně jako návod na instalaci SELinuxu v této distribuci. Moduly bezpečnostní politiky je možné přeložit a použít ke zvýšení bezpečnosti v rámci standardně dodávané referenční politiky. Testovány byly s distribucí Fedora 10. Pokud by došlo ke kompromitaci prohlížeče Konqueror, zužují tyto moduly rozsah možných škod. Útočník nebo chyba v programu mohou tedy ohrozit výrazně měnší část systému než v situaci, kdy aplikace není sama o sobě zabezpečena. Největší výzvou pro rozvinutí výsledků této práce je pokračování v procesu zabezpečení jednotlivých aplikací prostředí KDE. Ruku v ruce s tímto by měla jít snaha o harmonizaci zdrojových kódů poskytnutých touto prací s referenční politikou a jejich zařazení mezi oficiální moduly. Další oblastí, kde je možné na práci navázat, je zvýšení podpory SELinuxu v distribuci Arch Linux. Samotný SELinux je velice zajímavý a jeho důležitost v zabezpečení počítačů s operačním systémem Linux bude zřejmě nadále růst. Už nyní je SELinux vhodný pro nasazení na servery, kde vzhledem k velkému množství dostupných modulů pro typicky používané aplikace administrátor nejspíše nenarazí na vážnější problémy. Úsilí vynaložené na překonání těchto problémů či větší přizpůsobení existujících politik bude vyváženo kritičností této oblasti. Naproti tomu v oblasti osobních počítačů nelze čekat, že budou běžní uživatelé tuto technologii osobně studovat, jakkoliv to může být zajímavé pro člověka se zájmem o tuto oblast. Proto je zde velký prostor pro dodání typových řešení v rámci jednotlivých distribucí tak, jak se děje ve Fedoře či RHELu. V této oblasti ale stále zůstává velký prostor pro tvorbu dalších politik. Cílem by mělo být dosažení stavu, kdy budou zabezpečeny alespoň všechny aplikace přistupující k síti. 51 Balíčky

selinux-usr-libselinux-python, selinux-usr-libsemanage-python a selinux-setools jsou dostupné z http://aur.archlinux.org:80/packages.php? SeB=m&K=Nicky726

30

Seznam zkratek DAC Discretionary Access Control – Diskrétní řízení přístupu. MAC Mandatory Access Control – Povinné řízení přístupu. RBAC Role-Based Access Control – Řízení přístupu založené na rolích. LSM Linux Security Modules – Bezpečnostní moduly pro Linuxové jádro umožňují rozšíření Linuxu o různé modely řízení přístupu. TE Type Enforcement – Způsob řízení přístupu spočívající v povolování přístupu na základě shodnosti typů subjektů a objektů. MLS Multi Level Security – Víceúrovňová bezpečnost. MCS Multi Category Security – Bezpečnost rozlišující kategorie objektů a subjektů. GNU GNU’s Not Unix – Projekt zaštiťující základní nástrojem kolem Linuxového jádra. GPL General Public License – Licence pro svobodný software, která vyžaduje, aby změny v něm zůstaly také Svobodné, tedy aby byl zveřejněn jejich zdrojový kód. KDE K Desktop Environment – Jedno z hlavních pracovních prostředí pro operační systém Linux. SUID Set User ID – Příznak u souboru, který umožní spuštění procesu pod vlastníkem spustitelného souboru místo pod uživatelem, který ho spouští. NSA National Security Agency – Národní bezpečnostní agentura vlády Spojených států amerických. KISS Keep It Simple, Stupid – Princip pro tvorbu a návrh softwaru, který se snaží o jednoduchost. PAM Pluggable Authentication Modules – Mechanizmus pro autentizaci používaný mimo jiné v Linuxu. CLI Command Line Interface – Rozhraní příkazové řádky. GUI Graphical User Interface – Grafické uživatelské rozhraní. AVC Acces Vector Cache – Vyrovnávací paměť pro přístupový vektor, zde se ukládají rozhodnutí o udělení či zamítnutí přístupu. Při dalším výskytu stejné situace se tedy nemusí pravidla znovu vyhodnocovat. SLIDE SELinux Integrated Development Environment – Rozšíření pro Eclipse určené pro vývoj bezpečnostních politik pro SELinux. AUR Arch Linux User Repository – Repozitář obsahující skripty pro sestavení balíčků, které spravují jednotliví uživatelé distribuce Arch Linux. Umožňuje snadné sdílení balíčků mimo oficiální repozitáře.

31

Reference [1] Loscocco, P. A. – Smalley, S. D. – Muckelbauer, P. A. – Taylor, R. C. – Turner, S. J. – Farrell, J. F.: The Inevitability of Failure: The Flawed Assumption of Security in Modern Computing Environments [online]. 1998. Dostupný z WWW: . [2] Mayer, F. – MacMillan, L. – Caplan, K.: SELinux by Example: Using Security Enhanced Linux. 1st Ed. Upper Saddle River, Prentice Hall 2006. 456 s. ISBN-10: 0-13-196369-4. [3] Department of Defence: Trusted Computer System Evaluation Criteria [online]. 1985. Dostupný z WWW: . [4] Committee on National Security Systems: National Information Assurance Glossary [online]. 2006. Dostupný z WWW: . [5] Wikipedia: Access Control [online]. Poslední změna 2009-03-24 [cit. 2009-03-24]. Dostupný z WWW: . [6] Wikipedia: Discretionary Access Control [online]. Poslední změna 200902-08 [cit. 2009-03-24]. Dostupný z WWW: . [7] Wikipedia: Mandatory Access Control [online]. Poslední změna 2009-0307 [cit. 2009-03-24]. Dostupný z WWW: . [8] Wikipedia: Role-based Access Control [online]. Poslední změna 2009-0304 [cit. 2009-03-25]. Dostupný z WWW: . [9] Wright, C. – Cowan, C. – Smalley, S. D. – Moris J. – Kroah-Hartman, G.: Linux Security Module Framework [online]. 2002. Dostupný z WWW: . [10] Wikipedia: Linux Security Modules [online]. Poslední změna 2009-03-02 [cit. 2009-04-07]. Dostupný z WWW: . [11] Wikipedia: Principle of least privilege [online]. Poslední změna 2009-0326 [cit. 2009-04-02]. Dostupný z WWW: . [12] Wikipedia: Type enforcement [online]. Poslední změna 2009-03-17 [cit. 2009-04-02]. Dostupný z WWW: . 32

[13] Wikipedia: Bell-La Padula [online]. Poslední změna 2009-03-03 [cit. 2009-03-26]. Dostupný z WWW: . [14] Wikipedia: Multilevel security [online]. Poslední změna 2009-03-22 [cit. 2009-03-26]. Dostupný z WWW: . [15] Redhat Documentation: Multi-Category Security [online]. [cit. 2009-03-31]. Dostupný z WWW: . [16] Horák, J.: Česká dokumentace pro SELinux [online]. 2007. 37 s + přílohy. Bakalářská práce obhájená na FI MUNI Brno. Dostupný z WWW: . [17] PeBenito, Ch. J. – Mayer, F. – MacMillan, K.: Reference Policy for Security Enhanced Linux [online]. 2006. Dostupný z WWW: . [18] NSA: SELinux Frequently Asked Questions [online]. Poslední změna 200901-15 [cit. 2009-02-19]. Dostupný z WWW: . [19] Arch Linux WIKI: SELinux [online]. Poslední změna 2009-01-17 [cit. 2009-02-17]. Dostupný z WWW: . [20] Gentoo Linux Documentation: Boot SELinux Kernel [online]. Poslední změna 2007-07-22 [cit. 2009-02-18]. Dostupný z WWW: . [21] Techworld.com: New security features in Fedora 11 beta [online]. [cit. 2009-04-15]. Dostupný z WWW: . [22] Walsh, D.: SELinux policy minimum [online]. [cit. 2009-04-09]. Dostupný z WWW: . [23] Fedorahosted.org: SETroubleShoot Overview [online]. [cit. 200904-09]. Dostupný z WWW: . [24] Walsh, D.: A step-by-step guide to building a new SELinux policy module [online]. Poslední změna 2007-08-21 [cit. 2009-04-28]. Dostupný z WWW: .

33

Přílohy I I

Modul kde.pp Soubor s kontexty (kde.fc)

# Qt config file HOME_DIR/\.config/Trolltech\.conf -- \ gen_context(system_u:object_r:kde_shared_home_t,s0) # KDE home HOME_DIR/\.kde(/.*)? \ gen_context(system_u:object_r:kde_shared_home_t,s0) # Tmp shared among kdeapps /tmp/kde-(.*)? \ gen_context(system_u:object_r:kde_shared_tmp_t,s0) /tmp/ksocket-(.*)? \ gen_context(system_u:object_r:kde_shared_tmp_t,s0) /var/tmp/kdecache-(.*)? \ gen_context(system_u:object_r:kde_shared_tmp_t,s0) # Links to tmp in user home HOME_DIR/\.kde/socket-(.*)? \ gen_context(system_u:object_r:kde_shared_tmp_t,s0) HOME_DIR/\.kde/cache-(.*)? \ gen_context(system_u:object_r:kde_shared_tmp_t,s0) HOME_DIR/\.kde/tmp-(.*)? \ gen_context(system_u:object_r:kde_shared_tmp_t,s0)

II

Soubor s pravidly (kde.te)

policy_module(kde,0.0.1) ######################################## # # Declarations # type kde_shared_tmp_t; files_tmp_file(kde_shared_tmp_t) type kde_shared_home_t; files_type(kde_shared_home_t) 34

III

Soubor s rozhraními (kde.if )

## <summary>Basic kde confinement ######################################## ## <summary> ## Do not audit attempts to read, ## kde tmp files ## ## <param name=”domain”> ## <summary> ## Domain to not audit. ## ## # interface(‘kde_dontaudit_read_tmp_files’,‘ gen_require(‘ type kde_shared_tmp_t; ’) dontaudit $1 kde_shared_tmp_t:file read_file_perms; ’) ######################################## ## <summary> ## Allow domain to read, kde tmp files, ## links and sockets ## ## <param name=”domain”> ## <summary> ## Domain to not audit. ## ## # interface(‘kde_read_tmp’,‘ gen_require(‘ type kde_shared_tmp_t; ’) allow $1 kde_shared_tmp_t: \ dir search_dir_perms; allow $1 kde_shared_tmp_t: \ file read_file_perms; allow $1 kde_shared_tmp_t: \ lnk_file read_lnk_file_perms; allow $1 kde_shared_tmp_t: \ sock_file read_sock_file_perms; ’) ######################################## 35

## <summary> ## Allow domain to manage kde tmp files, links, ## sockets and dirs ## ## <param name=”domain”> ## <summary> ## Domain to not audit. ## ## # interface(‘kde_manage_tmp’,‘ gen_require(‘ type kde_shared_tmp_t; ’) manage_dirs_pattern \ ($1,kde_shared_tmp_t,kde_shared_tmp_t) manage_files_pattern \ ($1,kde_shared_tmp_t,kde_shared_tmp_t) manage_lnk_files_pattern \ ($1,kde_shared_tmp_t,kde_shared_tmp_t) manage_sock_files_pattern \ ($1,kde_shared_tmp_t,kde_shared_tmp_t) ’)

######################################## ## <summary> ## Search kde_shared_home directories. ## ## <param name=”domain”> ## <summary> ## Domain allowed access. ## ## # interface(‘kde_search_home_dir’,‘ gen_require(‘ type kde_shared_home_t; ’) allow $1 kde_shared_home_t:dir search_dir_perms; files_search_rw($1) ’) ######################################## ## <summary> ## Read kde_shared_home files. ## ## <param name=”domain”> 36

## <summary> ## Domain allowed access. ## ## # interface(‘kde_read_home_files’,‘ gen_require(‘ type kde_shared_home_t; ’) allow $1 kde_shared_home_t:file r_file_perms; allow $1 kde_shared_home_t:dir list_dir_perms; files_search_rw($1) ’) ######################################## ## <summary> ## Create, read, write, and delete ## kde_shared_home files. ## ## <param name=”domain”> ## <summary> ## Domain allowed access. ## ## # interface(‘kde_manage_home_files’,‘ gen_require(‘ type kde_shared_home_t; ’) allow $1 kde_shared_home_t:file manage_file_perms; allow $1 kde_shared_home_t:dir rw_dir_perms; ’) ######################################## ## <summary> ## Manage kde_shared_home files and dirs. ## ## <param name=”domain”> ## <summary> ## Domain allowed access. ## ## # interface(‘kde_manage_home’,‘ gen_require(‘ type kde_shared_home_t; ’)

37

manage_dirs_pattern \ ($1,kde_shared_home_t,kde_shared_home_t) manage_files_pattern \ ($1,kde_shared_home_t,kde_shared_home_t) manage_lnk_files_pattern \ ($1,kde_shared_home_t,kde_shared_home_t) ’)

######################################## ## <summary> ## Create file, dir, links of specified type in ## kde_shared_home_t dirs with type transition ## ## <param name=”domain”> ## <summary> ## Domain allowed access ## ## ## <param name=”private type”> ## <summary> ## Private type of created object ## ## # interface(‘files_kde_home_filetrans’,‘ gen_require(‘ type kde_shared_home_t; ’) type_transition $1 kde_shared_home_t:{ file lnk_file \ sock_file dir } $2; ’)

II I

Modul konqueror.pp Soubor s kontexty (konqueror.fc)

/usr/bin/konqueror --\ gen_context(system_u:object_r:konqueror_exec_t,s0) HOME_DIR/\.kde/share/config/konq_history --\ gen_context(system_u:object_r:konqueror_home_t,s0) HOME_DIR/\.kde/share/config/konquerorrc --\ gen_context(system_u:object_r:konqueror_home_t,s0) HOME_DIR/\.kde/share/config/konqsidebartng.rc --\ gen_context(system_u:object_r:konqueror_home_t,s0) 38

HOME_DIR/\.kde/share/config/kuriikwsfilterrc --\ gen_context(system_u:object_r:konqueror_home_t,s0) HOME_DIR/\.kde/share/apps/konqueror(/.*)? \ gen_context(system_u:object_r:konqueror_home_t,s0) HOME_DIR/\.kde/share/apps/khtml(/.*)? \ gen_context(system_u:object_r:konqueror_home_t,s0)

II

Soubor s pravidly (konqueror.te)

policy_module(konqueror,0.1.0) require { type unconfined_t; type unconfined_dbusd_t; type user_home_t; type kde_shared_tmp_t; type kde_shared_home_t; type bin_t; } ######################################## # # Declarations # type konqueror_t; type konqueror_exec_t; application_domain(konqueror_t, konqueror_exec_t) role system_r types konqueror_t; permissive konqueror_t; type konqueror_home_t; files_type(konqueror_home_t) ######################################## # # konqueror local policy # # internal communication is often done using # fifo and unix sockets. allow konqueror_t self:fifo_file rw_file_perms; allow konqueror_t self:unix_stream_socket \ create_stream_socket_perms; files_read_etc_files(konqueror_t) 39

# Use shared libs libs_use_ld_so(konqueror_t) libs_use_shared_libs(konqueror_t) # Read localization miscfiles_read_localization(konqueror_t) # Allow reading font files miscfiles_read_fonts(konqueror_t) # Temp acces from kde module kde_manage_tmp(konqueror_t) files_tmp_filetrans(konqueror_t,kde_shared_tmp_t, \ { file dir lnk_file sock_file }) # Full access to konqueror home konqueror_manage_home(konqueror_t) # For now manage kde_shared_home files and rw acces # to dir and filetrans of created files # In future with more other kde modules should be # reduced to read only or important files should be # removed from kde_shared_home kde_manage_home_files(konqueror_t) # Needed so that konqueror_home_files in # kde_shared_home_t # dir wouldn’t switch to dirs type files_kde_home_filetrans(konqueror_t, konqueror_home_t) # Konqueror runs drkonqi (bin_t) # want to allow running anything # so for now we wont audit that. # to confine drkonqi. dontaudit konqueror_t bin_t:file

We certainly dont in bin_t by Konqueror, Correct solution is exec_file_perms;

#/dev/urandom dev_read_urand(konqueror_t) #/usr files_read_usr_files(konqueror_t) #/proc kernel_read_system_state(konqueror_t) #connect to xdm xserver xserver_stream_connect_xdm_xserver(konqueror_t) # Get self process priority allow konqueror_t self:process getsched; # extended atributes support fs_getattr_xattr_fs(konqueror_t) sysnet_dns_name_resolve(konqueror_t) corenet_all_recvfrom_unlabeled(konqueror_t) # Access to ports 40

allow konqueror_t self:tcp_socket \ create_stream_socket_perms; corenet_tcp_sendrecv_all_if(konqueror_t) corenet_tcp_sendrecv_all_nodes(konqueror_t) corenet_tcp_sendrecv_all_ports(konqueror_t) corenet_tcp_connect_ftp_data_port(konqueror_t) corenet_tcp_connect_ftp_port(konqueror_t) corenet_tcp_connect_http_port(konqueror_t) corenet_tcp_connect_http_cache_port(konqueror_t) # dbus needed to run allow konqueror_t unconfined_dbusd_t:unix_stream_socket \ connectto; allow konqueror_t unconfined_t:unix_stream_socket \ { read write connectto }; dbus_system_bus_unconfined(konqueror_t) dbus_unconfined(konqueror_t) optional_policy(‘ gen_require(‘ type staff_t; type staff_devpts_t; type staff_tty_device_t; role staff_r; ’) konqueror_run(staff_t, staff_r, \ { staff_tty_device_t staff_devpts_t }) ’) optional_policy(‘ gen_require(‘ type unconfined_t; type unconfined_devpts_t; type unconfined_tty_device_t; role unconfined_r; ’) konqueror_run(unconfined_t, unconfined_r, \ { unconfined_tty_device_t unconfined_devpts_t }) ’) optional_policy(‘ gen_require(‘ type user_t; type user_devpts_t; type user_tty_device_t; role user_r; ’)

41

konqueror_run(user_t, user_r, \ { user_tty_device_t user_devpts_t }) ’)

III

Soubor s rozhraními (konqueror.if )

## <summary>policy for konqueror ######################################## ## <summary> ## Execute a domain transition to run konqueror. ## ## <param name=”domain”> ## <summary> ## Domain allowed to transition. ## ## # interface(‘konqueror_domtrans’,‘ gen_require(‘ type konqueror_t; type konqueror_exec_t; ’) domtrans_pattern($1,konqueror_exec_t,konqueror_t) ’)

######################################## ## <summary> ## Search konqueror rw directories. ## ## <param name=”domain”> ## <summary> ## Domain allowed access. ## ## # interface(‘konqueror_search_home_dir’,‘ gen_require(‘ type konqueror_home_t; ’) allow $1 konqueror_home_t:dir search_dir_perms; files_search_rw($1) ’) ######################################## ## <summary> ## Read konqueror rw files. 42

## ## <param name=”domain”> ## <summary> ## Domain allowed access. ## ## # interface(‘konqueror_read_home_files’,‘ gen_require(‘ type konqueror_home_t; ’) allow $1 konqueror_home_t:file r_file_perms; allow $1 konqueror_home_t:dir list_dir_perms; files_search_rw($1) ’) ######################################## ## <summary> ## Create, read, write, and delete ## konqueror rw files. ## ## <param name=”domain”> ## <summary> ## Domain allowed access. ## ## # interface(‘konqueror_manage_home_files’,‘ gen_require(‘ type konqueror_home_t; ’) allow $1 konqueror_home_t:file manage_file_perms; allow $1 konqueror_home_t:dir rw_dir_perms; ’) ######################################## ## <summary> ## Manage konqueror rw files. ## ## <param name=”domain”> ## <summary> ## Domain allowed access. ## ## # interface(‘konqueror_manage_home’,‘ gen_require(‘ type konqueror_home_t; 43

’) manage_dirs_pattern \ ($1,konqueror_home_t,konqueror_home_t) manage_files_pattern \ ($1,konqueror_home_t,konqueror_home_t) manage_lnk_files_pattern \ ($1,konqueror_home_t,konqueror_home_t) ’)

######################################## ## <summary> ## Execute konqueror in the konqueror domain, and ## allow the specified role the konqueror domain. ## ## <param name=”domain”> ## <summary> ## Domain allowed access ## ## ## <param name=”role”> ## <summary> ## The role to be allowed the konqueror domain. ## ## ## <param name=”terminal”> ## <summary> ## The type of the role’s terminal. ## ## # interface(‘konqueror_run’,‘ gen_require(‘ type konqueror_t; ’) konqueror_domtrans($1) role $2 types konqueror_t; dontaudit konqueror_t $3:chr_file rw_term_perms; ’)

######################################## ## <summary> ## Send and receive messages from ## konqueror over dbus. ## ## <param name=”domain”> ## <summary> 44

## Domain allowed access. ## ## # interface(‘konqueror_dbus_chat’,‘ gen_require(‘ type konqueror_t; class dbus send_msg; ’) allow $1 konqueror_t:dbus send_msg; allow konqueror_t $1:dbus send_msg; ’) ######################################## ## <summary> ## All of the rules required to administrate ## an konqueror environment ## ## <param name=”domain”> ## <summary> ## Domain allowed access. ## ## ## <param name=”role”> ## <summary> ## The role to be allowed to manage the ## konqueror domain. ## ## ## <param name=”terminal”> ## <summary> ## The type of the user terminal. ## ## ## # interface(‘konqueror_admin’,‘ gen_require(‘ type konqueror_t; ’) allow $1 konqueror_t:process \ {ptrace signal_perms getattr}; read_files_pattern($1, konqueror_t, konqueror_t) kde_manage_tmp($1) konqueror_manage_home($1) ’)

45

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

Recommend Documents