Craftcom > Windows > Windows Vista > UAC
Verze pro tisk
User Account Control

Hlavní cíl

Cílem UAC je umožňit uživateli vykonávat administrátorské akce pod běžným uživatelským účtem. Práva administrátora dovolují uživatelům číst a měnit jakoukoliv část systému včetně dat všech ostatních uživatelů. Bez těchto práv tak uživatelé nemohou měnit důležitá nastavení, nemají přístup k datům ostatních uživatelů na sdílených počítačích a malware nemůže upravovat zabezpečení, nebo vyřadit bezpečnostní software. Práce pod standardním uživatelským účtem ovšem může snížit počet problémů vyžadující zásah administrátora, do určité míry zabránit průniku malwaru a zabezpečit citlivá data na sdílených počítačích.
UAC musel řešit několik problémů, aby mohl běžet s běžným uživatelským účtem. Před Windows Vista se použití administrátorského účtu předpokládalo. Vývojáři předpokládali, že jejich software může upravit jakýkoliv soubor, klíč registru nebo nastavení systému. Některé instalátory návaděly uživatele, aby se přihlásili jako Administrátor nebo na jeden z účtů z administrátorské skupiny. Kromě instalace softwaru potřeboval uživatel práva administrátora i ke změně času nebo otevření portů firewallu.
UAC řeší tyto problémy tak, že většina aplikací může běžet se standardními uživatelskými právy a odstraňuje tím nebezpečí plynoucí z permanentního používání administrátorského účtu. Do jisté míry jsou také vývojáři nuceni psát aplikace, které jsou schopné běžet pod uživatelským účtem a vyžadovat tak co nejméně potvrzení od uživatele.

Práce pod standardním uživatelským účtem

Během vývoje Windows Vista se přišlo na to, že mnoho administračních operací může provádět i uživatel bez možnosti ohrozit bezpečnost systému. Například společnosti, ve kterých zaměstnanci běžně používají uživatelské účty, musely cestující uživatele umisťovat do skupiny administrátorů, protože Windows XP se změnou časové zóny měnil i systémový čas. Uživatel s notebookem, který v zahraničí chtěl změnit časovou zónu, musel mít právo "Change the system time" (vnitřně pojmenované SeSystemTimePrivilege) a toto právo mají jen administrátoři.
Čas je obvykle použit v bezpečnostních protokolech jako Kerberos, ale časová zóna ovlivní jen zobrazený čas. Windows Vista tak přidává další právo "Change the time zone" (SeTimeZonePrivilege), a přiřazuje ho skupině Users jak je vidět na obrázku 1. To společnostem umožní, aby uživatelé jejich notebooků pracovali pod standardním uživatelským účtem.


Obrázek 1 - Právo změnit časovou zónu mají i účty skupiny Users

