}w!"#$%&'()+,-./012345<ya

Transkript

1 Masarykova univerzita Fakulta informatiky Virtuální servery v prostředí Linuxu bakalářský projekt }w!"#$%&'()+,-./012345<ya Vedoucí práce: Mgr. Jan Kasprzak Václav Lorenc Brno, 2002

2 Chtěl bych poděkovat vedoucímu svého projektu, Mgr. Janu Kasprzakovi za pomoc při objasňování chování Linuxu i spoustu trpělivosti, dále pak prof. Donaldu E. Knuthovi za vynikající sázecí nástroj TEX a v neposlední řadě i spolužákům za ochotu poslouchat mé teorie o neprůstřelnosti některých konfigurací a jejich popírání.

3 Prohlašuji, že jsem tento projekt vypracoval samostatně a použil přitom pouze pramenů, které jsou uvedeny v seznamu použité literatury. V Brně dne 18. února

4 Abstract Virtuální servery v prostředí Linuxu, Václav Lorenc Tato práce pojednává o možném provozu virtuálních strojů a služeb v prostředí operačního systému Linux, včetně jeho zabezpečení proti případným chybám aplikací a útoku ze stran uživatelů.

5 Obsah 1 Úvod 6 2 Virtualizace Linuxu Apache, chroot & spol VMware Plex VXE Virtual executing Environment UML User Mode Linux Princip fungování Shrnutí Bezpečnost na úrovni Openwall Project LIDS Linux Intrusion Detection System RSBAC Rule Set Based Security System Vlastnosti Základní bezpečnostní moduly Shrnutí SELinux Security Enhanced Linux Medusa DS9 Security System Podrobnější náhled Shrnutí Závěr 17 Literatura 18

6 Kapitola 1. Úvod 1 Úvod V posledních letech dochází k prudkému rozvoji Internetu a technologií s ním souvisejících. Kdyby každý uživatel měl mít pro svoji stránku či doménu samotný počítač, byly by náklady na provoz těchto domén mnohonásobně vyšší, než tomu tak skutečně je. Poměrně běžně se tedy stává, že jeden fyzický počítač obsluhuje i stovky virtuálních webových serverů jedná se o tzv. webhosting. Teoreticky je možné takto virtuálně vytvářet a spravovat i jiné typy serverů velmi častým případem je takto fungující mail server nebo ftp server. Nebo dokonce cokoliv z tohoto dohromady, pro jednu doménu celý koš služeb. Navíc se poté značně zjednodušuje údržba takovýchto serverů stačí spravovat pouze jediný počítač, při stěhování není nutné přesouvat desítky krabic. Takovéto virtuální stroje zároveň mohou pomoci správcům testovat nové programy, nevyzkoušené konfigurace různých utilit, učit se psát pravidla a následně pro firewally a následně je testovat. A to vše na mnohem menším počtu strojů, než by bylo potřeba v extrémním případě se dá na stroji jediném simulovat celá síť... Při poskytování virtualizovaných služeb pro několik (někdy desítek či stovek) zákazníků je jistě velmi důležitá bezpečnost celého systému, neboť i ta rozhoduje o tom, zda-li se tyto služby budou nebo nebudou využívat. A právě v provozu jediného stroje se spoustou služeb je tu mnohem větší riziko než v nevirtualizovaném prostředí neb při napadení právě tohoto stroje se útočník může dostat ke spoustě citlivých dat najednou. O možném provozu takovéhoto virtuálního stroje, včetně zabezpečení celého systému, pojednává tato práce. Větší pozornost je věnována pouze programům, které se zdály být velmi vhodnými kandidáty pro tento úkol User Mode Linux a zabezpečovací systémy RSBAC a Medusa. Ještě malá poznámka k vybrané distribuci když jsem s tímto bakalářským projektem začínal, měl jsem k dispozici 4GB disk s novou instalací distribuce RedHat 7.0. Během dalších a dalších testů jsem došel k názoru, že použitá distribuce nebyla kvůli své velikosti i kvůli drobným problémům s překladačem (kgcc), který se zejména s prvními verzemi zmiňovaných zabezpečovacích projektu nechoval korektně, zvolena vhodně. V průběhu prvního měsíce jsem tedy vytvořil jakousi vlastní distribuci na základě RedHat 7.0, která se vměstnala na 25 MB a mohla sloužit jako routovací server s možností spravování přes protokol ssh a filtrováním packetů. Tuto verzi jsem používal na spouštění pod virtuálními stroji. K nácviku základních zabezpečovacích technik jsem teprve ke konci projektu vyzkoušel distribuci Slackware, která se díky minimálnímu počtu instalovaných programů vešla na 50 MB včetně Apache a dalších podpůrných utilit. Malé množství běžících démonů též velmi zjednodušilo zabezpečování a dovolilo rychleji uvést celý systém do chodu. 6

