Model zabezpečení Windows pro vývojáře ovladačů
Model zabezpečení systému Windows je založený na zabezpečitelných objektech. Každá komponenta operačního systému musí zajistit zabezpečení objektů, za které zodpovídá. Ovladače proto musí zajistit bezpečnost svých zařízení a objektů.
Toto téma shrnuje, jak se model zabezpečení Systému Windows vztahuje na ovladače režimu jádra.
Model zabezpečení Windows
Model zabezpečení systému Windows je založen především na právech jednotlivých objektů s malým počtem oprávnění pro celý systém. Mezi objekty, které lze zabezpečit, patří procesy, vlákna, události a další synchronizační objekty a soubory, adresáře a zařízení, ale nejsou omezené na ně.
Pro každý typ objektu se obecná práva ke čtení, zápisu a spuštění převádějí na podrobná práva specifická pro daný objekt. Například u souborů a adresářů zahrnují možná práva ke čtení nebo zápisu souboru nebo adresáře, práva ke čtení nebo zápisu rozšířených atributů souboru, práva pro procházení adresáře a práva k zápisu popisovače zabezpečení objektu.
Model zabezpečení zahrnuje následující koncepty:
- Identifikátory zabezpečení (SID)
- Přístupové tokeny
- Popisovače zabezpečení
- Seznamy řízení přístupu (ACL)
- Privilegia
Identifikátory zabezpečení (SID)
Identifikátor zabezpečení (SID, označovaný také jako hlavní subjekt) identifikuje uživatele, skupinu nebo přihlašovací relaci. Každý uživatel má jedinečný identifikátor SID, který operační systém načte při přihlášení.
Identifikátory SID vydává autorita, jako je operační systém nebo server domény. Některé identifikátory SID jsou dobře známé a mají názvy i identifikátory. Identifikátor SID S-1-1-0 například identifikuje všechny (nebo svět).
Přístupové tokeny
Každý proces má přístupový token. Přístupový token popisuje úplný kontext zabezpečení procesu. Obsahuje identifikátor SID uživatele, identifikátor SID skupin, do kterých uživatel patří, a identifikátor SID přihlašovací relace a také seznam systémových oprávnění udělených uživateli.
Ve výchozím nastavení systém používá primární přístupový token pro proces pokaždé, když vlákno procesu komunikuje se zabezpečitelným objektem. Vlákno však může zosobnit klientský účet. Když se vlákno zosobní, má token zosobnění kromě vlastního primárního tokenu. Token zosobnění popisuje kontext zabezpečení uživatelského účtu, který vlákno ztělesňuje. Zosobnění je obzvláště běžné při zpracování vzdáleného volání procedur (Remote Procedure Call, RPC).
Přístupový token, který popisuje omezený kontext zabezpečení pro vlákno nebo proces, se nazývá omezený token. Identifikátory SID v omezeném tokenu lze nastavit pouze pro odepření přístupu, nikoli pro povolení přístupu, pro zabezpečitelné objekty. Kromě toho může token popsat omezenou sadu oprávnění pro celý systém. Identifikátor SID a identita uživatele zůstávají stejné, ale přístupová práva uživatele jsou omezená, zatímco proces používá omezený token. Funkce CreateRestrictedToken vytvoří omezený token.
Popisovače zabezpečení
Každý pojmenovaný objekt Windows má bezpečnostní popisovač; některé nepojmenované objekty ho mají také. Popisovač zabezpečení popisuje identifikátory SID vlastníka a skupiny objektu spolu s jeho seznamy ACL.
Popisovač zabezpečení objektu je obvykle vytvořen funkcí, která objekt vytvoří. Když ovladač volá rutinu IoCreateDevice nebo IoCreateDeviceSecure pro vytvoření objektu zařízení, systém použije popisovač zabezpečení na vytvořený objekt zařízení a nastaví seznamy řízení přístupu (ACL) pro objekt. U většiny zařízení jsou seznamy ACL zadané v souboru informací o zařízení (INF).
Pro další informace viz popisovače zabezpečení v dokumentaci k ovladači jádra.
Seznamy řízení přístupu
Seznamy řízení přístupu (ACL) umožňují jemně odstupňovanou kontrolu přístupu k objektům. Seznam ACL je součástí popisovače zabezpečení pro každý objekt.
Každý seznam ACL obsahuje nula nebo více položek řízení přístupu (ACE). Každá funkce ACE obsahuje jeden identifikátor SID, který identifikuje uživatele, skupinu nebo počítač a seznam práv, která jsou pro daný identifikátor SID odepřena nebo povolena.
Seznamy ACL pro objekty zařízení
ACL pro objekt zařízení lze nastavit jedním ze tří způsobů:
- Nastavte výchozí popisovač zabezpečení pro jeho typ zařízení.
- Vytvořeno programově funkcí RtlCreateSecurityDescriptor a nastavenou funkcí RtlSetDaclSecurityDescriptor.
- Zadané v jazyce SDDL (Security Descriptor Definition Language) v souboru INF zařízení nebo při volání IoCreateDeviceSecure rutiny.
Všechny ovladače by měly v souboru INF používat SDDL k určení seznamů ACL pro jejich objekty zařízení.
SDDL je rozšiřitelný jazyk popisu, který umožňuje komponentám vytvářet seznamy ACL v řetězcovém formátu. SDDL se používá jak v uživatelském režimu, tak v režimu jádra. Následující obrázek znázorňuje formát řetězců SDDL pro objekty zařízení.
Hodnota Accessu určuje typ povoleného přístupu. Hodnota SID určuje identifikátor zabezpečení, který určuje, pro koho se hodnota Accessu vztahuje (například uživatel nebo skupina).
Například následující řetězec SDDL umožňuje systému (SY) přístup ke všemu a umožňuje všem ostatním (WD) přístup jen pro čtení:
“D:P(A;;GA;;;SY)(A;;GR;;;WD)”
Hlavičkový soubor wdmsec.h obsahuje také sadu předdefinovaných řetězců SDDL, které jsou vhodné pro objekty zařízení. Například soubor hlaviček definuje SDDL_DEVOBJ_SYS_ALL_ADM_RWX_WORLD_RWX_RES_RWX následujícím způsobem:
"D:P(A;;GA;;;SY)(A;;GRGWGX;;;BA)(A;;GRGWGX;;;WD)(A;;GRGWGX;;;RC)"
První segment tohoto řetězce umožňuje jádru a operačnímu systému (SY) úplnou kontrolu nad zařízením. Druhý segment umožňuje všem uživatelům v integrované skupině Administrators přístup k celému zařízení, ale ne ke změně seznamu ACL. Třetí segment umožňuje všem uživatelům (WD) číst nebo zapisovat do zařízení a čtvrtý segment uděluje stejná práva nedůvěryhodnému kódu (RC). Ovladače můžou používat předdefinované řetězce tak, jak jsou, nebo jako modely pro řetězce specifické pro objekty zařízení.
Všechny objekty zařízení v rámci zásobníku by měly mít stejné seznamy řízení přístupu (ACL). Změna seznamů ACL na jednom objektu zařízení v zásobníku změní seznamy ACL v celém zásobníku zařízení.
Přidání nového objektu zařízení do zásobníku ale nezmění žádné seznamy ACL, a to ani ty z nového objektu zařízení (pokud obsahuje seznamy ACL) nebo všechny existující objekty zařízení v zásobníku. Když ovladač vytvoří nový objekt zařízení a připojí ho k horní části zásobníku, měl by ovladač zkopírovat seznamy ACL zásobníku do nového objektu zařízení zkopírováním pole DeviceObject.Characteristics pole z dalšího nižšího ovladače.
Rutina IoCreateDeviceSecure podporuje podmnožinu řetězců SDDL, které používají předdefinované identifikátory SID, jako je WD a SY. Uživatelská rozhraní API a soubory INF podporují úplnou syntaxi SDDL.
Kontroly zabezpečení pomocí seznamů ACL
Když proces požádá o přístup k objektu, zabezpečení zkontroluje porovnání seznamů ACL objektu s identifikátory SID v přístupovém tokenu volajícího.
Systém porovnává ACE v přísném pořadí shora dolů a zastaví se při první relevantní shodě. Proto byste při vytváření seznamu ACL měli vždy umístit záznamy ACE pro odepření nad odpovídající záznamy ACE pro povolení. Následující příklady ukazují, jak probíhá porovnání.
Příklad 1: Porovnání seznamu ACL s přístupovým tokenem
Příklad 1 ukazuje, jak systém porovnává ACL s přístupovým tokenem procesu volajícího. Předpokládejme, že volající chce otevřít soubor, který má seznam ACL zobrazený v následující tabulce.
ukázkový soubor ACL
| Povolení | SID | Přístup |
|---|---|---|
| Povolit | Účetnictví | Zápis, odstranění |
| Povolit | Prodej | Připojit |
| Odmítnout | Legální | Připojení, zápis, odstranění |
| Povolit | Každý | Číst |
Tento seznam ACL má čtyři ACL, které platí konkrétně pro skupiny Accounting, Sales, Legal a Everyone.
Dále předpokládejme, že přístupový token pro proces žádosti obsahuje IDENTIFIKÁTORy SID pro jednoho uživatele a tři skupiny v následujícím pořadí:
Uživatel Jim (S-1-5-21...)
Skupinové účetnictví (S-1-5-22...)
Právní skupina (S-1-5-23...)
Skupina Všichni (S-1-1-0)
Při porovnávání seznamu ACL souboru s přístupovým tokenem systém nejprve vyhledá ACE pro uživatele Jima v seznamu ACL souboru. Žádný se nezobrazí, proto se hledá ACE pro skupinu Účetnictví. Jak je znázorněno v předchozí tabulce, ACE pro účetní skupinu se zobrazí jako první položka v seznamu ACL souboru, takže Jimovi je uděleno právo na zápis nebo odstranění souboru a porovnání se zastaví. Pokud ACE pro právní skupinu místo toho předchází ACE pro účetní skupinu v seznamu ACL, proces by měl odepřen přístup pro zápis, přidání a odstranění souboru.
Příklad 2: Porovnání ACL s omezeným tokenem
Systém porovnává seznam ACL s omezeným tokenem stejným způsobem jako porovnává hodnoty v tokenu, který není omezen. Identifikátor SID odepření v omezeném tokenu ale může odpovídat pouze hodnotě Odepření ACE v seznamu ACL.
Příklad 2 ukazuje, jak systém porovnává seznam ACL souboru s omezeným tokenem. Předpokládejme, že soubor má stejný seznam ACL zobrazený v předchozí tabulce. V tomto příkladu má však proces omezený token, který obsahuje následující identifikátory SID:
Uživatel Jim (S-1-5-21...) Popřít
Skupinové účetnictví (S-1-5-22...) Zakázat
Právní skupina (S-1-5-23...) Popřít
Skupina Všichni (S-1-1-0)
Identifikátor SID Jima není uveden v seznamu ACL souboru, takže systém pokračuje k identifikátoru SID účetní skupiny. I když seznam ACL souboru obsahuje ACE pro účetní skupinu, tento seznam ACE umožňuje přístup; proto neodpovídá identifikátoru SID v omezeném tokenu procesu, který odepře přístup. V důsledku toho systém směřuje k SID právní skupiny. Seznam ACL pro soubor obsahuje ACE pro skupinu právního oddělení, která odepírá přístup, takže proces nemůže zapisovat, připojovat nebo odstranit soubor.
Privilegia
Oprávnění je právo, aby uživatel provedl v místním počítači operaci související se systémem, například načtení ovladače, změnu času nebo vypnutí systému.
Oprávnění se liší od přístupových práv, protože se vztahují na systémové úlohy a prostředky, nikoli na objekty, a protože jsou přiřazena uživateli nebo skupině správcem systému, nikoli operačním systémem.
Přístupový token pro každý proces obsahuje seznam oprávnění udělených procesu. Před použitím musí být oprávnění výslovně povolena. Další informace o oprávněních najdete v tématu Oprávnění v dokumentaci ovladače jádra.
Příkazy ladicího programu souvisejícího se zabezpečením
Rozšíření !acl formátuje a zobrazuje obsah seznamu řízení přístupu (ACL). Další informace naleznete v tématu Určení seznamu ACL objektu a !acl.
Rozšíření !token zobrazí formátované zobrazení objektu tokenu zabezpečení. Další informace viz !token.
Rozšíření !tokenfields zobrazuje názvy a posuny polí v objektu přístupového tokenu (struktura TOKEN). Další informace najdete v tématu !tokenfields.
Rozšíření !sid zobrazí identifikátor zabezpečení (SID) na zadané adrese. Viz !sidpro více informací.
Rozšíření !sd zobrazí popisovač zabezpečení na zadané adrese. Další informace najdete v tématu !sd.
Scénář modelu zabezpečení Systému Windows: Vytvoření souboru
Systém používá konstrukty zabezpečení popsané v modelu zabezpečení Windows pokaždé, když proces vytvoří popisovač souboru nebo objektu.
Následující diagram znázorňuje akce související se zabezpečením, které se aktivují při pokusu o vytvoření souboru v uživatelském režimu.
Předchozí diagram znázorňuje, jak systém reaguje, když aplikace v uživatelském režimu volá funkci CreateFile. Následující poznámky odkazují na čísla zakroužkovaná na obrázku:
- Aplikace v uživatelském režimu volá funkci CreateFile a předává platný název souboru Microsoft Win32.
- Uživatelský režim Kernel32.dll předá požadavek do Ntdll.dll, který převede název win32 na název souboru systému Microsoft Windows NT.
- Ntdll.dll volá funkci NtCreateFile s názvem souboru systému Windows. V rámci Ntoskrnl.exezpracovává správce vstupně-výstupních operací NtCreateFile.
- V/V Manager znovu zabalí požadavek do volání Správce objektů.
- Správce objektů vyřeší symbolické odkazy a zajistí, že uživatel bude mít oprávnění k procházení cesty, ve které se soubor vytvoří. Další informace naleznete vSprávce objektů v části
Kontroly zabezpečení. - Správce objektů volá systémovou komponentu, která vlastní základní typ objektu přidružený k požadavku. U žádosti o vytvoření souboru je tato komponenta I/O Manager, který vlastní objekty zařízení.
- Správce vstupně-výstupních operací zkontroluje popisovač zabezpečení objektu zařízení proti přístupovém tokenu pro proces uživatele, aby se zajistilo, že má uživatel požadovaný přístup k zařízení. Další informace najdete v tématu Kontroly zabezpečení vV/V Manageru .
- Pokud má uživatelský proces požadovaný přístup, správce vstupně-výstupních operací vytvoří popisovač a odešle žádost o IRP_MJ_CREATE ovladači pro zařízení nebo systém souborů.
- Ovladač podle potřeby provádí další kontroly zabezpečení. Pokud například požadavek určuje objekt v oboru názvů zařízení, musí ovladač zajistit, aby volající měl požadovaná přístupová práva. Další informace naleznete v tématu Kontrola zabezpečení v ovladači.
Kontroly zabezpečení ve Správci objektů
Odpovědnost za kontrolu přístupových práv patří ke komponentě nejvyšší úrovně, která může takové kontroly provádět. Pokud správce objektů může ověřit přístupová práva volajícího, provede to. Pokud ne, správce objektů předá požadavek komponentě zodpovědné za příslušný typ objektu. Tato komponenta zase ověřuje přístup, pokud může; pokud nemůže, předá požadavek nižší komponentě, například ovladači.
Správce objektů kontroluje seznamy ACL pro jednoduché typy objektů, jako jsou události a zámky mutex. U objektů, které mají obor názvů, provádí vlastník typu kontrolu zabezpečení. Správce vstupně-výstupních operací se například považuje za vlastníka typu pro objekty zařízení a objekty souborů. Pokud Správce objektů při analýze názvu najde název objektu zařízení nebo objektu souboru, předá název správci vstupně-výstupních operací, jak je uvedeno ve scénáři vytvoření souboru výše. V/V Manager pak zkontroluje přístupová práva, pokud může. Pokud název určuje objekt v rámci prostoru názvů zařízení, V/V Manager předá název na ovladač zařízení (nebo systému souborů) a tento ovladač je zodpovědný za ověření požadovaného přístupu.
Kontroly zabezpečení ve Správci vstupně-výstupních operací
Když správce vstupu/výstupu vytvoří popisovač, porovná práva objektu s přístupovým tokenem procesu a pak uloží práva udělená uživateli spolu s popisovačem. Po přijetí pozdějších vstupně-výstupních požadavků správce vstupně-výstupních operací zkontroluje práva spojená s popisovačem, aby se zajistilo, že proces má právo provést požadovanou vstupně-výstupní operaci. Pokud například proces později požádá o operaci zápisu, správce V/V zkontroluje práva přidružená k popisovači, aby zajistil, že volající má k objektu přístup k zápisu.
Pokud je popisovač duplikován, je možné z kopie odebrat práva, ale není možné do ní žádná přidat.
Když správce vstupně-výstupních operací vytvoří objekt, převede obecné režimy přístupu Win32 na práva specifická pro objekty. Například následující práva platí pro soubory a adresáře:
| Režim přístupu Win32 | Práva specifická pro objekty |
|---|---|
| GENERIC_READ | ReadData |
| GENERIC_WRITE | ZapsatData |
| OBECNÝ_VYKONAT | Číst atributy |
| OBECNÉ_VŠE | Všichni |
Pokud chcete vytvořit soubor, proces musí mít oprávnění k procházení nadřazených adresářů v cílové cestě. Pokud například chcete vytvořit \Device\CDROM0\Directory\File.txt, proces musí mít právo procházet \Device, \Device\CDROM0 a \Device\CDROM0\Directory. V/V Manager kontroluje pouze práva procházení těchto adresářů.
Správce vstupně-výstupních operací kontroluje při analýze názvu souboru práva procházení. Pokud je název souboru symbolický odkaz, V/V Manager ho přeloží na úplnou cestu a pak zkontroluje práva procházení počínaje kořenem. Předpokládejme například, že symbolický odkaz \DosDevices\D se mapuje na název zařízení s Windows NT \Device\CDROM0. Proces musí mít přístupová práva k adresáři \Device.
Další informace naleznete v tématu Popisovače objektů a Zabezpečení objektů.
Bezpečnostní kontroly v ovladači
Jádro operačního systému zachází s každým ovladačem jako se systémem souborů s vlastním oborem názvů. Následně, když se volající pokusí vytvořit objekt v oboru názvů zařízení, manažer vstupu/výstupu zkontroluje, že proces má práva k procházení adresářů v cestě.
V případě ovladačů WDM správce vstupně-výstupních operací neprovádí bezpečnostní kontroly u prostoru názvů, ledaže je objekt zařízení vytvořen s určením FILE_DEVICE_SECURE_OPEN. Pokud FILE_DEVICE_SECURE_OPEN není aktivován, je ovladač zodpovědný za zajištění zabezpečení svého jmenného prostoru. Další informace naleznete v tématech Řízení přístupu k oboru názvů zařízení a Zabezpečení objektů zařízení.
U ovladačů WDF je příznak FILE_DEVICE_SECURE_OPEN vždy nastavený, což zajišťuje, že před povolením aplikace k přístupu k jakýmkoli názvům v oboru názvů zařízení proběhne kontrola bezpečnostního popisovače zařízení. Další informace naleznete v tématu Řízení přístupu zařízení v ovladačích KMDF.
Hranice zabezpečení Windows
Ovladače komunikující mezi sebou a s volajícími z uživatelského režimu s různými úrovněmi oprávnění se dají považovat za překročení hranice důvěryhodnosti. Hranice důvěryhodnosti je jakákoli cesta spuštění kódu, která překračuje z nižšího privilegovaného procesu na vyšší privilegovaný proces.
Čím vyšší je rozdíl v úrovních oprávnění, tím zajímavější je hranice pro útočníky, kteří chtějí provádět útoky, jako je eskalace oprávnění proti cílovému ovladači nebo procesu.
Součástí procesu vytváření modelu hrozeb je prozkoumání hranic zabezpečení a vyhledání neočekážených cest. Další informace naleznete v tématu Modelování hrozeb pro ovladače.
Všechna data, která překročí hranici důvěryhodnosti, jsou nedůvěryhodná a musí být ověřena.
Tento diagram znázorňuje tři ovladače jádra a dvě aplikace, jednu v kontejneru aplikací a jednu aplikaci, která běží s právy správce. Červené čáry označují ukázkové hranice důvěryhodnosti.
Protože kontejner aplikace může poskytovat další omezení a neběží na úrovni správce, cesta (1) je vyšší riziková cesta pro útok na eskalaci, protože hranice důvěryhodnosti je mezi kontejnerem aplikace (procesem velmi nízkých oprávnění) a ovladačem jádra.
Cesta (2) je nižší riziková cesta, protože aplikace běží s právy správce a volá přímo do ovladače jádra. Správce už má v systému poměrně vysoké oprávnění, takže prostor pro útok od správce k jádru je méně zajímavým cílem pro útočníky, ale stále je to zajímavá hranice důvěryhodnosti.
Cesta (3) je příkladem cesty spuštění kódu, která překračuje více hranic důvěryhodnosti, které by se daly vynechat, pokud se nevytvoří model hrozeb. V tomto příkladu existuje hranice důvěryhodnosti mezi ovladačem 1 a ovladačem 3, protože ovladač 1 přebírá vstup z aplikace uživatelského režimu a předává ji přímo ovladači 3.
Všechny vstupy přicházející do ovladače z uživatelského režimu jsou nedůvěryhodné a měly by být ověřeny. Vstupy pocházející z jiných ovladačů můžou být také nedůvěryhodné v závislosti na tom, jestli byl předchozí ovladač pouze jednoduchý průchozí (např. data byla přijata ovladačem 1 z aplikace 1, ovladač 1 neprovedl žádné ověření dat a právě ho předal ovladači 3). Nezapomeňte identifikovat všechny přístupy k útokům a hranice důvěryhodnosti a ověřit jejich překročení všemi daty vytvořením kompletního modelu hrozeb.
Doporučení k modelu zabezpečení Windows
- Nastavte silné výchozí seznamy ACL při volání rutiny IoCreateDeviceSecure.
- Zadejte seznamy ACL v souboru INF pro každé zařízení. Tyto ACL mohou v případě potřeby uvolnit výchozí ACL.
- Nastavte vlastnost FILE_DEVICE_SECURE_OPEN pro použití nastavení zabezpečení objektů zařízení v oboru názvů zařízení.
- Nedefinujte IOCTLs, které umožňují FILE_ANY_ACCESS, pokud takový přístup nelze záměrně zneužít.
- Pomocí rutiny IoValidateDeviceIoControlAccess zpřísněte zabezpečení stávajících ioCTLS, které umožňují FILE_ANY_ACCESS.
- Vytvořte model hrozeb pro prozkoumání hranic zabezpečení a vyhledání neočekážených cest. Další informace naleznete v tématu Modelování hrozeb pro ovladače.
- Další doporučení zabezpečení ovladačů najdete v kontrolním seznamu zabezpečení ovladačů.