Windows Vista také dovolí pod uživatelským účtem nastavovat WEP když se připojí k bezdrátové síti, vytvořit VPN připojení, nastavit správu napájení a instalovat kritické updaty systému. Navíc je Group Policy (zásady skupin) nastaven tak, že uživatel může instalovat tiskárny a jiné ovladače schválené administrátorem nebo instalovat ActiveX knihovny z administrátorem schválených stránek.
Co aplikace, které pod uživatelským účtem nepracují korektně? Zatímco některé opravdu ke své činnosti práva administrátora, většina je zbytečne vyžaduje, aby například mohla ukládat data do míst, kam uživatel nemá přístup. Microsoft doporučuje aplikacím vyžadující práva administrátora, aby se nainstalovala do %ProgramFiles% adresáře a v registru pro uložení nastavení vytvořila klíč pod HKEY_LOCAL_MACHINE\Software. Když je aplikace spuštěna, měla by uživatelská data ukládat do %AppData% a uživatelské nastavení do klíče pod HKEY_CURRENT_USER\Software. Jelikož má každý uživatel jiný %AppData% adresář a HKEY_LOCAL_MACHINE hive, jsou nastavení a data jednotlivých uživatelů oddělena. Windows jsou ale většinou používány jako jedno-uživatelský systém a nejpoužívanější účet je administrátorský, aplikace si tak ukládá data nekorektně do míst, kam standardní uživatelsků účet nemá přístup.
Windows Vista umožňuje těmto aplikacím běžet pod standarním uživatelským účtem pomocí virtualizace souborového systému a registru. Když chce aplikace něco měnit v globální části systému a operace selže z důvodu odepření přístupu, Windows přesměrují tyto operace do uživatelsé části. Pokud tedy aplikace čte z globální části, Windows nejprve zkontroluje data v uživatelské části a pokud je nenalezne, povolí čtení z globální části.
Windows Vista používá virtualizaci, pokud uživatel není přihlášen jako administrátor, proces je 32-bitový (ne 64-bitový) a nemá v manifestu informaci o tom, že je psán pro Windows Vista. Takový proces je označován jako legacy proces. Jakékoliv operace prováděné ostatními procesy nejsou virtualizovány. Stav o virtualizaci je uložen jako příznak v jeho token-u, což je kernelovská datová struktura uchovávající bezpečnostní kontext procesu (zahrnuje uživatelský účet, skupinu a práva).
Stav virtualizace procesu můžete vidět ve správci úloh (Task Manager) ve sloupci Virtualizace (Virtualization). Obrázek 2 ukazuje, že u většiny procesů systému jako Desktop Window Manager (Dwm.exe), Client Server Runtime Subsystem (Csrss.exe) nebo Explorer je virualizace vypnutá, protože mají v manifestu informaci o tom, že jsou napsané pro Windows Vista nebo běží pod účtem s administrátorskými právy. Internet Explorer (iexplore.exe) má virtualizaci zapnutou, protože může mít zavedené ActiveX knihovny a obsluhovat skripty, u kterých nelze rozhodnout, zda budou bez administrátorských práv správně fungovat.


Obrázek 2 - Zobrazení stavu virtualizace u procesů

Virtualizované cesty jsou %ProgramFiles%, %ProgramData% a %SystemRoot% s výjimkou některých podadresářů. Virtualizovány nejsou ani spustitelné soubory (přípony .exe, .bat, .cmd, .vbs apod.). To znamená, že když se program při zapnuté virtualizaci pokusí sám sebe updatovat z uživatelsého účtu, operace selže. Typy souborů vyloučené z virtualizace můžete přidávat do klíče:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Luafv\Parameters\ExcludedExtensionsAdd
Před příponami se neuvádějí tečky.
Modifikace virtualizovaných adresářů je přesměrována do uživatelského adresáře pro virtualizaci - %LocalAppData%\VirtualStore. Například když se proces se zapnoutou virtualizací pokusí vytvořit soubor C:\Windows\Application.ini, ve skutečnosti se vytvoří v C:\Users\<user>\AppData\Local\VirtualStore\Windows\Application.ini (kde <user> je jméno uživatele resp. název účtu). Adresář Local zvýrazňuje fakt, že se data ukládají jen na počítači kde se pracuje (pro případ že se na účet přihlašuje i z jiných počítačů).
Pokud v Exploreru přejdete do adresáře, kde se nacházejí virtualizované soubory, objeví se v toolbaru tlačítko Compatibility Files (Kompatibilní soubory) jako na obrázku 3. Pokud na něj kliknete, Explorer vás přesměruje do ekvivalentního adresáře ve VirtualStore.


Obrázek 3 - Tlačítko "Kompatibilní soubory" signalizující virtualizaci souborů

