Při návrhu systému je důležité mít jasný cíl co přesně je požadováno. To je základní stavební kámen. V minulosti nalezneme řadu příkladů:

Transkript

1 Operační systémy Tomáš Hudec 13 Design OS a bezpečnost Obsah: 13.1 Podstata problému designování, Abstrakce s operacemi, Izolace, Správa hardwaru, 13.2 Příčiny náročnosti návrhu OS, Nejdůležitější důvody náročnosti návrhu a implementace OS, 13.3 Principy a vodítka, Jednoduchost a úplnost, Efektivita implementace, 13.4 Bezpečnost systému, Nejčastější typy útoků, Techniky ochrany, 13.5 Opakování Podstata problému designování Při návrhu systému je důležité mít jasný cíl co přesně je požadováno. To je základní stavební kámen. V minulosti nalezneme řadu příkladů: Úspěch jazyka C (Ken Thompson, Dennis Ritchie). Návrh měl jasný cíl: navrhnout vyšší programovací jazyk vhodný pro systémové programování, do kterého by se přepsal kód operačního systému UNIX. Neúspěch jazyka PL/I (IBM 1960). V té době byly populární zejména jazyky Fortran a Cobol. Oba jazyky měly podstatné nedostatky, někteří tvrdili, že Algol je lepší než oba dva. IBM sestavila komisi pro navrhnutí jazyka pro všechny: vzít to nejlepší z jazyků Fortran, Cobol a Algol. Tahle definice nového jazyka je velmi vágní a návrh neměl žádnou sjednocující myšlenku. Při návrhu operačního systému je třeba mít jasné cíle. Ty se budou lišit v závislosti na budoucím určení OS: vestavěný, serverový, osobní. Hlavní cíle při navrhování OS jsou společné: definovat abstrakce, poskytnout základní (primitivní) operace nad abstrakcemi, zajistit izolaci, spravovat prostředky (hardware) Abstrakce s operacemi Je třeba si zejména uvědomit, že abstrakce jsou obvykle reprezentovány datovými strukturami. Definování abstrakcí v OS je zřejmě ta nejnáročnější část. Od tohoto návrhu se bude odvíjet další složitost (jednoduchost) implementace. Definování některých abstrakcí je poměrně zřejmé, např. proces, soubor, neboť existuje jasná intuitivní představa. Návrh dalších abstrakcí již tak zřejmý není: vlákna, prostředky pro synchronizaci, signály, paměťový model, vstupně výstupní systém, IPC, Nad datovými strukturami abstrakcí je třeba navrhnout základní (primitivní) operace. Některé operace mohou být přístupné pouze 1/5

