Aktualizace: 13.12.2008
Autor: Michal "Mitch" Pavlík
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:
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:
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.
| Oprava | Funkce |
| 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í. |
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 |
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 |
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.
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.
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 |
Čí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 |
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 |
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