7 Kapitola 2. Virtualizace Linuxu 2 Virtualizace Linuxu Tato kapitola je věnována pouze problematice virtualizace Linuxu. Pokusil jsem se seřadit veškerá použitá řešení podle vhodnosti, od nejméně vhodných po nejlepší. Kde to bylo jen trochu možné, snažil jsem se nastínit i postup, jakým se daná virtualizace provádí, včetně výhod a nevýhod. 2.1 Apache, chroot & spol. Prvním způsobem virtualizace, i když asi nejjednodušším ze všech zde zmiňovaných postupů, je pomocí mechanismů implementovaných do linuxových démonů, příp. jen za pomoci klasických linuxových nástrojů. Ještě před nalezením dalších relevantních zdrojů jsem si představoval tento projekt poněkud jinak jako vytvoření několika IP adres na jednom rozhraní, nakonfigurování webového serveru (apache) tak, aby na každé IP adrese měl jinou virtuální doménu a příp. provedení téhož i s ftp démonem (proftpd). Tím pádem by WWW a FTP služby vypadaly, jako by běžely na samostatných počítačích a bylo by možné je kdykoliv přesunout na počítač jiný, aniž by to bylo příliš náročné. Až potud by požadavek na virtualizaci služeb nejspíše mohl být splněn a často je takovéto řešení uspokojivé. Nijak by však nebylo možné, aby uživatel, který si tuto službu objedná, mohl sám provést změnu v konfiguraci Apache, příp. provést jeho restart. Zkusím rozebrat poněkud podrobněji problémy s restartem. Jistě by bylo vhodné, aby webové služby běžely i při takovýchto virtualizovaných strojích na standardních portech, v tomto případě na portu 80. Pro jeho použití je ale nutné získat rootovská práva, neboť linux běžnému uživateli nepovolí zabrat porty s číslem nižším než Toho se dá docílit tím, že Apache bude mít nastavený suid bit, na chvíli získá rootovská práva, zabere si pro sebe port 80 a vrátí se zpět ke svým původním právům. Už v tuto chvíli je tu díky suid bitu jisté nebezpečí v systému. Nicméně celá situace může být ještě mnohem komplikovanější jeden uživatel by rád Apache se zakompilovanou podporou PHP, druhý ji tam naopak odmítá, třetí by chtěl ještě další vymyšlenosti, aby mu vše pracovalo tak, jak si přeje. Tedy různé varianty kompilovaného Apache, různá bezpečnostní rizika a navíc spousta práce pro administrátora celého stroje, nenechá-li tyto operace na jednotlivých uživatelích a to nemůže, neb je tu ona hrozba se suid bitem a možnost, že by uživatel podstrčil místo Apache například shell. Je tedy možné provést jistou virtualizaci již pomocí takovýchto prostředků, záleží však na nárocích kladených na jednotlivé démony komplikovanější požadavky by vedly k neúměrným bezpečnostním rizikům. Pomocí nějakého zabezpečovacího systému zmiňovaného v další kapitole by se dala bezpečnostní rizika minimalizovat či zcela odstranit. Rozhodnutí, zda tedy tento způsob virtualizace zvolit, záleží spíše tedy na komplikovanosti požadavků a následného zabezpečení stroje VMware Komerční a velice kvalitně provedený program jak po uživatelské stránce, tak i po stránce výkonu a možností. Tento gigant je schopen emulovat v podstatě celý stroj typu i386 a tím pádem i libovolný operační systém, který na těchto strojích může být spuštěn. Je dostupný pro Linux, Windows NT4.0 a Windows 2000, pro testovací účely je možné stáhnout třicetidenní licenci zdarma... Takovéto virtuální stroje jsou schopny i síťové komunikace, VMware emuluje i síťovou kartu počítače, jednotlivé procesy VMware jsou schopny spolu komunikovat, dokonce je možné se z virtuálního stroje připojit i na Internet. Nicméně za všechno se platí v tomto případě dokonce dvojnásobně. Cena produktu se nepohybuje zrovna v nejnižších hladinách, navíc je emulace celého počítače velice náročnou záležitostí, neboť VMware musí odchytávat privilegované instrukce a vykonávat je ve vlastní režii, mapovat 7

8 2.3 Plex86 přístupy do paměti a na porty a veškeré takovéto požadavky předávat jádru pro vyřízení. Takovéto zacházení je znát na rychlosti celého provádění původního kódu i na paměťových nárocích, které jsou díky nutnosti mít vyhrazenou oblast paměti pro jeden konkrétní stroj jsou značně vysoké obvykle 64 MB na virtuální počítač, záleží vždy na konkrétním provozovaném operačním systému. Nyní něco o způsobu, jakým VMware a jemu podobné programy fungují. Pokud nějaký program chce emulovat architekturu IA32 (též značena jako x86), je nutné zabezpečit správnou funkci všech instrukcí této architektury. To však ve skutečných operačních systémech, jakým NT a Linux jsou, není možné a i sám procesor obsahuje podporu ochrany takovýchto instrukcí. Proto je nutné při vykonávání emulovaného kódu označit instrukce, které by procesor ani neprovedl, které se odkazují do paměti nebo na porty, na které virtuální počítač nemá přístup, příp. tyto přístupy emulovat. První způsob, který připadá v úvahu, je nechat emulovat kompletní instrukční sadu a stavy registrů a flagů udržovat někde v paměti. Provádění kódu se poté odehrává v jakémsi zcela virtuálním prostředí, kdy je možné pro jednu instrukci vykonat např. celou funkci napsanou v nějakém vyšším programovacím jazyce. Samotný překlad je obvykle obstarán nějakou statickou tabulkou s případnými parametry. Toto je sice jedna z možností, ale v reálné praxi použitelná pouze pro emulaci zcela odlišných architektur počítačů. Nároky na čas provádění původního kódu i na paměť jsou totiž neúměrně vysoké. Pokud je však zaručena rovnost emulovaného typu procesoru a procesoru, na němž bude emulace prováděna, dají se použít různé urychlující metody. Jedna z nich, využívající opět poměrně jednoduchý princip, který už je přeci jen v praxi používán, je vynechání nebezpečných instrukcí z běžného procesního řetězce. Obvykle se to řeší tak, že libovolný spustitelný kód se přetransformuje takovým způsobem, že na místě prvního bajtu oněch instrukcí je zapsána jednobajtová instrukce pro generování trasovacího přerušení. A v něm je možné zjistit původní instrukci, vykonat její kód virtuálně, nastavit správně registry a příznaky... a pokračovat úspěšně dál. Z pohledu přerušeného procesu je všechno v pořádku, privilegované instrukce se také nevykonávaly, přístupy do paměti je možné přemapovat a přístupy na porty emulovat. Jedinou nevýhodou této metody je poměrně výrazná režie, i když mnohem menší než v předchozím případě procesor je schopen vykonávat většinu kódu bez asistence emulačního prostředí. Z celého procesu, ač jenom zhruba nastíněného, lze poznat, že takováto emulace, ač má své klady i zápory, je pro zamýšlený projekt virtualizace jenom některých služeb zbytečně robustní a náročná. Z hlediska bezpečnosti je jistě velmi hezké, že se téměř o každé skupině instrukcí s nebezpečným potenciálem ví a že může být nahrazena posloupností instrukcí jiných, ale právě tato vlastnost neúměrně zatěžuje systém. Při několika instancích VMware (a to i při méně než deseti) již dochází ke značnému přetížení i rychlého systému. Jisté výhody tu přeci jenom jsou není-li k dispozici více fyzických počítačů, je možnost vyzkoušet si nové konfigurace systému nanečisto, včetně rychlejšího ladění startu linuxového systému (v případě vytváření vlastních startovacích skriptů). 2.3 Plex86 Vzhledem k tomu, že komunita vývojářů Open Source nerada vidí kvalitní produkty prodávané za vysoké ceny, bylo jen otázkou času, kdy se objeví i volně dostupná varianta programu VMware. Její jméno je Plex86 a zatím je ve stadiu betaverzí a značného testování. Co do rychlosti je zatím pomalejší než již zmiňovaný VMware, nároky na paměť i další zdroje jsou větší, uživatelské rozhraní nepříliš propracované. Do budoucna je ohlášena nová verze emulace instrukční sady, která by měla nechávat procesoru větší volnost při provádění instrukcí a tím dosahovat mnohem kvalitnějších výsledků na poli rychlosti i ostatních nároků... Ačkoliv by snad mohl být vhodnou náhradou za VMware, přinejmenším po dalším vývoji, spadá tento projekt do stejné kategorie jako VMware a je tedy pro použití u webhostingových společností pro své přílišné nároky nevhodný. 8