2 pro jádro OS, takové se případně mohou později změnit. Důležitější z hlediska vývoje OS jsou takové operace, které se zpřístupní uživateli (programátorovi) skrz systémová volání. Dobrý návrh a implementace systémových volání jsou důležité pro životnost operačního systému a vývoj budoucích verzí (zpětně kompatibilních) Izolace Jedna z nejdůležitějších funkcí operačního systému je zajištění izolace. Uživatelé systému si nesmí zasahovat navzájem do svých procesů, systémových prostředků (zdrojů) a dat. Chyba v procesu uživatele nesmí neovlivnit zbytek systému (ostatní procesy, ani systém samotný). Procesy obvykle ukládají trvalá data do souborů a alokované prostředky včetně souborů eviduje struktura procesu. Vztaženo na úroveň návrhu OS to znamená zajistit zejména izolaci procesů a jejich alokovaných zdrojů (zejména operační paměti). Dále je třeba řídit přístup k datům na sekundární paměti (disku) stanovením ochranných prostředků, a to jak trvalých (přístupová práva), tak i dočasných (zámky, exkluzivita přístupu). Výše uvedené platí nejen pro soubory, ale i pro další prostředky a operace nad nimi. Zajištění izolace by mělo být volitelné a selektivní, systém by tedy měl nabídnout možnost sdílení prostředků (zejména sdílení paměti) Správa hardwaru Jednou ze základních funkcí operačního systému je správa prostředků, kam spadá také hardware. Druhou základní funkcí je virtualizace (abstrakce) hardwaru. To znamená, že je třeba navrhnout systém ovladačů zařízení (device drivers). Hardware totiž nesmí být dovoleno používat procesům přímo. To by totiž ovlivnilo další vlastnosti systému, zejména schopnost zajistit izolaci. Je třeba si také uvědomit, že do správy hardwaru nepatří jen správa periferií (vstupně výstupních zařízení), ale také správa sběrnic, čipových sad, čipů řadiče přerušení, kanálů DMA apod Příčiny náročnosti návrhu OS Proč je těžké (složité) navrhnout dobře operační systém? Lze si povšimnout, že zatím nikdo nedeklaroval zákon o zlepšování operačních systémů (softwaru). Pro vývoj hardwaru je dobře známý Moorův zákon. I v současnosti existují operační systémy, které jsou v klíčových ohledech (jako je spolehlivost) horší než UNIX Version 7 ze 70. let 20. století. Proč? Důvodů je celá řada. Mezi nejdůležitější patří nedodržení dobrých designových principů. Operační systém je z podstaty jiný než aplikace Nejdůležitější důvody náročnosti návrhu a implementace OS Rozsáhlost, komplexnost Existují i rozsáhlejší a komplexnější systémy než operační systém, např. letadlo. Většina takových systémů lze však rozložit na izolované menší podsystémy mnohem snadněji než OS. Je to dáno zejména tím, že podsystémy se navzájem tolik neovlivňují. Konkurence Operační systém je víceúlohový, existuje v něm typicky mnoho procesů souběžně. Procesy soupeří o prostředky, zejména o procesor a paměť. Pokud pracují se sdílenými daty, vznikají problémy souběhu (race conditions) a kritické sekce. OS musí nabídnout programátorům prostředky, jak tyto situace řešit. Ochrana Úzce s konkurencí souvisí ochrana. Procesy jsou vlastněny uživateli, kteří si chtějí chránit svá data. Je třeba navrhnout systém tak, aby jim tuto možnost ochrany prostředků dal. Jedná se zejména o implementaci izolace procesů a oprávnění na souborových systémech. 2/5

