Sociálne siete

SecIT.sk na Facebooku SecIT.sk na Google+ SecIT.sk na Twitteri

Podporte nás


V prípade, že Vám obsah nášho portálu niekedy nejakým spôsobom pomohol, či bol pre Vás prínosom prosím podporte jeho chod ľubovoľnou čiastkou. Ďakujeme!

Štítky

Vyhľadávanie

You are here

Domov
Upozornenie: Obsah je licenčne chránený a bez písomných súhlasov autora článku a vlastníka webovej stránky nesmie byť v žiadnej forme ďalej kopírovaný a šírený v pôvodnom, či v akokoľvek upravenom stave.

Kontrola uživatelských účtů: seznámení

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 textu 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. Tuto variantu dialogu na obrázku nenajdete.

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 3 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 3: 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.

Odlišnosti oprávnění

Nyní tedy máte dostatečné znalosti, aby šlo zodpovědět otázku, jak se oprávnění aplikacích, které prošly UAC dialogem (nebo byly spuštěny některou z aplikací, jenž jím prošla) co se týče oprávnění odlišují od těch, které takové štěstí neměly. Přitom předpokládáme, že obě třídy aplikací byly spuštěny pod uživatelem s administrátorským oprávněním. Rozdíly ukazuje tabulka 1. Interpretace jejího obsahu je následující:­

  • SID skupiny Administrators nelze použít při povolování přístupu k objektu. Při procházení DACL dochází k ignorování trojic, které povolují přístup skupině Administrators. To například znamená, že aplikace, která neprošla UAC dialogem, nemůže se soubory, jejichž zabezpečení povoluje přístup pouze členům této skupiny, pracovat. ACE zakazující administrátorům oprávnění ale stále platí.
  • Normální úroveň integrity. Aplikace, které neprošly UAC dialogem, při žádostech o přístup k objetkům více trpí restrikcemi integritních politik, což vede například k nemožnosti číst paměť procesů běžících na vyšší úrovni integrity.
  • Superprivilegia nejsou k mání. Superprivilegia dovolují v jistých případech přeskočit celý proces kontroly přístupu a automaticky požadovaný přístup k cílovému objektu povolit, případně získat neomezenou kontrolu nad systémem jiným způsobem. Se superprivilegii se může aplikace tvářit například jako zálohovací (čtecí oprávnění k souborům a registru), obnovovací (záposová oprávnění k souborům a registru) či debugger (neomezený přístup ke všem procesům vyjma chráněných). Z tabulky je patrné, že ten, kdo přes UAC dialog neprojde (a není spuštěn někým, kdo tak učinil), na superprivilegia nemá nárok. Jedná se o důsledek příliš nízké úrovně integrity.

Aplikace, které prošly UAC (nebo byly spuštěny aplikací, jenž měla to štěstí), disponují vysokou úrovní integirty a neplatí pro ně žádné z omezení popsaných výše. Pokud je mechanismus Kontroly uživatelských účtů vypnut, chovají se všechny aplikace spuštěné pod účtem správce, jako by prošly přes UAC dialog.

Tabulka 1: Rozdíly mezi oprávněními aplikací, jenž prošly a neprošly UAC dialogem

Vlastnost Neprošly Prošly
SID skupiny Administrators Pouze zakazování přístupu Plná funkčnost
Úroveň integrity (IL) Normální (8192) Vysoká (12288)
Superprivilegia NE ANO

Podporte nás


Páčil sa Vám tento článok? Ak áno, prosím podporte nás ľubovoľnou čiastkou. Ďakujeme!


ITC manažer Security-portal.cz Soom.cz
Hoax.cz Antivirove centrum Crypto-world.info