Na obrázku 4 je znázorněno, jak UAC File Virtualization Filter Driver (%SystemRoot%\System32\Drivers\Luafv.sys) implementuje pro uživatelské účty souborovou virtualizaci. Jelikož je to ovladač souborového systému, vidí všechny souborové operace, ale virtualizaci zprostředkovává jen pokud operace pochází z legacy procesu. Můžete vidět to, co bylo již napsáno; ovladač mění cílovou cestu pro legacy proces snažící se o operaci v globální části systému, zatímco operace u Windows Vista aplikace projde bez povšimnutí. Legacy proces tak věří že operace byla úspěšná když se soubor vytvořil, ale u Windows Vista aplikace bude do adresáře \Windows odepřen přístup.


Obrázek 4 - Virtualizace souborového systému

Virtualizace registrů je řešena trochu jinak. Virtualizované klíče registru jsou většinou v HKEY_LOCAL_MACHINE\Software ale existuje několik výjimek jako:

HKLM\Software\Microsoft\Windows HKLM\Software\Microsoft\Windows NT HKLM\Software\Classes
Virtualizovány jsou pouze klíče, které jsou modifikovány legacy aplikacemi, ale nepřinášejí problémy v kompatibilitě nebo interoperabilitě. Windows přesměrovávají modifikace virtualizovanách klíčů do HKEY_ CURRENT_USER\Software\Classes\VirtualStore. Klíč je umístěn v Classes hive (soubor %LocalAppData%\Microsoft\Windows\UsrClass.dat), který stejně jako jiné virtualizované soubory, zůstavá na lokálním počítači.
Místo spravování nějakého seznamu virtualizovaných klíčů, má každý takový klíč nastaven příznak REG_KEY_DONT_VIRTUALIZE. Na obrázku 5 můžete vidět výpis i dalších příznaků pro virtualizaci (REG_KEY_ DONT_SILENT_FAIL a REG_KEY_ RECURSE_FLAG) pomocí aplikace Reg.exe. Pokud je REG_KEY_DONT_SILENT_FAIL čistý (hodnota Clear) a klíč není virtualizován (REG_KEY_DONT_VIRTUALIZE je nastaven), je legacy aplikaci umožněna jakákoliv operace . REG_KEY_RECURSE_FLAG určuje, zda klíče pod ním vytvořené budou mít virtualizační příznak s výchozí hodnotu nebo ji zdědí.


Obrázek 5 - Aplikace REG zobrazující příznaky virtualizace klíčů registru

Virtualizace registrů je implementována Configuration Manager-em, který spravuje registr z kernelu (Ntoskrnl.exe). Jako u souborové virtualizace, modifikace virtualizovaných klíčů způsobené lagacy aplikací se přesměrují, zatímco Windows Vista aplikaci se odepře přístup.
Virtualizaci můžete zapínat/vypínat pro jednotlivé procesy pomocí Správce úloh (Task Manager). Volba se nachází v kontextovém menu procesů (vyvoláte pravým tlačítkem). Na obrázku 6 je vidět chování aplikace při změně stavu virtualizace. Příkazový řádek je Windows Vista aplikace, takže virtualizace je po spuštění vypnutá. Protože běží pod uživatelským účtem, systém nepovolí zápis do souboru test.txt jelikož se nachází v adresáři \Windows kam uživatel nemá přístup, ale po zapnutí virtualizace proběhne vytvoření a zápis do test.txt úspěšně. Pokud virtualizaci vypneme, soubor nebude nalezen, protože se nachází ve VirtualStore adresáři.


Obrázek 6 - Chování aplikace v závislosti na virtualizaci

Některé aplikace ale potřebují ke svému běhu pod běžným účtem více než virtualizaci. Například aplikace zjišťující, do které skupiny patří aktuální účet a pokud to není administrátorská skupina, tak se nespustí. Windows Vista zavádí několik oprav kompatibility (compatibility fixes nebo také "shims"), které chod takové aplikace zajistí. Nejpoužívanější opravy pro legacy aplikace jsou popsány v tabulce 1.