9 2.4 VXE Virtual executing Environment 2.4 VXE Virtual executing Environment Tento produkt pochází z Ruska a mohl by být velmi kvalitním řešením problémů s bezpečností, přinejmenším na webových serverech při spouštění cgi skriptů, pro provozování FTP serverů nebo při spouštění nebezpečných démonů typu bind. Jde o komerční řešení, které je možné pro nekomerční účely používat zdarma. Celý tento systém je psán netradičním stylem v rámci ochrany know-how zvolili autoři kompilovaný produkt (dle všeho psaný v LISPu či perlu), jenž je připraven pro jádra 2.2.x a 2.4.x. Je poměrně zajímavé, že mezi podverzemi dané řady se tu nečiní rozdíly vezmou-li se v úvahu odlišnosti mezi jednotlivými verzemi jádra a skutečností, že tyto typy ochran se většinou váží na volání jádra sysctl a syscall. A právě ve způsobu distribuce (bez zdrojových textů) je základní nedostatek tohoto systému není totiž snadné zjistit, zda VXE neobsahuje bezpečnostní chyby a jaká by mohla být jeho slabá místa. Myšlenka však není špatná autoři na svých stránkách tvrdí, že je možné označit některé soubory pouze pro čtení, jiné pouze pro spuštění a ani proces běžící s právy superuživatele nemá šanci toto nastavení změnit. Mělo by se tedy jednat o mnohem přísnější variantu příkazu chroot, modifikovatelnou pomocí LISPových skriptů. Vzhledem k nemožnosti prozkoumat způsob fungování tohoto systému a nutnosti věřit černé skříňce, nezdá se mi použití pro komerční prostředí vhodné hlídat zabezpečovací systém jiným takovým systémem je přinejmenším... zvláštní. 2.5 UML User Mode Linux Toto se zdá být správnou volbou jak co do náročnosti na systémové prostředky, tak i co do poskytovaného výkonu. Pokud jsem u VMware naznačoval, jak moc se na rychlosti i nárocích projeví zlepšení při předpokladu, že se emuluje jeden typ architektury na té samé, dá se zajít i o stupeň dál. Proč nevyužít skutečnosti, že již na systému jedno kvalitní a funkční linuxové jádro běží a nezkusit jeho služeb využívat pro emulaci dalšího, virtuálního linuxového jádra? Autorem UML je Jeff Dike a jeho původním záměrem bylo zjednodušit práci vývojářů při psaní ovladačů a modulů do jádra. V nedávné době se objevil port tohoto prostředí i pro procesory PowerPC, ve stadiu betaverzí je i port pro operační systém Windows. Dike dokonce uveřejnil stránku, která se věnuje správné portaci UML na další systémy, takže je možné, že se v brzké době dočkáme možnosti spouštění linuxového jádra na libovolném systému a libovolném typu procesoru. Mezi zajímavé vlastnosti patří např. následující: Jedná se o skvělé prostředí pro různé testování funkcí jádra pokud UML proces spadne, nepoškodí hostující systém a navíc je restart tohoto procesu rychlejší než reboot celého počítače. Co víc, každý proces UML je současně procesem původního jádra, což umožňuje pohodlné ladění v různých prostředích, na které jsou programátoři zvyklí, např. v Emacsu. Ladící výpisy jádra a používání nejrůznějších logů při vývoji modulů a jádra se tímto stává mnohem snazší. Práce s různými distribucemi je pod UML poměrně běžnou záležitostí. I na stránkách projektu je možné si stáhnout spoustu obrazů s různými instalacemi distribucí, namátkou např. RedHat 7.0 nebo Slackware 7.1. Tím je možné zkoušet i nové distribuce, aniž by byl uživatel nebo správce nucen vyhradit prázdný oddíl na disku, příp. celý nový stroj. Opět je nutno podotknout, že možnost změnit konfiguraci původního systému je při standardním nastavení UML nulová. Analogicky je možné zkoušet i programy, jejichž chováním si nejste naprosto jisti. Teoreticky není problém zkoušet i chování zavirovaných programů a záměrně špatně psaných kusů kódu, ačkoliv je to poměrně svérázné využití možností UML. A v neposlední řadě možnost testování různých síťových konfigurací. Sluší se dodat, že bez podpory síti by byl UML pouze z poloviny tak kvalitní a mocný... 9