3 Sdílení Zdánlivě v kontrastu s předchozím bodem je možnost sdílení dat a prostředků. Nicméně se jedná v podstatě o stejnou věc. Izolaci je třeba navrhnout tak, aby nebyla absolutní, ale aby byla selektivní, tedy aby umožnila sdílení, je li to vyžadováno. Podobně implementace přístupových práv na souborových systémech by měla umožnit nejen chránit, ale také selektivně sdílet data mezi uživateli. Životnost Operační systém žije dlouho. Zatímco aplikační software je poměrně snadné vyměnit a nahradit jiným nebo novějším, operační systém se svým prostředím je dlouhodobějšího charakteru. Uživatelé jen neradi instalují celý systém znovu. Z tohoto hlediska je velmi důležité, aby operační systém byl navržen tak, aby v budoucnu s příchodem nového hardwaru (zejména nových periferií) nezpůsoboval pokud možno žádné potíže aby byl připraven. Návrh systému ovladačů by měl být takový, aby pro vývojáře hardwaru bylo snadné začlenit nový ovladač. Obecnost použití Vývojář operačního systému obvykle neví, co všechno bude chtít uživatel na systému dělat, jaké aplikace programátoři vyvinou a kde všude bude jejich systém nasazen. Pokud má vyhovět co největší množině uživatelů, musí být dobře škálovatelný. Příkladem takového systému je třeba QNX nebo Linux. Oba lze nalézt v celé řadě různých systémů od vestavěných zařízení až po distribuované systémy. Přenositelnost S vývojem hardwaru se může stát, že bude existovat (designově, cenově) lepší platforma, na které by mohl navrhovaný operační systém běžet. Pokud je návrh vypracován s ohledem na přenositelnost, může být poměrně snadné systém přenést provozovat i na jiném než původním hardwaru. Souvisí s tím také možnost změny reprezentace vícebajtových proměnných v paměti: big endian little endian. Příkladem může být operační systém společnosti Apple, která v roce 2009 přešla z platformy PowerPC (big endian) na platformu Intel (little endian). Jednalo se o již třetí změnu platformy. V předchozím příkladu se jedná o změnu podporované platformy. Některé operační systémy však podporují více platforem současně, např. Linux podporuje více než patnáct různých architektur procesorů a je schopen běžet od malých systémů (telefony, PDA) přes osobní počítače, servery až po superpočítače. (Linux běží na více než 90 procentech světových Top 500 nejvýkonnějších počítačových systémů.) Zpětná kompatibilita Většina uživatelů vyžaduje zpětnou kompatibilitu operačního systému s předchozím systémem (nebo jeho předešlou verzí). Mají li si nainstalovat novější verzi, nebudou spokojeni, pokud jim stávající používané aplikace na novém systému nepoběží. V designu operačního systému je tedy třeba dbát na to, aby návrh byl dostatečně robustní a aby v budoucnu nezpůsobil komplikace. Jakákoli chyba se pak může vléct s vývojem dalších verzí a může být velmi obtížné se takovéto designové chyby v budoucnu zbavit Principy a vodítka Při návrhu operačního systému je vhodné držet se několika málo vodítek: jednoduchost, úplnost, efektivita implementace Jednoduchost a úplnost Princip jednoduchosti je někdy označován termínem KISS (Keep It Simple, Stupid). Kdy je systém jednoduchý a úplný? Antoine de Saint Exupéry: Dokonalosti nedosáhneme tehdy, když není nic, co bychom přidali, ale tehdy, když už není, co bychom odebrali. Albert Einstein: Vše by mělo být tak jednoduché, jak to jde, ale ne jednodušší. Operační systém by měl dělat to, co má, ale nic navíc. Je třeba definovat minimum mechanismů s jasným chováním. Každá část, vlastnost, funkce, systémové volání by měla dělat jednu věc a tu dělat dobře (efektivně) a správně (korektně). Zvažuje li se přidání nové vlastnosti, je třeba položit si otázku: Co tak hrozného by se stalo, když se vlastnost nepřidá? Je li 3/5