OpravaFunkce
ElevateCreateProcess Nahrazuje CreateProcess a obsluhuje ERROR_ELEVATION_REQUIRED chyby vznikající, když se Application Information Service ptá na povýšení.
ForceAdminAccess Předstírá dotazy pocházející od člena skupiny administrátorů.
VirtualizeDeleteFile Předstírá úspěšné smazání globálních souborů a adresářů.
LocalMappedObject Přemapuje globální objekty do uživatelského jmenného prostoru.
VirtualizeHKCRLite, VirtualizeRegisterTypeLib Přesměrovává globální registrace COM objektů do uživatelského umístění.
Tabulka 1 - Seznam nejpoužívanějších oprav

Správci podnikových systémů mohou použít nástroje jako Standard User Analyzer (SUA, součást Application Compatibility Toolkit-u) nebo LUA Buglight, aby zjistili, které opravy jsou potřebné k chodu podnikových legacy aplikací. Opravy se přiřazují aplikacím pomocí Compatibility Administrator-a (také součást Application Compatibility Toolkit-u) a výsledky jsou uloženy do databáze (.sdb soubor) klientských systémů pomocí Zásad skupin (Group Policy).

Mód schvalování administrátorem

I když uživatelé používají jen aplikace kompatibilní se standardním uživatelským účtem, stále pro některé zásahy potřebuje práva administrátora. Nejvíce při instalaci softwaru do globální části, instalaci ovladačů nebo služeb. Modifikace globálních nastavení systému nebo aplikací také vyžaduje administrátorská práva. Řešení může být přepínání do administrátorského účtu, ale to by nutilo uživatele pod tímto účtem pracovat neustále.
Windows Vista zahrnuje vylepšenou funkci "run as", která umožňuje z uživatelského účtu spouštět aplikace s právy administrátora. Aby uživatelé nemuseli pokaždé zadávat administrátorské jméno a heslo, přichází Windows Vista s Admin Approval Mode (AAM). AAM vytváří při přihlašvání uživatele 2 identity: jedna se standardními uživatelskými právy a druhá s administrátorskými. Ve Windows Vista jsou tak uživatelé pod standardním účtem nebo z větší části pod standardním účtem v AAM a vývojáři tak musí předpokládat, že jejich produkty budou provozovány se standardními právy a třeba i bez virtualizace nebo oprav kompatibility.
Poskytnutí administrátorských práv procesu se nazývá povýšení (elevation). Povýšení prováděné v uživatelském účtu se nazývá Over the Shoulder (OTS) povýšení, protože je nutné prověření od někoho s účtem v administrátorské skupině (dá se to přirovnat k tomu, že vás někdo kontroluje "přes rameno" - over the shoulder). Povýšení prováděné AAM uživatelem se zase nazývá odsouhlasené povýšení (Consent elevation), protože uživatel jednoduše odsouhlasí přidělení administrátorskýsh práv.
Windows Vista kontroluje zda je uživatel člen jedné z administrátorských skupin shrnutých v tabulce 2.

Zabudované administrátorské skupiny
Certificate Administrators
Domain Administrators
Enterprise Administrators
Policy Administrators
Schema Administrators
Domain Controllers
Enterprise Read-Only Domain Controllers
Account Operators
Backup Operators
Cryptographic Operators
Network Configuration Operators
Print Operators
System Operators
RAS Servers
Power Users
Pre-Windows 2000 Compatible Access
Tabulka 2 - Seznam zabudovanch administrátorských skupin

Mnoho těchto skupin jsou jen v systémech připojených k doméně a nedávají uživatelům přímo administrátorská práva pro lokální systém, ale dovolují jim měnit doménová nastavení. Pokud je uživatel v jedné z těchto skupin, ale ne v administrátorské skupině pro lokální systém, je používáno OTS namísto odsouhlaseného povýšení.
Pokud se uživatel přihlásí jako člen některé z těchto skupin, Windows Vista vytvoří token reprezentující standarního uživatele. Nový token je ochuzen o všechna práva s výjimkou standardních uživatelských práv zhrnutých v tabulce 3.