10 2.5 UML User Mode Linux Princip fungování Způsob, jakým UML plní svůj úkol, je i není jednoduchý. Veškerá volání jádra totiž trochu pozmění, aby se virtualizovaným procesům zdálo všecho jako při obvyklém způsobu zpracování a aby si ani jádro nestěžovalo na nekorektní požadavky. Procesy spuštěné pod UML vypadají jako procesy v původního systému, jsou i vidět a mají svoje PID to je odlišné od toho, které mají v rámci virtuálního UML stroje. A právě v takovýchto chvílích musí rozdíly maskovat UML, včetně požadavků na alokaci paměti a přepínání mezi procesy. Její maximální velikost je možné nastavit pro libovolnou instanci UML a opravdu na ní závisí chod virtualizovaného systému na 1 MB paměti moc služeb spustit nelze. Ve srovnání s VMware jsou však požadavky UML mnohem menší a již 8 MB je poměrně dostatečným množstvím pro spuštění funkčního routeru s pár filtrovacími pravidly. A paměť je pouze jedním z oříšků, které musel autor UML překousnout, aby celý tento projekt uvedl do chodu. UML řeší ve vlastní režii i přepínání procesů (má to výhodu např. v tom, že ani sebenáročnější proces spuštěný pod UML nemůže drasticky zpomalit jádro hostitelského počítače). Na četné žádosti přidal i schopnost číst soubory nadřazeného systému, přidal možnost striktně oddělit paměti procesů v UML od zbytku světa, dodělal podporu copy-on-write (COW) systému. Striktní oddělení pamětí procesů bylo přiděláno kvůli tzv. jail programům, tedy programům uvězněným v jejich adresovém prostoru. Je to jakási silnější varianta chrootu a jedna z prvních vlaštovek, která tuto možnost UML využívá je balík obsahující bezpečnostními děrami proslulý bind. COW nachází využití především v okamžicích, kdy má běžet několik instancí UML se společným souborovým základem, který se po nějaké době provozu může lišit. Výborné by to mohlo být kupříkladu pro výuku konfigurace linuxových systémů, kdy mohou studenti dostat naprosto stejné kopie systému a na nich si dělat své úpravy a konfigurovat služby. To vše na jediném stroji a s minimálními diskovými nároky. Celý User Mode Linux je možné spustit i s právy běžného uživatele a nikde není nutné použít superuživatelská práva, s jedinou výjimkou. Má-li UML používat i síťová zařízení, je nutné tato zařízení navázat na původní jádro. To je možné provést několika způsoby. A právě jen jediný z nich nevyžaduje superuživatele. Jde o vytvoření vlastního socketu pomocí dodané utility a vnucení tohoto socketu ostatním instancím UML. Tím vznikne malá uzavřená síť neschopná komunikovat s venkovním světem. Je-li nutné připojit jednotlivé instance k fyzické síti, je nezbytné použít některou z dalších utilit a ty již vyžadují suid bit. Při mém testování síťových schopností UML se mi naneštěstí nepodařilo (krom onoho jediného neprivilegovaného případu) síť zprovoznit. Problém byl s největší pravděpodobností ve verzi kompilátoru gcc a jeho neschopnosti přeložit korektně buď jádro upravné pomocí UML patche nebo přiložené utility. Dle konference jsem byl však jeden z mála a u nás ostatních se tento problém zatím řeší Shrnutí Je důležité si rozmyslet, co přesně má být virtualizováno. Tento projekt se hodí pro tvorbu celých linuxových strojů s co nejmenšími nároky. Z konference o UML se čas od času ozve některý z účastníků, že na svém stroji používá UML pro vytvoření virtuálních linuxů pro uživatele a rekord zatím představuje asi 128 instancí UML. Z bezpečnostního hlediska je UML přinejmenším další komplikací pro útočníky. Případný útočník po síti by musel totiž najít nejen chybu v procesech spuštěných pod UML, ale navíc chybu v samotném UML a poté ještě v hostitelském jádře. A často na odrazení útočníka stačí i velká složitost celého útoku. 10

11 Kapitola 3. Bezpečnost na úrovni 3 Bezpečnost na úrovni V okamžiku, kdy se rozhodnete poskytovat virtuální stroje ostatním uživatelům, je bezpečnost systému naprosto nezbytná, neboť v rámci virtuálních strojů mohou uživatelé nabývat rootovských oprávnění. Snad proto existuje několik projektů zabezpečovacích systémů, které právě důsledné oddělení uživatelských procesů od sebe i od zbytku systému více či méně úspěšně řeší. V zásadě se dají tyto systémy rozdělit do dvou částí na ty, které se nemusí příliš složitě promýšlet a prostě fungují, a na ty, které jsou postaveny na tzv. bezpečnostní politice, tedy na promyšleném bezpečnostním modelu, který je možné i v určitých případech prokázat. 3.1 Openwall Project Než začnu popisovat sofistikovanější bezpečnostní systémy, chtěl bych se pozastavit u tohoto projektu. Ač to není komplexní řešení bezpečnosti linuxového systému, rozhodně má k tomuto tématu co říci. Ani linuxové jádro se totiž nevyhne bezpečnostním problémům a chování některých součástí systému (např. souborový systém procfs dovolující uživatelům na procesy i jiných uživatelů) je leckdy nevyhovující. Openwall tedy nejenže dokáže skrýt procesy uživatelů tak, aby každý viděl pouze ty své, ale dokáže zabránit i některým běžným problémům s přetečením zásobníku. To jsou však jen viditelné projevy chování Openwallu, cílem projektu je provést bezpečnostní audit některých verzí jádra vzhledem k rozsáhlosti takovéto snahy se nejprve soustředili na akce prováděné pod oprávněním superuživatele a na síťové služby. Je tu i jeden nepříjemný důsledek takovýchto snah patche do jádra se objevují s velkým odstupem. Dále se Openwall snaží používat silnou kryptografii, obsahuje i podporu pro určení doby platnosti hesel a účtů, kontrolu přístupu na bázi síťových adres a kontrolu integrity systému. Některé myšlenky z tohoto projektu se čas od času objeví ve stabilní větvi jádra, jiné ne důvodem je lehce jiné chování systému a nepříliš velká ochota začleňovat takovéto části do stabilního jádra. Kdoví, třeba někdy v budoucnu bude mít linuxové jádro provedený kompletní bezpečnostní audit právě díky tomuto projektu LIDS Linux Intrusion Detection System Jeden z nejznámějších projektů je právě LIDS, by bylo tedy vhodné se jím alespoň chvíli zabývat. Jedná se o patch do jádra a administrátorské utility lidsadm, pomocí které se celý LIDS konfiguruje. Zabezpečení celého systému se tedy dá provést jedním nebo více skripty. K dispozici je také verze s přidaným Openwall Projectem a nedílnou součástí LIDSu je i detekce skenování portů. Již podle názvu je patrné, pro jakou oblast použití se tento projekt dá použít, tedy zejména pro zabezpečení routerů a firewallů. A nejspíše se dá i dodat na kterých je co nejméně aktivních uživatelů (obvykle tedy tak jeden až dva). Ačkoliv se autoři již několikráte snažili tvrdit, že LIDS obsahuje korektní bezpečnostní model, není to pravda. Jedná se o sadu možných způsobů, kterak označit některý proces za zabezpečený proti signálu SIGKILL, neviditelný pro ostatní uživatele, je možné vytvořit nesmazatelný soubor či soubor čistě jen pro přidávání a jistě toho jde mnohem víc. Základní nedostatek pro běhu v multiuživatelském prostředí tkví ve skutečnosti, že veškerá omezení se týkají procesů a souborů, navíc není možné definovat ucelenou politiku prosazování těchto pravidel. Všichni uživatelé smí nebo nesmí to či ono, bez výjimky. Ale na již zmiňovaných routerech a firewallech to není na škodu a právě integrace nástroje na detekci skenování portů je přesně pro takováto řešení velkou výhodou. Pro systém s virtualizovanými službami, spoustou uživatelů a démony, kteří mění své efektivní UID, je LIDS naprosto nedostačující. 11

