1. diel - Kontrola používateľských účtov vo Windows - zoznámenie

Kontrola uživatelských účtů (User Account Control – UAC) je mechanismus představený ve Windows Vista za účelem snížení množství kódu běžícího s administrátorskými právy. V tomto miniseriálu se dozvíte, jak tento mechanismus běh s nižším oprávněním zajišťuje, a dostane se i na jeho slabiny.

Aplikace překládané pro Windows Vista (pro novější verze to samozřejmě platí také) by měly v rámci svého manifestu (XML soubor vkládaný přímo do binárky aplikace) určit, jaká oprávnění ke svému běhu požadují. Pro tento text je zajímavá možnost požadovat administrátorská práva. Pokud takovou aplikaci spustíte pod uživatelem s nižším oprávněním (ať už sníženým pomocí UAC, nebo protože daný uživatelský účet prostě administrátorskými právy nedisponuje), systém se vás prostřednictvím dialogu, jehož ukázku vidíte na obrázkách 1 a 2, zeptá, zda této aplikaci administrátorská oprávnění poskytnete. Dialog zobrazuje základní informace o aplikaci, zejména pak důvěryhodnost jejího vydavatele. Důvěryhodný vydavatel (obrázek 1) se pozná tak, že je EXE soubor aplikace digitálně podepsán certifikátem vydaným důvěryhodnou certifikační autoritou. Jinak je aplikace považována za nedůvěryhodnou, na což vás dialog upozorní vykřičníkem (obrázek 2).

Obrázek 1: UAC dialog pro důvěryhodné aplikace

Obrázek 2: UAC dialog pro nedůvěryhodné aplikace

Poznámka: V případě, že uživatel spouštějící aplikaci vyžadující administrátorská práva není správcem (administrátorem), pro povolení spuštění aplikace je nutné zadat uživatelské jméno a heslo účtu s administrátorskými právy, pod nímž je pak daná aplikace spuštěna.

Obrázek 3: UAC dialog uživatele bez administrátorských práv

Nabízí se otázka, jakými právy disponuje kód, který běží pod uživatelským účtem disponujícím administrátorskými právy, ale jenž neprošel UAC dialogem, protože administrátorská práva explicitně nepožadoval. Odpověď na tuto otázku vyžaduje základní zanlosti bezpečnostního modelu Windows.

Bezpečnostní model

Když aplikace potřebuje provést nějaké operace s určitým objektem (souborem, klíčem registru...), musí svůj záměr sdělit jádru operačního systému, včetně toho, jaké operace chce s daným objektem provádět. Jádro systému na základě procesu zvaného kontrola přístupu (access check) rozhodne, zda-li aplikaci požadovaný přístup k objektu povolí či nikoliv. Kontrola přístupu tedy patří mezi základní (a nejdůležitější) mechanismy, na kterých stojí bezpečnost celého systému.

Jak ukazuje obrázek 4 (znázorňující proces kontroly přístupu), aplikace musí svůj nárok na cílový objekt prokázat prostřednictvím přístupového tokenu (access token) uživatele, pod nímž je spuštěna. Token je objekt obsahující důkazy, proč subjektu, který se jím prokazuje (obvykle se jedná o běžící aplikaci), poskytnout či neposkytnout přístup, o který žádá. Proti tokenu stojí deskriptor zabezpečení (security descriptor), datová struktura přilepená na každý objekt, k němuž je třeba řídit přístup (securable object).

Poznámka: Mezi každodenní analogie k procesu kontroly přístupu patří odemykání dveří. Vy jako subjekt požadujete přístup za určité dveře, které jsou ale chráněny zámkem (deskriptor zabezpečení). Abyste se přes ně legitimním způsobem dostali, musíte se jejich zámku „prokázat“ klíčem (tokenem), který vás opravňuje pro vstup. V této analogii lze token chápat i jako svazek klíčů.

Jednu z důležitých součástí tokenu tvoří seznam identifikátorů uživatelů, skupin a dalších entit, kterými se může držitel tokenu prosazovat. Každou z entit definuje jedinečný identifikátor SID (security identifier) a informace o tom, jak jej lze využít v rámci kontroly přístupu. Dalším důležitým prvkem tokenu je úroveň integrity (integrity level); jedná se o číslo udávající důvěryhodnost držitele tokenu.

Protiváhu proti přístupovým tokenům tvoří deskriptory zabezpečení. Každý objekt podléhající bezpečnostnímu modelu disponuje jedním deskriptorem. Jedná se o datovou strukturu udávající, kdo může k danému objektu získat jaký přístup.

První části deskriptoru zabezpečení, na které se jádro při procesu kontroly přístupu zaměří, jsou úroveň integrity (definuje úroveň integrity objektu) a integritní politika (mandatory integrity policy). Jádro porovná úroveň integrity tokenu s tou uloženou v deskriptoru, a pokud se ta první ukáže jako nižší, dojde k aplikaci integritní politiky.

Integritní politika představuje možnost, jak nedůvěryhodnému kódu zakázat přístup k objektům citlivé povahy. Na základě jejího nastavení jsou subjektům s nižší úrovní integrity zakázány některé (případně žádné či všechny) třídy přístupu (čtení, zápis, spouštění). Pokud aplikací politiky dojde k zákazu některého z oprávnění požadovaných držitelem tokenu, přístup k cílovému objektu je odepřen. V opačném případě nastává porovnávání tokenu s další součástí deskriptoru zabezpečení – DACL.

Obrázek 4: Kontrola přístupu

DACL lze považovat za hlavní součást deskriptoru zabezpečení. Jedná se o datovou strukturu, která definuje, jaká oprávnění mohou různé subjekty (uživatelé) k danému objektu získat. Je reprezentována jako seznam trojic (typ;SID;přístup), kde

• typ udává, zda daná trojice (též zvaná jako access control entry – ACE) přístup povoluje či zakazuje,
• SID určuje entitu (uživatele, skupinu...), na kteoru se trojice vztahuje, a
• přístup definuje povolená či zakázaná oprávnění.

Při kontrole přístupu jádro systému postupně prochází DACl deskriptoru zabezpečení cílového objektu (od první trojice po poslední, takže zabezpečení objektu závisí na pořadí těchto trojic), a pokud narazí na trojici s SID obsaženým v tokenu žadatele o přístup, aplikuje tuto trojici na seznam požadovaných oprávnění. Procházení DACL končí jedním z následujících případů:

• Dosavadním procházením byla nalezena množina ACE povolující všechna oprávnění, která držitel tokenu požaduje. Přístup k objektu je povolen.
• Došlo k aplikaci ACE zakazujícího některé z požadovaných oprávnění, což vede k odepření přístupu k cílovému objektu.
• Bylo dosaženo konce DACL (což zahrnuje i prázdné DACL) aniž by nastal libovolný z předchozích případů. Přístup k objektu je odepřen.

Token pro každé v něm obsažené SID definuje, zda lze tento identifikátor aplikovat na oba typy položek v DACL (tedy povolujících či zakazujících určitý typ přístupu), nebo pouze při zakazování přístupu.

To je k úvodu vše. Příště budeme pokračovat a nastíníme si i několik přístupů, jak UAC obejít..