Název Interní název
Obcházení křížové kontroly (Bypass traverse checking) SeChangeNotifyPrivilege
Vypnutí systému SeShutdownPrivilege
Odpojení z dokovací stanice SeUndockPrivilege
Zvýšení hodnoty Working Set procesu SeIncreaseWorkingSetPrivilege
Změna časové zóny SeTimeZonePrivilege
Tabulka 3 - Standardní uživatelsá práva

Navíc je v tokenu pro zmíněné administrátorské skupiny příznak USE_FOR_DENY_ONLY. Na obrázku 7 Process Explorer ukazuje členství ve skupině a práva procesu běžícího s administrátorskými právy (vlevo) a bez nich (vpravo).


Obrázek 7 - Token AAM administrátora a běžného uživatele

Tyto skupiny s USE_FOR_DENY_ONLY příznakem mohou být použity pouze k zamítnutí přístupu ke zdrojům, aby nevznikla bezpečnostní díra. Například pokud by Access Control List (ACL) souboru zamítal veškerý přístup administrátorské skupině, ale povoloval přístup jiné skupině do které uživatel patří. V takovém případě, při chybějícím záznamu o administrátorské skupině v tokenu by standarní uživatelská identita měla širší přístup než administrátorská identita.
Domácí systémy a systémy připojené k doméně se k AAM přístupu vzdálených uživatelů chovají různě, protože počítače připojené k doméně mohou používat doménové administrátorské skupiny. Když chce uživatel využít sdílených souborů na domácím počítači, požadují Windows standardní uživatelskou identitu vzdáleného uživatele, ale na systémech připojených k doméně bere Windows ohled na členství uživatele ve všech doménových skupinách a vyžaduje administrátorskou identitu.

Pohodlně přístupná administrátorská práva

Je mnoho způsobů jak systém nebo aplikace upozorní, že vyžadují administrátorská práva. Jedním z nich je ikona barevného štítu například u položky "Spustit jako Administrátor" (Run as Administrator) v kontextové nabídce Exploreru, nebo v nastavení zástupce. "Spustit jako Administrátor" způsobí, že API funkce ShellExecute bude volána s hodnotou "runas" v lpVerb parametru.
Mnoho instalátorů potřebují administrátorská práva a tak image loader, který inicializuje spuštění aplikace, obsahuje detekční mechanismy k identifikaci možných legacy instalátorů. Některé z těchto heuristických mechanismů jednoduše ověřují, jestli název souboru (nebo vnitřní název) neobsahuje výraz "setup", "install" nebo "update". Více sofistikované hledají v souboru určité sekvence bajtů.
Image loader také používá application compatibility (appcompat) knihovnu, aby zjistil, jestli aplikace potřebuje administrátorská práva. Tato knihovna ověřuje databázi kompatibility, zda má aplikace přiřazena příznaky RequireAdministrator nebo RunAsInvoker.
Nejobvyklejší způsob jak aplikace zveřejní, že potřebuje administrátorská práva, je přítomnost requestedElevationLevel tagu v manifestu. Manifest je XML soubor obsahující doplňkové informace o aplikaci a byl zaveden již ve Windows XP k určení závislostí side-by-side knihoven a .NET assemblies. RequestedElevationLevel je potomkem elementu trustInfo, který značí, že aplikace byla nápsána pro Windows Vista. Níže je pro názornost element trustInfo z manifestu souboru Firewallsettings.exe.