12 3.3 RSBAC Rule Set Based Security System 3.3 RSBAC Rule Set Based Security System Autorem je Amon Ott a tato práce vznikla původně jako diplomový projekt. V současné době jsou spoluautory celého systému a některých modelů i Simone Fischer-Hübner a Vadim Kogan. Projekt se i nadále rozvíjí a Ott v rámci svého postgraduálního studia zkouší přidávat nové bezpečností modely. Bezpečnostní model je postaven na systému zvaném Generalized Framework for Access Control (autoři Abrams a LaPadula) Vlastnosti Konfigurace RSBAC není úplně jednoduchá, pokud nemáte mechanismus rolí a přístupových práv v malíčku. Tuto skutečnost se autoři projektu snažili zmírnit existencí přehledného konfiguračního programu používajícího knihovnu Dialogs (a tedy má poměrně hezké textové nabídkové rozhraní). Pro příznivce příkazových řádek je tu však stále možnost používat specializované příkazy pro jednotlivé části konfigurace a tím tvořit automatizované skripty vhodné pro sériovou výrobu serverů zabezpečených pomocí RSBAC. Pomocnou berličkou pro začátečníky je i dokument RSBAC for beginners [9], který se od nedávna díky panu Mlnaříkovi objevil na domovských stránkách RSBAC i v češtině. Jedna z rozporuplných vlastností, o nichž je těžké rozhodnout, zda je dobrá nebo špatná, je způsob, jakým je konfigurace RSBAC uložena. Jedná se o množství binárních souborů, které jsou bez dodatečných prostředků nečitelné. Autoři se hájí skutečností, že je k dispozici přehledné programové rozhraní a administrátoři tím pádem nemají šanci nic pokazit ručně. S tím je možné souhlasit, na druhou stranu je tato konfigurace značně závislá na verzi použitého RSBAC a tedy špatně uchovávatelná pro zálohy. Zároveň není zcela jisté, nakolik autoři počítali s možnosti poškození těchto binárních souborů a následnou možností žádné (nebo ještě hůře špatné) funkce systému. Absence textových konfiguračních souborů se projeví ještě v případě, kdy je třeba zabezpečit větší množství počítačů a na každém z nich provést v bezpečnostní politice drobné změny. Zatímco u textové konfigurace není problém si napsat skript, který provede patřičné změny dle nějaké šablony a poté tyto soubory rozdistribuovat na přislušné počítače, u binárních souborů je tento proces mnohem složitější a často je nutné každý počítač konfigurovat samostatně právě pomocí již zmíněné soustavy menu. Autoři sice dodávají i řádkové ekvivalenty celého menu, ale nikde zatím neexistuje program, který by naklikané konfigurace převedl do soustavy skriptů nebo jiné, čitelné podoby. RSBAC je již od počátků navržen jako modulární systém, s možností přidávat a tvořit nové moduly (základní přehled je uveden v části 3.3.2). Rozhodování o tom, je-li povolen nebo zakázán přístup poté funguje tak, že požadavek přístupu k zabezpečenému objektu (souboru, procesu, zařízení) je předán postupně všem aktivovaným modulům. Zamítne-li jediný z nich přístup, je zamítnut i celý požadavek, bez ohledu na výsledky ostatních bezpečnostních modulů. To má jistě mnoho výhod kdyby mělo být zabezpečení např. souboru pomocí rolí a standardních přístupových práv linux příliš obtížné, je možné pro tento případ použít modul jiný Základní bezpečnostní moduly Úplný přehled modulů, včetně jejich formálního popisu je možné získat z dokumentace RSBAC, příp. na jejich stránkách. Je velmi pravděpodobné, že díky dokumentovanému rozhraní pro psaní dalších modulů budou s postupujícím časem přibývat. Následující přehled tedy zahrnuje pouze ty moduly, které jsou obsaženy v současné verzi RSBAC. Mandatory Access Control (MAC) (Povinné řízení přístupu) Modul MAC je založen na modelu Bell-La Padula původně vyvinutého pro operační systém Multics. Je tvořen skupinou až 64 kategorií, každý objekt (soubory, adresáře, sdílenou paměť, fronty zpráv a další systémové zdroje) může být členem jedné nebo více kategorií. Každý subjekt (uživatelé a procesy, které 12

13 3.3 RSBAC Rule Set Based Security System spouští) na systému, která se snaží o přístup k původnímu objektu musí být ve stejné kategorii jako objekt, příp. v kategorii, která je jí nadřazena. Tradičním objektům v UNIXovém souborovém systému jsou přiřazena oprávnění s tzv. volným řízením přístupu (Discretionary Access Control (DAC), neboť uživatel může změnit vlastnictví dle vlastní vůle. MAC umožňuje systému zajistit, aby cokoliv s klasifikací Secret nemohlo být čteno nebo zapisováno někým, kdo není v kategorii Secret. Celkově se jedná o velmi složitý model a spousta programů by nemusela při takovémto chování práv fungovat korektně. Privacy Model (PM) Modul umožňuje, aby byla určitá data označena svým vlastníkem jako soukromá. RSBAC obsahuje ukázkový zdrojový soubor pro jednoduchou lékařskou aplikaci, která dovoluje např. i to, že informace o pacientech jsou uloženy na stroji s přístupem omezeným jen na určité uživatele. Tento modul je vytvořen podle direktivy EU o bezpečnosti a byl vyvinut ve spolupráci s návrhářem modelu, Simone Fisher-Hübnerem. Malware Scan (MS) Tento model používá prostředí RSBAC k ochraně systému proti poškození některými nechvalně proslulými viry a trojskými koni. Nejedná se přímo o implementovaný bezpečnostní model, spíše o ukázku toho, co se dá do RSBAC poměrně jednoduše přidat. V současnosti tento modul dokáže detekovat pouze viry BlissA a BlissB. Tato kontrola se bohužel provádí při každém spuštění libovolného souboru (ať již binárního nebo v podobě skriptu), čímž se značně zvyšuje zatížení celého systému. Role Compatibility (RC) Modul dovoluje vytváření rolí pro přístup k cílovým typům služeb jakými jsou soubor/adresář, zařízení, proces, IPC a systémová řídící data. Role jsou definovány pro systémového administrátora, administrátora rolí a běžného uživatele. Další role mohou být dodefinovány administrátorem rolí. Každý uživatel má vlastní standardní roli, každá z nich se dědí uživatelovými podprocesy. Běžné chování RSBAC je takové, že root má roli systémového administrátora a správce bezpečnosti je v roli administrátora rolí. Není to ale dáno pevně, administrátor rolí má možnost toto nastavení změnit. Function Control (FC) Tento modul implementuje přístup založený na rolích, jako jsou system administrator, general user nebo security officer. Opět je koncipován tak, aby byl využíván společně s jinými modely. Authentication Module (AUTH) Autentizační modul slouží k prosazování akcí typu setuid. Všechny ostatní moduly, ať už zakompilované nebo generované prostředím, používají modul AUTH k zabezpeční jejich vlastních bezpečnostních modelů. Kontroluje změny UID a není-li řečeno jinak, zamítá je. Access Control Lists (ACL) Modul ACL poskytuje standardní služby typu ACL (v překladu snad Seznamy pro řízení přístupu) pro omezení přístupu k cílům jednotlivým subjektům na systému. Tento modul se tváří, jako by byl nemalou měrou ovlivněn implementací v operačním systému Novell Netware. Poměrně intuitivní způsob fungování je navíc podpořen i přehlednou konfigurací Shrnutí RSBAC je velmi pěkně navržený bezpečnostní projekt. Nebýt problémů se způsobem uložení konfigurace, lehce vyšším zatížením systému a nepříliš propracovaným chováním při změně bezpečnostních pravidel při běhu systému, byl by ideálním kandidátem. I tak je však velmi vhodný pro své příjemné rozhraní, spoustu dokumentace (a to i v češtině) a zejména kvůli svému standardnímu chování po instalaci téměř nic není dovoleno a je nutné celý systém prozkoumat, povolit v RSBAC nejdůležitější změny UID a vytvořit i několik rolí (vhodné jsou např. pro přístup i do /etc/shadow). Tím se správce dozví leckdy i podstatné věci o chování některých démonů. Jedná se tedy o sympatické provedení procesem zabezpečení daného stroje. Přehlednosti pomáhá vlastnost nechat logovat zakázané bezpečnostní přístupy do speciálního souboru, RSBAC umí dokonce zabránit i zahlcení takového logu. Výhodná je i možnost zadat při 13

14 3.4 SELinux Security Enhanced Linux konfiguraci AUTH modulu (tedy při povolování změn UID) rozsah možných UID tato vlastnost se dá s výhodou využít během zabezpečování spouštění skriptů u webového serveru apache 1. Počet rolí v RSBAC je omezen shora číslem 64, ale i autoři sami tvrdí, že systém, který by jich potřeboval více, má špatně navržený bezpečností model, s čímž se dá souhlasit. Přesto je dobré toto omezení znát a počítat s ním v době návrhu bezpečnostního modelu. Celkem tedy až na drobné nedostatky je RSBAC velmi vhodným projektem na zabezpečení serveru se spoustou uživatelů i spuštěných procesů. 3.4 SELinux Security Enhanced Linux Předposlední z projektů, které mají co říci v oblasti zabezpečování chodu linuxového jádra, vyšel z dílny společnosti nad jiné povolané National Security Agency (NSA). Jedná se o poměrně známou organizaci Spojených států, jejímž úkolem je zjišťovat chyby v operačních systémech a případně vydávat certifikáty o jejich bezpečnosti. Již od samého počátku je vidět, že autoři problematice bezpečnosti systémů opravdu rozumí, též to není jejich první počin v této oblasti předchůdce SELinuxu byl Flask Security Architecture. Celý projekt je zpracovaný do nejmenších podrobností, jsou řešeny i otázky, které RSBAC poněkud zanedbal jako jeden příklad za všechny je například i řešení přístupu k mmapovaným souborům: RSBAC nepředpokládá příliš dynamické změny bezpečnostní politiky a pokud se změní za běhu přístupová práva k souboru, který je právě mmapovaný, neprojeví se tyto změny na takto již otevřené soubory. Jinak řečeno všichni uživatelé, kteří měli soubor mmapovaný jej mohou používat dál, zapisovat do něj nebo z něj číst, přesně podle původních oprávnění. SELinux je naopak již od základu koncipován tak, aby každá změna bezpečnostní politiky a oprávnění byla co nejvíce atomická a projevila se do zbytku systému v příkladu s mmapovaným souborem by došlo při přístupu k takovémuto souboru k výjimce Segmentation Fault, příp. General protection fault. SELinux je zajímavý ještě dalšími věcmi a sice svým způsobem aplikace do linuxového jádra a sadou modifikovaných linuxových utilit. V prvních verzích, zhruba někdy kolem počátků větve jádra 2.4.x, byl SELinux patchem do jádra. Postupem času se rozhodli myslet více do budoucna a změnili způsob distribuce i aplikace SELinuxu pomocí využití loadable security modules (LSM), tedy modulů s bezpečností zaveditelných za běhu systému, které by snad měly být součástí linuxového jádra řad 2.5.x a 2.6.x. Druhou zmíněnou zvláštností jsou modifikované utility pro práci se systémem zabezpečeným pomocí SELinuxu. Autoři se totiž rozhodli přidat do jádra další funkce, které je možné z aplikací volat a tím zjišťovat např. bezpečnostní informace o jiných spuštěných aplikacích. Kupříkladu již do základní distribuce přidali lehce modifikovaný příkaz ps, který je schopen zobrazit i bezpečnostní kontexty jednotlivých spuštěných procesů. Druhý (a zdaleka ne poslední) modifikovaný program je login, který při přihlašování uživatele bez zřízeného bezpečnostního kontextu tento kontext po pár otázkách zřídí. Uživatelům bez definovaného kontextu jinak není povoleno se přihlásit. Další možnost naznačili v konferenci věnované SELinuxu jednalo se o běžný X-terminál, který by si ovšem hlídal i to, kdo uložil data do clipboardu a zakázal případně vkládání informací běžným uživatelem do terminálu, kde by byl přihlášený root. Takovýchto možností využití by jistě byla celá řada. Celá konfigurace je čistě textová, což je jistě klad, a je rozdělena do několika souborů, ve kterých se definují role uživatelů a domény jak spouštěných procesů tak souborů na disku. V souvislosti s konfiguračními souboru je tu hned další odlišnost od RSBAC SELinux není závislý na jediném typu konfiguračních souborů, rozhraní pro komunikaci s bezpečnostním démonem je k dispozici a není problém zcela změnit konfigurační program a s ním i strukturu konfigurace. Navíc se SELinux dodává se skriptem, který projde všechny soubory na disku a pokud je zná (tedy pokud se jmenují jako nějaký jemu známý démon a jsou na jím očekávaném místě), přiřadí 1 v tomto místě je nutné ovšem poukázat na skutečnost, že např. PHP skripty se nezávisle na uživateli spouští vždy se stejným UID jako apache, což uspokojivě řeší až apache verze 2 a vyšší. 14

15 3.5 Medusa DS9 Security System jim správnou doménu a typ, čímž je zejména pro uživatele distribuce RedHat značně usnadněna práce. U ostatních distribucí tento skript s největší pravděpodobností nebude natolik účinný. Dalším kladným bodem pro SELinux je přítomnost Openwall patche, který lehce přidává na bezpečnosti celého systému. Jedinu nevýhodu přeci jen SELinux měl při testování jeho schopností mi na počítači nepracoval příliš spolehlivě a navíc bylo nutné před každým jeho použitím nechat aktualizovat informace o souborech na disku, aby jim přiřadil bezpečnostní informace. To značně prodlužovalo dobu práce s tímto projektem. Jinak jsou jeho schopnosti více než vhodné pro zabezpečení systému s mnoha uživateli i procesy. 3.5 Medusa DS9 Security System Tento bezpečnostní projekt pochází ze Slovenska a vypadá jako jeden z nejrobustněji pojatých. Jeho autory jsou slovenští studenti fakulty elektrotechniky a informatiky Slovenské technické univerzity v Bratislavě, Marek Zelem a Milan Pikula, Medusa je jejich diplomovým projektem. Ještě před půl rokem nebyla k dispozici verze pro jádra řady 2.4.x, což jistě spoustu lidí odradilo, ale od té doby se autoři rozhodli poněkud změnit architekturu celého systému. Nyní je tedy k dispozici jak podpora linuxových kernelů 2.2.x i 2.4.x, tak by se v brzké době měly objevit i porty Free/NetBSD pro architektury i386, sparc a mips Podrobnější náhled Projekt je rozdělen na dvě části samotný bezpečnostní kód Medusy (v podobě patche do jádra) a tzv. Constable, tedy program, který se stará o zpracování konfigurace a komunikaci s bezpečnostním jádrem. Stejně jako u SELinuxu to má tedy výhodu v tom, že není nutné se omezit na jediný typ konfiguračního souboru. A také jednu nevýhodu démon navíc by mohl být příčinou deadlocku systému 2. Samotná konfigurace je alespoň zpočátku velmi náročná a komplikovaná v porovnávní s RSBAC chybí počáteční restriktivní konfigurace a tedy je nutné začít opravdu přemýšlet, co je nutné zabezpečit a jaké prostředky k tomu zvolit. Jedná se ale jen o první dojem a po nějaké době se dá na systém tvorby konfigurace nejen zvyknout, ale hrát si s ním podle potřeb a jásat nadšením nad jeho možnostmi. Medusa má totiž nepřeberné množství způsobů, jak systém zabezpečit. Je to dáno i tím, že se konfigurace nepodobá žádnému z předchozích systémů připomíná totiž zdrojový program v některém programovacím jazyce podobnému C/C++. Medusa podporuje hlídaní provádění takřka libovolné služby jádra a přístupy k souborům nebo zařízením. O každém procesu v paměti má Constable stejné informace jako jádro, plus bonus v podobě několika proměnných s bezpečnostním kontextem a právě na hlídaní a vhodné změně těchto informací o procesech je celá Medusa postavena. Zároveň je tu možnost odloučit od sebe skupiny procesů díky tzv. virtual spaces, tedy virtuálním prostorům, kterých může být až 32. Je možné zadefinovat, které procesy spolu mohou komunikovat, kterým je dovoleno čtení a kterým zápis z/do ostatních procesů. Další, čím se Medusa odlišuje od svých kolegů je i způsob zacházení s původními linuxovými právy. Ani jeden z výše představených projektů neumožňoval obejít standardní mechanismus linuxových práv ta se kontrolovala vždy jako první. Naopak Medusa se v řetězci vyhodnocování povolení přístupu předřadí linuxu a je možné díky ní dělat v systému kouzla přístup povolit, ačkoliv by linux jistě zamítnul, povolit a nechat na linuxu, aby vyhodnotil svými prostředky oprávněnost požadavku, zamítnout, příp. požadavek přeskočit. V posledně jmenovaném případě se Medusa tváří, jako by požadavek proběhl, ale ve skutečnosti se nestane vůbec nic. Při přístupu k souborům je možné provést navíc další skvělou věc požadavek na konkrétní soubor nebo adresář přesměrovat na zcela jiné místo. 2 Což se mi stávalo pravidelně při ukončení práce systému. Doteď se mi chybu nepodařilo odhalit, i když věřím, že není způsobena Medusou. 15

16 3.5 Medusa DS9 Security System Schopností modifikovat atributy daného procesu si Medusa připisuje další body k dobru je totiž možné zbavit se potřeby suid programů. Medusa je schopna měnit za chodu i efektivní UID procesu, čímž může chování suid bitu efektivně emulovat. S tím rozdílem, že na konfigurací Medusy je lepší dohled než na tisíce souborů roztroušených po disku. V jedné z ukázkových konfigurací dodávaných s Medusou autoři předvádějí i způsob vylepšování předdefinovaných vlastností tohoto projektu. Jedná se o zabezpečení rozlišující procesy pracující se sítí a procesy lokální. Síťové jsou okamžitě po žádosti o síťové prostředky označeny za nebezpečné a přesunuty do vyhrazeného virtuálního prostoru a je jim vyhrazena speciální oblast na disku, která se stává jejich kořenových adresářem, lokální procesy se řídí běžným způsobem vyhodnocování bezpečnostních požadavků. Vzhledem k tomu, že i procesy login a sshd, které se po přihlášení uživatele mění v jeho nastavený shell, se dají takto ošetřit, platí tato omezení i pro uživatele systému jediní, kteří smějí využívat celý systém bez omezení jsou ti, kteří se přihlásili z konzole Shrnutí Jednoznačně jeden z nejlepších a nejrobustnějších projektů není snadné přijít na to, kterak se má nakonfigurovat, ovšem čtení dokumentace a připojených ukázkových souborů se vyplatí. Ačkoliv to není její původní určení, je Medusa schopna virtualizovat dokonce některé služby. A to natolik, že není snadné (ne-li přímo nemožné) tuto virtualizaci obejít a dostat se do samotného systému s oprávněním superuživatele. Pro budoucí uživatele je tu jedna povzbudivá zpráva zatím se jedná pouze o vývojovou verzi, ale brzy bude k dispozici zcela nový Constable a s ním i nový způsob konfigurace. Dle náhledu již nepůjde o ekvivalent programovacího jazyka, ale spíše o intuitivní popsání systému rolí, domén a jednotlivých omezení jejich interakce. To však neznamená, že starý způsob konfigurace bude nutné zapomenout a rázem přejít na nový, ani v nejmenším. Autoři to zkrátka mají velmi dobře vymyšlené... 16

17 Kapitola 4. Závěr 4 Závěr Co napsat závěrem? Snad jen, že jednoznačný vítěz v žádné z kategorií neexistuje. Správa serverů je velmi různorodá záležitost, stejně jako účely jednotlivých serverů. Občas se hodí virtualizovat jedinou službu, někdy je zapotřebí virtualizovat celý počítač. To samé platí i o bezpečnosti bezpečnostní model je leckdy kanónem na vrabce. Dalším faktorem znemožňující řádné vyhlášení vítězů je i neustálá práce na těchto projektech, včetně poměrně radikálních přepisů jednotlivých částí (např. UML a RSBAC). Za dobu práce na tomto projektu jsem získal zkušenosti se systémy RSBAC, Medusa a projektem UML, které jsem si zároveň velmi oblíbil. Pro zabezpečení routerů a firewallů je spíše vhodnější LIDS. Bylo by však chybou si myslet, že takto zabezpečený systém je nenapadnutelný všechno stojí na linuxovém jádře, jehož bezpečnost není prokázána, a vyjma SELinuxu (a i tam je to sporné) se jedná pouze o ujišťování autorů, že právě jejich systém je ten nejlepší, nejbezpečnější, nejrychlejší, nej... Za nejuniverzálnější i snad nejlépe funkční zabezpečení aplikačního serveru by se dala označit kombinace projektů několika Openwall Project, RSBAC/Medusa, portsentry a pokud je to možné, tak snad rovnou OpenBSD+RSBAC a bdělého správce k tomu. Ale to už by byla úplně jiná práce... 17

18 LITERATURA Literatura [1] Domovská stránka projektu RSBAC. [2] Linux Intrusion Detection System. [3] Medusa DS9 Security System. [4] Openwall Project. [5] Security Enhanced Linux. [6] User Mode Linux. [7] VMware. [8] Virtual executing Environment. [9] Stanislav Ievlev; Hynek Mlnarik. RSBAC pro začátečníky. 18