4 odpověď: Nic, ale někdo by to někdy mohl potřebovat., pak je lepší takovou vlastnost zahrnout do knihovny, nikoliv do jádra OS, i když to bude pomalejší (méně efektivní). Je vhodné zmínit citaci, jejímž autorem je sir C. A. R. Hoare, autor algoritmu quicksort a současného znění původně Dijkstrova problému obědvajících filosofů. Citace se týká zejména jednodušších počítačových systémů, ale lze ji vztáhnout i na operační systém: Tony Hoare: There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. Principy a vodítka příklady Příklady systémů, které jdou v jednoduchosti návrhu systémových volání téměř do extrému: MINIX systém je sada procesů se správou paměti, souborovým systémem a ovladači, které běží jako samostatné procesy nad mikrojádrem. Implementuje tři systémová volání nutná pro komunikaci (předávání zpráv) mezi procesy subsystémů: send, receive a sendrec. Poslední jmenované je implementované pro efektivitu: lze je nahradit postupným voláním send a receive, ale v takovém případě by bylo třeba přepínat na režim jádra a zpět zbytečně dvakrát. Amoeba distribuovaný operační systém založený na mikrojádru. Implementuje jediné systémové volání RPC (Remote Procedure Call) velmi podobné volání sendrec ze systému MINIX Efektivita implementace Pokud by měla být implementace vlastnosti operačního systému (např. nové systémové volání) neefektivní, pravděpodobně nemá cenu ji vůbec implementovat. Programátor (jako uživatel operačního systému z hlediska nabízených systémových volání) by měl vždy znát cenu systémového volání. V některých případech je cena poměrně dobře odhadnutelná, např. posunutí pozice v souboru lze dosáhnout dvěma systémovými voláními: lseek prosté posunutí pozice: implementováno jako změna proměnné, read provedení vstupně výstupní operace: implementováno jako volání vstupně výstupní vrstvy a ovladače zařízení. Je li intuitivní předpoklad ceny systémového volání špatný, budou psát programátoři neefektivní programy Bezpečnost systému Hlavní cíle jsou: zajištění důvěrnosti dat, integrita dat, dostupnost systému a dat. Mezi nejčastější příčiny ztráty dat patří: vyšší moc živelní pohroma, válka, hardwarové či softwarové chyby CPU, disky, chyby SW a lidský faktor chybné vstupy, ztráta disku, počítače. Útoky na systém lze rozdělit na útoky zvenčí (typicky po síti) a útoky zevnitř, tj. od uživatelů, pro které je systém určen. Většina útoků bývá vnitřních Nejčastější typy útoků Typy útoků na systém: trojské koně nevinně vypadající programy, které mají škodlivou funkci navíc (malware), login spoofing imitace přihlašovací obrazovky, viry, červi, zadní vrátka (trap door, back door) vložená metoda přístupu navíc, např. při speciální kombinaci vstupních dat se zaručí další práva, logické (časované) bomby po určité době nebo za určitých okolností se spouští škodlivý kód, buffer / stack overflow chyba neošetření maximální délky vstupu při načítání pole hodnot; delší vstup pak přepíše další proměnné nebo dokonce kód a způsobí neočekávané chování programu, 4/5

5 skenování portů (port scanning) zjišťování spuštěných služeb a jejich obslužných programů pro následný pokus o využití známé bezpečnostní slabiny, (D)DoS (Distributed) Denial of Service zahlcení serveru množstvím požadavků, takže se služba zastaví nebo alespoň velmi zpomalí; distribuovaná verze požadavky přicházejí z mnoha různých (již napadených) uzlů sítě. Při podvržení zdrojové adresy lze dosáhnout blokace části sítě (sekundární zneužití ochrany před DoS) Techniky ochrany Při ochraně dat je třeba promyslet cenu dat a podle toho navrhnout (cenově) vhodné zabezpečení. Co se týká uživatelů, zavádí se autentifikace (též autentizace) ověření identity. Identitu lze ověřit mnoha způsoby. Typicky se přiděluje uživatelům přihlašovací jméno a heslo. Mezi další způsoby autentifikace patří: hesla na jedno použití (tokens), challenge response algoritmy, použití smart card nebo podobného specializovaného hardwaru, biometrie otisky prstů, oční sítnice apod. Po ověření identity je třeba zajistit autorizaci ověření oprávnění, tedy co smí uživatel se systémem dělat a která data bude mít přístupná. Mezi různé způsoby zajištění patří: domény ochrany stanovení domén a práv, ACL (Access Control List) stanovení seznamu práv na objekty pro jednotlivé uživatele a jejich skupiny, capability (C list) stanovení práv procesům, firewally a komunikační filtry. Chránit data lze také šifrováním, a to i na úrovni souborových systémů. Více bude probíráno v kurzu Správa operačních systémů Opakování 1. Vysvětlete, co se rozumí definováním abstrakcí s operacemi při návrhu designu OS. 2. Uveďte důvody pro implementaci izolace procesů v OS. 3. Jmenujte nejdůležitější důvody náročnosti návrhu a implementace OS. 4. Stanovte principy, kterých by se měl vývoj OS držet. 5. Jmenujte bezpečnostní rizika a nejčastější metody útoku na systémy. 6. Popište techniky ochrany používané v OS. Naposledy změněno: Pondělí, 7. říjen 2013, /5