<trustInfo xmlns=”urn:schema-microsoft-com:asm.v3”> <security> <requestedPrivileges> <requestedExecutionLevel Level=”requireAdministrator” uiAccess=”false”/> </requestedPrivileges> </security> </trustInfo>
Atribut Level může nabývat jedné ze tří hodnot: asInvoker, highestAvailable, requireAdministrator.
Aplikace nevyžadující ke své práci práva administrátorská práva (jako Notepad.exe), mají hodnotu asInvoker. Aplikace vyžadující maximální přístup pak highestAvailable. Uživatelovi je poskytnuta volba povýšení takové aplikace, jen pokud je přihlášen v AAM nebo je člen lokální administrátorské skupiny. Mezi tyto palikace například patří Regedit.exe, Mmc.exe a Eventvwr.exe. Nakonec hodnotu requireAdministrator mají aplikace, které bez administrátorských práv mohou selhat. V takovém případě je povýšení vyžadováno vždy. Atribut uiAccess určuje, zda aplikace vyžaduje přístup k systémovému uživatelskému prostředí jako systémové dialogy nebo okna povýšených procesů. Takové aplikace musí být podepsané a umístěné v %SystemRoot% nebo %ProgramFiles%.
Manifest si můžete prohlédnout například pomocí aplikace Sigcheck ze Sysinternals.
sigcheck –m <soubor>
Start aplikace vyžadující administrátorská práva zapříčiní, že Application Information Service (AIS, %SystemRoot%\System32\Appinfo.dll) běžící v procesu Service Host, spustí Consent.exe (%SystemRoot%\System32\Consent.exe). Consent si uloží obsah obrazovky jako bitmapu, vytvoří efekt vyblednutí, přepne do desktopu přístupného jen z Local System účtu, vykreslí bitmapu jako pozadí a zobrazí dialog umožňující povýšení procesu. Zobrazení na jiném desktopu zabrání malwaru manipulovat s dialogem.


Obrázek 8 - Variace Consent dialogu

Jak můžete vidět na obrázku 8, dialog může v horní části obsahovat 3 různé pruhy. Pokud je aplikace digitálně podepsaná Microsoftem a nachází se systémové složce Windows, pak má dialog modro-zelený pruh. Šedý pruh je pro aplikace podepsané někým jiným než Microsoftem a nakonec oranžový pruh je pro nepodepsané aplikace. Pro digitálně podepsané aplikace dialog dále zobrazuje ikonu, popis a vydavatele. Pro nepodepsané pak obenou ikonu, název souboru a text "Unidentified Publisher" (Neznámý vydavatel). Pro malware je tak těžší vydávat se za důvěryhodnou aplikaci. Tlačítkem Details (detaily) zobrazíte příkaz, kterým byla aplikace spuštěna. AAM dialog je podobný ale není nutné zadávat údaje pro administrátorský účet, stačí kliknout na Continue (Pokračovat). Pokud uživatel povýšení zamítne, systém pošle zprávu o odepření přístupu procesu, který se pokusil aplikaci spustit. Pokud uživatel s povýšením souhlasí, AIS zavolá funkci CreateProcessAsUser aby se aplikace spustila s příslušnou administrátorskou identitou. Protože by se tak ale AIS stal rodičem povýšeného procesu, funkce CreateProcessAsUser může spouštěnému procesu nastavit jiné ID rodiče. AIS tak nastavuje jako rodiče proces, který aplikaci původně spouštěl (obrázek 10).


Obrázek 10 - Postup povyšování procesu

Přestože dialog pro povýšení běží na jiném desktopu, uživatel nemá způsob, jak ověřit že jde o pravý dialog a ne o podvržený malwarem. To ovšem není záležitost AAM, protože samotným podvržením dialogu nemůže malware získat administrátorská práva. Mohl by ale podvržením dialogu pro OTS povýšení získat od uživatele přihlašovací údaje (a tím i přístup) k administrátorskému účtu.
Z tohoto důvodu se nedoporučuje používat OTS povýšení ve firemním prostředí. OTS povýšení se dá zakázat v Local Security Policy Editor (Secpol.msc) nastavením položky "User Account Control: Behavior of the elevation prompt for standard users" na hodnotu "Automatically deny elevation requests".
Domácí uživatlé vyžadující vysokou bezpečnost by měli nastavit OTS povýšení tak, aby vyžadoval Secure Attention Sequence (SAS), který nedokáže malware odchytit ani simulovat. SAS můžete nastavit v Group Policy Editor (Gpedit.msc) - Computer Configuration | Administrative Templates | Windows Components | Credential User Interface povolením "Require trusted path for credential entry". Po tomto nastavení bude k zobrazení dialogu nutné stisknout Ctrl+Alt+Delete.

Izolace povýšených procesů

Windows Vista izoluje povýšené procesy, aby je chránil před malwarem běžícím na stejném desktopu se standarními uživatelskými právy. Bez izolace by malware mohl povýšené procesy ovládat pomocí uměle vytvořených zpráv myši a klávesnice. Přestože bezpečnostní model systému zabraňuje malwaru pod uživatelským účtem manipulovat s povýšenými procesy, nezabrání malwaru s právy administrátora, aby otevřel povýšený proces, vnesl do něj vlastní kód a spustil v něm thread, který tento vpravený kód vykoná.
Ochrana pro zprávy posílané oknům se nazývá User Interface Privilege Isolation (UIPI) a je založena na Windows Integrity Mechanism, který systém používá také k izolaci povýšených procesů. V tomto novém bezpečnostním modelu mají všechny procesy a objekty svůj stupeň integrity. Zásada integrity objektů (object’s integrity policy) může k procesu omezit přístup, který by jinak model Windows Discretionary Access Control (DAC) povolil.
Úrovně integrity (Integrity levels - IL) jsou reprezentovány bezpečnostními identifikátory (Security Identifiers - SIDs), které také reprezentují uživatele a skupiny, kde je úroveň uložena v SID’s Relative Identifier (RID). V následující tabulce jsou názvy, SID a RID (v hexadecimální podobě) pro 4 primární úrovně integrity.

Název SID RID
Low Mandatory Level S-1-16-4096 0x1000
Medium Mandatory Level S-1-16-8192 0x2000
High Mandatory Level S-1-16-12288 0x3000
System Mandatory Level S-1-16-16384 0x4000
Tabulka 4 - Základní úrovně integrity

Čísla RID ukazují, že mezi úrovněmi je rozestup 0x1000 a to dovoluje v budoucnu přidávat další.
Tabulka 5 pak ukazuje zásady mezi objekty a typy přístupů, které tyto zásady omezují. Tyto typy korespondují s definovanými generickými přístupovými právy (více o generických přístupových právech se dočtete na MSDN: Generic Access Rights).

Zásada Efekt
No-Write-Up Proces s nižším IL nemůže modifikovat proces s vyšším IL
No-Read-Up Proces s nižším IL nemůže číst z procesu s vyšším IL
No-Execute-Up Proces s nižším IL nemůže spouštět proces s vyšším IL
Tabulka 5 - Zásady úrovní integrity

Například No-Write-Up zabrání, aby proces s nižší IL získal jakékoliv právo ve skupině GENERIC_WRITE. Výchozí zásada pro většinu objektů (zahrnuje soubory a klíče registru), je No-Write-Up, která předchází tomu, aby proces získal přístup pro zápis do objektu se stejnou nebo vyšší IL, i když Discretionary Access Control List (DACL) takový přístup uživateli povolí. Jinou zásadu mají jen objekty v podobě procesů a threadů. Jejich zásada, No-Write-Up + No-Read-Up, zabraňuje vnesení kódu (a tak i čtení důvěrných dat) procesem s nižší IL.
Windows přiřazují IL každému procesu a její hodnota je uložena v tokenu (spolu se SIDs skupin, kterým náleží účet pod kterým proces běží). Následující tabulka ukazuje některé příklady přiřazení IL určitým typům procesů.

Úroveň integrity Procesy
Low Mandatory Level Internet Explorer v chráneném módu a jím spuštěné procesy
Medium Mandatory Level Nepovýšené procesy spuštěné standarním uživatelem
High Mandatory Level Procesy bežící s administrátorskými právy
System Mandatory Level Procesy spuštěné pod účty Local System, Local Service a Network Service
Tabulka 6 - Příklady přiřazování úrovní integrity procesům

Procesy obvykle zdědí IL po svém rodiči, ale rodič může spustit proces s jinou IL jako například AIS, když spouští povýšený proces. Integrity level procesu můžete zjistit pomocí utility Whoami volané s parametrem /all, pomocí Process Exploreru od Sysinternals (přidáním sloupce Integrity Level) nebo pomocí utility AccessChk.
Každý zabezpečitelný objekt má buď explicitní nebo implicitní IL. Objekty jako proces, thread nebo token mají vždy IL přiřazeny explicitně. Většina objektů nemá IL přiřazenou explicitně a tak se použije výchozí hodnota Medium. Výjimkou jsou objekty, které vytvořil proces s IL na Low. Takové objekty mají výchozí hodnotu také Low. Na obrázku 11 můžete vidět, že složka, která musí být přístupná pro Internet Explorer v chráněném módu, má IL hodnotu Low.


Obrázek 11 - Aplikace Accesschk zobrazující IL uživatelského adresáře favorites

- Podrobnosti o implementaci IL naleznete v původním článku na TechNetu -

Povýšené procesy a bezpečnostní hranice

Je nutné si uvědomit, že povýšení procesů je výhoda ale ne tzv. bezpečnostní hranice. Taková bezpečnostní hranice je třeba uživatelský účet (protože bez povolení nemá uživatel přístup k datům jiného uživatele) a vyžaduje bezpečnostní politiku, která určí co takovou hranici překročí.
Protože povýšení není bezpečnostní hranice, není možné zajistit, aby malware běžící s běžnými uživatelskými právy nezneužil povýšený proces k získání administrátorských práv. Například dialog pro povýšení zjistí informace o procesu, který žádá o povýšení, ale neřekne nic o tom, co proces udělá až bude povýšen. Takový proces může načítat knihovny, otevírat soubory nebo komunikovat s jinými procesy. Každá z těchto operací může způsobit zneužití procesu malwarem.
Povýšené AAM procesy jsou obzvláště náchylné k zneužití, protože běží pod stejným účtem jako procesy se standarními právy a sdílejí tak uživatelský profil. Mnoho aplikací čte nastavení a načítá rozšíření registrované v uživatelském profilu a to je příležitost k povýšení malwaru. Například běžné dialogy načítají rozšíření, jejichž nastavení je v registru (pod HKEY_CURRENT_USER). Malware tak může mezi tyto rozšíření uložit sám sebe a získat vyšší práva, když jej dialog povýšeného procesu načte.
Další riziko spočívá v tom, že povýšené procesy sdílejí s ostatními procesy v relaci (Session) vnitřní jmený prostor, kde systém uchovává objekty jako události, mutexy, signalizace a sdílenou paměť. Pokud malware ví, jaký objekt při spuštění povýšený proces čte, mohl by vytvořit objekt, který dokáže způsobit přetečení bufferu a malware pak může zavést svůj kód do povýšeného procesu. Tento typ ůtoku je velice složitý, ale i tak je lepší mu předcházet pomocí OTS povýšení.

Závěr

Zavedením UAC mohou nyní domácí uživatelé i zaměstanci podniků pracovat běžně pod uživatelským účtem a získat tím výhody jako ocharana systému před náhodným nebo úmyslným poškozením, ocharana dat nebo zabránění neautorizovanému přístupu.

Mitch


© 2005 - 2011 Craft, craftcom.net
Všechna práva vyhrazena.
Šíření a kopírování textů, obrázků a jiných záznamů je bez předchozího souhlasu zakázáno.
Stránky vyhovují standardům: HTML 4.01 · CSS 2 · RSS 2
Čas zpracování: 98.112 ms