Podrobně o bezpečnosti - Windows Vista by Zoner Press

E N C Y K L O P E D I E

Z O N E R

P R E S S

Podrobně o bezpečnosti

Windows Vista Podrobně o bezpečnosti Windows Vista pro systémové administrátory

pro systémové administrátory

Mark Minasi B Wiley y rPublishing, o n Inc. Hynes

Podrobně o bezpečnosti Windows Vista pro systémové administrátory

Wiley Publishing, Inc.

Podrobně o bezpečnosti Windows Vista pro systémové administrátory Mark Minasi, Byron Hynes

Administering Windows Vista Security - The Big Surprises Mark Minasi, Byron Hynes Published by Wiley Publishing, Inc., 10475 Crosspoint Boulevard, Indianapolis, IN 46256, www.wiley.com. Copyright © 2007 by Wiley Publishing, Inc., Indianapolis, Indiana. © Translation: ZONER software, s.r.o., 2009. All Rights Reserved. This translation published under license with the original publisher John Wiley & Sons, Inc. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording or by any information storage retrieval system, without permission from Wiley Publishing, Inc. Všechna práva vyhrazena. Tento překlad je vydán na základě licenční smlouvy s John Wiley & Sons, Inc. Žádná část této publikace nesmí být reprodukována nebo předávána žádnou formou nebo způsobem, elektronicky ani mechanicky, včetně fotokopií, natáčení ani žádnými jinými systémy pro ukládání bez výslovného svolení Wiley Publishing, Inc.

Podrobně o bezpečnosti Windows Vista pro systémové administrátory Autoři: Mark Minasi, Byron Hynes Copyright © ZONER software, s.r.o. Vydání první v roce 2009. Všechna práva vyhrazena. Zoner Press Katalogové číslo: ZR945 ZONER software, s.r.o. Nové sady 18, 602 00 Brno Překlad: Jaroslav Černý, Marek Střihavka, Šéfredaktor: Ing. Pavel Kristián DTP: Lenka Křížová Trademarks: Wiley, the Wiley logo, and the Sybex logo are trademarks or registered trademarks of John Wiley & Sons, Inc. and/or its affiliates, in the United States and other countries, and may not be used without written permission. All other trademarks are the property of their respective owners. Wiley Publishing, Inc., is not associated with any product or vendor mentioned in this book. The Sybex Brand trade dress is a trademark of John Wiley & Sons, Inc. in the United States and/or other countries. Used by permission. Ochranné známky: Wiley, logo Wiley a logo Sybex jsou ochrannými známkami nebo registrovanými ochrannými známkami vydavatelství John Wiley & Sons, Inc, nebo jejich poboček, ve Spojených státech a/nebo ostatních zemích a nemohou být používány bez písemného oprávnění. Všechny ostatní ochranné známky jsou majetkem jejich vlastníků. Wiley Publishing, Inc. není propojen s jakýmkoliv produktem nebo výrobcem zmíněným v této knize. Obchodní značka Sybex je ochrannou známkou John Wiley & Sons, Inc. ve Spojených státech a/nebo ostatních zemích. Veškeré dotazy týkající se distribuce směřujte na: Zoner Press ZONER software, s.r.o. Nové sady 18, 602 00 Brno tel.: 532 190 883, fax: 543 257 245 e-mail: knihy@zoner.cz http://www.zonerpress.cz

ISBN 978-80-7413-024-3

Tuto knihu věnuji své mamince Virginii Marii Minasi, rozené Hartley. I když mezi námi již delší dobu není, moji bratři a já v sobě stále neseme – a vždy budeme nést – otisk její duše. Maminko, moc nám scházíš a doufáme, že tam, kam jsi odešla, jsi našla klid a možná – kdo ví – i pár báječných překvapení, kterými jsi nás tak těšila.

Poděkování Jak se podrobněji dozvíte v Úvodu, nápad na tuto knihu jsem dostal koncem června 2006 a téměř současně s tím jsem si uvědomil, že pokud ji skutečně napíšu, musím to udělat co nejrychleji. Jakmile totiž autor dopíše poslední větu knihy, stále ještě spousta práce zbývá – celé měsíce následných redakčních úprav, oprav, grafického návrhu rozvržení, sloupcových korektur, tisku, vazby, balení a finální dopravy do vám nejbližšího knihkupectví. Věděl jsem ale také to, že tato kniha musí být vydána do konce roku 2006, protože jsou v ní probírány věci, které podle mne musí vědět každý správce, v jehož síti se operační systém Vista objeví, a to pokud možno ještě před tím, než začne tento systém do sítě zavádět. (Tím vůbec nechci říci, že studiem této knihy dejme tomu v srpnu 2007 zbytečně ztrácíte čas. Windows XP jsou hodně kvalitní desktopový operační systém a já si proto myslím, že přechod na novou Vistu potrvá delší dobu. Doufám, že tuto knihu oceníte nezávisle na tom, kdy se začnete administraci systému Vista učit. Chtěl jsem jen míz jistotu, že se tato kniha dostane včas do rukou těch, kteří Vistu nasazují ihned po jejím uvedení na trh.) Ale ještě předtím, než se začne něco dít ve vlastním vydavatelství, musí být v zákulisí budoucí kniha řádně připravena, a to – samozřejmě – rovněž nějakou dobu trvá. Proto jsem se spojil se svým redaktorem Tomem Cirtinem a naléhavě ho žádal, aby se v její prospěch začal angažovat. Tom souhlasil a jak to tak vypadá, tato kniha se skutečně dostane na prodejní pulty ještě před začátkem roku 2007. Bez pomoci mnoha dalších lidí by k tomu ale jistě nedošlo. Za prvé chci poděkovat svým spoluautorům Byronu Hynesovi a Jennifer Allen, kteří přispěli po jedné kapitole, a to během velmi krátké doby. Jejich práci oceňuji především kvůli tomu, že své texty psali při běžné každodenní práci! Moji redaktoři Tom Cirtin, Rachel Gunn a Cheryl Hauser dokázali moje koncepty v rekordním čase převést do úhledného tvaru, techničtí redaktoři John Mueller a Russ Mullen mě dokázali včas upozornit, když jsem se někde odchýlil od tématu, aniž by to mělo nějaký vliv na jejich trvalou morální podporu. (Vistu se všichni pořád učíme. A mám takové podezření, že to budeme dělat ještě hodně dlouho, protože její kód je ve srovnání s XP téměř celý přepsán.) Craig Woods se postaral o závěrečnou grafickou podobu této knížky. Celý proces vzniku této knihy byl značně urychlen díky velkému množství informací, které mi poskytli lidé z Microsoftu. Na základě zkušeností z vývoje některých předchozích verzí Windows jsem očekával strohé odpovědi na mé otázky, ale během vývoje beta verzí Visty to vypadalo podstatně jinak, než dříve. Setkal jsem se nejen s mnohem otevřenějším přístupem, ale i s nefalšovaným zájmem o to, co vlastně lidé od systému Vista očekávají a potřebují. Cítil jsem se někdy dost divně, když se role tazatele a dotazovaného vyměnily – jako by se některý vývojář, zodpovědný za malou, ale důležitou součást Visty, ptal: „Dobrá, tak jak bychom podle vás měli tento problém řešit?“ Doufám, že tato otevřenost bude Microsoftu ku prospěchu a pomůže Vistě dosáhnout velkého úspěchu. Zapomenout nesmím ještě na jednu důležitou oporu, kterou jsem po celou dobu měl: mou asistentku Jean Snead. Bez ní bych díky nepřetržité nutnosti řešit a opravovat nejrůznější věci nemohl dělat nic jiného. A na závěr bych rád poděkoval vám, kteří si moje knihy kupujete; pokud byste to totiž nedělali, pochybuji, že by tato kniha spatřila světlo světa. Díky vám všem!

Obsah Poděkování

Jak se nenechat překvapit novinkami v zabezpečení visty Ukazuje se, že Vista bude víc než jen omalovánky. Kdo to mohl tušit? Seznamte se s dalšími autory Co je v této knize Můj bulletin vám pomůže udržet krok s dobou Jak se s námi spojit

Kapitola1: Správa zabezpečení windows vista – drobná překvapení Obnova účtu Administrator Vytváříme vlastní účet Administrator Aktivace účtu Administrator Skupina Power Users již v podstatě neexistuje Příkaz „Spustit“ již není v nabídce Start BOOT.INI zemřel, ať žije BCD! Shrnutí obsahu souboru BOOT.INI Terminologie BCD Vytvoření položky pro druhý operační systém Co jsou identifikátory správce spuštění Výběr doby zobrazení spouštěcí nabídky a výchozího operačního systému v nástroji bcdedit Změna doby zobrazení spouštěcí nabídky Změna výchozí položky Správce spuštění Změna možnosti položky Úklid: mazání položek operačního systému Složka „Documents and Settings“ je pryč (ale ne úplně) Vlastnosti sítě a protokol IPv6 Vzdálená plocha je nyní výrazně bezpečnější NTFS a systémový registr nyní podporují transakce Ve Windows máme nyní lepší obnovu smazaných souborů! Změny ve volbách zabezpečení Změny v přístupu k pojmenovaným rourám Změny ve sdílení a přístupu k systémovému registru LM odchází do ústraní, prosazován je protokol NTLMv2 Už žádná varování o nepodepsaných ovladačích Novinky v oblasti šifrování Vista obsahuje nové kryptografické služby Šifrovat se dá i odkládací soubor Složky offline souborů jsou šifrovány pro každého uživatele zvlášť Nový Prohlížeč událostí V Prohlížeči událostí se objevil i formát XML Vlastní dotazy dovolují přizpůsobit si Prohlížeč událostí na míru Generování akcí z událostí

15 16 19 19 22 22

23 23 24 24 26 29 30 30

32 33 34 35 35 35 36 38 38 39 43 45 46 47 48 49 50 52 53 53 54 54 55 55 57 60

Obsah Jak přikázat službě Protokol událostí zobrazovat hlášení Předávání událostí mezi počítači Přehled odběru událostí Nastavení zdrojových počítačů Nastavení sběrače Vytvoření ukázkového odběru První krok: Příprava služby WinRM na počítači Vista2 Druhý krok: vytvoření odběru na počítači Vista1 Řešení problémů s prodlevami u odběrů Úprava 15minutového intervalu Co je „prodleva při restartu“ (reboot delay) Předávání událostí v pracovních skupinách Krok první: nastavení služby WS-Management na počítači Vista2 Krok druhý: sběrač musí důvěřovat zdrojovému počítači Krok třetí: test vzájemné komunikace službe WS-Management Krok čtvrtý: nastavení odběru

63 65 65 66 66 66 66 68 72 73 73 74 75 75 77 78

Kapitola 2: Řízení uživatelských účtů aneb „jste si opravdu jist, pane správče?“

Úvod do UAC 81 Přes všechny nevýhody je UAC dobrým nástrojem. Proč? 83 Výhody UAC pro uživatele 83 Výhody UAC pro správce 84 UAC jako nástroj pro přechodové období 84 Stručný přehled UAC 85 Hlubší ponor do problematiky UAC 88 Jak Windows vytvoří token uživatele se standardním oprávněním 89 Strukturování tokenů ve Windows Vista 89 Jak zobrazit údaje ze svého tokenu 95 Souhrn: Přerod ze správce ve standardního uživatele 97 Jak říci UAC, aby použilo váš token plného přístupu správce 97 Příkaz Spustit jako umožní otevřít okno příkazového řádku s přiděleným tokenem správce 97 Snadnější otvírání oken se zvýšenými právy 99 Jak Windows poznají, kdy mají použít token plného přístupu správce 103 Vista hledá instalátory 104 UAC a GUI Visty 105 Vista vyžaduje povýšení práv, pokud o to žádá manifest 108 Pomocník s kompatibilitou programů a jeho vliv na UAC 120 Také úpravy Application Compatibility Toolkitu mohou mít vliv na UAC 123 Změna konfigurace služby Řízení uživatelských účtů 124 Jak se dá motor UAC zapnout nebo vypnout, případně přetočit 124 Nastavení „mladého“ UAC: UAC pro uživatele 125 Odbočka: Jak moc velký správce musíte být, aby se vás UAC týkalo? 126 Vyloučení vestavěného správce 127 Jak přikázat služba UAC vynechat heuristiku 128

11 Řízení zabezpečené plochy Co je zabezpečená plocha Vypnutí Zabezpečené plochy Povolení některých aplikací při aktivní Zabezpečené ploše Podepiš si kód nebo táhni: jak si vyžádat jen podepsané aplikace Co dělat s aplikacemi, které ukládají data na nesprávná místa Velký skok: Úplné vypnutí UAC Prosadí se UAC v praxi? Souhrn

128 128 129 130 131 134 134 135 136

Kapitola 3: Nápověda pro virtualizaci souborů a registru

137

Základy virtualizace souborů a registru Virtualizace souborů v akci Úvahy nad virtualizací souborů a registru Které oblasti jsou chráněny a kde jsou virtualizovány Jak virtualizace zachází se soubory Zápisy souborů pod dohledem virtualizace Čtení souborů pod dohledem virtualizace Jak virtualizace zachází s registrem Co přesně znamená pojem „starší“ (legacy) aplikace? Ukázka virtualizace souborů a registru u standardních uživatelů a správců Sledování virtualizace Možné potíže s virtualizací Řízení virtualizace Budoucnost virtualizace Souhrn

Kapitola 4: Kontrola integrity windows Přehled řízení integrity Windows Srovnání povinného a výběrového řízení Oranžová kniha Certifikace C2 a Windows NT C a B: Výběrový vs. povinný Přehled a terminologie výběrového přístupu Přehled a terminologie povinného přístupu Součásti WIC Šest úrovní integrity WIC Jak objekty získávají a ukládají své úrovní integrity: Mandatory Labels SACL: už nejen pro audity Mandatory Labels Řízení integrity Windows: Lost in SACE Prohlížení úrovní integrity objektu: seznamte se s chml a icacls Změna úrovní integrity objektu Úrovně integrity uživatelů Kde jsou ukládány úrovně integrity uživatelů Prohlížení úrovní integrity uživatelů Úrovně integrity procesů

137 138 140 141 141 141 142 142 144 145 147 149 149 150 151

153 154 155 156 157 158 158 160 161 161 163 164 164 165 169 174 174 175 175

Obsah Jak procesy získávají své úrovně integrity Prohlížení úrovní integrity procesů Sledování běžících procesů Příprava Příklad: Spuštění aplikace s nízkou úrovní integrity Chráněný režim Internet Exploreru a WIC Rébus základní direktivy: WIC a mazání souborů Testujeme oprávnění k mazání souborů v nástroji icacls Zákaz smazat soubor se liší od zákazu jiných činností Kdy a jak může blokování mazání souborů prostřednictvím WIC selhat Řešení: je nutné zajistit, aby služba WIC chránila objekty Jak použít ACE služby Řízení integrity Windows pro omezení přístupu Co ACE řízení integrity Windows nedokáže Mandatory labels se nedají aplikovat prostřednictvím zásad skupiny Nelze vytvořit standardní oprávnění, která jmenují mandatory labels Poznámka k modifi kacím systémových souborů Tvorba vlastních mandatory label Co jsou řetězce SDDL Tajemství jazyka kategorie B: syntaxe popisků SDDL Označovač (designat or) SACL Příznaky SACL Typ SACE Příznaky SACE Práva SACE Vykonavatel SACE: úroveň integrity Jak nastavit úroveň integrity prostřednictvím řetězců SDDL Souhrn

Kapitola 5: Bitlocker – řešení problémů se zabezpečením přenosných počítačů Zabezpečení notebooků v dnešní době Šifrování disků BitLocker – přehled Součásti BitLockeru Co je TPM? Šifrování celého pevného disku Algoritmus šifrování Ukládání klíčů Ověřování nebo řízení přístupu Zvýšení bezpečnosti pomocí dalších ochránců klíčů PIN Spouštěcí klíče Ověřování zaváděcího procesu (kontrola integrity) První zapnutí BitLockeru Používáme BitLocker bez TPM Souhrn ochránců klíčů

176 177 178 178 178 179 182 182 186 187 187 188 190 190 191 192 195 195 196 196 196 198 199 201 202 202 203

205 206 207 208 209 210 213 215 218 218 219 220 221 223 226 227

13 Kapitola 6: Ochrana po zavedení systému – integrita kódu, nová pravidla pro podepisování kódu a patchguard Náhodné rozložení adresního prostoru Nové pancíře pro 64bitové systémy PatchGuard PatchGuard nepovolí mou aplikaci: co mám dělat? Chcete vypnout PatchGuard? Integrita kódu Co se může pokazit? Řešení potíží se službami Windows Řešení potíží s ovladači Řešení potíží se součástmi Windows Nová pravidla pro podepisování kódu Co si představit pod pojmem „podepisování kódu“ a proč na něm tak záleží? Ovládací prvky ActiveX Požadavky služby Protected Media Path Požadavky platformy x64 Jak podepsat aplikaci nebo ovladač Používáme interní certifikační úřad Používáme komerční CA Nasazení aplikace nebo ovladače, podepsaného vydavatelem Souhrn

Kapitola 7: Jak vista chrání služby Stručné představení služeb Správce služeb Jak Vista „zpevňuje“ služby: přehled Oddělení relací Zmenšení rozsahu oprávnění pro služby Vývojáři mohou omezit oprávnění služeb Správci mohou také omezit privilegia služeb Speciální případ: více služeb vyžaduje různá oprávnění Souhrn výkladu o omezených privilegiích Izolace služeb Podstata činnosti izolace služeb Jak omezit SID služby Jak udělit oprávnění zápisu pro SID služby Příkazy nástroje sc.exe pro práci s omezenými SID Omezení síťových portů pro službu Souhrn

251 251 252 252 253 254 255 256 256 256 257 257 257 258 259 259 260 260 261 261 262

263 263 266 267 269 270 270 271 272 272 273 273 274 275 276 277 277

Úvod Jak se nenechat překvapit novinkami v zabezpečení visty V červnu 2006 jsem se zúčastnil přednášky o zabezpečení systému Windows Vista na konferenci TechEd (pořádá Microsoft) a tam jsem uslyšel pár věcí, ze kterých se mi skoro rozskočila hlava. (To ale není myšleno nijak hanlivě. Za chvíli to vysvětlím podrobněji.) Fakta, která jsem se tu dozvěděl, mne pobídla k napsání této knihy, protože se domnívám, že nové technologie značně zjednoduší práci administrátorů – což je výtečné – ale zároveň některé technologie považuji za tak zásadní inovaci, že by mohly některé profesionály odradit od nasazení Visty (nebo ho přinejmenším odložit), což by byla určitě škoda – podle mne je totiž zabezpečení Visty kvalitativně na mnohem vyšší úrovni než u jeho předchůdců. Věřím tomu, že když pochopíte nové koncepty zabezpečení systému Vista, přejdete na něj dříve a díky tomu budete mít také dříve lépe zabezpečenou síť. Při návrhu obsahu této knihy jsem se snažil o co nejkratší text, který však bude stále dobře čitelný, doplněný o ukázky skutečných postupů (tam, kde to je možné) a zaměřený na záležitosti, které jinak nejsou příliš veřejně probírány (i když by měly). Zkusím být trochu konkrétnější: ■

Za prvé, tato kniha je sice zaměřena na otázky související se zabezpečením, není však určena jen pro experty v této oblasti, ale na širší publikum tvořené správci sítí a IT profesionály obecně. Experti přes zabezpečení již vědí, co je SeChangeNotifyPrivilege a proč se o něj tolik lidí zajímá, ale většina správců podle mne se s něčím podobným setká, aniž by měli čas podrobněji zkoumat, o co jde. Obdobně si myslím, že mnozí správci již zaslechli pojmy DACE a SACE, ale nerozumí jim dostatečně dobře na to, aby pochopili skutečný významů některých nástrojů, například nového mechanismu pro zajištění integrity. V takových případech tu najdete stručný výklad potřebných principů a zhodnocení jejich aplikace z hlediska zabezpečení na předchozích verzích Windows. Experti přes zabezpečení mohou samozřejmě tyto sekce knihy prostě přeskočit (jsou psány dost stručně).

■

Za druhé, kniha podrobněji vysvětluje osm novinek, které představují významné strukturální změny ve Windows, značně ztěžující snahu různých darebáků napadajících naše soukromí nebo peněženky. Tyto novinky nejsou tak populární jako nový Průzkumník nebo nový formát Windows pro obrázky.

■

Za třetí, uvedená témata jsou v knize probírána čitelným a prakticky zaměřeným způsobem; nejdříve projdeme základní pojmy a všude tam, kde je to možné, doplníme teoretický výklad o praktické příklady – věci, které si sami na svých systémech můžete okamžitě vyzkoušet. Prakticky jsem si ověřil, že příliš teoretický výklad těchto integrálních bezpečnostních

Úvod – Jak se nenechat překvapit novinkami v zabezpečení visty

technologií je k ničemu, protože co nevidím na vlastní oči, tomu těžko porozumím. V této knize budou nové technologie zabezpečení předváděny postupně a v případech, kdy by působily negativně, vám ukážu, jak je vypnout nebo částečně zakázat. Sice toto vypínání nedoporučuji, ale když už to musíte udělat, tak prostě musíte – a já chci, abyste to dokázali co nejrychleji! ■ A konečně za čtvrté, snažili jsme se celou knihu zbytečně neprodlužovat, abychom ji mohli co nejrychleji vydat a dostat do knihkupectví již v době, kdy Microsoft začne systém Vista prodávat, případně s trochou štěstí ještě dříve. Nejde přece ani tak o každou jednotlivou technologii zabezpečení ve Vistě – to by kniha musela být mnohem silnější! – ale jen o úzce zaměřený popis všech zásadních změn v přístupu, ze kterých mnohé bude chvíli bolet hlava. Kvůli krátkému času na přípravu jsem nemohl popsat všechny faktory a komponenty nových technologií, proto jsem angažoval pár dalších lidí, kteří perfektně ovládají jak obecné zabezpečení, tak nový systém Vista. Ve zbylé části úvodu vysvětlím podrobněji, proč se domnívám, že tyto novinky v zabezpečení jsou tak důležité, co všechno bude v knize probráno a představím své spolupracovníky.

Ukazuje se, že Vista bude víc než jen omalovánky. Kdo to mohl tušit? Co jsem měl na mysli, když jsem napsal, že se mi „skoro rozskočila hlava“? Začalo to asi takto…. S různými beta verzemi systému Vista jsem si „hrál“ už od prvního zveřejněného „technology preview“, které Microsoft uvolnil v roce 2003, a abych byl upřímný, neudělaly na mne skoro žádný dojem. Zdálo se mi, že Vista nabízí z větší části jen parádní novinky pro programátory. Nová pracovní plocha „Aero Glass“ působila dojmem pestrobarevných omalovánek, ale co se týče GUI, jsem zvyklý všechny vizuální efekty vypínat – drahocenné cykly procesoru, které by si vyžádaly různé animované nabídky, raději používám pro jiné úkoly – takže náhodný příchozí by se při letmém pohledu na jeden z mých počítačů s Vistou domníval, že se jedná o Windows Server 2003. Ano, šířily se zvěsti o super novinkách ve Windows… jenže tou verzí Windows, ve které se měly objevit, nebyly Windows Vista, ale Windows Server 2007 (neboli „operační systém dříve označovaný jako Longhorn“). V první polovině roku 2006 se však všechno změnilo. Nové beta verze Visty se začaly pyšnit nejrůznějšími vlastnostmi a já byl velmi překvapen, protože velká část z nich byla tím, co se původně mělo objevit až ve Windows Serveru 2007. Jakmile jsem toto zjistil, začal jsem v novém systému trávit mnohem více času, ať již šlo o beta verze nebo „customer technology preview“. Ale i poté jsem přišel do kontaktu jen s těmi věcmi, které návrháři OS zpřístupnili v rámci GUI a vestavěných aplikací; změny hluboko uvnitř OS se takto objevit nedaly. Proto jsem byl na červnové přednášce tak překvapen. Již předtím jsem absolvoval několik sezení, kde se hovořilo o nových bezpečnostních technologiích systému Vista. Něco z toho, co jsem na nich slyšel, znělo dost znepokojivě. Nová ochrana přenosných počítačů s názvem „BitLocker“ měla chránit notebook tak dobře, že při troše nepozornosti

Ukazuje se, že Vista bude víc než jen omalovánky. Kdo to mohl tušit?

by při ztrátě hesla mohlo dojít ke ztrátě dat. Po instalaci se zdálo, že Vista již nemá vestavěný účet Administrator, pouze účet jakéhosi „správce začátečníka“, který nebyl schopen provést mnohé ze základních prací, které této profesi náleží. Desítky různých bezpečnostních vylepšení v souborovém systému a systémovém registru mohou zneschopnit spoustu aplikací psaných pro Windows XP. Pokaždé, když chcete provést něco více či méně souvisejícího se správou systému, Vista zobrazí otravné okno s dotazem typu „a jste si jisti, že chcete opravdu toto?“. Zdálo se tedy, že všechny změny v zabezpečení uvalí na správce spoustu nových, spíše nádenických úkolů, a nemohu říci, že bych se po seznámení s nimi nějak moc těšil na příchod Visty. Poté to řečník ještě vylepšil tím, že začal mluvit o „povinné kontrole integrity“ neboli MIC (mandatory integrity control) – později přejmenované na „Windows integrity control“ a myslím, že tento název bude před uvedením na trh ještě změněn – neboli nové vrstvě v zabezpečení Visty, o které jsem již slyšel, ale příliš o ni neuvažoval. Nesoustředil jsem se v těchto okamžicích úplně, dokud jsem neuslyšel řečníka říci toto: „a průvodním jevem bude také to, že se v systému Vista mohou vyskytnout soubory, které nikdo – ani administrátor – nedokáže smazat“. Až tehdy jsem si uvědomil, proč se mi zdál MIC tak známý: vychází totiž z metod zabezpečení souborů, které se v operačních systémech vyskytují již celá desetiletí… ale jen u armádních počítačů. Právě z této věci se mi málem rozskočila hlava. Ptal jsem se sám sebe – proč, proboha, bych měl stát právě o takový operační systém? Pane Bože, přece neprovozuji raketovou základnu ani na svém počítači neukládám žádné státní tajemství! Poté, co jsem trosky lebky jakž-takž sklížil zpět do použitelného tvaru, jsem si však připomenul pár věcí. Třeba to, že během několika posledních let jsem téměř na každém počítači, o jehož údržbu jsem byl požádán svými přáteli nebo členy rodiny, našel (a úspěšně odstranil) nejrůznější spyware, nástroje pro logování a monitorování stisků kláves a dokonce i jeden rootkit. A pokud jste také správcem systému, vsadil bych sto ku jedné na to, že vás tento fakt ani nepřekvapil, ani neudivil. Tipnul bych si, že jste při čtení této věty jen souhlasně pokýval hlavou; snad každý zkušenější uživatel XP zažil něco podobného. Přesto však nelze mé přátelé ani členy rodiny považovat za idioty; s počítači umí pracovat velmi dobře, ale ne na úrovni expertů. Každému z nich se jen povedlo narazit na něco potencionálně nebezpečného, protože v dnešní době se tyto potvory umí šířit mnoha dříve neznámými způsoby. Vzpomněl jsem si také na všechna falešná upozornění o špatném zabezpečení mých účtů, které jsem dostával i od finančních ústavů, u kterých nemám uloženu ani korunu, „phishingové“ útoky využívající sociální inženýring k obelstění lidí s cílem získat od nich jejich uživatelská jména, hesla a čísla účtů. Nikdy jsem nenechal nechytat, ale nepovažuji to za žádný doklad své geniality – spíš je to tím, že nepoužívám služby typu PayPal, které jsou asi největším cílem phishingových útoků. Kromě toho mám coby autor knih oproti „normálním“ uživatelům jednu tajnou zbraň: mnohem vyšší pravděpodobnost, že si při čtení všimnu pravopisných a gramatických chyb, které se vyskytují v 99 procentech phishingových zpráv. Na moje soukromí dále nepřetržitě útočí různé webové stránky, které po mně chtějí, abych klepnul na nějakou nahotinku nebo „báječnou nabídku“ zboží zdarma, přičemž jejich cílem je jediné: nasadit mi do počítače brouka, který bude sledovat každý můj pohyb na Internetu a tyto informace pak prodají lidem, kteří mně budou obtěžovat tunou spamu denně. (Proč si myslíte, že Google tak štědře rozdává e-mailové účty?)

Úvod – Jak se nenechat překvapit novinkami v zabezpečení visty

A potom mi to došlo: je sice pravda, že ze svého počítače nikdy nebudu odpalovat mezikontinentální střely a nebudou na něm uložena žádná státní tajemství… ale mám tam své osobní tajné údaje, například hesla, osobní dokumenty a účty – pokud by se k nim dostaly nepovolané osoby, dostal bych se asi do pěkné finanční patálie. Svět malwaru – virů, červů, botů, trojských koní, rootkitů, phishingu… prostě čehokoliv – se během posledních pár let drasticky změnil a ne každému to došlo. Ano, otrapové už píšou malware spoustu let, ale motivace této „autorské tvorby“ se změnila. Ještě nedávno byly viry a podobná havěť psány patetickými jedinci, kteří se většinou chtěli vychloubat tím, kolik systémů se jim podařilo nainfikovat. Dnes podobní potměšilci vymizeli a cílem autorů nového malwaru je něco zcela jiného: vaše bankovní účty. „Tam venku“ žijí skutečně zlí lidé, jsou jich tisíce, chtějí vám opravdu ublížit – a co je nejhorší, někteří z nich žijí ve vašem těsném sousedství. (V době Internetu je sousedem skoro každý…) Válčíme tak s mnohem houževnatějším nepřítelem než před několika lety, kdy byly největším škůdcem viry, a jsme pod neustálým tlakem… proto se aplikace několika nápadů, pocházejících z dob studené války, uvnitř operačního systému jeví – bohužel – jako vcelku dobrý nápad. Zkuste se na to podívat takto. Koncem 90. let 20. století byli naši nepřátelé jen otravnými dětmi, které bavilo vkrádat se do cizích domů v době, kdy jejich majitelé byli pryč. Ve většině případů přitom stačilo opatřit dveře zámky, nezapomenout při odchodu z domu otočit v zámku klíčem a případně nainstalovat jednoduchý alarm. V dnešní době však proti nám stojí armáda inteligentních a silně motivovaných zlodějů s automatickými páčidly a dokonalými vysavači, po jejichž „úklidu“ zůstane účet prázdný jako poslanecká sněmovna v pátek po obědě – a stihnou to udělat během několik sekund. Tyto nové typy útoků vyžadují mnohem silnější obranná zařízení, například neprůstřelné zdi, ochranku, ploty a povolení vstupu do objektu jen pro majitele smart card s potřebným oprávněním. To znamená učit se nové věci a hodně pracovat … je to ale nutné, protože jinak nás nečeká nic jiného než prohra. Vista nabízí mnohé z těchto uvedených zbraní, a jejich uživatelé je musí umět používat a rozumět jim. Existuje ještě jedno (konkrétnější) vysvětlení toho, proč jsem cítil, že tuto knihu je třeba napsat, a to co nejrychleji. Vista mění spoustu věcí – což je přirozené, protože Vista představuje první zcela nově napsaný OS Microsoftu od doby, kdy jeho vedení osvítil fakt, že zabezpečení je důležitější než reklama. (Ano, já vím, že Windows Server 2003 byl puštěn na trh až poté, co se Billu Gatesovi zjevili začátkem roku 2002 tři králové Firewall, Antivir a Antispam, ale verzi 2003 prostě nemohu počítat, ta byla vyvíjena už předtím. Domnívám se, že se Microsoft měl stále ještě co učit i poté, co se v dubnu 2003 objevila uvedená verze Serveru.) Lidé v Microsoftu pochopili velkou důležitost zabezpečení systému, ale nebyli ještě připraveni obětovat většinu zpětně kompatibilních záležitostí. Tipnul bych si, že až červ Blaster, šířící se od srpna 2003, byl tím posledním hřebíčkem, který zatloukl nové firemní heslo nad bránu v Redmondu, but only so long as we can still run 1992 programs" way of thinking. POZNÁMKA:

Chápejte prosím správně, co říkám. Pochopitelně se mi nelíbí obětování zpětné kompatibility se starším softwarem, a uvědomuji si, že pro významný počet uživatelů Windows bude velkým problémem fakt, že na Vistě nebude možné některé starší aplikace spustit. Zkuste se ale zamyslet. Za prvé, i když – dejme tomu – jeden z pěti uživatelů nebude moci spustit určitou podmnožinu svých programů, je to pořád lepší než vystavit všech pět uživatelů útokům stále destruktivnějšího malwaru. Za druhé, Vista obsahuje nástroje pro zajištění zpětné kompatibility bez snížení úrovně

Co je v této knize

zabezpečení, proto by mělo stačit pohrát si trochu s nastavením systému a starší aplikace by měly normálně běžet. Jeden z těchto nástrojů – virtualizaci souborů a systémového registru – blíže prozkoumáme ve třetí kapitole.

Aféra s červem Blaster uvedla Microsoft do velkých rozpaků, a podle toho, co jsem slyšel, byla klíčovou událostí vedoucí k opuštění původní koncepce Visty a novému začátku „od čistého stolu“. Nemám přístup ke zdrojovému kódu Windows XP ani Visty, ale dozvěděl jsem se, že převážná část (skutečně velmi vysoké procento) programů Visty je úplně přepsána a věřím tomu na základě toho, že velké množství věcí probíhá ve Vistě opravdu zcela jinak. V každém případě bych mohl na základě velkého množství novinek ve Vistě, orientovaných celkově na problematiku zabezpečení prostě jen vyjmenovat desítky nebo možná i stovky nových pojmů a říci: „tady došlo ke změně, měli byste si to prostudovat“… všechna nová témata budou probírána v dalších našich knihách se širším záběrem (Mastering Windows Vista Professional a Mastering Windows Server 2003; druhá vyjde až v roce 2007). Existuje však několik věcí, které musí znát každý správce Windows a které přitom nejsou dostatečně popsány, nebo je o nich publikováno jen málo přesných informací.

Seznamte se s dalšími autory Tuto knihu bych nedokázal napsat tak rychle, kdyby mi nepomohli dvě pilné včeličky Byron Hynes a Jennifer Allen. S Byronem Hynesem mne seznámil přímo na TechEdu náš společný přítel Steve Riley z Microsoftu. Byron strávil mnoho let lektorováním různých technických seminářů a psaním dokumentace. Před rokem nastoupil do Microsoftu a věnuje se tam přípravě části dokumentace k Serveru 2007, týkající se zabezpečení. Možná je to také jediný člověk na celé planetě, který dokonale rozumí novému šifrovacímu systému BitLocker, který je součástí Visty – proto jsem byl velmi potěšen, když mi slíbil napsat kapitolu o BitLockeru. Nemusíte se bát, že napsal jen běžné marketinkové pindy – Byron se s ničím nemaže a jde přímo k jádru věci, ať už se jedná o přednosti či slabosti Windows. Jennifer Allen pracuje jako operátorka a redaktorka ve skupině Microsoft Security Technology, kde spravuje a vytváří dokumentaci pro bezpečnostní technologie. Jennifer bydlí Seattlu (stát Washington). Velmi si cením práce obou autorů a doufám, že si jejich příspěvky náležitě vychutnáte.

Co je v této knize V této části uvádím stručný přehled toho, co se v této knize naučíte. Jak jsem již řekl, v této knize budeme probírat některá revoluční paradigmata, ale rád bych, abyste začali v klidu první kapitolou. V ní vám vysvětlím, jak se vypořádat s několika otravnými problémy (například jak obnovit účet Administrator, který je ve Vistě implicitně zakázán) a poté si probereme asi deset-patnáct menších změn v implicitním nastavení zabezpečení. To jsou věci, kterých si v praxi vůbec nemusíte všimnout… dokud o jednu z nich nezakopnete. (Víte například to, že ve Vistě už není skupina uživatelů Power Users?) Naštěstí vás čekají i příjemná překvapení, jak vám ukážu při prohlídce supernovy v souhvězdí Vista s názvem Prohlížeč událostí (Event

Úvod – Jak se nenechat překvapit novinkami v zabezpečení visty

Viewer). Při popisu změn zabezpečení budeme také zkoumat útroby Vzdálené správy Windows, nového typu infrastruktury Windows, na kterou asi všichni budeme muset zvyknout a pohotově s ní pracovat. V druhé kapitole se pustíme do vlastního zabezpečení Visty a probereme první z osmi zásadních novinek, které jsem uvedl v předchozím textu. Na rozdíl od jiných zde diskutovaných bezpečnostních technologií Visty půjde o tu, o které jste pravděpodobně již slyšeli, nebo se s ní i setkali: Řízení uživatelských účtů neboli User Account Control (UAC), označované také jako „součást Visty, kterou každý ochotně nenávidí“. Jedná se o významný posun v názorech Microsoftu, co se funkčnosti Windows týká: je třeba opustit starý přístup práce v systému pod účtem patřícím do skupiny administrátorů a přejít na účty s nižším rozsahem oprávnění. UAC je z dlouhodobého hlediska jednoznačně pozitivní záležitost, ale u veteránů mezi správci může vyvolat menší či větší frustrace, pokud nedokážou pochopit, jak tahle věc funguje. Takový zkušený harcovník si může upravit dvojici zásad skupiny a UAC úplně vypnout – ukážeme si, jak na to – nebo nechat věci tak jak jsou, a využívat je (za předpokladu, že přesně chápe, jak UAC funguje). V této kapitole nám nebude stačit samotné uživatelské rozhraní: ponoříme se trochu hlouběji a vysvětlíme si nové „split tokeny“ a jejich význam pro administrátory i uživatele… a také to, že UAC v zapnutém stavu může být tou nejlepší ochranou proti rootkitům, červům, trojským koním a virům. Ve třetí kapitole vysvětlím druhý prvek Velké Osmičky – virtualizaci souborového systému a registru. Tato vestavěná součást Visty obdobně jako UAC pomáhá opustit dnešní nevyhovující zvyk pracovat pod účtem administrátora (což dělá asi 99 % správců) a nechat se teleportovat do bezpečnějších zítřků, kde budeme po většinu pracovní doby přihlášeni jako běžní uživatelé. Tento krok je nutný kvůli tomu, že velká část malwaru nedokáže infikovat naše systémy, pokud budeme přihlášeni jako běžní uživatelé a ne administrátoři. Znalci ovšem upozorňují na jednu z největších překážek přesunu do světa běžných uživatelů – uživatelé samotní jsou v pohodě, zato ty stupidní aplikace nehodlají pod účtem obyčejného uživatele běžet, protože jsou zvyklé zapisovat si různá interní data do míst na disku nebo v systémovém registru, kam běžný uživatel nic zapisovat nesmí. Co dělat v takovém případě, najít vývojáře programu a fackovat ho, dokud nepřepíše příslušné části kódu? Tato námitka je správná, či spíše byla… dokud se neobjevila Vista. Tento systém umí všelijaké kejkle – a zde dovolí uživatelům s oprávněním obyčejného uživatele spustit automaticky programy, které by v předchozím systému pracovaly špatně nebo vůbec ne. Říká se tomu sice „virtualizace“, ale nemá to nic společného s VMWare ani Virtual Serverem, pouze usandňuje spouštění aplikací na nižší úrovni oprávnění. Díky virtualizaci se dají provozovat aplikace zapisující v systémovém registru do klíčů HKEY_LOCAL_MACHINE nebo do složky System32, a to i v případě, kdy nejste přihlášen jako administrátor. Jak ale poznáte, všechno má svá „ale“. Třetí kapitola vysvětluje způsob činnosti virtualizace, místa, kde nefunguje a situace, kdy může a kdy nemůže uživateli pomoci. Čtvrtá kapitola představí technologii, která na mne rovněž udělal velký dojem: řízení integrity Windows, dříve označované pojmem Mandatory Integrity Control (MIC). Ve svém úsilí zastavit nápor malwaru už Microsoftu – věřte nevěřte – nestačí původní model „výběrových oprávnění“ pro přístup k NTFS a systémovému registru, který známe od jeho uvolnění v roce 1993, a vytvořil proto model další, který se doposud neobjevil v žádném operačním systému na této planetě, s výjimkou pár systémů používaných pro speciální účely, například v armádě nebo pro aplikace tajných

Co je v této knize

služeb. Této nové bezpečnostní vrstvě se říká „řízení integrity Windows“ a mohu s klidem říci, že dlouholetí správci Windows nikdy nic podobného neviděli. Ve čtvrté kapitole vám vysvětlím teoretické pozadí této kontroly a poté si uvnitř systému ukážeme, co tato kontrola vlastně dělá… a jak ji můžete využít pro vlastní úpravy integrity systému. Kapitola má jednu nevýhodu: musím čtenáře varovat, že tuto kapitolu nemohou číst lidé, kteří neprojdou důkladnou bezpečnostní prověrkou. POZNÁMKA:

Jistě, poslední věta byla jen žert. Dodávám jen, že během psaní tohoto odstavce v říjnu 2006 nebyl název pro tuto novou součást zabezpečení ještě znám, ale pokud vím, bude se jmenovat jinak.

V páté kapitole se k nám připojí Byron a popíše čtvrtou položku mého seznamu zásadních novinek zabezpečení, skutečný skvost zabezpečení, jehož původ se dá stopovat až do roku z roku 2002, a který nakonec skutečně spatřil světlo světa: BitLocker, kompletní šifrování celých diskových jednotek. Každý rok přijdou americké firmy přibližně o 600 tisíc přenosných počítačů, které jsou někdy ukradeny, častěji však zapomenuty v taxících nebo na letištích. Na vlastním způsobu ztráty moc nezáleží – podstatné je to, že se na nich někdy nacházejí data, jejich prozrazení může znamenat konec firmy. Možná si vzpomínáte na nedávný případ státního zástupce, který zapomněl v autě v centru Brna spis k případu Radovana Krejčíře… v USA je zase dobře znám případ zaměstnance úřadu péče o armádní veterány, který si vzal domů notebook obsahující osobní data takového rozsahu, že jeho ukradení stačilo ke zcizení totožnosti libovolného veterána… a počítač byl přímo u něj doma skutečně ukraden. Co se s tím dělat? (Kromě zastřelení toho pitomce, který za to může…) Zašifrovat celý pevný disk a klíč uchovat tam, kde ho nikdo nenajde. Ve Vistě se tento nový nástroj jmenuje BitLocker. Když Microsoft poprvé veřejně oznámil jeho přípravu, zdál se BitLocker sice zajímavou, ale silně nepraktickou technologií, protože by každý systém, na kterém by byl nasazen, vyžadoval osazení kryptografického čipu TPM (Trusted Platform Module) na základní desce. BitLocker ve Vistě však povoluje zašifrovat systém také v případě, kdy je na desce přítomen slot USB. Pokud máte vlastní laptop nebo na starosti všechny přenosné počítače ve firmě, může to být jediný, ale zcela dostačující důvod přechodu na OS Vista! V šesté kapitole se k nám připojí Jennifer Allen a vysvětlí vám tři další důležité bezpečnostní technologie Visty: integritu kódu, nová pravidla pro podepisování ovladačů a PatchGuard. Tady poznáte, že Vistu bychom mohli s klidem považovat za první verzi Windows s logem „Paranoia Inside“ (firma Intel laskavě promine narážku na jejich velmi dobře známé logo). Zásadní změnou proti všem předchozím verzím Windows je to, že Vista náhodně mění umístění základních služeb systému, což značně komplikuje práci autorům červů. Další sada anti-malwarových nástrojů zahrnuje integritu kódu, kontrolu digitálních podpisů souborů během zavádění systému a novou sadu pravidel pro 64bitové Windows. Podle těchto pravidel musí být všechny ovladače digitálně podepsány. Šestá kapitola podrobně popíše obě tyto ochrany. Tím ale výčet novinek pro 64bitové systémy nekončí: 64bitové jádro obsahuje nástroj PatchGuard, který inteligentně detekuje a likviduje malware. V sedmé kapitole rozebírám starého bezpečnostního bubáka, služby Windows. Přestože jsou tyto služby v literatuře věnované zabezpečení hodně pomlouvány, jedná se o užitečné procesy, zajišťující spoustu činností a také bezchybný běh samotných Windows. Protože však běží nepřetržitě, jsou velmi snadným cílem útočníků, pokud obsahují chyby. Microsoft během let usiloval

Úvod – Jak se nenechat překvapit novinkami v zabezpečení visty

o vylepšení obrany proti těmto útokům a prováděl sice jednoduché, přesto však cenné úpravy jejich kódu. Vista celý vývoj výrazně posunula směrem vpřed a zcela změnila pravidla pro vytváření služeb. V sedmé kapitole najdete popis změn služeb ve Vistě a vliv těchto změn na správu systému. Zde naše rychlé seznámení s novinkami v zabezpečení Visty končí. Věřím, že po dočtení této knihy budete souhlasit s tím, že přinejmenším z hlediska zabezpečení se Vista liší od přechozích verzí Windows asi tak, jako se Rolls-Royce liší od kolečkových bruslí.

Můj bulletin vám pomůže udržet krok s dobou Změny v oblasti správy a zabezpečení Windows probíhají tak rychle, že jejich sledování člověka plně zaměstná na celý úvazek. Pokusili jsme se tuto knihu napsat tak, aby v ní byly co možná nejaktuálnější informace, ale uvědomte si prosím, že jsme ji psali ještě podle beta verzí Visty, a může proto ještě dojít k některým změnám. (Sakra, při psaní této věty si uvědomuji, že nikdo vlastně přesně neví termín uvedení nového OS na trh. Zde probírané technologie se však určitě objeví ve Vistě i Serveru 2007 nezávisle na tom, zda začnou být prodávány dříve či později, proto čím dříve se s nimi seznámíte, tím lépe. ) Nevím ještě, zda budeme tuto knihu upravovat pro druhé vydání, ale ať ano či ne, proč čekat s nejnovějšími informacemi na druhé vydání? Z tohoto důvodu mám pro své čtenáře následující nabídku. Navštivte můj web na adrese http://www.minasi.com a přihlaste se tam k odběru mého bezplatného bulletinu Windows Networking. Věnuji se v něm nejrůznější tématice sítí, počínaje NT 4 přes 2000 až k XP, Serveru 2003, Vistě a dokonce i trochu Linuxu. Každý měsíc, kdy mám čas něco napsat, posílám přihlášeným odběratelům stručnou aktualizaci tipů a triků, které jsem se nově naučil, a také každou opravu závažnějších chyb, nalezených v této knize (těch bude doufám co nejméně). Nejedná se o žádný spam – plně souhlasím s heslem „Smrt spammerům!“ – ale jen o krátké pohotové komentáře o všem, co se týká systémů NT, 2000, XP, 2003 nebo Vista a co se mi zdálo zajímavé. Tento bulletin rozesílám už od roku 1999 a na svém webu k němu nabízím prohledávání archivu starších vydání. V posledních vydáních jsou také dlouhé články o provozu a zabezpečení volně dostupných databázových serverů Microsoftu (MSDE a SQL Server Express), řešení potíží s DNS, konfiguraci služby Indexing Service a články o protokolu IPSec, proto si myslím, že se z tu cenu (zdarma) rozhodně vyplatí.

Jak se s námi spojit Pokud máte libovolnou otázku, připomínku, nebo se domníváte, že jste našli v knize nějakou chybu, ozvěte se nám! E-maily můžete zasílat na adresu help@minasi.com, ale ještě než napíšete, pročtěte si prosím FAQ na adrese http://www.minasi.com/gethelp. Sepsal jsem tuto knihu ne proto, že bych toužil nějak nutit její čtenáře k souhlasu s naším hodnocením nových bezpečnostních paradigmat, i když si myslím, že by mnozí lidé souhlasili tak jako tak; jde o to, že z hlediska zabezpečení jsou útroby Windows plné závažných a rozsáhlých změn a já bych rád přispěl ke zkrácení doby, potřebné pro jejich nasazení – není přece nutné, aby i vaše hlavy explodovaly po zjištění, co všechno se ve Vistě mění. Díky za to, že jste si tuto knihu zakoupili a doufáme, že si ji řádně užijete!

1 Správa zabezpečení windows vista – drobná překvapení Většina této knihy popisuje principy a způsob činnosti nových bezpečnostních technologií Visty, jejich vliv na správce a uživatele a místa, ve kterých je můžete konfigurovat. V této kapitole se však s uvedenými nástroje ještě nesetkáme; zde najdete „jen“ přehled významných změn ve Vistě, které nejsou patrné na první pohled … dokud nenarazíte na něco podivného, neočekávaného nebo matoucího – prostě na nějakou „Vystery“ (slovní hříčka odvozená od slova „mystery“ čili tajemství). Možná si nyní říkáte: „pokud má následovat směsice nějakých rádoby šokózních drobností ohledně správy a zabezpečení Visty, proč to proboha nedají na konec knihy?“ Pomýšlel jsem na to, ale poté jsem pochopil, že pokud si chcete nainstalovat Vistu a postupně zkoušet jednotlivé věci, které jsou probírány v dalších kapitolách, možná by vás více rozčilovalo drobné trní, chytající se na kotníky a zdržující v chůzi, než náročné pokusy o výstup na mrakodrapy interních záležitostí UAC – proto je lepší tyto drobnosti umístit na začátek. Rád bych však zdůraznil, že věci zde probírané nejsou vždy změnou k horšímu. V této kapitole se pokouším jen o stručné poznámky k tomu, co se podle mne nejvíce změnilo z hlediska práce administrátora systému – především pak z hlediska zabezpečení. Zdůrazňuji přitom hlavně ty změny, které byly jen málo publikovány (nebo vůbec ne). Díky tomu se budete moci po přečtení této kapitoly sami rozhodnout, čemu budete věnovat nejvíce času. (Kromě toho doufám, že vám tyto záležitosti předvedu dříve, než je některý klient zmíní během schůzky . Také máte tak „rádi“ tyto situace?) Uváděné věci nejsou nijak řazeny; jedná se skutečně o náhodnou směsici. Jak jsem již uvedl v úvodu, pokouším se psát maximálně stručně a navíc mám k dispozici jen beta verze Visty. Předpokládám proto, že jste již sami dokázali Vistu nainstalovat a zprovoznit na nejméně jednom či dvou testovacích strojích. Můžeme se tedy rovnou pustit do díla.

Obnova účtu Administrator Poprvé se přihlašujete do systému Vista a chcete se přihlásit na účet Administrator, stejně jako jste to dělali předtím (na XP nebo 2000). Ale ouvej, je tu problém. Účet Administrator podle systému neexistuje. Grrr.

Kapitola 1 – Správa zabezpečení windows vista – drobná překvapení

Ve skutečnosti je však účet Administrator v systému přítomen a je možné se na něj přihlásit do systému. Implicitně je však zakázán. Podívejme se tedy, jak ho zase povolit. Nejdříve se přihlaste k systému jako lokální administrátor. Pokud je počítač připojen k doméně, znamená to, že se budete nejspíše muset přihlásit na účet doménového správce, nebo – nejste-li sám správcem sítě – požádejte doménového administrátora, ať váš účet zařadí do lokální skupiny Administrators na vašem počítači. Jestliže je váš počítač členem domény a vy nemůžete provést ani jednu z obou uvedených věcí, jste „vyřízení“ a musíte si Vistu znovu přeinstalovat tak, aby byla členem jen pracovní skupiny, nikoli domény.

Vytváříme vlastní účet Administrator Jestliže však váš počítač není členem žádné domény, Vista vás při prvním spuštění vyzve k vytvoření účtu uživatele. Tento účet poté Vista automaticky zařadí do skupiny Administrators, tedy stejně jako to dělají XP. Nejste sice nuceni přiřadit tomuto účtu i heslo, ale rozhodně není vhodné toto heslo nechávat prázdné, protože Vista – obdobně jako XP a 2003 – považuje účty s prázdnými hesly za podřadné a nedovoluje používat je přes síť. Vzhledem k tomu, že tento první účet je účtem lokálního administrátora, nemusíte ve skutečnosti oživovat účet Administrator.

Aktivace účtu Administrator Je tedy opravdu potřebné aktivovat účet Administrator? Pravděpodobně ne. Na způsob aktivace účtu Administrator jsem přišel už u prvních předběžných verzí Visty, ale brzy jsem pochopil, že pod účtem, který vytvořím při prvním spuštění Visty, mohu dělat to samé, co pod účtem Administrator. Při testování beta verzí Visty s číslem sestavení 5472, 5536 a u verze RC1 I jsem se už vůbec neobtěžoval účet Administrator aktivovat. Slyšel jsem o lidech, kteří potřebují účet Administrator kvůli kompatibilitě některých aplikací; existují totiž vývojáři, kteří píší aplikace tak, aby běhaly jen pod účtem Administrator (což rozhodně není dobrý nápad, ale jak říkám, údajně to někteří lidé potřebují). V každém případě uvádím podrobný návod pro ty, kteří tento účet potřebují. Co platí především: účet Administrator vyžaduje zadat nové heslo, protože ve výchozím stavu je jeho heslo prázdné a jak všichni víme, systémový účet Administrator s prázdným heslem, patřící do skupiny Administrators, je nesmírně nešťastný nápad. Dále platí, že pokud je váš systém členem domény, ve které platí zásada minimálních požadavků na hesla, není možné aktivovat účet Administrator s prázdným heslem. (Chybové hlášení, které Windows v tomto případě zobrazí, není příliš šťastné: pokud se o aktivaci účtu Administrator s prázdným heslem pokusíte, dozvíte se, že „heslo nesplňuje minimální požadavky na jeho délku a obsah“. Ale vy jste přece žádné heslo nezadávali, že?) Přidělíme proto účtu Administrator silné heslo a zároveň ho aktivujeme.

Obnova účtu Administrátor

POZNÁMKA:

Všimněte si, že v tomto návodu pracuji s „klasickou nabídkou Start“. Dále uvidíte, že mám nastaveno také klasické téma Windows, takže moje pracovní plocha ve Vistě vypadá jako Windows 2000. Mám to takto nastaveno především kvůli větší rychlosti a rychlejším odezvám systému.

1. Přihlaste se k systému Vista na libovolný účet lokálního administrátora, který jste si opatřili. 2. Spusťte příkazový řádek: klepněte na tlačítko Start (není na něm sice již napsáno „Start“, ale je umístěno na stejném místě jako staré tlačítko Start v levém dolním rohu obrazovky a v jeho kulaté ploše je vlajka Windows). Poté klepněte na Všechny programy a dále na Příslušenství. 3. A teď pozor! Chápu, že budete mít tendenci klepnout přímo na položku Příkazový řádek, protože přece „vím, co dělám“. Nedělejte to. Klepněte na tuto položku pravým tlačítkem myši a z místní nabídky vyberte příkaz „Spustit jako správce“. Poté vaše plocha ztmavne a objeví se dialogové okno s varováním, že hodláte provádět něco jako správce a dotaz, zda to skutečně chcete udělat … v tomto dialogu se dá klepnout na tlačítko Pokračovat nebo Storno. 4. Říká se tomu „souhlasné uživatelské rozhraní“, protože program otvírající toto dialogové okno se jmenuje consent.exe (consent = dát souhlas). Jedná se o součást UAC (Řízení uživatelských účtů), které budeme probírat ve druhé kapitole. Toto dialogové okno spatříte pokaždé, když se snažíte něco, co i jen velmi volně souvisí se správou systému. Dialog zůstane zobrazen dvě minuty a poté zmizí . 5. Máme nyní spuštěn příkazový řádek, ve kterém nastavíme heslo k účtu Administrator na nějaký neprázdný řetězec (a to takový, proti kterému nebude protestovat případně zapnutá doménová zásada skupiny.) Potřebný příkaz má tvar net user administrator nové heslo. Pokud tedy chcete tomuto uživateli přidělit heslo mecoun123, zapište net user administrator mecoun123. Na rozdíl od téměř všech ostatních příkazů Windows, spouštěných v příkazovém řádku, se v heslu rozlišují malá a velká písmena. Příkaz je nutné odeslat stiskem klávesy Enter, poté by se mělo objevit hlášení „Příkaz byl úspěšně dokončen“. TIP:

A co když se to nepovede? Pokud se objeví hlášení „Došlo k systémové chybě 5. Přístup byl odepřen“, spustili jste příkazový řádek přímo, nikoli pravým tlačítkem myši a volbou příkazu „Spustit jako správce“. Jistě, jste přitom sice přihlášeni na účet lokálního administrátora, takže byste měli mít právo spravovat systém přímo … k tomuto se vrátím později, souvisí to s velmi rozsáhlou problematikou UAC. Prozatím si zapamatujte, že příkazový řádek je vždy nutné rozběhnout přes příkaz „Spustit jako správce“, pokud chcete provádět cokoli souvisejícího se správou systému.

Kapitola 1 – Správa zabezpečení windows vista – drobná překvapení

6. Nyní máme účet správce se silným heslem, můžeme tedy vše dokončit a aktivovat ho. V příkazovém řádku zapište net user administrator /active:yes a stiskněte Enter. TIP:

Z důvodů přehlednosti jsem celou úlohu rozdělil do dvou příkazů, ale můžete ji provést i najednou příkazem net user administrator mecoun123 /active:yes.

TIP:

Nezávisle na tom, jak budete postupovat, dávejte velký pozor na to, aby zapisované nové heslo z obrazovky někdo neodkoukal. Rozhodně stojí za to po dokončení celé operace okno příkazového řádku zavřít, aby se nikdo nemohl stiskem šipky nahoru vrátit na předchozí řádek a přečíst si heslo správce.

Skupina Power Users již v podstatě neexistuje Skupina uživatelů Power Users byla ze strany Microsoftu vždy pokusem nabídnout takovou skupinu uživatelů, která by neměla tak velká práva jako skupina Administrators, ovšem zároveň by její členové mohli provádět spoustu věcí, které nejsou dovoleny obyčejným uživatelům (skupina Users). Tato potřeba – jak nejspíše víte – byla dána faktem, že oprávnění členů skupiny Users nepostačovala ke spuštění velkého množství aplikací. Většina správců ví, že je nutné odvykat uživatele pracovat pod účtem lokálního administrátora, ale přitom je nutné dát jim tak silná oprávnění, aby mohli nerušeně pracovat (spouštět aplikace). Skupina Power Users byla pro mnohé vyhovujícím řešením této otázky. Bohužel, nebyla to odpověď příliš kvalitní. Vzhledem k tomu, že uživatelé ze skupiny Power Users mohli zapisovat do souboru ntoskrnl.exe (základního programu Windows), může zákeřný (a zároveň dostatečně inteligentní) Power User tento soubor upravit a přidělit si tak větší oprávnění, než mu náleží. Členové skupiny Power Users mohou také změnit nejméně jednu systémovou službu, běžící pod účtem LocalSystem, a tak si otevřít možnost přihlásit se do systému na účet LocalSystem. (Podrobný popis realizace těchto útoků najdete v blogu Marka Russinoviche na adrese http://www.sysinternals.com/blog/2006/05/power-in-power-users.html.) Skupina Power Users byla vytvořena coby „charitativní“ nástroj a pomáhá řešit potíže s kompatibilitou aplikací (mnohé aplikace nepracují správně, jsou-li spuštěny pod účtem tzv. standardního uživatele). TIP:

Pozor, zažité pojmy nemusí být zažité každému: pojem „standardní uživatel“ je relativně nový výraz Microsoftu, na který při práci ve Vistě budete narážet stále více a více. Dá se rozvést jako „uživatel, který je v podstatě jen členem místní skupiny Users na daném počítači“ a nemá absolutně žádná oprávnění pro správu systému. Na pojem narazíte především ve frázích typu „jakmile budete mít všechny své uživatele zařazeny mezi standardní uživatele…."

Při návrhu skupiny Power Users šlo o to, aby její účty měly dostatečně velkou úroveň administrátorských oprávnění ke spouštění problematických aplikací vyžadujících práva správce. Jinými

Skupina Power Users již v podstatě neexistuje

slovy, Microsoft vytvořil skupinu Power Users proto, aby napravil lenost mnoha programátorů, kteří své aplikace pro Windows dostatečně netestují. (Bohužel je nutné přiznat, že někteří z těchto vývojářů pracují pro Microsoft.) Konečným důsledkem tohoto přístupu je dnešní svět, ve kterém miliony uživatelů pracují přihlášeni ke svým systémům na účet správce nebo člena skupiny Power Users, a tedy světa milionů počítačů, u kterých může snadněji dojít k prolomení jejich zabezpečení. Problém aplikací vyžadujících oprávnění na úrovni správce se dal řešit alternativním způsobem –neustálým sekýrováním vývojářů, které by je donutilo psát aplikace pracující správným způsobem i pod účtem standardního uživatele. Touto cestou se však Microsoft dal až nedávno, poté co se nové druhy červů a jiného spywaru začali objevovat téměř každý den. Nakonec to skončilo tak, že Microsoft skupinu Power Users de facto zlikvidoval. Je sice stále přítomna v tom smyslu, že některé prostředky mají oprávnění odkazující na skupinu Power Users, ale „síla“ (power) této skupiny je jen v jejím názvu, protože jinak jsou její oprávnění v podstatě totožná se skupinou Users. Pokud vás tato změna zajímá, zkuste si na systému Windows XP vytvořit člena skupiny Power Users a poté si pomocí aplikace whoami.exe (je součástí různých verzí Support Tools a Resource Kitu, u 64bitových XP a Visty je přímo součástí systému) zobrazte oprávnění tohoto uživatele. Příkaz whoami /priv vypíše následující seznam: ■ ■ ■ ■ ■ ■

SeChangeNotifyPrivilege SeShutdownPrivilege SeUndockPrivilege SeSystemtimePrivilege SeProfileSingleProcessPrivilege SeCreateGlobalPrivilege

Udělejte to samé pro účet ze skupiny Power Users na Vistě; v tomto případě vypíše příkaz whoami /priv toto: ■ ■ ■ ■ ■

SeChangeNotifyPrivilege SeShutdownPrivilege SeUndockPrivilege SeTimeZonePrivilege SeIncreaseWorkingSetPrivilege

(Zajímá vás, co znamenají všechna ta Se-něco? Budeme to probírat v příští kapitole.) Rozbor začneme porovnáním toho, co mají staří a noví členové Power Users společné, a čím se liší. Obě skupiny přidělují oprávnění SeChangeNotifyPrivilege, které možná znáte spíše než pod tímto názvem ve významu „vynechat postupnou kontrolu při průchodu adresáři“. Pokud má uživatel oprávnění NTFS pro přístup k určité složce, ale tato složka je zanořena uvnitř složek, ke kterým uživatel přístup nemá, má uživatel povolen přístup do dané složky. (Takto to funguje již od NT 3.1.) Jsou ještě dvě další práva, která mají skupiny Power Users ve Windows XP i Vistě společné: SeShutdownPrivilege a SeUndockPrivilege. Jejich význam se odhadnout z jejich názvů: jde o právo vypnout systém a odpojit přenosný počítač z dokovací stanice. Uživatelé Windows XP i Visty mají právo měnit systémový čas, ale různým způsobem. Na XP mohou členové skupiny Power Users měnit čas, datum i časové pásmo. Standardní uživatelé a členové skupiny Power Users ve Vistě mají zcela nové oprávnění: možnost změnit jen časovou zónu,

Kapitola 1 – Správa zabezpečení windows vista – drobná překvapení

což není výmysl Microsoftu, ale jeho reakce na přání zákazníků. Běžní uživatelé nemají nyní právo měli systémový čas na pracovních stanicích, protože Microsoft vždy vnímal tuto záležitost jako bezpečnostní problém. (Změna času může velmi nepříznivě ovlivnit například ověřování protokolem Kerberos v rámci domény, protože při něm se nesmí hodiny klienta rozcházet o více jak pět minut s hodinami na řadiči domény.) Firmy však správně argumentovali, že mají dost pravidelných uživatelů, kteří cestují s přenosnými počítači a překračují přitom hranice časových zón. Administrátoři tedy potřebovali, aby tito lidé mohli měnit časové pásmo, ale už ne samotný čas. Proto je ve Vistě nové oprávnění „měnit časové pásmo“, přidělené členům skupiny Power Users (a také Users). Skupina Power Users však již nemá oprávnění měnit systémový čas na pracovní stanici. Členové skupiny Power Users na Windows XP mají dvě oprávnění, které jim ve Vistě chybí: „profilovat jeden proces“ (SeProfileSingleProcessPrivilege) a „vytvářet globální objekty“ (SeCreateGlobalPrivilege). První bylo trochu divné, protože dovolovalo uživateli zkoumat proces spuštěný jiným uživatelem. Proč? Šlo asi o toto: dejme tomu, že chci spustit Sledování systému a v něm kontrolovat procesy, které spouštějí jiní uživatelé. To znamená, že mi operační systém musí přidělit právo sbírat statistické údaje o procesech jiných uživatelů. Toto oprávnění je normálně používáno právě k tomu, aby někdo mohl sledovat, co se děje se systémem … teoreticky se však dá zneužít také ke špehování určitého uživatele, případně i celého systému. (Existuje ještě oprávnění SeDebugPrivilege, jehož špehounský potenciál je mnohem větší, ale tomu se budeme věnovat až v další kapitole.) Druhé oprávnění SeCreateGlobalPrivilege říká, zda uživatel má či nemá právo vytvářet tzv. „objekty pro mapování souborů v globálním jmenném prostoru“. Nebojte, hned tento těžko srozumitelný pojem přeložím do lidštiny. Když programy potřebují číst soubory či složky nebo do nich zapisovat, případně komunikovat s jinými programy, řídit vstupně/výstupní zařízení typu tiskárna nebo sériový port, dá se to – z hlediska psaní konkrétního kódu – dělat různě. Jednou z možností – která je využívána již hodně dlouho – je považovat všechny druhy těchto vstupně-výstupních zařízení za speciální případy čtení a zápisu z/do diskových souborů; například pro vzájemnou komunikaci jednoho programu proto vývojář může napsat větší množství potřebného kódu, ale může pro ně také namísto toho vytvořit určitý druh „imaginárního“ souboru. Oba programy pak mezi sebou mohou komunikovat tak, že čtou obsah imaginárního souboru (nebo do něj zapisují odesílané údaje). Kde tu hraje roli zabezpečení? Inu, pokud jsem jen obyčejným uživatelem a chci spustit program A komunikující s programem B, poté tyto programy – které jsou přihlášeny k systému na můj účet, protože jsem je já spustil – musí být schopny vytvářet tyto imaginární soubory neboli „objekty mapování souborů“. Je jasné, že i ti nejméně „spolehliví“ uživatelé by toto právo k vytváření souborů mít měli – zde žádné nebezpečí nečíhá. Ovšem pozor, uvažujme nyní o připojení k systému přes Terminal Services, a už máme velký problém. Na stejném systému může běžet více relací TS různých uživatelů, přičemž každý uživatel může mít spuštěn nějaký program, který tyto objekty mapování souborů vytváří. Co když dojde ke kolizi? Co když uživatel 1 spustí program, který vytvoří objekt s názvem „Jarda“ a uživatel 2 poté spustí svůj program, který se pokusí udělat to samé? Tuto potíž naštěstí řeší fakt, že každá uživatelská relace má svůj samostatný lokální „jmenný prostor“ a každý uživatel poto může vytvářet své objekty pro mapování souborů bez nebezpečí jejich kolizí. Služba Terminal Services však nabízí také globální jmenný prostor pro objekty mapování souborů, přes který může probíhat vzájemná interakce dvou různých relací.

Příkaz „Spustit“ již není v nabídce Start

To už se zabezpečením úzce souvisí, protože pokud si záškodník bude umět „pohrát“ s globálním jmenným prostorem, mohl by ovlivnit relace jiných uživatelů Terminal Services, Microsoft proto tuto schopnost uživatelům skupiny Power Users ve Vistě odebral. Takto spatra nejsem schopen uvést název žádné aplikace, kterou by toto odebrání privilegia uživatelů poškodilo, možná ale existuje. V tomto případě stačí přidat uvedené oprávnění určité skupině uživatelů a zařadit uživatele do dané skupiny, protože – jak již bylo řečeno – uživatelé skupiny Power Users ve Vistě (a také standardní uživatelé) nemají uděleno oprávnění SeProfileSingleProcessPrivilege a SeCreateGlobalPrivilege.

Skupina Power User ve Vistě má jedno oprávnění, které této skupině v XP schází. Je jím právo bump up množství paměti, které používá zadaná aplikace, tzv. „pracovní sadu“ aplikace. Microsoft očividně z určitého důvodu potřeboval toto oprávnění vytvořit. Po seznámení s právy a členstvím ve skupině Power Users nyní zkuste ve Vistě vytvořit normální uživatelský účet a příkazem whoami/priv si porovnejte jeho oprávnění s předchozím příkladem: sami uvidíte, že členové skupiny Users mají přesně stejná práva jako členové skupiny Power Users. Z hlediska přístupových oprávnění jsou na tom tedy členové Power Users hůře než předtím. Jak to však vypadá u oprávnění k souborovému systému NTFS? Ta byla rovněž omezena. Když porovnám svou kopii 64bitových Windows XP s nainstalovaným SP2, na které tuto knihu píšu, je tu obrovský rozdíl mezi tím, co si na tomto systému mohou dovolit ve složce System32 členové skupiny Power Users a co členové skupiny Users…, ale u složek ve Vistě se mi nepodařilo najít jediné oprávnění, které by odlišovalo skupinu Power Users od běžných uživatelů – ani to nejmenší!

Příkaz „Spustit“ již není v nabídce Start Nejsem si jistý, kdo nařizuje lidem z oddělení uživatelského rozhraní u Microsoftu provádět jeho změny, ale mám dojem, že to je někdo, kdo uživatele považuje za idioty. Vypadá to tak, že v každé verzi Windows se změní výchozí chování i vzhled nabídky Start, a to s neustále rostoucí mírou obtěžování. Ve Windows XP zmizely Nástroje pro správu, na Serveru 2003 se zkomplikoval přístup k Ovládacím panelům, a nyní ve Vistě zmizela položka Spustit …. Osobně používám tento příkaz velmi často, když už kvůli ničemu jinému, tak kvůli rychlému přístupu k Editoru systémového registru a editoru místních zásad. Ztráta položky Spustit… tak snižuje efektivitu mojí práce. Tak to napravíme, co vy na to? 1. Pravým tlačítkem myši klepněte na nabídku Start a v místní nabídce vyberte „Vlastnosti“. Stejně jako u předchozích verzí Windows takto otevřete dialogové okno vlastností Hlavního panelu a nabídky Start s aktivní stránkou „Nabídka Start“. Zde klepněte na tlačítko „Vlastní“ v pravém horním rohu karty a otevřete tak dialogové okno Upravit nabídku Start. 2. V tomto dialogovém okně je vidět velké množství přepínačů a posuvník vpravo. Táhněte posuvník, dokud nenarazíte na vypnuté zaškrtávací políčko „Příkaz Start“. Zapněte toto políčko. 3. Zůstaňte stále v otevřeném dialogu a vraťte se nahoru ke skupině přepínačů „Nástroje pro správu systému“. Zde zapněte přepínač „Zobrazit v nabídce Všechny programy“.

Kapitola 1 – Správa zabezpečení windows vista – drobná překvapení

4. Tlačítkem OK zavřete dialogové okno Upravit nabídku Start a dalším tlačítkem OK zavřete dialogové okno vlastností Hlavního panelu a nabídky Start. Příkaz Spustit a Nástroje pro správu jsou nyní opět na svých místech, a stačilo k tomu jen pár klepnutí. (Proto se o Vistě říká, že je tolik produktivní!)

BOOT.INI zemřel, ať žije BCD! Čas od času potřebuji upravit obsah souboru boot.ini,abych opravil určité potíže s konfigurací systému. Již od dob NT 3.1 se jednalo o textový soubor ve formátu ASCII, uložený na pevném disku. S nástupem Visty se všechno změnilo; tento systém má svůj zaváděcí soubor Boot Configuration Data (neboli BCD), umístěný na zaváděcím svazku (tedy diskové jednotce, že které je operační systém zaváděn, nezávisle na tom, jak ji Microsoft označuje) ve složce s názvem BOOT. Jedná se o jeden ze souborů, který je operačním systémem uzamčen v otevřeném stavu (obdobně jako soubory protokolu událostí *.EVT), takže ho není možné upravit klasickým způsobem a případný malware tak bude mít značně ztíženu možnost jeho nežádoucí změny či poškození. Vůbec se nepokoušejte o úpravu tohoto souboru přes Ovládací panely; dialogové okno Spuštění a zotavení systému tam sice najdete (je trochu zastrčené, musíte se k němu propracovat), ale na místě, kde v XP verzi tohoto dialogu je tlačítko „Možnosti spuštění systému upravíte ručně klepnutím na tlačítko Upravit“, je ve Vistě prázdné místo. Namísto něj je k dispozici nástroj příkazového řádku bcdedit.exe, který se umí vypořádat s volbami pro zavádění Visty.

Shrnutí obsahu souboru BOOT.INI Důvodem, proč já potřebuji měnit obsah souboru boot.ini – normálně jde o operaci trvající pár minut, i když se z ní nyní stala několikahodinová záležitost (ale po pročtení následujícího návodu váým to tak dlouho trvat nebude) – je to, že při testování počítačů (ať již virtuálních nebo reálných), které nejsou připojeny k Internetu, používám často slabší počítače, a abych při svých hrátkách s Vistou nemusel příliš dlouho čekat, vypínám funkci Zabránění spuštění dat (Data Execution Prevention, DEP). To rozhodně nedoporučuji na produkčních strojích a ostatně ani na žádném systému, do kterého byste zadávali data, o kterých nemá nikdo vědět. U testovacích systémů, kde nebude docházet k žádnému sdílení vitálně důležitých dat, je to však dobrý nápad. Na systémech XP a 2003 jsem ochranu DEP mohl vždy vypnout úpravou souboru boot.ini, do kterého jsem přidal k libovolné položce nabídky možnost /NoExecute=AlwaysOff. Ale jak se toto (a další věci) dělá u BCD? Abychom se to naučili, budeme se muset nejdříve trochu našprtat BCD-štinu. Začneme výpisem souboru boot.ini: takto vypadá na mé pracovní stanici s Windows XP: [boot loader] timeout=30 default=multi(0)disk(0)rdisk(0)partition(2)\WINDOWS [operating systems] multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="XP x64 " /fastdetect/ NoExecute=OptOut

BOOT.INI zemřel, ať žije BCD!

multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="XP x64 w/debug" /fastdetect/ NoExecute=OptOut /DEBUG multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /fastdetect

Tento konkrétní boot.ini nabízí uživateli při spouštění počítače výběr ze tří různých operačních systémů; všechny tři volby jsou uvedeny v části [operating systems]. Třem následujícím řádkům (jsou dlouhé a na stránkách této knihy zalomené, ale na dostatečně široké obrazovce byste skutečně viděli jen tři řádky) se říká „položky boot.ini“. Podívejme se například na tuto z nich: multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="XP x64 " /fastdetect / NoExecute=OptOut

Část multi(0)disk(0)partition(2)\WINDOWS je jen trochu záhadný způsob vyjádření umístění operačního systému: v tomto případě jde o druhý oddíl prvního pevného disku a složku s názvem Windows na tomto oddílu. Za tímto umístěním systému následují dva přepínače /fastdetect (říká systému Windows, aby se nezdržoval vyhledáváním zařízení připojených k paralelním a sériovým portům, což od nástupu Windows 2000 stejně není nutné) a /NoExecute=OptOut, což je výchozí nstavení ochrany DEP. Vzhledem k tomu, že mám v tomto souboru tři různé položky, vidím při každém spouštění své pracovní stanice nabídku boot.ini s těmito třemi variantami. Mezi další užitečné přepínače patří /maxmem, která zakazuje systému Windows používat RAM nad určitou hranicí velikosti, dále /debug zapínající systémové ladění nebo /numprocs, který stanoví počet používaných procesorů. Nad sekcí [operating systems] je ještě sekce [boot loader]. V ní jsou zadány dvě věci: jak dlouho bude nabídka na obrazovce vidět a která položka bude brána jako výchozí, pokud si uživatel nic nevybere a nechá nabídku zmizet. Pokud se nyní škrábete za uchem a říkáte si: „no to je divné, v životě jsem o souboru boot.ini neslyšel a žádnou jeho nabídku neviděl, a to v XP ani ve Vistě“, znamená to, že v tomto souboru máte jen jedinou položku (a tudíž není co vybírat – v takovém případě se nabídka ani na jednom z těchto systémů nezobrazí). Jestliže máte na Vistě BCD s více jak jednou položkou, bude nabídka s výběrem systémů vypadat trochu jinak než v předchozím systému (za předpokladu, že jste v něm vícepoložkový soubor boot.ini měli. Spouštěcí nabídka Visty je sice stále vypisována ve znakovém režimu, ale vpadá přece jen elegantněji než boot.ini, jak se můžete přesvědčit na obrázku 1.1. V této nabídce vidíte dvě položky: „Microsoft Windows Vista“, což je položka vytvořená při instalaci Visty, a „Vista bez DEP“ – tuto druhou položku jsem si vytvořil sám a v následujících odstavcích vám ukážu, jak si něco podobného můžete vytvořit sami. Kromě položek pro výběr operačního systému nabízí Boot Manager systému Vista rovněž volbu pro přímé spuštění programu pro testování operační paměti – to je od Microsoftu velmi milá pozornost, zvláště s ohledem na to, že systémy Vista obvykle vyžadují mnohem více paměti než systémy XP.

Kapitola 1 – Správa zabezpečení windows vista – drobná překvapení

OBRÁZEK 1.1: Operační systém Vista s více položkami spouštěcí nabídky

Terminologie BCD Abychom mohli pracovat s BCD, musíme se naučit něco málo z jeho „jazyka“. Ta jeho část, kterou bychom mohli považovat za celou „databázi“ BCD, se oficiálně označuje jako „úložiště“ (store) nebo „úložiště systému BCD („system BCD store“). Sklad obsahuje jednu nebo více „položek“, které fungují stejně jako položky boot.ini; pokud bych proto chtěl svůj starý soubor boot.ini převést do BCD, vytvořil bych úložiště se třemi položkami. Kromě těchto položek je v BCD ještě nabídka nástrojů, která implicitně obsahuje jedinou položku (testovače paměti). Každá položka může obsahovat ještě to, co dnes označujeme jako přepínače boot.ini (například /NoExecute=AlwaysOff), už se jim však neříká „přepínače“, ale „možnosti položek“. Podívejme se na to, jaký vztah má boot.ini k současnému BCD, a přikažme tomuto nástroji, aby vypsal svou aktuální konfiguraci. Otevřete okno příkazového řádku pod účtem Administrator (= pravým tlačítkem myši klepněte na položku Příkazový řádek, v místní nabídce vyberte příkaz „Spustit jako správce…“ a potvrďte příslušným tlačítkem dotaz UAC). Jako příkaz napište jen bcdedit. Poté se objeví výpis, který bude vypadat asi takto (některé položky jsem kvůli přehlednosti zkrátil): C:\Users\mark>bcdedit Správce spuštění systému Windows -------------------identifikátor {bootmgr} device partition=D:

BOOT.INI zemřel, ať žije BCD! description locale inherit default displayorder toolsdisplayorder timeout

Windows Boot Manager en-US {globalsettings} {current} {current} {c0e803c8-217c-11db-8f12-0016364dab15} {memdiag} 30

Zaváděcí program pro spouštění systému Windows ------------------identifikátor {current} device partition=C: path \Windows\system32\winload.exe description Microsoft Windows Vista locale en-US inherit {bootloadersettings} osdevice partition=C: systemroot \Windows nx OptOut Zaváděcí program pro spouštění systému Windows ------------------identifikátor {c0e803c8-217c-11db-8f12-0016364dab15} device partition=C: path \Windows\system32\winload.exe description Vista without DEP locale en-US inherit {bootloadersettings} osdevice partition=C: systemroot \Windows nx AlwaysOff

Všimněte si třech částí celé sestavy: jedna se jmenuje „Správce spuštění systému Windows“ a další dvě „Zaváděcí program pro spouštění systému Windows“. Pamatujete si ještě sekci [boot loader]? Ta byla transformována do informací v sekci Správce spuštění systému Windows. Každá položka v sekci [operating systems] se po novém stane samostatnou sekcí Zaváděcí program pro spouštění systému Windows.

Vytvoření položky pro druhý operační systém Pustíme se tedy do změn … ale pozor, opatrně! Vista vytvoří při své instalaci jednu položku pro operační systém s názvem „Microsoft Windows Vista“. Pokud se rozhodnete trochu si pohrát s volbami zavádění systému, určitě vám to schválím, když už kvůli ničemu jinému, tak jen kvůli uváděnému zrychlení testovacích počítačů, na kterých je vypnuta služba DEP. Ale rozhodně si nehrajte s tou jedinou zaváděcí položkou, kterou máte k dispozici! Důrazně radím udělat si nejdříve

Kapitola 1 – Správa zabezpečení windows vista – drobná překvapení

položku další a s tou teprve experimentovat. Jinak totiž hrozí nebezpečí, že vám vadná nabídka znemožní systém spustit, což má za následek asi tak jeden celý den ztracený reinstalací celého počítače. (Samozřejmě pokud instalace Visty není vaším koníčkem. Proč ne, když se během instalace zobrazuje na monitoru to krásné pozadí s pohledem na mořské řasy zespodu.) Jak vytvořit položku pro druhý operační systém? To je jedna z věcí, kvůli kterým byl nástroj bcdedit napsán. Nejjednodušší způsob vytvoření další položky po jiný OS je zkopírování položky stávající. Příslušný příkaz vypadá takto: bcdedit /copy {ID-kopírované-položky} /d popis. Část {ID-kopírované-položky} vysvětlím v následujících odstavcích, prozatím můžeme použít i zástupce {default}, neboli identifikátor výchozí položky operačního systému. S pomocí tohoto zástupce jsem kdysi vytvořil svou druhou položku „Vista bez DEP“ asi takto: bcdedit /copy {default} /d „Vista bez DEP“

Po spuštění tohoto příkazu nástroj bcdedit vypsal následující hlášení: Tato položka 0016364dab15}

byla

úspěšně

zkopírována

{c0e803c8-217c-11db-8f12-

Tu věc ve složených závorkách si určitě vysvětlíme … říká se jí globálně jedinečný identifikátor neboli GUID … ale ještě než se do toho pustíme, dovolte mi shrnout, kam až jsme se zatím dostali. Jestliže si tento příkaz na systému Vista skutečně vyzkoušíte a restartujete poté počítač, uvidíte při jeho spouštění Správce spuštění systému Windows (Windows Boot Manager) s dvěma položkami. Zatím se ovšem nová položka „Vista bez DEP“ bude chovat přesně stejně jako původní „Microsoft Windows Vista“. Máme ale bezpečnou kopii položky spouštěcí nabídky a s ní můžeme dále experimentovat.

Co jsou identiﬁkátory správce spuštění K čemu slouží řetězce {default} a {c0e803c8-217c-11db-8f12-0016364dab15}? Správce spuštění systému Windows musí dokázat nějak rozlišit různé položky pro operační systémy. Mohl by jim sice dát nějaké popisnější názvy, například „výchozí OS Vista“, ale to by bylo … hm … no dobře, přiznávám, že nevím, proč si nemůžete tyto identifikátory vybrat sami; zdá se, že jsou ve Windows přítomny již od verze 2000. Domnívám se, že se někdo v Microsoftu bojí toho, že byste se mohli zbláznit a vytvořit dvě položky OS se stejným názvem „výchozí OS Vista“ – pak by se váš počítač zřejmě zhroutil. Vista tedy vždy při vytvoření nové položky pro OS vygeneruje také náhodné 128bitové číslo a to nadále používá jako „pravé jméno“ nové položky. Uvnitř této položky je dále něco, co je označováno jako „popis“ – do této části můžete zapsat vlastní text, například „Vista bez DEP“ nebo něco podobného, a pomocí něj budete poté identifikovat konkrétní položky, ale Vista tyto texty za pravé názvy považovat nebude – pro systém je tím jediným názvem z hlediska softwaru ono záhadné {c0e803c8-217c-11db-8f12-0016364dab15}. Z toho vyplývá, že když budete chtít, aby bcdedit provedl určitou změnu v konkrétní položce operačního systému, budete muset tuto položku nějak identifikovat. Obvykle se pro identifikaci používá právě její GUID. Někdy si však budete moci ušetřit trochu práce, protože GUID nejsou jediným druhem identifikátoru položky operačního systému, který umí bcdedit zpracovat. Rozeznává také identifikátory {default} a {current}. Všimněte si, že jsou uzavřeny do složených

BOOT.INI zemřel, ať žije BCD!

závorek, protože to jsou také GUID. Výraz {default} říká nástroji bcdedit, aby zkonfiguroval položku operačního systému, která je implicitně zaváděna, ale aby přitom nevyhledával její GUID. Výraz {current} dělá to samé, ale na tu položku OS, jejíž systém je momentálně spuštěn. Pokud tedy pracujete ve Vistě, která byla spuštěna jako výchozí operační systém, poté na její položku odkazují oba identifikátory – {default} i {current}. O něco dříve jsem proto příkazem bcdedit /copy {default}… přikazoval nástroji bcdedit zkopírovat implicitní (výchozí) položku operačního systému. Když poté bcdedit vypsal ono dlouhé číslo ve složených závorkách, sdělil mi tak GUID nové položky operačního systému, kterou pro mne vytvořil. Pokud byste si někdy potřebovali zjistit GUID výchozí položky operačního systému, zjistíte ho příkazem bcdedit /v. Nástroj poté vypíše stejně dlouhý seznam údajů, který jste viděli u příkazu bcdedit bez parametrů, ale v řádku Identifikátor bude namísto {current} uveden skutečný GUID dané položky. V terminologii nástroje bcdedit jsou identifikátorem jak GUID ve složených závorkách, tak předdefinované položky {current} a {default}.

Výběr doby zobrazení spouštěcí nabídky a výchozího operačního systému v nástroji bcdedit Když už umíme identifikovat jednotlivé položky OS, budeme pokračovat v probírání základních principů. Obdobně jako u boot.ini je základní úlohou Správce spuštění definice doby zobrazení spouštěcí nabídky a její výchozí položky. (Správce spuštění umí dělat i spoustu jiných věcí, ale zde se soustředím pouze na to nejnutnější.)

Změna doby zobrazení spouštěcí nabídky Chcete-li změnit dobu zobrazení spouštěcí nabídky, spusťte příkaz bcdedit /timeout početsekund. Poslední parametr – jak je zřejmé z jeho názvu – stanoví novou dobu zobrazení nabídky v sekundách (po jejím uplynutí Správce spuštění sám vybere výchozí položku). Pokud tedy má Správce čekat například 15 sekund, zapište bcdedit /timeout 15

Tuto volbu asi moc často měnit nebudete, pravděpodobnější je spíš změna výchozího operačního systému.

Změna výchozí položky Správce spuštění Druhá úloha – výběr výchozí položky, kterou Správce zavede, pokud uživatel neprovede výběr v nabídce sám – vypadá na první pohled jako brnkačka. Je to skutečně velmi jednoduché, jak však asi správně tušíte, nyní se budete muset na novou výchozí položku odkázat jejím identifikátorem, a tím bude s největší pravděpodobností GUID. Jak jsme již viděli, dostala na mém systému nová položka operačního systému „Vista bez DEP“ přidělen GUID s hodnotou {c0e803c8-217c-11db-8f12-0016364dab15}.

36 VAROVÁNÍ:

Kapitola 1 – Správa zabezpečení windows vista – drobná překvapení

I když budete ve svém systému spouštět přesně ty samé příkazy, které čtete v knize, nebude souhlasit hodnota vašeho GUID, protože ta je generována náhodně. Nepanikařte proto, pokud budou vaše GUID vypadat jinak než to moje, je to zcela normální.

Znám-li GUID nové výchozí položky, stačí spustit příkaz bcdedit /default {guid}. Abych tedy nastavil položku „Vista bez DEP“ jako výchozí, spustím příkaz?: bcdedit /default {c0e803c8-217c-11db-8f12-0016364dab15}

Vy na vašem systému spusťte podobný příkaz, který se bude lišit jen hodnotou GUID vaší položky operačního systému „Vista bez DEP“ – tu si musíte zjistit. Jak? Spustíte-li příkaz bcdedit bez parametrů, uvidíte výpis všech položek a jejich GUID. Nezapomeňte také uzavřít GUID do složených závorek, jinak bcdedit nebude fungovat. Když poté znovu spustím příkaz bcdedit bez parametrů, uvidím stejný výstup, ale v řádku „identifikátor“ bude původní hodnota {c0e803c8217c-11db-8f12-0016364dab15} nahrazena zkráceným {default}. U druhé položky operačního systému „Microsoft Windows Vista“ bude nyní identifikátor {current}.

Změna možnosti položky Máme vytvořenu novou položku a nastavili jsme ji jako výchozí, můžeme si tedy začít hrát s možnostmi (předvolbami) položky. Připomeňme si, že pojem „možnost položky“ je nový kabát pro starší „přepínače boot.ini“. Některé přepínače mají hodnoty, například /NoExecute=AlwaysOff (tuto ukázku jste již viděli), jiné jsou bez hodnoty (například /basevideo, který přikazuje systému spustit se jen se základním grafickým ovladačem VGA) a jsou zapnuty nebo vypnuty podle toho, jestli je do položky OS zařadíte nebo ne. V BCD a bcdedit má však každá možnost nabídky svůj název – například NoExecute – a hodnotu – například AlwaysOff. (Velikost písmen se podle mé zkušenosti v BCD a bcdedit nerozlišuje.) Přepínače boot.ini, které předtím neměli hodnotu – například již zmíněné /basevideo, nyní mají hodnoty „yes“ nebo „no“. (Mimochodem, samotná možnost /basevideo se nyní jmenuje stručně vga.) Možnost lze přidat k položce následujícím způsobem: bcdedit /set [{guid položky}]název-možnosti-položky [hodnota-možnosti-položky]. Chceme-li tedy v položce aktuálního operačního systému nastavit nx na AlwaysOff, spustíme tento příkaz: bcdedit /set {current} nx AlwaysOff

Pokud bychom v příkazu vůbec neuvedli položku operačního systému, bcdedit bude předpokládat, že chceme měnit tu položku, která je momentálně zavedena, a proto se dá předchozí příklad zkrátit takto: bcdedit /set nx AlwaysOff

Pro nastavení nx ve výchozí položce operačního systému slouží příkaz bcdedit /set {default} nx AlwaysOff

BOOT.INI zemřel, ať žije BCD!

Jestliže chceme, aby položka OS s GUID {c0e803c8-217c-11db-8f12-0016364dab15} byla spouštěna se standardním grafickým ovladačem VGA, můžeme to zapsat takto bcdedit /set {c0e803c8-217c-11db-8f12-0016364dab15} vga yes

(Pro upřesnění dodávám, že tento příkaz je třeba zapsat na jeden řádek.) Poté, co jsme si ukázali, jak měnit možnosti položek, uvádím seznam některých dostupných zaváděcích možností BCD pro Vistu a pro srovnání s boot.ini též odpovídající starší přepínač z tohoto souboru pro každou z uvedených položek: ■

nx, jak již bylo řečeno, řídí používání DEP. V boot.ini šlo o přepínač /NoExecute. Mož-

nost nx lze nastavit na hodnoty AlwaysOn (DEP je použito na všechny uživatelské aplikace a programy operačního systému), AlwaysOff (DEP vypnuto a nikdy není použito), OptOut (DEP je použito na všechny uživatelské aplikace a programy s výjimkou těch, které explicitně vyloučíte) nebo OptIn (DEP je použito na všechny programy operačního systému a všechny aplikace, které explicitně vyjmenujete. (Přidávání a odebírání aplikací probíhá v appletu Systém uvnitř Ovládacích panelů.) ■

vga je nastavení vysvětlené již v předchozím textu: při jeho zapnutí použije systém při stan-

dardní grafický ovladač VGA namísto toho, který má normálně nainstalován. Možné hodnoty jsou „yes“ nebo „no“. Jeho protějškem v boot.ini byl přepínač /basevideo. ■

numproc umožňuje omezit používaný počet procesorů (v boot.ini šlo o přepínač /numproc).

Jeho hodnotou je číslo; zápis bcdedit /set numproc 1 přikazuje aktuálně spuštěnému systému používat jen jeden procesor. Tato možnost se může hodit v případě, kdy narazíte na aplikaci testovanou jen na jednoprocesorových systémech, která při spuštění na víceprocesorovém stroji padá nebo vyvolává jiné chyby. ■

removememory umožňuje zakázat operačnímu systému používat určité množství operační paměti. Protějškem v boot.ini byl přepínač /burnmemory. Hodnota se zadává jako dekadické nebo hexadecimální číslo (ve druhém případě je třeba na začátek čísla přidat řetězec „0x“), určující přesný počet odebraných bajtů paměti pro Vistu – zadáte-li číslo „500000“, je to asi půl megabajtu paměti (ne půl gigabajtu!).

■

truncatememory je další příkaz omezující množství používané paměti. Zatímco však

removememory stanoví množství odebrané paměti (zbytek RAM zůstává přidělen), truncatememory funguje opačně: jeho hodnota stanoví množství přidělené paměti (a zby-

tek je zakázán). Obě možnosti najednou není možné v rámci jedné položky zadat. Obdobně jako u removememory i truncatememory přebírá jako parametr číslo, které znamená přesný počet bajtů RAM, které Vista může používat. V boot.ini byl pro tyto účely stanoven přepínač /maxmem. Pokud to někomu stále není jasné, představte si, že máte počítač se 2 GB RAM. Možnost removememory 500000000 zakáže systému používat půl giga RAM, takže Vistě zbude 1,5 GB. To samé se dá udělat i pomocí truncatememory, ale v tomto případě je nutné zadat truncatememory 1500000000.

38 ■

Kapitola 1 – Správa zabezpečení windows vista – drobná překvapení quietboot vypíná malé animované obdélníčky, běhající zleva doprava po monitoru coby

indikátor průběhu zavádění systému. Nastavit se dá na „yes“ nebo „no“. V souboru boot. ini šlo o přepínač /noguiboot. ■

sos (v souboru boot.ini šlo o přepínač /sos) přikazuje operačnímu systému vypsat během svého zavádění název každého spouštěného ovladače a služby. Tato možnost se hodí v případech, kdy se systém při startu zasekává; stačí nastavit sos na „yes“ a restartovat (pochopitelně je k tomu účelu nutný jiný způsob, jak systém spustit, pokud možno přes další, předem připravenou položku operačního systému!). Název posledního zobrazeného ovladače může indikovat viníka. Možné hodnoty jsou „yes“ nebo „no“.

■

bootlog přikazuje operačnímu systému vytvořit protokol o všech nahrávaných ovladačích, a to v tom pořadí, v jakém jsou spouštěny. Vytvořený protokol je poté uložen do složky Windows jako soubor s názvem ntbtlog.txt. Možné hodnoty jsou „yes“ nebo „no“, v souboru boot.ini šlo o přepínač /bootlog.

Úklid: mazání položek operačního systému To je v podstatě vše, co jsem chtěl probrat v části o BCD a bcdedit – mělo by vám to stačit k tomu, abyste dokázali úspěšně vyladit spouštěcí parametry systému na optimum. Pokud přitom zjistíte, že vaše vlastní položka operačního systému je lepší než ta, kterou OS Vista vytvořil automaticky, můžete tuto nepotřebnou položku odstranit. Potřebný příkaz má tvar bcdedit /delete identifikátor. Na mém systému jsem nejdříve zjistil GUID nepotřebné položky příkazem bcdedit. Ten vypsal hodnotu {24a500f3-12ea-11db-a536-b7db70c06ac2}, kterou jsem následně použil v příkazu bcdedit /delete {24a500f3-12ea-11db-a536-b7db70c06ac2} {24a500f3-12ea-11db-a536-b7db70c06ac2

Složka „Documents and Settings“ je pryč (ale ne úplně) Když se objevily Windows 2000, zalíbila se mi jejich různá vylepšení oproti starším NT 4.0, ale jedna věc mne velmi rozčarovala: složka Documents and Settings. Hodně totiž pracuji v příkazovém řádku, a názvy složek obsahující mezery jsou zde neuvěřitelně otravné. Musíte je totiž uzavírat do uvozovek a ani to někdy nestačí, některé programy prostě s takovými názvy nefungují správně. TIP:

Ve Vistě se však naštěstí s názvy složek a souborů obsahujícími mezery pracuje mnohem snadněji. Kdykoli pracujete v příkazovém řádku a potřebujete zapsat název souboru nebo složky, stačí napsat jen takovou část názvu, která požadovaný soubor či složku jednoznačně identifikuje, a poté stisknout tabulátor. Systém poté automaticky dokončí zbytek názvu. Chci-li tedy nastavit jako aktuální složku C:\Documents and Settings, stačí napsat cd d a stisknout Tab, ihned poté se příkaz změní na cd 'c:\documents and settings'. Pokud na písmeno D začínají názvy více adresářů a já si vyberu ten špatný, stačí mačkat Tab znovu a postupně procházet nabídku všech možností. Pokud je v názvu mezera, příkazový řádek Visty automaticky doplní uvozovky. (Toto chování bylo k dispozici již ve Windows 2000, XP a 2003, ale nebylo implicitně zapnuto.)

Vlastnosti sítě a protokol IPv6

Windows NT původně ukládal profily uživatelů do složky winnt\profiles, ale Microsoft se rozhodl přesunout profily mimo složku operačního systému (což je rozumné rozhodnutí) do odděleného adresáře. To je také v pořádku, ale nazvat tuto složku „Documents and Settings“ bylo velmi nešťastné. (Ne sice tak pitomé jako nucení správců učit se potrhlé fráze typu HKEY_LOCAL_ MACHINE, nutné pro chápání systémového registru, ale dost pitomé.) Ve Vistě je vše konečně jinak a lokální profily jsou ukládány do složky \Users. To je prostě super: bez mezer, krátké a znělé. Se složkou Documents and Settings jsme ovšem museli žít něco málo přes šest let a Microsoft ví, že se určitě najdou aplikace, kterým nové pojmenování nebude po chuti a budou chtít natvrdo zapisovat data do složek c:\documents and settings\ jména-některých-uživatelů \ jméno-určité-složky, namísto aby se nejdříve zeptaly operačního systému na umístění složky s profilem uživatele. Aby se s těmito neposlušnými aplikacemi vypořádal, ponechal tedy Microsoft na systémové jednotce složku Documents and Settings, ale skryl ji a nastavil její přístupová oprávnění NTFS tak, že – to se vám bude určitě líbit – odebral skupině Everyone právo na čtení této složky. Co z toho plyne? Jakákoli aplikace, která se pokusí vytvořit soubor ve složce Documents and Settings, aniž by se nejdříve zeptala systému, kde se nachází složka s profilem uživatele, zákonitě selže. Co dělat, pokud se vám podaří najít na svém systému jednu z takových aplikací? Buď je nutné obrátit se na vývojáře, aby tento problém opravil, nebo složku zobrazte a změňte její přístupová oprávnění NTFS . Problém může také na pozadí odstranit virtualiazce souborů a složek, jedna z novinek Visty (kterou probereme v třetí kapitole.)

Vlastnosti sítě a protokol IPv6 Když jsem poprvé spustil jednu z prvních verzí Visty (ještě v dobách, kdy se jí říkalo „Longhorn Desktop“), zdálo se, že mi nefunguje žádné síťové připojení. Proto jsem udělal to, co v takové situaci udělá většina správců sítě: otevřel jsem okno příkazového řádku, zapsal do něj příkaz ipconfig a poté stisknul Enter. Na obrázku 1.2 vidíte, co jsem asi tenkrát uviděl já. OBRÁZEK 1.2: ipconfig v novém, trochu divném kabátě

Kapitola 1 – Správa zabezpečení windows vista – drobná překvapení

Za prvé, přestože mám na svém počítači jen dvě síťové karty, ve výpisu jsem viděl karet celkem pět … že bych neuměl počítat? To snad ne. Přemítal jsem, co se děje: „proč jsou v adresách dvojtečky a znaky procent, když tam mají být jen tečky … aha … už to mám!“ IPv6. Jak asi víte, v současné době se na Internetu používá protokol IP především ve čtvrté verzi (IPv4). Existoval i IPv5 (Internet Stream Protocol), a to díky několika lidem, kteří se úpravou síťových zařízení pokoušeli usnadnit přenos multimediálních dat, ale ten nikdy nepřekročil experimentální fázi. Když se začaly projevovat obavy z blízkého vyčerpání všech volných IP adres, začalo pár jiných inteligentních lidí pracovat na nové verzi protokolu IP, ve které jsou 128bitové adresy namísto 32bitových v IPv4. Kdyby celý Internet přešel na IPv6, nemuseli bychom se už nikdy obávat, že nám dojdou síťové adresy, protože se dá lehce spočítat, že bychom pro každý centimetr čtverečný zemského povrchu měli k dispozici 66 564 400 308 818 430 487 adres IP, a to prosím počítám i plochu oceánů a moří. Bylo mi jasné, proč chce Microsoft do Visty zabudovat také IPv6. Je to výchozí bod pro spoustu zajímavých mobilních technologií; pokud by celý svět přešel na IPv6, bylo by teoreticky možné, abyste si ráno po probuzení stáhli po bezdrátovém připojení novou poštu, během cesty autobusem do práce pročítali zprávy, stahované do notebooku z veřejné městské bezdrátové LAN, a nakonec v práci připojili svůj notebook do firemní sítě a přihlásili se do domény … a po celou dobu by se přitom nezměnila vaše adresa protokolu IP. Microsoft se pustil do boje o získání co největšího tržního podílu v mobilním světě, proto zřejmě přidal IPv6 do Visty jako implicitní protokol, ať už se vám to líbí nebo ne. V Číně se pustili do budování celostátní internetové sítě založení na IPv6, a Čína je velmi důležitý trh, což považuji za důvod implicitní instalace IPv6, ať už se mi to líbí či nikoli. V Microsoftu nesnáší ty neustále povídačky o to, že jsou v oblasti sítí všude pozadu a ve většině distribucí Linuxu se ještě implicitně IPv6 neobjevuje, takže se lidem z Microsoftu možná IPv6 zdál jako marketinková šance prezentovat se ve srovnání se svým největším desktopovým rivalem coby „závan budoucnosti". Budou za to ovšem muset i zaplatit., a podle mne hodně. Microsoft vyloženě nesnáší provozování oddělení technické podpory, protože to ani zdaleka není tak výdělečná činnost jako vylisování milionů DVD s Vistou, za které si účtují pár stodolarovek za jeden kus, ale bez podpory se neobejde – jinak by většin uživatelů přešla na jiný systém. Myslím si však, že Microsoft během let získal dost rozsáhlou základnu pomocníků, kteří za něj pracují zdarma. Jak jsem již napsal, bez rozpaků bych vsadil na to, že každý čtenář této knihy už někdy fungoval jako bezplatná technická podpora pro své přátele, členy rodiny nebo sousedy. A teď si představte, co se stane, až někdo z této (ne)dobrovolnické armády začne poprvé řešit problémy s kabelovým modemem souseda, který si právě nainstaloval svou čerstvě koupenou kopii Visty. Podívá se do výstupu příkazu ipconfig a pak s největší pravděpodobností řekne: „hmm, asi bude lepší, když si na to zavoláte poskytovatele“. A určitě víte, jak jsou potěšeni servisáci telekomunikačních firem, když vidí adresy IPv6. Rád bych nyní zdůraznil a vyjasnil jednu velmi, skutečně velmi důležitou věc: pokud vím, domácí uživatelé mohou provozovat IPv6, aniž by to mělo nějaký nepříznivý dopad na jejich sítě. V prostředích Active Directory, kde jsou provozovány systémy XP, 2003 nebo Vista, jsem však narazil na problémy – špatně fungovala dynamická registrace DNS, pravděpodobně díky zmatečnosti adres IPv6. Tento problém se vyskytoval i v RC1 verzi – proto bych osobně dal přednost tomu, abych si IPv6 mohl do systému přidat, ne ho odebírat. Ale vzhledem k tomu, že se jedná o výchozí

Vlastnosti sítě a protokol IPv6

protokol, znamená to, že ho budu muset zrušit, pokud budu chtít, aby výstupy z ipconfig nevypadaly tak záhadně. Jestliže si nyní říkáte: „to nebude nic těžkého, prostě si najdu stránku vlastností příslušné síťové karty a tam vypnu zaškrtávací políčko v řádku IPv6“, tak to samé jsem si poprvé myslel i já. Poté jsem ale začal hledat stránku vlastností své síťové karty. Chcete ji také najít? Pokud ano, sežeňte si nějakou přilbu a svítilnu – jdeme na výpravu do hlubin Visty …. 1. Klepněte na tlačítko Start a poté vyberte Ovládací panely. Ty se zobrazí v okně z obrázku 1.3, ve kterém jsem příslušnou část zarámoval. Tento obrázek se možná zdá zbytečný, ale není, protože na něm chci ukázat jednu z novinek Ovládacích panelů. Podívejte se na sekci, kterou jsem orámoval; tady normální člověk očekává sekci týkající se sítí. Ale pozor, máme tu malé překvapení – nejde o jedinou sekci jako v XP (kde byla jediná ikona „Připojení k síti a Internetu“), ale o sekce tři, i když to není zřejmé na první pohled. Tyto tři sekce se jmenují „Síť a Internet“, „Zobrazit úlohy a stav sítě“ a Sdílení souborů a složek“. Každá z nich je samostatná a vypadá jako hypertextový odkaz, a každý z těchto odkazů vás přenese na jiné místo. Žádný z nich ale nevede přímo k vlastnostem síťové karty. 2. Nyní klepněte na odkaz „Zobrazit úlohy a stav sítě“ a poté ve výsledné stránce Ovládacích panelů uvidíte po levé straně panel s nadpisem „Úkoly“. Jedním z těchto úkolů je „Spravovat síťová připojení“: po klepnutí na tento úkol budou Ovládací panely vypadat jako na obrázku 1.4. OBRÁZEK 1.3: Ovládací panely systému Vista

Kapitola 1 – Správa zabezpečení windows vista – drobná překvapení

OBRÁZEK 1.4: Síťová připojení ve stylu Visty

3. Tohle už je povědomé, že? Klepněte pravým tlačítkem myši na síťovou kartu Ethernetu (u vás samozřejmě půjde o jiný model síťové karty, dialog ale bude jinak vypadat stejně) a v místní nabídce vyberte příkaz Vlastnosti. Poté se objeví dialog z obrázku 1.5. OBRÁZEK 1.5: Stránka vlastností síťové karty ve Vistě

Vzdálená plocha je nyní výrazně bezpečnější

4. Toto dialogové okno také velmi dobře znáte … ale něco nového tu přece jen je. Všimněte si všech voleb pro IPv6 a různých nástrojů pro zajištění kompatibility mezi IPv6 a IPv4. Podle potřeby vypněte vše, co nechcete a některé části týkající se IPv6 zmizí; horní tři odkazy na „tunelové adaptéry“ zůstanou. Naučili jste se najít stránky vlastností síťových karet. Rád bych ještě jednou zdůraznil, že nenavádím lidi k tomu, aby se zbavili protokolu IPv6; chtěl jsem vám jen ukázat, kde najdete vlastnosti síťové karty a IPv6 byla jen záminka.

Vzdálená plocha je nyní výrazně bezpečnější Na první pohled vypadá Vzdálená plocha ve Vistě téměř stejně jako v systému XP. Při bližším zkoumání však objevíme malou, ale důležitou změnu v zabezpečení. Najdete ji na stránce Vzdálený přístup v dialogovém okně vlastností systému. Jak se tam dostanete? 1. Klepněte na tlačítko Start. 2. V nabídce Start pravým tlačítkem myši klepněte na položku Počítač a v místní nabídce vyberte příkaz Vlastnosti. 3. Na stránce Ovládacích panelů, která se poté objeví, klepněte v levém seznamu Úkoly na položku „Vzdálená nastavení“. Poté uvidíte stránku vlastností z obrázku 1.6. Tato stránka vypadá opravdu dost podobně jako její protějšek v XP, ale všimněte si, že namísto dvou voleb „povolit nebo zakázat vzdálenou plochu“ je tu ještě třetí nabídka „Umožnit připojení pouze těch počítačů, v nichž je spuštěna Vzdálená plocha s ověřováním na úrovni sítě (vyšší zabezpečení)“. OBRÁZEK 1.6: Nastavení Vzdálené plochy ve Windows Vista

Kapitola 1 – Správa zabezpečení windows vista – drobná překvapení

Co tato volba znamená? Zkuste si představit, co se vlastně děje při každém pokusu o připojení k vzdálenému systému prostřednictvím Vzdálené plochy. Ve Windows XP nebo 2003 spustíte Připojení ke vzdálené ploše (Remote Desktop Connection, RDC) a přikážete této aplikaci, aby se připojila k nějakému systému. RDC se pustí do práce a – za předpokladu, že je na určeném systému Vzdálená plocha povolena a jeho firewall toto připojení povolí – se na vaší obrazovce objeví přihlašovací dialog pro vzdálený systém. Z hlediska obzvláště paranoidního zabezpečováka se jedná o zajímavou situaci: ještě nejste ke vzdálenému systému přihlášeni, ale on již odpověděl na váš příkaz. Vzdálená plocha tedy „cizincům“ důvěřuje trochu více, než by měla, protože posloupnost událostí vypadá takto: (1) odešlete požadavek na připojení ke vzdálené ploše vzdáleného systému, (2) vzdálený systém pozastaví všechny prováděné úlohy a vytvoří vzdálenou relaci pro váš počítač, (3) přihlásíte se. Zapnutím třetí volby v nastavení Vzdálené plochy přikazujete tomuto nástroji, aby prohodil fáze (2) a (3). Když se pokusíte připojit ke vzdálenému systému, který tento přístup k věci podporuje (Microsoft to označuje jako „ověřování totožnosti na úrovni sítě“), neuvidíte vzdálený standardní přihlašovací dialog Windows nad vzdálenou pracovní plochou, ale dialogové okno z obrázku 1.7. OBRÁZEK 1.7: Přihlašovací dialog Network Level Authentication

Vyplývá z toho, že přihlašování na úrovni sítě funguje aktuálně jen vůči systémům s Windows Vista? Zřejmě ano. V době, kdy jsem tento text psal (září 2006), vydal Microsoft balíček s názvem „Remote Desktop Connection 6.0“ pro systémy XP SP2, 2003 SP1 a 64bitové verze XP a 2003. Nebyly sice vydána veřejně, stáhnout si jen člověk mohl jen na stránce Microsoftu s beta verzemi programů, ale byl bych překvapen, kdyby nebyly obecně dostupné od začátku prodeje Windows Vista, nebo možná skončí na instalačním DVD Visty. Ale ani s takto aktualizovaným klientem RDP se nelze ověřit na úrovni sítě proti Vistě (a pokud ano, neumím si představit, jak je to možné). Co když budete chtít, aby se starší systémy mohly připojit k vašemu počítači, ale počítače s Vistou by museli použít nové ověřování na úrovni sítě? V tom případě zapněte druhý přepínač. Klienti Visty budou používat ověřování na úrovni sítě i v případě, kdy to vzdálený počítač s Vistou nevyžaduje. Je něco špatného na zapnutí druhého přepínače? Samozřejmě ano. Na jedné straně tak povolíte připojení k vašemu systému Vista prostřednictvím nejrůznějších klientů; na stran druhé se tak ochudíte o zabezpečení zajišťované novým ověřováním na úrovni sítě, které značně snižuje

Vzdálená plocha je nyní výrazně bezpečnější

nebezpečí útoku vůči vašemu počítači, realizovanému jako opakované série pokusů o přihlášení. Jako jinde i tady platí, že zabezpečení a kompatibilita jsou často otázkou kompromisu – kde jeden získá, tam druhý ztratí. A málem bych zapomněl ještě na jednu novinku v oblasti Vzdálené plochy, která patří k mým oblíbeným. Přes připojení ke vzdálené ploše je nyní možné kopírovat nebo přesouvat soubory pomocí schránky. Chcete zkopírovat celou složku souborů ze svého počítače na vzdálený systém, ke kterému jste připojeni? Stačí na ni klepnout pravým tlačítkem myši a v místní nabídce vybrat příkaz Kopírovat, poté vybrat nějakou složku na vzdáleném systému a přes pravé tlačítko myši spustit příkaz Vložit. Šikovná věcička, i když na základě toho, co jsem zkoušel, to není možné využít ani v aktualizovaném klientovi RDP pro systémy Windows XP a 2003. V něm sice tato technika zdánlivě funguje, ale nic se přitom neděje.

NTFS a systémový registr nyní podporují transakce Tato novinka patří mezi příjemná překvapení, dokonce se nebojím použít slovo „výtečně“. Ve Vistě je nyní jak souborový systém, tak systémový registr transakční. Velmi mne to překvapilo, protože se tato věc měla objevit až v Serveru 2007. Pojem „transakční“ znamená asi toto: vezmete libovolné množství souborů a provedete s nimi nějakou operaci (kopírování, přesun …). Operace musí proběhnout úspěšně na všech souborech, pokud se u jediného souboru nezdaří, stačí ji zrušit („odrolovat“, roll back) a všechny předchozí kroky jsou odvolány, takže vše vypadá jako na začátku. Podívejme se na ukázku takové transakce: Microsoft Windows [Version 6.0.5456] (C) Copyright 1985-2005 Microsoft Corp. C:\Users\mark>transaction /start A transaction has been successfully started. Transaction ID: {1288b5a4-4b58-4006-88d8-6bc86f4b8ad3} C:\Users\mark>md newfiles C:\Users\mark>copy con newfiles\test hi there ˆZ 1 file(s) copied. C:\Users\mark>dir newfiles Volume in drive C has no label. Volume Serial Number is 4834-858C Directory of C:\Users\mark\newfiles 07/17/2006 06:48 PM <DIR> . 07/17/2006 06:48 PM <DIR> .. 07/17/2006 06:48 PM 10 test 1 File(s) 10 bytes 2 Dir(s) 15,731,507,200 bytes free

Kapitola 1 – Správa zabezpečení windows vista – drobná překvapení

C:\Users\mark>transaction /rollback The current transaction has been rolled back. C:\Users\mark>dir newfiles Volume in drive C has no label. Volume Serial Number is 4834-858C Directory of C:\Users\mark File Not Found C:\Users\mark>

V tomto výpisu jsou vidět následující věci: spustím transakci, vytvořím novou složku a vložím do ní soubor. Poté však celou transakci zruším a tak odvolám všechny provedené činnosti – příkaz dir vypíše, že zadaný adresář neexistuje. Kdybych namísto transaction /rollback zapsal transaction /commit, řekl bych tak systému, ať celou transakci „zvěční“ neboli uskuteční. Kdy se souborové transakce nebo transakce v rámci systémového registru mohou hodit? Například pro aplikaci záplat. Takto si v klidu můžete nainstalovat a otestovat nějaký program, a když nebude vyhovovat, odvoláte transakci a program je pryč. Ovšem pozor, během spuštěné transakce nesmí dojít k restartu počítače; ten by automaticky spustil příkaz transaction /rollback. Dá se očekávat, že se najde spousta dalších možných situací, kdy se transakce budou hodit. (Musím to zopakovat: mně se okamžitě vybaví pojem „záplatování systému“.) VAROVÁNÍ:

Bohužel počínaje verzí RC1 není příkaz transaction ve Vistě k dispozici. Interní podpora transakcí na úrovni souborového systému NTFS i registru podle všeho v systému zůstala, ale příkaz sám vyvolával asi některé kontroverzi a Microsoft proto rozhodnul, že by obyčejní uživatelé neměli dostat tento nástroj k dispozici. Dokud nebude tento názor opuštěn, budou moci transakce používat jen programátoři. (Which might make sense; it's just a shame.)

Ve Windows máme nyní lepší obnovu smazaných souborů! Jestliže jste někdy v XP využili Obnovu systému, určitě mi dáte za pravdu, že to může být velmi užitečný nástroj. Obnova systému vytváří periodické snímky stavu operačního systému a umožňuje se vrátit do některého z předchozích stavů, což umožňuje úspěšně řešit průšvihy typu instalace vadného nízkoúrovňového ovladače nebo pády systému zaviněné nesprávnou činností antivirového systému (takové pády jsou zajisté také jedním ze způsobů, jak se uchránit před záškodnickými programy, ale rozhodně ne optimální). V systému Vista funguje Obnova systému i na úrovni souborů. Když pravým tlačítkem myši klepnete na nějakém souboru či složce a v místní nabídce vyberete příkaz Vlastnosti, uvidíte dialogové okno z obrázku 1.8. Máme tu novou stránku s názvem Předchozí verze. V češtině to sice není poznat, ale jde o množné číslo! Zjistili jste, že Velký Bestseller, který píšete po večerech, bude údernější ve starší verzi a tu nemáte zálohovanou? Žádný problém – najděte si v okně vlastností na stránce Předchozí verze vyhovující záložní kopii a tu otevřete. Ve výchozím nastavení ukládá Obnova systému nový bod obnovy souboru jednou za den, v případě potřeby se dá bod obnovy vytvořit i ručně.

Změny ve volbách zabezpečení

OBRÁZEK 1.8: Stránka předchozí verze v dialogovém okně vlastností souboru

Změny ve volbách zabezpečení Zodpovídáte-li na svěřených počítačích také za jejich zabezpečení, dá se předpokládat, že jste už někdy v Editoru zásad skupiny (a to buď v lokálním nebo doménovém objektu) otvírali složku Konfigurace počítače  Nastavení systému Windows  Nastavení zabezpečení  Místní zásady  Možnosti zabezpečení. V této složce se nachází větší množství voleb, které umožňují posílit nebo zeslabit zabezpečení systému. Pokud byste všechny tyto volby vypnuli, vracíte se v podstatě do dob sítí NT, z hlediska zabezpečení asi tak do roku 1993: systém by byl velmi snadno napadnutelný, zato však kompatibilní se starými aplikacemi a operačními systémy. Zapněte všechny – a spustíte jen aplikace psané pro systémy XP, 2003 a Vista. Většina těchto bezpečnostních voleb jsou jednoduché přepínače zapnuto/vypnuto a má nastavenu určitou výchozí hodnotu, které stanovil Microsoft (a bylo to určitě obtížné rozhodování). Microsoft postupně zpřísňuje zabezpečení nejen s každou novou vydanou verzí Windows, ale i s každým Service Packem, proto by nikoho nemělo překvapit, že Vista nabízí nejen ty samé volby zabezpečení jako XP SP2, ale přidává k nim další a zpřísňuje nastavení některých voleb existujících. V této sekci probereme všechny volby, u kterých došlo ke změně, a podíváme se na to, jak tyto změny mohou ovlivnit nasazení Visty do produkčních sítí. TIP:

Není důvod k panice: ano, Vista skutečně „utahuje šrouby“ v některých oblastech zabezpečení, které zůstávaly delší dobu povolené, ale jedná se jen o změny v objektu místních zásad skupiny, které lze v případě potřeby snadno odvolat. Jestliže jste připojeni k doméně, která obsahuje objekt doménové zásady skupiny specifikující hodnoty ve složce Možnosti zabezpečení, budou mít tyto hodnoty přednost před lokálním nastavením

Kapitola 1 – Správa zabezpečení windows vista – drobná překvapení

systému Vista. Jedinou opravdu stinnou stránkou, kterou můžete zaznamenat při přehnaných ručních hrátkách s nastavením zabezpečení, budu projevy nevole Visty při pokusu o její první připojení do existující domény Active Directory (tyto problémy budeme probírat později).

POZNÁMKA:

Ještě než začneme, poslední stručná poznámka: pokud píšu, že se něco „změnilo oproti XP“ nebo „změnilo oproti Serveru 2003“, mám na mysli 32bitovou verzi XP a 2003. Uvádím to proto, že když jsem se podíval na výchozí nastavení objektu lokálních zásad skupiny své x64 pracovní stanice, všimnul jsem si, že některá „nová“ nastavení Visty se ve skutečnosti nachází již v 64bitové verzi XP a Serveru 2003.

Změny v přístupu k pojmenovaným rourám Pojmenované roury jsou jedním z prostředků pro vzájemnou komunikaci programů. Před mnoha lety byla většina pojmenovaných rour, vytvářených operačním systémem, zabezpečena velmi mizerně nebo vůbec ne. Velké množství úspěšných útoků hackerů na systémy Windows proběhlo právě přes špatně zabezpečené pojmenované roury. Už jen připojení k systému na účet „anonymous“ se dalo považovat přímo za široce otevřenou dálnici do niter systému. Tento – kdysi nepříliš známý – způsob připojení k mnoha protokolům firmy Microsoft je dnes bohužel totálně „profláknutý“ a jak vyplývá z jeho názvu, není přitom vůbec nutné znát jméno žádného uživatele ani jeho heslo; přihlásit se můžete jako anonym. Povolení přístupu do sítě Microsoft anonymním uživatelům není rozhodně šťastný nápad, faktem však zůstává, že kvůli zpětné kompatibilitě jsou ve Windows stále některé anonymní připojení možná. Microsoft pomalu anonymního uživatele ze systému odebírá – pokud si pamatuji správně, poprvé byla práva tohoto uživatele omezena v roce 1998 s nástupem NT 4.0 SP3. Jeho účet však stále existuje, Vista však jeho moc – a tím i hrozbu pro systém – značně redukuje změnami v oblasti pojmenovaných rour. Ve Windows – přinejmenším od verze XP – je k dispozici možnost zabezpečení s názvem „Přístup k síti: Povolit anonymní přístup k pojmenovaným kanálům“ (Network access: Named Pipes that can be accessed anonymously). V této možnosti je uveden seznam názvů systémových pojmenovaných rour, které jsou potřeba k tomu, aby měl anonymní uživatel přístup k systému. Implicitně jsou přitom v nastavení zásady skupiny mezi tyto roury zahrnuty i ty, které k ničemu nejsou: ■

COMNAP a COMNODE se objevují jen na serverech se spuštěným gateway programem Microsoftu pro komunikaci s mainframy IBM (jmenuje se Host Integration Server, HIS). Pokud je mi známo, HIS není možné spustit na žádném desktopovém operačním systému Microsoftu.

■

SQL\QUERY je k dispozici na systému se spuštěným Microsoft SQL Serverem nebo jeho ekvivalentem. Na Vistě je možné (i když to není příliš pravděpodobné) provozovat SQL Server 2005 Express Edition. Jak mi bylo řečeno, nebude možné na Vistě spustit předchůdce této aplikace, tzv. Microsoft Desktop Engine (MSDE). (pozn. překl. – MSDE skutečně „není podporováno“, ale dle technické podpory by „mělo jít nainstalovat.)

Změny ve volbách zabezpečení

■

LLSRPC se objevuje jen na serverech se spuštěnou službou Licensing Service. Proč Microsoft umožňuje anonymní přístup k této službě je záhadou, na desktopovém operačním systému by tato služba stejně neměla být nikdy v provozu.

■

BROWSER umožňuje systému fungovat buď jako hlavní nebo záložní browser na jeho podsíti; přes tuto rouru spolu hlavní a záložní backup komunikují. Pokud hlavní a záložní browser v rámci stejné podsítě nejsou členy stejné doménové struktury, musí být schopny přistupovat k rouře BROWSER anonymně, aby mohl hlavní browser poslat záložnímu browseru kopii svého seznamu členů v daném segmentu. Microsoft ponechal rouru BROWSER v seznamu povolených rour pro anonymní přístup kvůli tomu, aby bylo možné vytvořit hlavní a záložní browsery v rámci pracovní skupiny. V každém případě existuje pravděpodobnost (sice malá, ale přece jen), že půjde o desktopový operační systém; snadno si můžeme představit malou domácí pracovní skupinu, složenou jen z počítačů se systémem Vista. V takovém případě však půjde skoro určitě o síť s jediným segmentem, kde se překlad adres dá zajistit všesměrovými pakety.

Ve výchozím nastavení Visty pro zásadu „Přístup k síti: Povolit anonymní přístup k pojmenovaným kanálům“ jsou všechny tyto pojmenované roury odstraněny a zůstává povolen přístup jen k jediné rouře SPOOLSS. Ta spolupracuje s tiskovým spoolerem a v tomto případě jde o serverovou roli, která se běžně objevuje na desktopových operačních systémech. Proč Microsoft ponechal tak velké množství zbytečných pojmenovaných rour ve výchozím nastavení zásad skupiny pro XP? Očividně si trochu ušetřili práci a vytvořili sadu zásad, které mohli aplikovat na serverové i desktopové operační systémy. U Visty již tak líní nebyli a desktop získal své vlastní nastavení.

Změny ve sdílení a přístupu k systémovému registru Kriminálníci toužící nabourat se anonymně do nějakého systému mají k dispozici i jiné přístupové cesty než pojmenované roury. Systémy Windows mají vestavěny také nejrůznější sdílené zdroje, k některým z nich lze přistupovat i anonymně – či spíše šlo, protože teď je tu Vista. Windows XP ve výchozím nastavení povolovaly anonymní přístup ke dvěma sdíleným prostředkům, které jsou vyjmenovány v možnosti zabezpečení zásady skupiny s názvem „Přístup k síti: sdílené položky s povoleným anonymním přístupem“. Zde najdeme ve Windows XP jednak COMCFG, který se vztahuje k aplikaci Host Integration System, jednak DFS$, který je nutný u serverů, na kterých je hostován kořen DFS (distribuovaného souborového systému). Vzhledem k tomu, že na Vistě nemůže být umístěn ani HIS, ani kořen DFS, jsou obě položky ve Vistě vypuštěny a možnost zabezpečení „Přístup k síti: sdílené položky s povoleným anonymním přístupem“ je nyní prázdná. Další vstupní dálnicí pro zlé hochy je možnost načíst vzdáleně část systémového registru a z něj si zjistit bližší údaje o systému. Některé klíče registru přitom musí být přes síť přístupné, aby síťové služby a vzdálená správa mohly fungovat. Tyto klíče jsou vyjmenovány v možnosti zabezpečení s názvem „Přístup k síti: Vzdáleně přístupné cesty registru“. Zatímco na XP je tu uvedeno 9 klíčů, na Vistě jen 3.

Kapitola 1 – Správa zabezpečení windows vista – drobná překvapení

LM odchází do ústraní, prosazován je protokol NTLMv2 Osobně velmi oceňuji, že Vista mění také dvě další položky v Možnostech zabezpečení, ale rád bych vám nyní vysvětlil, co tyto změny mohou znamenat pro síťovou kompatibilitu vašich počítačů. Jedná se o tato dvě nastavení: ■ „Zabezpečení sítě: Neukládat hodnot hash systému LAN Manager při příští změně hesla“ – ta

je nyní zapnuta, i když až doposud byla vždy vypnuta. ■ „Zabezpečení sítě: Úroveň ověřování pro systém LAN Manager“ – ta je změněna z hodnoty

„Odeslat odpovědi LM a NTLM“ na „Odesílat pouze odpovědi NTLM verze 2“. Nejdřív trochu teorie. Myšlenka centrálních počítačů, kterým se říká řadiče domény (domain controllers, DC) a na kterých jsou uložena uživatelská jména a jejich hesla, aby je nemusely spravovat jednotlivé počítače, je nepochybně skvělá. Ovšem centrálně umístěné přihlašovací služby znamenají také to, že musíte nějak zajistit, aby jejich používání bylo skutečně zabezpečené. Budu-li sedět u pracovní stanice A a té sdělím své doménové jméno a heslo k tomuto účtu, jak se pracovní stanice A zeptá řadiče domény B, zda jsou zadané údaje správné? Rozhodně by nebylo vhodné, aby odeslala po síti nešifrovaný dotaz typu: „nazdar řadiči domény B, mám tady borce, který tvrdí, že se jmenuje Marek a jeho heslo je mečoun, je tahle kombinace oukej“? Vzhledem k tomu, že komunikace po síti se dá snadno odposlouchávat, by tento způsob ověřování byl opravdu mimořádně pitomý. Aby si řadiče domény a pracovní stanice navzájem nezasílaly tyto po linkách tajné údaje veřejně, implementoval Microsoft (a jiní dodavatelé) rafinovanější řešení. Když se pracovní stanice obrátí na řadič domény s dotazem „chci přihlásit do domény Marka, můžeš ověřit, že se mnou komunikuje skutečně Marek?“, odpoví mu na to řadič domény „Ano, heslo Marka znám, ty máš něco, co by mělo být Markovým heslem. Tady ti posílám náhodné hodně velké číslo. Zašifruj ho pomocí hesla, které ti sdělil Marek, a pošli mi zašifrovaný výsledek.“ Pracovní stanice převezme zaslané náhodné číslo, kterému se říká výzva (challenge), zašifruje ho (jako šifrovací klíč použije řetězec, který jí jako heslo předal ten, co se vydává za uživatele Marek) a výsledek čili odpověď (response) odešle řadiči domény. Mezitím si řadič domény rovněž zašifruje svou výzvu, a jako klíč použije heslo, které má uložené pro uživatele se jménem Marek. Pokud odpověď, která dorazí z pracovní stanice, souhlasí se zašifrovanou výzvou, je řadiči jasné, že heslo bylo na pracovní stanici zapsáno správně – a přitom není vůbec nutné toto heslo přenášet v nezašifrované podobě. To byl jen velmi stručný nástin toho, jak funguje tato metoda ověřování, označovaná pojmem „mechanismus výzva-odpověď“. Je tu spousta skrytých „ale“: složité šifrování se dá jen velmi těžce prorazit (to je dobře), ale vyžaduje to větší počet výpočetních cyklů procesoru; delší klíče se dají také velmi těžko prorazit, ale opět to znamená větší zátěž pro procesor a tedy i zpomalení vlastního procesu přihlašování (to není dobře), proto si dodavatel operačního systému musí dobře rozmyslet, jakou metodu šifrování a délku klíčů použije. Postupem doby Microsoft vytvořil celkem tři různé přihlašovací protokoly využívající mechanismus výzva-odpověď: na konci 80tých let minulého století nabídnul „LM“ neboli „LAN Manager“, který byl nahrazen začátkem 90tých let modernějším „NTLM“ (NT verze LAN Manageru) a na konci 90tých let vytvořil Microsoft mnohem lepší NTLMv2. Ve Windows 2000 se dále objevila metoda ověřování Kerberos, používaná většinou

Změny ve volbách zabezpečení

v Active Directory. Ale i sítě s nejmodernějšími technologiemi někdy zavrhnou Kerbera a používají LM, NTLM nebo NTLMv2. Není to moc potěšující, protože Kerberos je mnohem bezpečnější než ostatní tři uvedené mechanismy, ale neexistuje žádný způsob, jak „rodinu LM“ zcela potlačit. Jestliže však chcete svou síť zabezpečit co nejlépe, ověřte si, že v situacích, kdy Kerberos není dostupný, bude k ověřování totožnosti použit NTLMv2, nikoli starší a mnohem méně bezpečné mechanismy. Pokud je NTLMv2 na světle božím již skoro 10 let, proč všichni nepoužíváme právě tento protokol? Jak to, že LM a NTLM již dávno nezmizely v propadlišti dějin? Odpověď je stejná jako u jiných technologií: zpětná kompatibilita. Budou-li do sítě zapojeny nějaké starší systémy (například Windows 9x), dají se sice přinutit k používání NTLMv2, ale je s tím práce; systémy MS-DOS a Windows for Workgroup však prostě NTLMv2 nikdy umět nebudou. Obdobně je možné, že síťová zařízení od jiných výrobců, například některé typy NAS (Network Attached Storage, konkrétně mám na mysli třeba Quantum Snap Server), neumí protokol NTLMv2. Každá moderní kopie Windows umí ověřovat uživatele pomocí protokolů LM, NTLM nebo NTLMv2, kterou z těchto metod si ale ve skutečnosti systém vybere? To se dá nastavit v uzlu Možnosti zabezpečení, v klíči „Zabezpečení sítě: Úroveň ověřování pro systém LAN Manager“ Systém XP standardně šifruje zaslanou výzvu dvěma možnými způsoby a vytvoří dvě odpovědi: LM a NTLM. Vzhledem k tomu, že oba tyto algoritmy šifrování již byly v minulosti prolomeny a každý rok se pravděpodobnost jejich dalšího prolamování zvyšuje spolu s neustálým nárůstem výpočetní rychlosti CPU, je automatické odpovídání prostřednictvím protokolů LM a NTLM vhodné stále méně a méně. Implicitní nastavení Visty je proto změněno na protokol NTLMv2. Může tato nová výchozí hodnota vyvolat nějaké potíže? Odpovědi protokolu NTLMv2 umí zpracovat každý systém Windows 2000, XP, 2003 nebo Vista působící v roli serveru, takže pokud na stanicích s Vistou nastavíte odpovídání NTLMv2, mělo by být všechno v pořádku. Nezapomeňte si ale zkontrolovat všechna síťová zařízení, například ty malinké tiskové servery velikosti A5, díky kterým je možné tiskárnu umístit kamkoliv a zpřístupnit ji všem uživatelům po síti. Stejně jako u všech zpřísňujících procesů je velmi důležité otestovat správnou funkčnost systému po provedené změně. Vista dále posiluje zabezpečení systému tím, že je v ní zakázáno vytvářet tzv. „hashe LM“. Když v systému zapíšete heslo, počítač ho jako takové neukládá. Namísto toho aplikuje na heslo speciální matematickou (tzv. hashovací) funkci, která převede heslo nezávisle na jeho délce na 128bitové číslo. To je poté uloženo na počítači i na doménovém řadiči namísto původního hesla; říká se tomu hash hesla. Proč se to dělá tímto způsobem? Je to ochrana uživatele: jestliže by se někdo dostal k uloženému hashi, je téměř nemožné zjistit z něj původní heslo (pokud je systém správně navržen). Microsoft začal namísto hesel ukládat jejich hashe v LAN Manageru, tedy koncem 80. let 20. století, a této formě hashů (vytvářených a ukládaných LAN Managerem) se říká „LM hashe“. Při návrhu této metody ukládání LM hashů odvedl Microsoft vcelku dobrou práci a vytvořil – s ohledem na výpočetní sílu tehdejších počítačů – kvalitní hashovací systém, ale dopustil se jedné závažné chyby. LM hashe uživatelských hesel totiž umožňovaly na první pohled zjistit, zda původní heslo bylo kratší než osm znaků nebo ne. A když má takový zlý hoch jistotu, že si určitý uživatel zvolil heslo se 7 nebo méně znaky, hodně mu to pomůže při jeho další „práci“ (lámání takového hesla nezabere příliš mnoho času).

Kapitola 1 – Správa zabezpečení windows vista – drobná překvapení

V systému NT 3.1 (rok 1993) Microsoft použil jinou a mnohem bezpečnější hashovací funkci. Kvůli nutnosti zachovat zpětnou kompatibilit však systém NT při každé změně hesla vytváří a ukládá hashe dva: „LM hash“ a „NT hash“. Jestliže se crackerovi podaří stáhnout hashe, nemusí je prolamovat oba – stačí rozluštit LM hash a má heslo uživatele, NT hash k tomu vůbec nepotřebuje. Ukládání LM hashů je tedy z bezpečnostního hlediska něco jako volně položená láhev s nitroglycerinem, nicméně Windows XP i 2003 stále ve svém výchozím nastavení LM hashe vytvářejí. Ve větvi Možnosti zabezpečení byla ve Windows po léta zásada „Zabezpečení sítě: Neukládat hodnot hash systému LAN Manager při příští změně hesla“, ale Microsoft ji ponechal kvůli starším operačním systémům a síťovým zařízením zakázanou, protože by tito stařečci nemuseli fungovat, pokud by neměli přístup k LM hashům. Ve Vistě se toto nastavení mění. Osobně jsem LM hashe na své síti úplně vypnul již v roce 2002 a nikdy od té doby nebyly potřebné, takže se domnívám, že si toto můžete bez problémů dovolit i vy – ale opět zdůrazňuji nutnost vše pořádně přezkoušet. Vista je v tomto ohledu mnohem přísnější a jde o první verzi Windows, kde jsou LM hashe implicitně zakázány.

Už žádná varování o nepodepsaných ovladačích Snad každý, kdo po nějakou dobu pracoval na systémech Windows 2000, XP nebo 2003, musel alespoň jednou zavádět do systému ovladače pro nový typ hardwaru, nebo případně prováděl aktualizaci ovladače nějakého stávajícího zařízení. Velmi často jste přitom narazili na dialogové okno s naléhavě znějícím varováním, upozorňujícím na to, že se pokoušíte nainstalovat ovladač, který nebyl podepsán v technické laboratoři Microsoftu s názvem Windows Hardware Quality Labs (WHQL). Tento dialog byl vymyšlen asi proto, aby vám řekl: „pokus o instalaci neprověřeného ovladače je nebezpečný, ale žijete ve svobodné zemi a můžete si samozřejmě dle libosti zničit svůj operační systém – ale pak neříkejte, že jste nebyli varováni“. Neuvádím tu přesný text toho dialogového okna, ale jeho smysl jsem zachoval. Ve WHQL laboratoři Microsoftu vznikla pravidla, která je třeba dodržet při psaní ovladačů nebo jiného softwaru obsahujícího kód pracující na nízké úrovni (úrovni jádra). Jestliže vývojář tato pravidla při psaní ovladače dodrží a poté si zakoupí digitální certifikát, kterým ovladač podepíše, může ho odeslat do WHQL laboratoří Microsoftu, kde otestují jeho kompatibilitu. (Od srpna 2006 stojí tyto testy 250 dolarů za každý ovladač a testovaný operační systém; varianta „XP“ pokrývá všechny druhy XP, čili za otestování ovladačů na systémech XP a 2003 zaplatíte 500 dolarů. Podrobnější informace najdete v dokumentu „Global WHQL Policies Document“ na adrese http://www.microsoft. com/whdc/whql/policies/default.mspx.) Pokud ovladač zvládne testy úspěšně, WHQL ho podepíše certifikátem Microsoftu. Při instalaci ovladače do Windows pak systém nezobrazuje zmíněné varovné dialogové okno. Většina dodavatelů hardwaru nijak zvlášť netouží platit Microsoftu 250 dolarů při každé aktualizaci svého ovladače, a proto se smířili s tím, že při instalaci bude toto varovné okno zobrazeno. Upřímně řečeno, nemám dost poznatků o tom, jak důkladně jsou testy WHQL prováděny, abych mohl vyjádřit názor na to, zda celá tato procedura není jen další příjem dolárků pro Microsoft nebo skutečně přínosný proces. V každém případě existuje jen jeden důvod, proč jste na svém monitoru tyto varovné dialogy viděli: aktuální hodnota možnosti zabezpečení „Zařízení: chování při

Novinky v oblasti šifrování

instalaci nepodepsaného ovladače“. Na systémech 2000, XP a 2003 tu jsou k dispozici tři možné hodnoty: „Nepovolit instalaci“, „Zobrazit upozornění a povolit instalaci“ a „Povolit bez upozornění“ Implicitní hodnota byla „Zobrazit upozornění a povolit instalaci“. Když se však budete chtít podívat na tuto možnost zabezpečení ve Vistě, nenajdete ji, Microsoft ji úplně odstranil, a to proto, že nasadil tvrdou linii a u 64bitových verzí bude vyžadovat, aby všechny ovladače bez výjimek byly digitálně podepsány v laboratořích WHQL. To je podle mne velmi přísný požadavek, a podotýkám, že jsem v tomto případě přímo zainteresován – 64bitovým systémům dávám přednost a tato záležitost s ovladači je jedním z pěti hlavních důvodů, proč se mi asi nezdaří nasadit Visty do svých sítí tak rychle, jak bych si přál. V každém případě se k ovladačům ještě vrátíme podrobněji v šesté kapitole. Ale ještě moment – uvedená volba zabezpečení je pryč, 64bitová Vista vyžaduje digitální podpis ovladačů … a co 32bitová? Inu, pokud se týká 32bitové verze Visty, je to podle Microsoftu poslední 32bitový operační systém , který tato firma vytvořila. Z toho odvozuji, že u ní nebudou klást až tak razantní důraz na zabezpečení (které je důvodem pro povinné testování a podepisování ovladačů) a prostě ve 32bitové Vistě povolí tichou instalaci nepodepsaných ovladačů. Podle mne je to změna k lepšímu, protož jsem nikdy neviděl nikoho, kdo by se uvedeného dialogového okna leknul a zrušil instalaci ovladače, a viděl jsem také několik těchto dialogů u nedoprovázených (!) instalací.

Novinky v oblasti šifrování Zabezpečení se neobejde bez šifrování, a v operačních systémech Microsoftu (s výjimkou MS-DOS) se nejméně jeden druh šifrování vyskytuje d doby vydání OS/2 1.0 v roce 1987. Postupem doby se však typy vestavěného šifrování a způsob jejich využití liší. Podívejme se na to, co nového se v této oblasti objevilo v systému Vista.

Vista obsahuje nové kryptograﬁcké služby Každý dodavatel softwaru si někdy musel vybrat, zda zkusí vytvořit svůj vlastní šifrovací algoritmus nebo koupí/použije již existující standardní algoritmy. Na první pohled se může zdát, že b pro výrobce bylo vhodnější napsat si vlastní šifrovací algoritmus a udržet jeho princip činnosti v tajnosti, ale bezpečnostní expert Bruce Schneier uvádí ve své knize Secrets and Lies: Digital Security in a Networked World (vydavatelství Wiley, 2000), že namísto vytváření šifrovacích algoritmů, studovaných a pečlivě testovaných hrstkou zasvěcenců je vhodnější používat algoritmy kontrolované stovkami matematických expertů. Ve své knize Schneier poukazoval právě na Microsoft s tím, že každý pokus této firmy o vytvoření proprietárního kryptografického algoritmu skončil během několika měsíců jeho prolomením. Nevím, jestli k tomu došlo skutečně vždy, ale určitě se to stalo mnohokrát. Nejspíše proto Microsoft stále více a více používá standardní kryptografické algoritmy. (Že by četli Schneierovu knihu?) Nejdříve vás určitě napadnou SHA (Secure Hashing Algorithm) a AES (Advanced Encryption System); oba byly vyvinuty pod záštitou národního institutu pro standardy a technologie USA (NIST) s cílem poskytnout veřejnosti kvalitní sadu algoritmů pro hashování (SHA) a šifrování (AES). Algoritmus AES je v komunitě kryptografů považován za kvalitní dílo, ale SHA již byl několikrát

Kapitola 1 – Správa zabezpečení windows vista – drobná překvapení

ve speciálních případech prolomen. V době psaní této knihy však poslední verze SHA s názvem „SHA-2“ pořád úspěšně odolávala všem útokům. Microsoft přidal algoritmus AES do Windows XP v jeho prvním Service Packu a do Serveru 2003 již od počátku, ale používal ho jen omezeně; pokud si vzpomínám, konkrétně v XP byl AES používán jen v rámci šifrovaného souborového systému EFS (Encrypting File System). Ve Vistě přibude podle Microsoftu možnost používat AES v kombinaci s protokolem IPSec. Není to nic světoborného, dříve bylo možné IPSec šifrovat sice jen algoritmem Triple DES (Data Encryption Standard), k jehož prolomení pravděpodobně ještě po nějakou dobu nedojde, ale určitě je to krok vpřed. Přidání SHA-2 do protokolu IPSec bude rovněž přínosné, ale chci poznamenat, že během psaní této knihy se nikde v editoru zásad skupiny neobjevovaly žádné volby pro použití AES ani SHA-2. Mohu však potvrdit, že AES se objeví v jiné nové technologii Windows, a to v šifrování celých diskových oddílů BitLocker (dostupné přitom budou dvě varianty, 128 a 256bitové šifrování). O technologii BitLocker se dozvíte více v páté kapitole.)

Šifrovat se dá i odkládací soubor Pro úplné paranoiky mám jednu výtečnou zprávu: zašifrovat si ve Vistě můžete i odkládací soubor. Ale osobně vám radím – nedělejte to. Rozhodně se tomu vyhněte, pokud nechcete čekat přibližně hodinu při spuštění počítače, dokud systém nedešifruje odkládací soubor, jehož velikost se bude pohybovat někde kolem jednoho gigabajtu.

Složky oﬄine souborů jsou šifrovány pro každého uživatele zvlášť Offline soubory jsou výtečným nápadem, který umožňuje lokálně ukládat v mezipaměti data z často používaných sdílených složek. Poprvé se objevily ve Windows 2000, a přestože nejsou určeny pro každého, velké množství lidí si je oblíbilo. Ale jakmile se objevily podrobnější informace o principu fungování offline souborů, bylo zřejmé, že v sobě skrývají určitou díru v zabezpečení. Ve Windows 2000 byly všechny tyto soubory mezipaměti uloženy v adresáři, kde si je mohl prohlížet každý uživatel systému. Pokud jste tedy nepracovali na počítači sami a měli byste vytvořené své offline soubory, mohl by se vám v jejich složce kdokoli (kdo sdílí stejnou složku) hrabat – a to by rozhodně nebylo dobré. Ve Windows XP začal Microsoft složku s uloženými offline soubory šifrovat. Šifrovací proces byl ovšem implementován jako služba běžící pod účtem LocalSystem, což znamenalo, že šifrovací klíč EFS pro data v offline souborech mohl snadno použít každý program, běžící pod tímto účtem. A jak bohužel ukázalo, že přihlášení k tomuto účtu nesmírně jednoduché – stačí pomocí příkazu at.exe spustit příkazový řádek. Vzhledem k tomu, že plánovač úloh běží pod účtem LocalSystem, obdržíte příkazový řádek spuštěný pod stejným účtem – cracknutí offline souborů a čtení dat jiného uživatele na stejném systému tak bylo pořád relativně snadnou záležitostí. Vista toto chování mění na dvou místech. Za prvé, soubory mezipaměti každého uživatele jsou ukládány spolu se svým klíčem EFS, ne s klíčem účtu LocalSystem. Za druhé, i kdyby toto Microsoft nezměnil na úrovni operačního systému, dala by se tato díra mnohem hůře zneužít, protože je značně ztíženo přihlášení pod účtem LocalSystem. Veškeré triky, které jsem v tomto směru znal a používal v dřívějších dobách na starších systémech, už na Vistě nefungují!

Nový Prohlížeč událostí

Nový Prohlížeč událostí A nyní jedno pěkné překvapení: Prohlížeč událostí byl kompletně přepsán a ve své nové podobě: ■

Dokáže shromáždit události z mnoha systémů do jednoho systémového protokolu, což umožňuje centralizovat protokoly událostí na jedno místo.

■

Umožňuje snadno definovat, co se má stát v případě výskytu určité události, například odeslat e-mail, spustit program, restartovat systém apod.

■

Dovoluje vytvářet vlastní dotazy, pomocí kterých se dá změnit vzhled prohlížeče událostí tak, aby v něm byly vidět jen ty věci, které skutečně chcete vidět.

■

Generuje svoje data ve formátu XML.

Rozsah této knihy nedovoluj probírat nový Prohlížeč událostí podrobně, rád bych vám však ukázal něco z toho, co se vám dle mého názoru na novém prohlížeči bude líbit nejvíce, a to sestupně podle důležitosti z mého hlediska. Než se vak do těchto novinek pustíme, řekneme si ještě, jak se Prohlížeč událostí spouští. Stejně jako u jiných programů pro Windows je k dispozici několik možností. ■

Pokud jste si na základě mé předchozí rady zpřístupnili položku Spustit v nabídce Start, stačí tento příkaz spustit, zapsat do jeho dialogu eventvwr a klepnout na tlačítko OK.

■

Jestliže jste si do nabídky Start přidali Nástroje pro správu, klepněte na ně a poté vyberte Prohlížeč událostí.

■

Třetí možnost je zdlouhavější, protože musíte jít do Ovládacích panelů: klepněte postupně na Start  Ovládací panely  Systém a údržba, a poté v části „Nástroje pro správu“ na „Zobrazit protokoly událostí“.

Jak již někteří poznamenali: „Vistu tvoří 10 nejoblíbenějších uživatelských rozhraní vůbec.“

V Prohlížeči událostí se objevil i formát XML Hurá, XML! Počkat, moment, neobracejte stránku … Ano, určitě jste všichni v posledních letech slýchali zkratku „XML“ až příliš často, ale tady jde o případ, kdy se vám její nasazení určitě líbit bude. Podívejme se na ukázkovou, jednoduchou udáOBRÁZEK 1.9: Typická událost systému Vista

Kapitola 1 – Správa zabezpečení windows vista – drobná překvapení

lost zabezpečení, která ohlašuje, že došlo k úspěšné změně systémového času. Událost v grafické podobě zachycuje obrázek 1.9. Jde o událost generovanou v protokolu zabezpečení, protože jsem se právě přihlásil na účet „Marek“. Nejdřív si určitě všimnete toho, že Prohlížeč událostí tuto událost zobrazuje v jiném formátu než jak jsme byli zvyklí již od dob NT 3.1. Dále si všimněte vlevo dole tlačítka „Kopírovat“, což je rozhodně lepší než tlačítko s dvěma listy papíru ve starším prohlížeči událostí, kdy jste si jeho význam „klikni na mne, aby se důležité informace z této události zkopíroval v textovém formátu ASCII do schránky Windows“. Celý text události na obrázku není vidět, protože je dost dlouhý a zasahuje mimo viditelnou část okna, uvádím proto alespoň jeho část: Tato událost je generována po vytvoření relace přihlášení. Je generována v počítači, ke kterému byl získán přístup. Pole s předmětem označují účet v místním systému, který požadoval přihlášení. Jedná se nejčastěji o službu, například službu serveru nebo místní proces, například Winlogon.exe nebo Services.exe. Pole Typ přihlášení označuje, k jakému typu přihlášení došlo. Nejběžnější typy jsou 2 (interaktivní) a 3 (síť). Pole Nové přihlášení označují účet, pro který bylo nové přihlášení vytvořeno, tj. účet, který byl přihlášen.

Na „typ přihlašování“ jsem se v událostech přihlášení uvnitř Windows díval celé roky a nikdy mne nenapadlo se podívat, co se tímto pojmem vlastně myslí. Windows Vista mi to ve srovnání s XP řeknou samy. Nezkopíroval jsem do knihy všechny informace z dané zprávy, ale mělo by to stačit k vysvětlení toho, co je přihlašovací GUID, název balíčku a pár dalších, na první pohled záhadných pojmů. Super. V jiné události, ohlašující změnu systémového času, už vysvětlující komentář v podstatě říká jen: „nazdar, aktualizace systémového času proběhla normálně, s největší pravděpodobností toto můžeš ignorovat. Existují ale důvody, proč se zlí hošani mohou pokoušet změnit systémový čas“. Pokud na tlačítko Kopírovat klepnete a vložíte text ze schránky do Poznámkového bloku, uvidíte v něm velké množství informací. Začátek vypadá podobně jako staré dobré protokoly událostí, takže tu máme napsáno, co je zdrojem události, její ID atd. Poté začne vlastní halda XML, která ve zkrácené podobě vypadá asi takto: <Data <Data <Data <Data <Data <Data

Name="TargetUserSid">S-1-5-21 …-1000</Data> Name="TargetUserName">mark</Data> Name="TargetDomainName">VISTA64</Data> Name="TargetLogonId">0x20788</Data> Name="LogonType">2</Data> Name="LogonProcessName">User32 </Data>

Co má tato směsice znamenat? Jsou to prostě různá data, týkající se této konkrétní položky protokolu událostí. Tyto informace byly v položkách protokolu uchovávány vždy, ale jejich užitečnost byla zanedbatelná, a to ze dvou důvodů. Za prvé, případný export těchto dat z protokolu (aby je

Nový Prohlížeč událostí

bylo možné využít ve skriptech nebo jiných podomácku udělaných pomůckách) by byl velmi obtížný, a za druhé nebylo moc známo, co tato data vlastně znamenají. Dal by se sice snadno napsat skript, který by ze zadané události vytáhnul „datovou položku 1“, „datovou položku 2“, „datovou položku 3“ atd., ale co to je, ta „datová položka 1“? Inu, v tomto případě záleží na konkrétní zkoumané události. U Visty však tento zmatek již neplatí. Data jsou ukládána ve formátu XML a dá se k nim snadno přistupovat jak ze skriptů, tak přímo v Prohlížeči událostí – stačí pravým tlačítkem myši klepnout na libovolnou položku a vybrat v místní nabídce příkaz „Uložit vybrané události“. Poté si můžete vybrat cílový formát: v nabídce jsou kromě výchozího formátu .evtx ještě textové soubory, soubory XML a soubory CSV (hodnoty oddělené čárkou). Výhodou formátu XML je to, že se ukládají nejen data, ale i popisné informace, které je blíže identifikují. To je ta pravá krása XML; řádek <Data Name="TargetUserName">marek</Data>

je možné z XMLštiny do češtiny přeložit takto: „toto je kus dat v této události s názvem „TargetUserName“ a jejich hodnota je „marek“. Data však není nutné exportovat, prohlížet se dají i přímo v dialogovém okně události, kde stačí klepnout na stránku Podrobnosti a poté uvidíte asi to, co je na obrázku 1.10 I tento letmý pohled ukazuje (za to vám ručím), že uvedené novinky určitě vyvolají nadšení mezi autory mnoha propracovaných nástrojů pro správu protokolu událostí. Přitom ale šlo o tu nejméně zajímavou část ze tří novinek, které bych rád probral v této části věnované Prohlížeči událostí; nezdržujme se tedy a vyražme dále.

Vlastní dotazy dovolují přizpůsobit si Prohlížeč událostí na míru V Prohlížeči událostí bylo vždy možné jednoduše filtrovat počet zobrazených položek: po klepnutí pravým tlačítkem myši někde v ploše prohlížeče se v místní nabídce vybral příkaz „Nové zobrazení protokolu“ a poté stačilo upravit vlastnosti filtru. Prohlížeč událostí ve Vistě je však trochu propracovanější. V čem? Podívejte se na obrázek 1.11, kde vidíte tuto aplikaci po jejím spuštění. OBRÁZEK 1.10: Podrobnosti o položce protokolu událostí

Kapitola 1 – Správa zabezpečení windows vista – drobná překvapení

OBRÁZEK 1.11: Prohlížeč událostí

Stejně jako ve starší verzi prohlížeče je vlevo panel se seznamem protokolů, se kterými můžete pracovat. Namísto standardního seznamu Aplikace, Systém a Zabezpečení však Prohlížeč událostí ve Vistě rozčlení všechny události do desítek menších „pod-protokolů“. Souhrnné informace jsou uvedeny v pravém panelu, ve kterém si rychle všimnete toho, že tu jsou údaje členěny do více úrovní. Kromě dobře známých úrovní Informace, Upozornění, Chyba, Úspěch auditu a Selhání auditu je tu nyní také Kritická. Podívejte se ale do levého horního rohu – tam uvidíte složku s názvem „Vlastní zobrazení“ a uvnitř ní složku s názvem „Události správy“. Tyto složky jsem nevytvářel, jsou již do Visty zabudovány. V nich jsou shromážděny všechny události ze všech protokolů, které patří do kategorií Kritická, Chyba nebo Upozornění. Je to tedy nástroj pro rychlou kontrolu toho, co se kde pokazilo. Co však má dělat ten, kdo se zajímá jen o kolekci „kritických“ položek? Prakticky nic – stačí mu klepnout pravým tlačítkem myši na složku Custom Views a vybrat v místní nabídce položku „Vytvořit vlastní pohled“. Poté se objeví dialogové okno z obrázku 1.12. V tomto dialogu je ihned patrné, jak Microsoft vytvořil pohled „Události správy“. Chcete-li vytvořit náhled jen pro „kritické“ položky, je třeba dialogové okno upravit následujícím způsobem: ■

Ponechte v rozvíracím seznamu „Protokolován:“ nastavenu položku Kdykoli, abyste viděli všechny události v protokolu. (Ve výchozím nastavení Windows uchovávají jen tolik událostí, na kolik mají místo.)

■

V části „Úroveň:“ zapněte jen políčko „Kritická“.

■

Zapněte jeden z přepínačů „Podle protokolu“ a „Podle zdroje“, a poté klepněte na rozvírací seznam vpravo od nich. Zapnutím políček „Protokoly systému Windows“ a „Protokoly aplikací a služeb“ vyberete všechny protokoly.

Nový Prohlížeč událostí

■

Klepněte na tlačítko OK a dialogové okno s hlášením o možné delší době trvání operace potvrďte tlačítkem „Ano“. Poté se objeví dialogové okno z obrázku 1.13.

OBRÁZEK 1.12: vytvoření vlastního pohledu v Prohlížeči událostí OS Vista

OBRÁZEK 1.13: Název pro nový vlastní pohled

Zde jsem do pole Název zapsal „Jen kritické“ a do pole Popis „Zobrazuje kriticky důležité události ve všech administrativních protokolech“. Po klepnutí na tlačítko OK uvidíte nový pohled. (Mimochodem, nejedná se o bezvýznamnou ukázku. Již po několika dnech vyprodukoval můj systém Vista tisíce položek v protokolu událostí s různými stupni důležitosti. Pohled „Jen kritické“ však obsahoval jen pár desítek událostí a všechny z nich pro byly zajímavé. (Mezi oblíbené jsem si zařadil především zprávu o tom, že určitý program „zpomaluje Windows Shell“ což mělo asi znamenat, že když tento špatně napsaný program vypnu, systém se zrychlí. Chcete vědět název toho vadného programu? Explorer.exe. A pak že programátorům schází smysl pro humor …)

Kapitola 1 – Správa zabezpečení windows vista – drobná překvapení

Jakmile vytvoříte vlastní ideální pohled, můžete ho snadno zálohovat nebo šířit dále. Příkaz pro export pohledu najdete v položkách místní nabídky. Zkusíte si tipnout, v jakém formátu bude pohled exportován? Ano, správně: XML. (Možná by v Microsoftu mohli pouvažovat o tom, zda by nebyl pro Vistu vhodnější název „Windows XML“? Název by tak víc připomínal upgrade z XP.)

Generování akcí z událostí Windows XP a 2003 jako první obsahovaly jednu pěknou věcičku: „spouště událostí“ (event triggers). Šlo o to, že správce mohl prostřednictvím jedné pomůcky příkazového řádku eventtriggers. exe přikázat službě protokolování událostí, aby spustila určitou aplikaci, pokud se vyskytne určitý druh události. Spouště událostí pravděpodobně nevyužívá mnoho lidí, ale já jsem o nich publikoval několik článků v časopisech, kde jsem je doporučil jako vhodný prostředek pro ohlašování problémů se sítěmi. Spouště událostí se ukuchtily ze tří ingrediencí: ■

Potřebujete mobilní telefon, schopný přijímat SMS přes e-mail. Já mám například mobilní telefon Verizon Wireless: do této sítě se dá zaslat SMS tak, že odešlete e-mail na adresu číslotelefonu@vtext.com.

■

Potřebujete aplikaci, která umí odesílat jednoduché e-mailové zprávy z příkazového řádku. Z těch, které jsou zdarma, uvádím například blat (http://www.blat.org).

■

Musíte mít systém Windows XP nebo 2003, na kterých jsou spouště událostí podporovány.

Jestliže se v systému vyskytnou události, které vás coby správce musí zajímat – například uzamčení nějakého účtu – můžete prostřednictvím nástroje eventtriggers.exe přikázat službě Protokol událostí, aby spustila přesně zadaný příkazový řádek, kterým pomůcka blat odešle administrátorovi (tedy vám) varování ve formě SMS přímo na mobilní telefon. Fungovalo to celé velmi pěkně, ale ovládání bylo hodně těžkopádné. Takže nová volba „Přidružit k této události úlohu“ je skutečným požehnáním. Chcete-li vidět, jak tato novinka funguje, otevřete aplikační protokol a podívejte se na události, které jsou v něm zapsány. Pokud máte Prohlížeč událostí spuštěn poprvé, najděte složku „Protokoly systému Windows“ – měla by být již otevřena; pokud ne, otevřete ji – a všimněte si, že v této složce kromě známých názvů Aplikace, Zabezpečení a Systém jsou také dvě nové podsložky s názvy Instalace a „Předané události“. V levém panelu klepněte na složku Aplikace a poté v pravém panelu (panel Akce si vždy zavřu, protože na to, aby se mi na obrazovku pohodlně vešly všechny tři panely konzoly MMC 3.0, bych potřeboval panoramatický monitor – a takové se zatím nevyrábějí) poté uvidíte události z daného protokolu. Pravým tlačítkem myši klepněte na libovolnou z položek a v místní nabídce uvidíte novou volbu „Přidružit k této události úlohu“; tu odklepnete a tak spustíte z obrázku 1.14. Proč průvodce? Jak se za chvíli ukáže, Prohlížeč událostí ve Vistě nabízí několik možností, jak reagovat. (Dokonce je zjednodušeno nastavení pro odesílání e-mailových zpráv administrátorovi, o kterém byla řeč před chvílí.) Tlačítkem Další pokračujte na stránku z obrázku 1.15. Za prvé lze specifikovat určitou aplikaci, která bude spuštěna (obdobně jako u staršího eventtriggers.exe). Dále je možné odeslat e-mailovou zprávu a třetí volbou je zobrazení zprávy na pracovní ploše serveru. Ukážeme si tu postupně všechny tři volby, ale nyní zůstaneme

Nový Prohlížeč událostí

u druhé z nich: zapneme přepínač „Odeslat e-mail“ a tlačítkem Další se přesuneme na stránku z obrázku 1.16. OBRÁZEK 1.14: Spuštění Průvodce vytvořením základní úlohy

OBRÁZEK 1.15: Prohlížeč událostí nabízí tři typy reakcí na vznik události.

Kapitola 1 – Správa zabezpečení windows vista – drobná překvapení

OBRÁZEK 1.16: Nastavení e-mailové zprávy o vzniku události

Stránka vypadá vcelku dle očekávání, je na ní možné nastavit adresu odesílatele a příjemce, předmět a text zprávy. Dále se tu dá přidat ke zprávě i příloha, což je milá pozornost, a určit, který server SMTP zprávu odešle. VAROVÁNÍ:

Nezapomeňte nastavit server SMTP tak, aby přijímal zprávy zaslané z daného počítače, jinak vám zaslaná varování nikdy nedojdou. Všechny kvalitně nastavené servery SMTP mají dnes přesně určená pravidla týkající se SMTP relaye a je vysoce pravděpodobné, že bez úpravy jejich nastavení zaslané varování o vzniku události zahodí. A vůbec neuvažujte o zřízení zvláštního serveru SMTP, na kterém by zmíněná přísná pravidla neplatila, protože takové servery jsou pro spammery ideálním zdrojem pro rozesílání jejich nevyžádaných zpráv, aniž by se museli obávat, že budou dopadeni.

Obrázek 1.17: Souhrnné informace o nové spoušti Zde je stručný souhrn všeho, co se stane po klepnutí na tlačítko Dokončit, i když podle mého není nutné tyto údaje opakovat. Správce může každou úlohu události dodatečně změnit nebo ji odstranit. Ale kde se tyto dodatečné úpravy provádí, to vás asi překvapí. Po klepnutí na tlačítko Dokončit se objeví okno hlášení z obrázku 1.18.

Nový Prohlížeč událostí

OBRÁZEK 1.17: Souhrnné informace o nové spoušti

OBRÁZEK 1.18: Chcete úlohu změnit? Najdete ji v Naplánovaných úlohách

To se mi moc nelíbí, nepovažuji to za šťastné řešení. Do uživatelského rozhraní Visty vložil Microsoft dost práce, aby v něm poskytnul uživatelům co největší možnou „rozpoznatelnost“ (discoverability), což je jejich nedávno vynalezený pojem pro „uživatelské rozhraní, ve kterém uživatel snadno odhadne, co se dá s GUI programem všechno udělat“. Zde ovšem vytvoříme úlohu události v Prohlížeči; člověk by tedy očekával, že ji bude moci upravit nebo změnit opět v Prohlížeči událostí. Ale ne, Microsoft vás směruje do Naplánovaných úloh, jinde se to provést nedá.

Jak přikázat službě Protokol událostí zobrazovat hlášení V předchozím textu jsem dal přednost volbě po odeslání e-mailu, Prohlížeč událostí ve Vistě však nabízí ještě dvě další volby, jak je vidět na obrázku 1.17. Volba „Spustit program“ je jasná, tu není nutné nijak zvlášť rozebírat, ale chtěl jsem tu probrat poslední volbu „Zobrazit zprávu“. Na první pohled se zdá být rovněž velmi jednoduchou; zadáte jí, jaký text se má zobrazit a když se odpovídající událost vyskytne, služba Protokol událostí vygeneruje okno hlášení se zadanou zprávou. Existence této volby ve mně ale zpočátku vyvolávala rozpaky. Je tato možnost skutečně k něčemu? Pak mi to došlo.

Kapitola 1 – Správa zabezpečení windows vista – drobná překvapení

Už od svého seznámení se systémy NT mám problémy zvyknout si na „úrovně ukecanosti“ těchto operačních systémů. Strávil jsem celé roky prací na různých mikropočítačových operačních systémech, navržených tak, aby v případě vzniku problémů (i těch zanedbatelných) byl uživatel určitě informován, a to okamžitě, přičemž bylo použito přinejmenším klasické okno hlášení a přinejhorším systémově modální dialog, který není možné ani minimalizovat, ani zmenšit. Windows se ve skutečnosti někdy stále chovají takto, ale jejich chování je dost nevyrovnané. Pokud třeba nejde něco vytisknout, ohlásí vám to systém nepřehlédnutelným způsobem v oznamovací oblasti hlavního panelu. Aplikace pro Windows jsou stejně tak špatně navrženy jako samotný systém, a jako prvotřídní ukázku tu poslouží třeba Adobe Acrobat Reader. Pokud se tento program rozhodne, že je nutná jeho aktualizace, umístí prostě doprostřed obrazovky velký dialog se stavovými údaji, ve kterém chybí tlačítko Minimalizovat a hotovo. Co mě však vždy dokázalo spolehlivě vytočit, je skutečnost, že tato ukecaná Windows přede mnou zatajují některé údaje, které jsou přitom velmi užitečné. Před pár lety jsem například měl počítač, u kterého odešel pevný disk. Podařilo se mi ho udržet v chodu dostatečně dlouho na to, abych z něj stačil zachránit vše potřebné, a během čekání na dokončení procesu kopírování souborů jsem si všimnul, že v protokolu událostí jsou už po dobu několika týdnů generovány potíže při zápisu na disk. „To mi ta mrcha nemohla dát nějak najevo?“ zahudral jsem si tehdy. Obdobně existuje velké množství událostí Active Directory, které jsou vysloveně děsivé, věci jsoucí předzvěstí dlouhotrvajících problémů a neštěstí, pokud nejsou velmi rychle napraveny … ale služba Active Directory vám o tom neřekne. Namísto toho jen potichu zapíše událost do protokolu, což odpovídá nespokojenému pracovníka, který si dělá poznámky o tom, jak jeho firma pomalu a neodvratně směřuje ke krachu, a teprve když se z ní skutečně stane další Enron, vytáhne své zápisky a vykřikuje „já to věděl“. (Umím si ale představit, že tvůrci Active Directory předpokládají – možná oprávněně – že u většiny řadičů domény nesedí někdo 24 hodin denně a nesleduje protokoly.) Proč tedy Windows trpí touto schizofrenií a něco okamžitě vykřičí do světa, zatímco o jiných věcech mlčí? Je to jednoduché: u Microsoftu totiž neexistuje centrální Výbor pro schvalování zobrazovaných zpráv v uživatelském rozhraní. Jestliže se Jana Nějaká věnuje klientu pro sdílení souborů a Petr Někdo píše modul na úrovni shellu pro detekci nového hardwaru (což je ta věc, která se vás ptá „co mám dělat“ při každém zasunutí USB zařízené do některé zásuvky v počítači), platí pravidlo, že si Jana Nějaká sama určí, co všechno vám klient pro sdílení souborů řekne a co ne, a obdobně Petr Někdo řídí úroveň hysterie svého modulu. (Podle mého názoru by Petr Někdo měl omezit pití kávy, protože jeho modul se ptá na můj vkus moc často.) Co je na volbě „Zobrazit zprávu“ tak skvělé? Fakt, že umožňuje zvýšit hladinu hysterie Windows v případě výskytu libovolné události (nebo událostí), kterou(é) si zvolíte. Díky tomu už nikdy nezažiji náhlou závadu pevného disku, která byla předtím potichu ohlašována zápisy do protokolu událostí, a až se objeví Server 2007 se stejně nově předělaným Prohlížečem událostí, už nikdy nepřehlédnu určité typy zpráv, které signalizují, že některý z řadičů domény několik týdnů nekomunikuje s okolím.

Nový Prohlížeč událostí

Předávání událostí mezi počítači Nemusím doufám vysvětlovat, proč si myslím, že moje nejoblíbenější novinka v Prohlížeči událostí se velmi rychle stane běžným pracovním nástrojem ostatních správců: ano, teď bude řeč o předávání událostí. Až doposud vždy platilo, že systémy NT měly protokoly událostí, které byly úplně decentralizované: jestliže jste ve firmě měli 500 počítačů s Windows XP, a někdo se postupně pokoušel proniknout na všechny stroje, bylo třeba prověřit záznamy o všech neúspěšných pokusech o přihlášení na všech 500 počítačích … jak se toto dá co nejefektivněji udělat? Buď jste těch 500 počítačů poctivě obešli, nebo jste zakoupili specializovaný nástroj od nezávislých výrobců, anebo se obrátili na velmi dobře použitelný a zdarma dostupný nástroj eventcombmt (jeho nevýhodou je ale velká neohrabanost). Je to dost překvapující, ale po 13 letech vývoje NT stále správci nemají k dispozici žádný vestavěný nástroj pro centrální uložení a vyhodnocení událostí z protokolů různě rozmístěných počítačů. Pokud si ovšem nakonec pořídí systém Vista, mají vyhráno. V něm je totiž obsaženo tzv. „předávání událostí“ (event forwarding), sloužící ke shromáždění událostí z různých počítačů s tímto systémem do jediného centrálního stroje. Proto dnes stačí na všech 500 počítačích nastavit odesílání událostí o neúspěšných přihlášeních k systému na jeden z těchto strojů, a pak už stačí si jen k danému stroji sednout, otevřít složku „Předané události“ … a jste ihned v obraze. Platí to jenom pro počítače s nainstalovanou Vistu? Zúčastnil jsem se jedné konference, kde vedoucí oddělení pro vývoj Prohlížeče událostí Visty prohlásil, že se počítá s vývojem modulů pro starší operační systémy Windows (předpokládám XP a 2003), které by umožnily předávat události z těchto starších systémů na počítač s Vistou. Proto na otázku ze začátku odstavce odpovídám: „ano, prozatím to platí jen pro Vistu, ale můžeme doufat, že i na starších verzích Windows se objeví předávače událostí“. Ovšem pozor, není to tak jisté. V roce 2002 Microsoft slíbil volně dostupný nástroj pro sběr všech událostí z protokolu zabezpečení na systémech 2000, XP a 2003, které měly být ukládány do centrálního SQL Serveru. Když byl tento nástroj koncem roku 2005 dokončen, lidé z Microsoftu změnili názor a zabudovali tuto pomůcku do aplikace Microsoft Operations Manager, která – jak pravděpodobně víte – rozhodně zdarma není.

Přehled odběru událostí Microsoft používá pro předávání událostí ještě jeden pojem: „odběr událostí“. Jeden z počítačů se „přihlásí k odběru“ událostí z jiných počítačů. Podívejme se na to, jak to celé z hlediska této terminologie Microsoftu funguje: ■

V odběru stanovíte jeden počítač se systémem Vista, který bude sbírat události z jednoho či více jiných počítačů.

■

Vyhrazenému systému se říká sběrač.

■

Systémy, ze kterých sběrač sbírá události, jsou označovány jako zdrojové počítače.

Jakmile nastavíte nový odběr, sběrač se v intervalu 15 minut dotazuje zdrojových počítačů, zda pro něj nemají nové události. Ve výchozím nastavení jsou odbírané události ukládány do složky „Předané události“, ale toto umístění se dá změnit. A ještě jedna poznámka: odběry fungují snáze,

Kapitola 1 – Správa zabezpečení windows vista – drobná překvapení

pokud se sběrač zdrojové počítače nacházejí ve stejné doméně. Odběry se dají nastavit i mezi dvěma počítači v pracovní skupině, ale to je problematičtější. Nastavování odběrů se bude v praxi lišit, v následujících odstavcích stručně popíšu ten nejjednodušší způsob nastavení.

Nastavení zdrojových počítačů Nejprve je nutné obejít všechny budoucí zdrojové počítače a zapnout na nich službu, která očekává požadavky sběrače na zaslání událostí. K tomuto zapnutí použijete nástroj příkazového řádku winrm. Dále je třeba upravit přístupová oprávnění k protokolům událostí u všech zdrojů tak, aby zdroje měly povoleno na žádost sběrače odpovědět.

Nastavení sběrače Poté na sběrači zapnete službu „Sběr událostí systému Windows“, která provádí vlastní sběr dat. Stačí ji spustit a samozřejmě nastavit také její automatické spuštění při zavádění operačního systému, stejně jako u ostatních služeb. (Ve skutečnosti není tento krok nutný, protože – jak za chvíli uvidíte – při nastavování prvního odběru událostí na počítači se vás Prohlížeč událostí zeptá, jestli má službu Sběr událostí systému Windows nakonfigurovat sám.) Poté vytvořte nový odběr a v něm sběrači přesně sdělíte, jaké události má sbírat a názvy všech systémů, ze kterých budou události vyžadovány. Pár minut poté začnou události proudit ze zdrojových počítačů na pevný disk sběrače.

Vytvoření ukázkového odběru Podívejme se, jak se vytváří jednoduchý odběr. V příkladu budu používat následující počítače a hodnoty (pokud si příklad chcete vyzkoušet, vytvořte si kopii mého nastavení): ■

Dva počítače se systémy Vista; první se jmenuje „Vista1“, druhý bude „Vista2“.

■

Oba počítače Vista1 a Vista2 jsou členové domény Active Directory „http://www.velkafirma. cz“. Zařazení do domény usnadňuje konfiguraci – počítače, které jsou jen členové pracovní skupiny, bychom propojili trochu obtížněji.

■

Při konfiguraci obou systémů jsem k nim přihlášen na účet marek@velkafirma.cz, který je členem skupiny Domain Admins.

Počítač Vista1 bude v této stručné ukázce vystupovat v roli sběrače, Vista2 jako (jediný) zdrojový počítač. Počítač Vista1 nechám sbírat informativní události Windows z počítače Vista2. Jak již bylo napsáno, celý proces nastavení proběhne ve dvou krocích: nejprve na zdrojovém počítači Vista2 zapnu určité služby a upravím jejich zabezpečení, aby jejich prostřednictvím mohl počítač Vista1 sbírat události. Poté se přesunu na sběrač Vista1, zde zapnu službu Sběr událostí systému Windows a vytvořím odběr. Na začátku budeme mít dva systémy nastavené v podstatě tak, jak byly nainstalovány, pouze jsem jim změnil zobrazované téma, aby se sejmuté obrazovky daly lépe číst. Na obou počítačích byl zapnut Windows Firewall a – jak je u Visty obvyklé – v jeho nastavení byly zakázány všechny výjimky kromě tzv. „základních síťových služeb“.

Nový Prohlížeč událostí

První krok: Příprava služby WinRM na počítači Vista2 Nejprve se přihlásíme k počítači Vista2, který bude odesílat události na sběrače, a zde aktivujeme infrastrukturu potřebnou pro reakce na žádosti došlé z počítače Vista1. Můžeme také říci, že počítač Vista2 se na základě toho, že začne reagovat na žádosti počítače Vista1, změní na něco jako „server“ – proto musíme na Vista 1 spustit službu, která bude na tyto žádosti reagovat. Microsoft vytvořil celou komponentu protokolu událostí nad sadou standardů pro vzdálenou správu pracovní plochy, která se jmenuje „WS-Management“. Microsoft – samozřejmě – vyvinul vlastní implementaci těchto standardů a pojmenoval ji „WinRM“ (zkratka pro Windows Remote Management). Spusťte příkazový řádek s právy administrátora (pravým tlačítkem myši klepněte na položku Příkazový řádek a v místní nabídce vyberte jako vždy příkaz Spustit jako správce atd.) a zapište do něj příkaz: winrm quickconfig

Služba WinRM odpoví asi takto: Služba WinRM není nastavena k povolení vzdáleného přístupu pro správu k tomuto počítači. Je třeba provést následující změny: Nastaví typ služby WinRM na odložené automatické spuštění. Spuštění služby WinRM. Vytvoří naslouchání služby WinRM na adrese HTTP://* pro přijímání žádostí služby WS-Man na jakékoli adrese IP v tomto počítači. Povolí výjimku brány firewall pro službu WinRM. Chcete provést tyto změny [A/N]?

Ano, přečetli jste to správně: Služba WinRM běží na portu č. 80 (proto ten odkaz na HTTP://*), ale nejedná se přitom o zprovoznění webového serveru uvnitř Visty, přinejmenším ne plnohodnotného. Jako odpověď na tuto výzvu stisknu A. Služba zareaguje takto: WinRM has been updated for remote management. WinRM service type changed successfully. WinRM service started. Created a WinRM listener on HTTP://* to accept WS-Man requests to any IP on this machine. WinRM firewall exception enabled.

Jakmile je toto hotovo, zůstaneme ještě v příkazovém řádku a udělíme počítači-sběrači oprávnění nahlížet na události tohoto počítače. Jak? Vložíme účet počítače-sběrače do skupiny „Event Log Readers“ na všech zdrojových počítačích – jak jste jistě uhodli, tato skupina je jednou z novinek Visty. Přidání účtu do skupiny se dá provádět v GUI, ale upřímně řečeno se to mnohem snáze dělá v příkazovém řádku, kde je pro tyto účely již mnoho let k dispozici příkaz NET (pozor, nikoli .NET), vkládající mj. účet uživatele do lokální skupiny. Přesná syntaxe vypadá takto: net localgroup názevskupiny názevúčtu/add

Kapitola 1 – Správa zabezpečení windows vista – drobná překvapení

Název skupiny je „Event Log Readers“. Jaký je však název počítače Vista1? Chceme přece zadat název doménového účtu počítače Vista1 … už od dob Windows 2000 mají počítače v doméně Active Directory názvy přidělované podle vzoru názevpočítače$@názevdoményDNS. Z toho vyplývá, že počítač s názvem „Vista1“ v doméně „http://www.velkafirma.cz“ bude mít přidělen název „vista1$@velkafirma.cz“. (Znak dolaru jako přípona názvu je používán pro rozlišení účtů počítače a účtů uživatele se stejným názvem – byl zaveden v dobách NT 4.0.) Na příkazovém řádku tedy v našem příkladu zapíšu příkaz ve tvaru net localgroup "Event Log Readers" vista1@velkafirma.cz /add

Počítač Vista2 by měl na tento příkaz reagovat hlášením Příkaz byl úspěšně dokončen. Tím je nastavení tohoto počítače dokončeno, přesuneme se na druhý počítač Vista1.

Druhý krok: vytvoření odběru na počítači Vista1 Na počítači Vista1 se také přihlásím na účet marek@velkafirma.cz, který je i zde doménovým administrátorem. Než se pustíme do úpravy nastavení tohoto počítače, zkontrolujeme si, zda správně funguje připojení k počítači Vista2 a že je spuštěn software WS-Management. To se dá udělat opět v prostředí příkazového řádku, proto spustíme příkazový řádek s právy správce a zapíšeme příkaz winrm id -remote:vista2.velkafirma.cz

Opět se potkáváme s příkazem winrm, ale tentokrát používáme parametr id, což je zkratka pro „WS-Management ping“. Přepínač -remote identifikuje vzdálený počítač, se kterým budeme komunikovat. Vista2 odpoví na úspěšně provedený ping asi takto: IdentifyResponse ProtocolVersion = http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd ProductVendor = Microsoft Corporation ProductVersion = OS: 6.0.5472 SP: 0.5 Stack: 1.0

V případě neúspěšné kontroly bude výstup vypadat asi takto: „WS-Management could not connect to the specified destination“. Máme ověřeno, že oba počítače vidí; skvělé. Můžeme se proto pustit do nastavování počítače Vista1. Spustíme na počítači Vista1 aplikaci Prohlížeč událostí. Pravým tlačítkem myši klepneme ve složce Zápisy a vybereme příkaz „Vytvořit odběr“. Vzhledem k tomu, že jde o první vytváření odběru na daném počítači, objeví se dialogové okno z obrázku 1.19. OBRÁZEK 1.19: Chcete spustit službu Sběr událostí systému Windows?

Nový Prohlížeč událostí

Klepněte na tlačítko Ano. Pokud byste chtěli nastavit parametry služby Sběr událostí systému Windows dopředu, je možné také v okně příkazového řádku spustit příkaz wecutil qc. Kdybyste postupovali takto, neviděli byste dialogové okno z obrázku 1.19. Když tento dialog zavřete tlačítkem Ano, objeví se vcelku impozantní dialogové okno Vlastnosti zápisu z obrázku 1.20. OBRÁZEK 1.20: Vytvoření odběru, část 1

Jak je vidět, začal jsem vytvářet odběr vyplněním polí Název zápisu a Popis. VAROVÁNÍ:

Dejte si pozor na jednu věc: nedávejte do názvů odběrů mezery. Pokud to uděláte, budete muset později používat na mnoha místech jinou, dost podivnou syntaxi.

Než je možné nový odběr spustit, musíme ještě Prohlížeči událostí sdělit, jaké typy událostí si má nechat zasílat od počítače Vista2 a – to hlavně – název počítače, ze kterého bude události dostávat. Nejdříve vybereme typy událostí, k tomu účelu je připraveno tlačítko Vybrané události…, kterým otevřete dialogové okno z obrázku 1.21. V tomto dialogovém okně Filtr dotazu je několik úrovní událostí, ze kterých můžete vybírat (Kritická, Chyba atd.), vyjádřených pomocí zaškrtávacích políček vedle popisku „Úroveň“. Já jsem zvolil „Informace“, což odpovídá zvolenému názvu odběru. Nad těmito zaškrtávacími políčky si dále můžete vybrat, zda má být vybrána každá vyhovující událost zdrojového počítače nebo jen události generované během určitého časového intervalu. V našem případě ponechám výchozí volbu „Kdykoliv“. Nejdůležitější volbou tu však budou nejspíše protokoly, které budou sledovány. Jak již bylo řečeno, ve Windows Vista se nachází více protokolů, než na kolik jste byli zvyklí v předchozích

Kapitola 1 – Správa zabezpečení windows vista – drobná překvapení

operačních systémech (obvykle byly tři). Po klepnutí na rozvírací seznam vedle přepínače „Podle protokolu“ uvidíte asi to, co zachycuje obrázek 1.22. OBRÁZEK 1.21: Výběr událostí, které budou sledovány

OBRÁZEK 1.22: Prosím, jen protokoly Windows

Nový Prohlížeč událostí

Pokud se mnou stále držíte krok, uvidíte v seznamu položky „Protokoly systému Windows“ a „Protokoly aplikací a služeb“; na obrázku je rozbalena úroveň „Protokoly systému Windows“, abyste viděli, co je tu k dispozici. Implicitně není zaškrtnut žádný protokol, já jsem zapnul všechny položky ve skupině Protokoly systému Windows s výjimkou „Předaných událostí“ (mám vcelku pochopitelný strach z toho, že by se mi někdy v budoucnosti podařilo nastavit odběr i v opačném směru a tak vytvořit nekonečný cyklus). Pokud se vám obsah rozvíracího seznamu zdá trochu divný, souhlasím s vámi – nepamatuji si, že bych podobnou strukturu někdy předtím v GUI Windows viděl. Podívejme ještě jednou pořádně na toto dialogové okno (obrázek 1.21 ), kde můžete dále zpřesnit, jaké události vás zajímají. V případě zájmu by se například daly odebírat jen události s ID 1030 a to ještě jen v případě, kdy by je generovala služba zásad skupiny. A abych nezapomněl – pamatujete si ještě důraz na XML, který byl patrný v Prohlížeči objektů? Možná jste si všimli, že dialogové okno Filtr dotazu má ještě stránku XML … pokud se na ni přepnete, uvidíte asi to, co je na obrázku 1.23. Co vidíte, je zápis v jazyce XPath, jedné z variant XML, určené pro psaní dotazů. Microsoft nám tu tedy nabízí středně snadno použitelné GUI pro zadání parametrů odběru (co vyžadovat a odkud), pokud však potřebujeme nějaký vskutku exotický filtr, můžeme GUI vynechat a dotaz zapsat přímo v XML. U složitých dotazů, které vymýšlíte dobrou půlhodinu v GUI, je také možné zkopírovat výsledné XML do Poznámkového bloku, uložit si ho a tak si vytvořit vzor pro případné další podobně složité odběry které kdykoli poté můžete vložit do stránky XML jiného odběru. V naší ukázce předávání však nic složitého vymýšlet nebudu, proto tlačítkem OK uzavřu dialogové okno Filtr dotazu a vrátím se do dialogu vlastností odběru. OBRÁZEK 1.23: Výsledný dotaz vyjádřený v XMLštině

Kapitola 1 – Správa zabezpečení windows vista – drobná překvapení

Zde je nutné provést ještě jednu věc, než hotový odběr spustíte: sdělit prohlížeči událostí, ze kterého počítače má události vyžadovat. To je už velmi snadné; po klepnutí na tlačítko Přidat se objeví standardní dialog Vyberte objekt typu: počítač, který vypadá téměř stejně jako na XP (a proto jeho obrázek vynechám). Zde zapíšu název „Vista2“, tlačítkem Kontrola názvů zkontroluji, že je vybraný počítač zapsán správně a poté tlačítkem OK ukončím práci s dialogovým oknem vlastností odběru (to nyní vypadá asi tak, jako na obrázku 1.24). OBRÁZEK 1.24: Nastavení odběru před jeho aktivací

Poslední obrázek jsem do knihy zařadil z jednoho praktického důvodu: když dokončíte tvorbu svého prvního odběru, pravděpodobně ještě před závěrečným stiskem OK naposledy vše zkontrolujete … a lehce zesináte – v poli „Zdrojové počítače“ uvidíte zapsán název Vista2, ale za ním bude slovo „neznámý“ a pod tímto polem pak neradostné hlášení o tom, že počítač http://www.VISTA2. velkafirma.cz není dostupný. Prosím, nedělejte si s tím hlavu, to je normální chování tohoto okna, nejde o žádnou chybu. Odběr je skutečně hotov, proto směle klepněte na tlačítko OK.

Řešení problémů s prodlevami u odběrů Jsme hotovi a přišel čas sklidit ovoce naší práce. Otevřete proto v Prohlížeči událostí složku Předané události a v ní uvidíte … neuvidíte tam vůbec nic. Je zbytečné panikařit, to je opět normální chování. Stačí počkat asi 15 minut – jak se zdá, je to nejoblíbenější interval Microsoftu vůbec – a poté se začnou objevovat první události. Toto zpoždění je u odběrů událostí důležitým faktem – stejně jako u leteckých linek je třeba vždy počítat s možným zpožděním.

Nový Prohlížeč událostí

Úprava 15minutového intervalu Některé z prodlev se dají změnit, jiné ne. Existují dva základní důvody, proč odbírané události docházejí na sběrač se zpožděním. První je zřejmý, je to již zmíněný 15minutový interval načítání. Systémy Vista fungující jako sběrače jakou implicitně nastaveny tak, aby o data žádaly v tomto intervalu. Vy si možná myslíte, že by první sběr měl proběhnout hned po dokončení tvorby nového odběru, Vista má však na věc jiný názor a počká 15 minut, než začne žádat o vyhovující události. V případě potřeby je možné tento 15minutový interval zkrátit. To se ale nedá udělat v GUI, v tomto případě je nutné použít pomůcku příkazového řádku wecutil (Windows Event Collector utility). Spustit ji budete muset celkem dvakrát. Nejdříve sdělíme prohlížeči událostí, že nechceme standardní 15minutový interval a dáme přednost vlastní úpravě odběru. Tento první příkaz bude mít tvar wecutil ss názevodběru /cm:custom. Přepínač /cm je zkratka slov „configuration mode“ (režim nastavení), proto „custom“ (vlastní). Když byste chtěli vrátit odběr do původního standardního formátu, stačí namísto /cm:custom zapsat /cm:normal. Parametr ss je zkratka pro „subscription settings“ (nastavení odběru). Pro přepnutí odběru Vista2Test do vlastního režimu konfigurace tedy zapíšeme a spustíme příkaz wecutil ss vista2test /cm:custom

Jestliže nástroj po stisku Enter nic nevypíše, je vše v pořádku. Pomůcka wecutil patří zřejmě mezi ty druhy aplikací, které toho moc neřeknou. Poté, co jsme odběr Vista2Test zbavili okovů „normálnosti“, můžeme změnit interval žádostí o události. K tomu slouží příkaz ve tvaru wecutil ss názevodběru /hi: milisekundy, ve kterém je význam parametru názevodběru jasný a milisekundy jsou nový interval odběru v tisícinách sekundy. Zkusíme změnit interval na 10 sekund: wecutil ss vista2test /hi:10000

TIP:

Pokud se mnou stále držíte krok a chcete si toto vyzkoušet, je jasné, že na počítači Vista2 potřebujete alespoň jednu „informační“ událost. Nejsnáze ji vyrobíte asi tak, že na tomto počítači spustíte okno příkazového řádku s právy správce a v něm povedete příkaz ipconfig /renew, kterým obnovíte zápůjčku adresy protokolu IP u služby DHCP. Tato obnova generuje na systému Vista událost „informační“ úrovně. Tyto události se objeví ve složce předané události na počítači Vista1 téměř okamžitě, budete ale muset stiskem F5 v prohlížeči událostí překreslit zobrazení, aby byly vidět.

Co je „prodleva při restartu“ (reboot delay) Druhou příčinou občasné pomalosti při změně odběru jsou samotné dvě služby Visty které se na odběru podílejí: služba winrm poskytuje služby WS-Management na zdrojových počítačích, služba wecsvc (Sběr událostí systému Windows) na počítači-sběrači. S čím se asi v praxi setkáte: spustíte jeden ze zdrojových počítačů a přejdete ke sběrači, abyste na něm sledovali události z tohoto právě puštěného zdrojového počítače. Sledujete. A pořád sledujete. A nic. Zkontrolujete proto parametry odběru, což se dá rychle provést následujícím příkazem, spuštěným na sběrači: wecutil gs vista2test

Kapitola 1 – Správa zabezpečení windows vista – drobná překvapení

Příkaz vypíše interval dotazování (wecutil ho označuje pojmem „heartbeat interval“) – a je to 10 sekund. Než kontrolu dokončíte, uplynulo od spuštění zdrojového počítače určitě už 10 sekund – a to mnohokrát. A pořád nejsou vidět žádné události co se sakra děje? Důvodem této prodlevy je změna způsobu spouštění některých služeb. Lidé z Microsoftu se nehodlají smířit s tím, že jejich operační systémy startují velmi dlouho. Proto se během několika posledních let pokouší ze zaváděcího procesu odebrat vše, co není nezbytně nutné, aby se celý proces zdál uživatelům – především desktopových systémů – mnohem svižnější (část těchto pokusů se odrazila již na Windows XP). Poslední fáze těchto pokusů o urychlení zaváděcího procesu zasáhla i některé služby. Pokud sledujete Windows (přesněji řečeno, jejich NT řadu) po technické stránce, víte, že služby Windows jsou zařazeny do různých startovacích tříd. U většiny z nich je ale nastavena „automatická“ třída, což znamená, že jsou spouštěny v podstatě paralelně se zaváděním GUI. Většina? Spočítejte si, kolik služeb ve Windows vlastně je. A pak jejich velikost. Když to udělali v Microsoftu, je snadné si představit, co následovalo: „Proboha! Vždyť služby tvoří skoro 40 procent součástí Windows, které jsou spouštěny spolu se systémem!“ Proto vznikla nová startovací třída služeb: „automaticky … ale zpožděně“. Tyto třídy mají být teoreticky spuštěny ve stejnou dobu jako služby „automatické“, ale jsou doplněny o atribut, který systému říká: „ano, tohle je automaticky spouštěná služba, ale moc s ní nespěchej“. Priorita jejich spuštění je tedy velmi malá, což může mít vliv na opožděné doručování odebíraných událostí, protože – jak jste si jistě domysleli – obě zainteresované služby winrm a wecsvc patří mezi služby s odloženým startem. Co z toho plyne: nebuďte překvapeni, pokud během prvních 7–8 minut (to je interval odvozený z mých zkušeností) nedorazí na sběrač žádné odebírané události. Jestliže vám to vadí, můžete kdykoli přehodit služby winrm a wecsvc ze třídy „automaticky … ale zpožděně“ do třídy „automaticky“, i když já osobně bych toto nedělal. (A pouvažujte o tom, zda by nebylo vhodné se připojit k Petru Někdo a rovněž omezit kávu.)

Předávání událostí v pracovních skupinách Ještě než ukončím tento úvod do předávání událostí, rád bych uvedl složitější příklad nastavení odběru, protože vám tak mohu předvést některé další volby nastavení a především další nástroje pro řešení případných problémů. Nejdříve si zopakujeme kroky potřebné pro navázání komunikace mezi dvěma počítači Vista1 a Vista2, které jsou členy domény. To bude výchozím bodem pro výklad procesu přípravy předávání událostí mezi členy pracovní skupiny: ■

Na zdrojovém počítači Vista2 jsme spustili službu winrm, aby tento počítač dokázal zachytávat příchozí žádosti sběrače.

■

Na zdrojovém počítači Vista2 jsme přidali účet počítače-sběrače do skupiny Event Log Readers, aby měl sběrač povoleno žádat zdrojový počítač o zaslání jeho událostí.

■

Na sběrači Vista1 jsme spustili službu Sběr událostí systému Windows (Windows Event Collection, wecsvc) která bude odesílat zdrojovému počítači žádosti o zaslání událostí.

Nový Prohlížeč událostí

■

Na sběrači jsme nastavili parametry odběru. A poté již jen čekali na doručení prvních událostí.

U počítačů, které nejsou členy stejné doménové struktury Active Directory, se postupuje obdobně, ale velký rozdíl je tu v zabezpečení. Účet počítače Vista1 nelze zařadit do skupiny na počítači Vista2, protože oba počítače mezi sebou nemají navázán žádný vztah důvěryhodnosti, který je automaticky vytvořen v rámci doménové struktury. Proto je nutné provést určité úpravy v zabezpečení počítačů. Chcete-li si celý postup vyzkoušet, připravte si dva počítače, které opět pojmenujeme jako Vista1 a Vista2. Tyto počítače nesmí být členy stejné doménové struktury AD. (Mohou být členy dvou různých domén, ale tyto domény nesmí být umístěny ve stejné doménové struktuře ani ve dvou různých strukturách, které si navzájem důvěřují.) Zkontrolujte si, že oba počítače jsou schopné správně překládat své názvy DNS (http://www.vista1.velkafirma.cz a http://www.vista2.velkafirma.cz). Jakmile je toto hotovo, odblokujte na obou systémech účet Administrator a nastavte mu hesla (na počítači Vista1 bude mít heslo tvar „velkesutry1“ a na počítači Vista2 tvar „velkesutry2“. Poté můžeme začít s odběrem.

Krok první: nastavení služby WS-Management na počítači Vista2 Obdobně jako v předchozím příkladu začneme aktivací služby WS-Management na budoucím zdrojovém počítači Vista2. K tomuto počítači se přihlaste na účet lokálního správce. Spusťte příkazový řádek s právy správce a zapište v něm winrm quickconfig

POZNÁMKA:

Vista u výchozího účtu správce nepoužívá Řízení uživatelských účtů (UAC), proto by ve skutečnosti nemělo být třeba otevírat okno příkazového řádku příkazem Spustit jako správce místní nabídky. Systém Vista však může být nastaven i tak, že jsou omezena práva výchozího účtu správce, proto tu explicitně upozorňuji na to, abyste okno příkazového řádku otevírali raději uvedeným příkazem.

Dotaz na aktivaci služby WinRM potvrďte zápisem písmene „a“ a poté stiskněte Enter. Tím je nastavení počítače Vista2 ukončeno.

Krok druhý: sběrač musí důvěřovat zdrojovému počítači Nyní se přesuneme k počítači Vista1 a zde se rovněž přihlásíme na účet lokálního správce. Vzhledem k tomu, že počítače Vista1 a Vista2 nesdílejí stejný doménový vztah, musíme přijít na to, jak si mohou navzájem ověřit svou totožnost. Otevřete okno příkazového řádku s právy správce a zapište tento příkaz: winrm set winrm/config/client @{TrustedHosts="vista2.velkafirma.cz"}

Tímto příkazem říkáte počítači Vista1, aby se v případě nutnosti bez nějakých cirátů pokusil o připojení k počítači Vista2. Tento krok se mi zdá hodně divný – člověk by logicky očekával, že bude nutné přikázat počítači Vista2, aby důvěřoval počítači Vista1, nikoli opačně – ale služba winrm funguje takto.

Kapitola 1 – Správa zabezpečení windows vista – drobná překvapení

U tohoto divně vypadajícího příkazu se na chvíli zastavíme. Služba winrm má množství konfiguračních parametrů, které lze zkoumat a měnit. Jejich úplný výpis zjistíte příkazem winrm get winrm/config

Výpis v tomto případě zabere skoro celou obrazovku; zde uvádím pro ukázku jen jeho část: C:\>winrm get winrm/config Config MaxEnvelopeSizekb = 150 MaxTimeoutms = 60000 MaxBatchItems = 20 MaxProviderRequests = 25 Client NetworkDelayms = 5000 URLPrefix = wsman AllowUnencrypted = false Auth Basic = false Digest = true Kerberos = true Negotiate = true DefaultPorts HTTP = 80 HTTPS = 443 TrustedHosts = vista2.velkafirma.cz

... Všimněte si, že údaje jsou vypisovány s různým odsazením, které vyjadřuje hierarchické uspořádání těchto parametrů, kterému se říká „schéma služby WS-management“. První řádek (Config) odsazen není, protože všechny vypsané parametry jsou částí Config. V dalším řádku MaxEnvelopeSizebk=150 vidíme, že parametr MaxEnvelopeSizekb (nemám tušení, co to znamená, takže se mne a to neptejte) má nastavenu hodnotu 150. Poskočme směrem dolů o několik řádků až na řádek Client. Ten je odsazen o jednu úroveň vůči Config a jde o kontejner (nebo spíš podřízený kontejner) sebe sama. Ještě níže vidíte TrustedHosts, což je parametr uvnitř větve Config/Client. Tuto hierarchii lze používat v příkazu winrm get nebo winrm set. Spustíte-li třeba příkaz winrm get winrm/config, bude zobrazeno celé schéma; pokud chcete vidět jen parametry ve větvi config/client, spusťte příkaz winrm get winrm/config/client. Jeho výpis bude vypadat asi takto: C:\>winrm get winrm/config/client Client NetworkDelayms = 5000 URLPrefix = wsman AllowUnencrypted = false Auth Basic = false

Nový Prohlížeč událostí

Digest = true Kerberos = true Negotiate = true DefaultPorts HTTP = 80 HTTPS = 443 TrustedHosts = vista2.velkafirma.cz C:\>

Způsob nastavení hodnoty parametru schématu winrm jste již viděli: winrm set winrm/místo-ve-schématu @{parametr="hodnota"}

V tomto vzorovém příkazu vyjadřuje místo-ve-schématu pozici (místo uložení) parametru uvnitř schématu. V hodnotě TrustedHosts je možné jako zástupný znak použít hvězdičku („*“), a je zde také možné zadat více než jednu hodnotu – v tomto případě je třeba seznam hodnot vložit do uvozovek a oddělit je navzájem čárkami. Následující ukázkový příkaz říká systému, aby důvěřoval dvěma počítačům: http://www.mojepc.velkafirma.cz a http://www.tvojepc.velkafirma.cz: winrm set winrm/config/client @{TrustedHosts= "mojepc.velkafirma.cz, tvojepc.velkafirma.cz"}

Oba dva řádky musí být ve skutečnosti zapsány jako jeden a mezi názvy počítačů v seznamu nepatří mezery. (Divíte se, proč tolik času věnuji ukázkám nastavení a řízení služby winrm? Kvůli tomu, že tato služba je na systémech Vista a Server 2007 základnou pro nejrůznější typy věcí. Věřte mi, nakonec této službě neuniknete ani vy.) Ukážeme si ještě, jak zapnout důvěřování všem počítačům, i když tento příkaz v produkčním prostředí asi nikdy nespustíte: winrm set winrm/config/client @{TrustedHosts= "*"}

Když si vše ještě jednou shrneme, první novinkou v nastavení předávání událostí mezi dvěma počítači bez doménového vztahu důvěryhodnosti vůči předchozímu příkladu je to, že jsme příkazem winrm set přidali zdrojový počítač do seznamu TrustedHosts na sběrači.

Krok třetí: test vzájemné komunikace službe WS-Management Tento krok není nezbytně nutný, ale osobně jsem velkým vyznavačem přísloví „dvakrát měř a jednou řež“ – každá kontrola je dobrá, pokud zabrání následným chybám. Otevřete okno příkazového řádku s právy správce a zkuste „pingnout“ vzdálený počítač prostřednictvím služby winrm. Příkaz vypadá stejně jako v předchozím příkladu: winrm id -r:vista2.velkafirma.cz

Tentokrát však příkaz fungovat nebude. Služba winrm musí znát způsob ověřování totožnosti mezi systémy. Pokud jí tento způsob nepředáte jako parametr, služba předpokládá, že může použít protokol Kerberos, který je však použitelný jen u počítačů ve stejné doméně (proto také v prvním příkladu tento poslední příkaz fungoval bezchybně, protože šlo o členy stejné domény). Tentokrát to už neplatí, proto je nutné způsob ověřování totožnosti explicitně uvést. Nejjednodušší varianta zní: „nepoužívej žádné ověřování“:

Kapitola 1 – Správa zabezpečení windows vista – drobná překvapení

winrm id -r:vista2.velkafirma.cz -a:none

Přepínač -a: je zkratka slova „authenticate“ a má několik možných hodnot: ■

-a:none znamená „neověřovat totožnost“. Vzhledem k tomu, že příkaz id patří k těm jednodušším, nebude služba winrm proti vynechání ověřovací fáze protestovat a příkaz proběh-

ne bezchybně. Vím, že lidí pracující v oblasti zabezpečení jsou někdy dost paranoidní, ale přece jen „vše má své hranice“ – nejsem zatím psychicky připraven na „bezpečný ping“ (při kterém by se ověřovala totožnost), obávám se ale, že na něj jednoho dne dojde. ■

-a:basic přikazuje ověřit totožnost pomocí jména a hesla, odesílaných ve formátu prosté-

ho textu. Tuto hodnotu nelze použít ve výchozím nastavení služby, protože winrm odmítá všechny nezašifrované přihlašovací údaje. Toto chování se ale dá změnit následujícím příkazem: winrm set winrm/config/client @{AllowUnencrypted="true"}

Nedoporučuji vám ale toto nastavení měnit. Za přepínačem -a:basic musí následovat jméno uživatele a heslo ve tvaru -u: doména \ uživatel -p:heslo. Ukázku uvidíte za chvíli. ·

-a:digest používá stejný přihlašovací „digest“ mechanismus jako ten, který již léta znáte ze služby IIS. Služba winrm ho považuje za nešifrovaný mechanismus a digest přihlašování

proto implicitně nelze použít. ·

-a:kerberos přikazuje použít k ověření totožnosti protokol Kerberos. Tento přepínač je

výchozí a znovu připomínám, že vyžaduje doménu. ·

-a:negotiate přikazuje použít mechanismus výzva-odpověď, připomínající NTLM. Jde o šifrované ověřování, použitelné ve výchozím nastavení.

Aby mechanismus výzva-odpověď fungoval, přidáme přepínače -u a -p. Heslo správce počítače Vista2 jsme nastavili na „velkesutry2“, takže výsledný příkaz bude vypadat takto: winrm id -r:vista2.velkafirma.cz -a:negotiate -u:vista2\administrator p:velkesutry2

(Opět musí být celý příkaz na jednom řádku, i když zde v knize je zalomen do dvou řádků.) Příkaz by měl proběhnout v pořádku a zároveň tak máme jistotu, že se k počítači Vista2 připojíme z Vista1 na jeho účet lokálního správce. Tento fakt nás opravňuje přejít do dalšího kroku.

Krok čtvrtý: nastavení odběru Pracujeme stále na počítači Vista1. Odběr nastavíme téměř stejně jako v předchozím příkladu, jsou tu jen dvě změny. Za prvé je nutné navázat nějaký typ síťového připojení k počítači Vista2, jinak by prohlížeč událostí nedovolil ani zadat „vista2“ jako název zdrojového počítače. Vytvořil jsem proto na počítači Vista2 výjimku z pravidel firewallu pro službu „Sdílení souborů a tiskáren“. Poté jsem na počítači Vista1 spustil příkaz net use \\vista2\ipc$ /u:vista2\administrator velkesutry2

79 Takto jsem se připojil k počítači Vista2 a mohl jsem potom jeho název zadat ve vlastnostech odběru jako název zdrojového počítače. Druhá změna se rovněž týkala zabezpečení. V dialogovém okně vlastností odběru, kterým bude Vista1 tahat události z počítače Vista2, se nachází tlačítko „Upřesnit“. Po klepnutí na něj uvidíte část výsledného dialogového okna Rozšířené nastavení s názvem Uživatelský účet. Uvnitř je přepínač Určitý uživatel. Po jeho zapnutí se ukáže tlačítko s názvem „Uživatelské jméno a “ kterým vyvoláte další dialog pro zadání jména uživatele a hesla. V tomto případě zapíšeme jako jméno vista2\administrator a jako heslo velkesutry2. Počkejte povinných 15 minut a pak můžete začíst studovat stáhnuté události! Když to celé shrneme, nastavení odběru událostí mezi počítači v rámci pracovní skupiny se liší od doménového odběru událostí v následujících ohledech: ■

Zdrojové počítače je nutné přidat do parametru TrustedHosts služby winrm na počítači-sběrači.

■

Na zdrojových počítačích je nutné dočasně zpřístupnit sdílení souborů a tiskáren a poté nějak počítače propojit (já jsem k tomu použil IPC$ trik). Po navázání relace je možné přidat počítače do seznamu zdrojů v dialogovém okně vlastností odběru.

■

V dialogu Rozšířené nastavení je nutné zapsat jména uživatelských účtů na zdrojových počítačích a hesla k nim. Tyto účty musí být členy lokálních skupin Event Log Readers na zdrojových počítačích.

V této kapitole jsem vás stručně seznámil s některými menšími novinkami systému Vista. V další kapitole už nás čeká první „větší“ překvapení: Řízení uživatelských účtů (User Account Control).

Kapitola 1 – Správa zabezpečení windows vista – drobná překvapení

2 Řízení uživatelských účtů aneb „jste si opravdu jist, pane správče?“ Vista obsahuje mnoho nových parádních funkcí a prostředků a já mám podezření, že si v ní každý najde něco, do čeho se zamiluje. Ne že všichni budou milovat všechno, to ne, ale každý nástroj získá obdiv nejméně jednoho člověka… je to tak? Jistě, je to lež. Existuje nejméně jedna vlastnost Visty, kterou budou naopak všichni nenávidět: Řízení uživatelských účtů (User Account Control, UAC). Ale ve skutečnosti ani toto moje tvrzení není pravdivé, protože třeba já mám UAC rád. I když přiznávám, že když jsem se s ním setkal poprvé, nesnášel jsem ho pravděpodobně víc než kdokoli jiný. V této kapitole vám nabízím stručný přehled všeho, co UAC dělá – určený pro ty, kteří se s ním ještě nesetkali – a vysvětlím také, proč všechny obtěžuje. Poté budu popisovat, proč si myslím, že UAC je významným krokem vpřed nejen z hlediska zabezpečení Windows, ale i kvůli jeho úloze při školení běžného uživatele, který si díky němu lépe uvědomí důležitost správného zabezpečení Windows… a to je právě to, co se mi na UAC tak líbí: pokud si všichni začnou dávat pozor, poté se dá předpokládat, že většina potíží se zabezpečením Windows zmizí. Poté se podíváme přímo do ledví UAC. Vysvětlíme-li si principy jeho činnosti, pomůže to dle mého názoru převést pod jeho prapory pár zbylých zatvrzelců, a pokud snad někdo nekonvertuje, bude přinejmenším vědět, jak se dá UAC vypnout.

Úvod do UAC UAC o sobě dá vědět velmi brzy, a obvykle to není moc šťastné setkání – snad se neurazíte, když vám budu vyprávět o svých raných infarktových zážitcích s Vistou, na které jsem dělal narážky již v úvodu a první kapitole. Nainstaloval jsem svou první kopii Visty. Když se po dokončení instalace spustila, vyzvala mne k vytvoření místního účtu – protože se jednalo o počítač zařazený jen do pracovní skupiny – a když jsem zapsal název tohoto účtu, Vista z něj udělala člena skupiny Administrators. To je implicitní chování, stejné jako na XP. (V jiných případech jsem instaloval kopii Visty, která byla členem domény a přihlašoval jsem se k tomuto počítači jako člen doménové skupiny Domain Admins,

Kapitola 2 – Řízení uživatelských účtů

která je samozřejmě také členem místní skupiny Administrators.) V obou případech jsem ale nebyl k Vistě přihlášen jako místní Administrator. (Připomínám, že tento účet je implicitně zakázán.) Po přihlášení do systému bylo mým prvním úkolem vytvoření místního uživatelského účtu s názvem „Marek“ a heslem „mecoun“. Protože jsem zvyklý pracovat v okně příkazového řádku – a po pravdě řečeno jsem dodnes neměl zájem zkoumat, jak se s uživateli pracuje v GUI – postupně jsem klepnul na Start, Příslušenství a Příkazový řádek a v otevřeném okně příkazového řádku jsem zkusil účet Marek vytvořit následujícím příkazem: net users marek mecoun /add

Byl jsem hodně překvapen, když jsem poté uviděl hlášení o systémové chybě č. 5. Přístup byl odepřen. Zdálo se mi to hodně divné, protože tento příkaz bezproblémově používám na systémech řady Windows NT už od dob NT 3.1. Ale momentíček …ten vzkaz neříkal, že by byla špatná syntaxe; jen „přístup byl odepřen“. Aha! Možná jsem se zapomněl přihlásit jako správce? Pro jistotu jsem se tedy odhlásil a znovu přihlásil, abych měl jistotu, že jsem přihlášen jako místní správce – ale příkaz pořád nebylo možné provést. Dobře, říkal jsem si, vzdávám to a zkusím to udělat v GUI. Klepnul jsem na Start, poté na Ovládací panely… a všimnul si, že Microsoft opět změnil uspořádání tohoto důležitého okna (což jsem ale stejně podvědomě očekával). V Ovládacích panelech jsem našel ikonu dvojice lidí (s hlavami, ale bez tváří), která mne v době jejího prvního výskytu v XP trochu šokovala. Vypadá totiž jako něco z Krajních mezí …nebo spíš jako špatná epizoda Sopranos. Vedle lidí bez tváře byl velký nápis „Uživatelské účty“ a pod ním „Přidat nebo odebrat uživatelské účty“. Ano, to je ta správná volba, domníval jsem se naivně a klepnul na ni. Obrazovka poté ztmavla a objevilo se na ní podlouhlé dialogové okno, které vypadalo jako obrázek 2.1. OBRÁZEK 2.1: Těší mne, já jsem „Consent UI"

Přes všechny nevýhody je UAC dobrým nástrojem. Proč?

Co to proboha je? Po důkladném pročtení obsahu tohoto dialogu jsem rozmrzele pochopil, že to je v podstatě převlečený dialog „jste si opravdu jist?“. (Jeho oficiální název jsem uváděl již v minulé kapitole:„consent user interface“ neboli „Consent UI“.) Z určitých důvodů měly Windows absolutní jistotu, že hodlám provádět něco souvisejícího se správou systému. Klepnul jsem tedy na tlačítko „Pokračovat“ a Vista otevřela GUI pro vytváření účtů. Tam už jsem si dokázal poradit. Při další, stále častější prací ve Vistě jsem se s Consent UI potkával pořád víc a víc. A postupem času mne tento dialog otravoval pořád víc a víc. (Toto všechno probíhalo samozřejmě ještě předtím, než jsem byl v červnu 2006 osvícen, jak jsem popsal v Úvodu.)

Přes všechny nevýhody je UAC dobrým nástrojem. Proč? Účel existence UAC je nesmírně jednoduchý: budeme-li muset potvrzovat dialog Consent UI pokaždé, když hodláme provádět něco, co vyžaduje práva správce, budeme si lépe uvědomovat, kdy tyto úkoly vykonáváme. Jak jsem již ale poznamenal, být neustále upozorňován na něco, co již vím, může člověka silně rozzlobit. Kde je tedy ta slíbená pomoc? Jak už jsem napsal v úvodu, až do června 2006 jsem nedokázal rozeznat žádný přínos UAC, žádnou novou přidanou hodnotu. Nebylo to pro mne nic jiného než klasické dialogové okno „Jste si opravdu jist?“, dotýkající se velmi citlivého místa v mé psychice. Víte, celá léta předtím jsem občas žertoval v tom smyslu, že kdybych si mohl ve Windows přát jednu jedinou věc, byla by to nová položka ve větvi HKEY_LOCAL_ MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion systémového registru typu REG_ DWORD s názvem NeverQuestionMarksJudgment (NikdySeNaNicNeptat). Já bych tuto položku spokojeně nastavil na hodnotu 1, restartoval bych systém a už nikdy, ale opravdu nikdy bych nemusel potvrzovat žádná okna hlášení ani jiné dialogy. Jak sami vidíte, rozhodně jsem nepatřil mezi ty, kteří by si UAC mohli oblíbit.

Výhody UAC pro uživatele Nikdy jsem si UAC příliš neoblíbil. Odklepávání Consent UI prostě člověka dopaluje, i když i se na to dá zvyknout. Abyste však pochopili můj úhel pohledu, zkuste se na UAC dívat jako na dva zcela odlišné přínosy. Za prvé je tato věc přínosem pro počítačové veterány, mezi které patřím i já , za druhé je přínosem i pro méně zkušené uživatele Windows. Ti druzí, méně technicky zdatní, brzy pochopí – v to doufám – že Consent UI je v podstatě důrazný budík. Když budou surfovat po Internetu a na nějaké stránce narazí na slibný odkaz „klepni a přečti si svůj horoskop“ nebo obdobný reklamní text, a po klepnutí na takový odkaz vyskočí dialog Consent UI, možná budou dostatečně poučeni, aby se dokázali zastavit a říci si: „to je divné … po klepnutí na obyčejný hypertextový odkaz Windows obvykle nezešednou a nevyhazují žádné dialogové okno … možná bude lepší odklepnout „Storno“ … A díky tomu si nevpustí do systému nežádoucí spyware. Takové zodpovědné chování každého správce jistě potěší.

Kapitola 2 – Řízení uživatelských účtů

Výhody UAC pro správce Ale co my technici? Není snad pro nás UAC zcela zbytečné? Nemyslím si to. Když začnete pracovat na některém ze systémů disponujících hierarchií uživatelských účtů (NT, Unix, Linux, OS/X apod.), ve kterém mají některé účty jen minimální práva a jiné práva vyšší, určitě jste byli někým poučeni o základních pravidlech dodržování bezpečnosti: nesmíte být celý den přihlášeni k počítači pod účtem správce. V praxi se spíš potkávám se situací, že každý nováček je sice náležitě poučen, ale jeho okolí se ho poté svým chováním snaží přesvědčit o tom, že by se takto chovat měl, ale nikdo to nedodržuje. Pracovat pod účtem běžného uživatele je prostě příliš omezující a každý, kdo někdy zkusil na Windows 2000 Professional nebo XP pracovat pár dnů pod takovým účtem, poznal, že v mnoha případech se nedá dělat doslova nic. Dokonce i aplikace, které slouží jen k odvedení nějaké práce a v žádném případě ke správě počítače (mnozí jim proto říkají produkční aplikace), velmi často nefungují správně nebo vůbec, pokud nejsou spuštěny pod účtem správce. Patří sem i tak běžné aplikace jako Internet Explorer, Outlook Express a Outlook.

UAC jako nástroj pro přechodové období Mnoho lidí, kteří se pokoušeli pracovat v systému XP pod účtem běžného uživatele, velmi rychle rezignovalo a po celou pracovní dobu jsou raději přihlášení na účet správce systému – a to platí i pro všechny ostatní starší verze NT, na které si vzpomínám. Díky tomu jsme si na tento způsob práce tak zvykli, že už o tom ani nepřemýšlíme; je to neodmyslitelná součást „kultury“ světa Windows. Práce pod účtem správce má ale jednu velkou nevýhodu: každý z nás někdy udělá chybu; už několikrát se mi stalo, že jsem odklepnul tlačítko „Smazat“ a přitom jsem chtěl soubor jen přejmenovat; obdobně se mi párkrát podařilo souhlasit s instalací spyware, i když jsem zcela určitě chtěl zvolit „Ne“. V obou případech by mne operační systém mohl chránit před mými vlastními chybami, a to díky vestavěným ochranám, vytvářeným právě kvůli takovým situacím. Mohl, ale neochránil, protože když jsem přihlášen jako správce systému, jsou všechny tyto ochrany vypnuty – bezpečnostní pásy v autě chybí, airbagy jsou pevně zamčeny a ochranné oblouky jsou odebrány. Jen výjimečně se s autem připletu k nějaké havárii, ale když se to stane, jsem rád, že mám tyto věci ve výbavě. U Visty se Microsoft pokusil zrušit tuto potřebu být přihlášen jako správce systému, pokud děláme běžné úkoly (čtení a vyřizování e-mailů, surfování na webu, psaní různých dokumentů). Zda se jim to povedlo nebo ne, budete muset posoudit sami, ale osobně vám důrazně doporučuji, abyste ve Vistě dali práci pod účtem běžného uživatele šanci a teprve poté – v případě skutečné nemožnosti tak pracovat – UAC vypnuli. Ve zbylé části této kapitoly se budu snažit poskytnout vám různé návody a nástroje, které vám takovou práci umožní. V každém případě chci na tomto místě říci, že je skutečně nutné změnit pracovní návyky uživatelů Windows a pracovat především (nebo vždy) pod účty standardních uživatelů, a určitě nejsem první, kdo toto tvrdí. Změna zažité kultury práce je obtížná, ale ne nemožná; „unixáři“ si tímto prošli již před mnoha lety. Když si na počítač nainstalujete Unix nebo Linux, budete tam mít k dispozici účet „root“, který je obdobou účtu „administrator“ ve Windows: může si se systémem dělat, co chce, a je proto velmi vhodný pro změnu konfigurace systému, ale případná chyba se může tvrdě vymstít a skončit těžkým poškozením operačního systému. Tomu se lze snadno vyhnout, pokud budete přihlášeni jen na účet standardního uživatele. Dlouhá léta se uživatelé Unixu také běžně přihlašovali na účet root,

Stručný přehled UAC

ale velmi rychle se ukázalo, že to je hrozné bláznovství. Ale když se uživatelé pokoušeli pracovat pod standardními účty, mnohé unixové aplikace nefungovaly. Během let se vývojáři naučili psát aplikace pro Unix tak, aby mohly bez omezení fungovat i pod účtem běžných uživatelů, a v dnešní době již většina lidí na Unixech nebo Linuxu pracuje jako běžný uživatel. Funguje jim to velmi dobře, ale změna návyků uživatelů i vývojářů trvala delší dobu. Dokonce jsem se dozvěděl, že Mac OS – který vychází z jedné varianty Unixu s názvem BSD – má účet root, ale firma Apple vám neuzná záruku na počítač, pokud se byť jedinkrát pod tímto účtem přihlásíte k systému! Windows nyní prochází podobnou změnou, a bude nás to hodně bolet – ale vyplatí se to. POZNÁMKA:

Kdyby mi však někdo vyhrožoval tím, že mi neuzná záruku, pokud bych se někdy přihlásil jako Administrator, zašel bych si k sousedům Microsoftu (Boeing) a koupil bych si tam nějaké letadélko s dostatečnou výbavičkou, která by je přinutila změnit názor. (Jen žertuji. Většinou.)

Když si po sobě čtu několik posledních odstavců, připomíná mi to, že jsem tuto kapitolu málem vybavil podnadpisem „Rybí tuk pro vaše PC“. Více než dvacet let jsem lidem vysvětloval, co všechno mohou na počítačích dělat, ukazoval jsem jim různé zajímavosti, které většinou neznali, a vyprávěl jsem jim, jak se vypořádat s různými nepříjemnými záležitostmi; nejsem zvyklý otravovat lidi nepříjemnými věcmi, například dotazy na to, zda si řádně umyli uši a vyčistili zuby – ale v tomto případě (řeč je o UAC, ne uších a dentálních nitích) si myslím, že je to jen pro jejich dobro, takže mi, prosím, promiňte, pokud se vám někdy zdá, že vypichuji maličkosti zvýšeným hlasem a připomínám tak kazatele se zdviženým prstem, který hřímá o ohni a síře pekelné! Celý výklad jsem zahájil tím, že UAC sice nemusí být velkým přínosem pro znalce a zkušené uživatele, kteří jsou dostatečně chytří na to, aby poznali, na co nemají klepat myší (a nikdy by neotevřeli přílohu e-mailu, aniž by ji nejdříve pořádně „neproklepli“), může vám však pomocí jinak. Proto tu píšu o procesu kulturní aklimatizace z aktuálního stavu věcí na stav nový, kdy nebudeme pracovat pod účtem správce; jak nám UAC v tomto směru pomůže? Je to velmi jednoduché: některé věci bude nutné stále provádět pod tímto účtem, a to v i zářivé budoucnosti celodenní práce pod účtem standardního Franty Vomáčky, ale bylo by hrozně otravné se muset neustále odhlašovat z účtu běžného uživatele a přihlašovat se na účet správce (a naopak). Ve Windows 2000 se Microsoft pokusil tuto nepříjemnost řešit nástrojem „Spustit jako“, ale ten byl dost nevyrovnaný a některé programy ho odmítaly. UAC je oproti tomu nějako jako Superman – když ho použijete coby standardní uživatel, může si spouštěná aplikace dovolit skutečně vše. Budeme to ještě rozebírat dále v této kapitole, ale když to poznáte v praxi, myslím si, že se mnou budete souhlasit v tom, že UAC celý přechod značně usnadní. Dokonce, i když budete ve Vistě stále přihlášen jako správce po celou dobu práce, aktivní UAC vás nenápadně „přepne“ do role standardního uživatele tak jako tak – to si také vysvětlíme později.

Stručný přehled UAC Průzkum vnitřností UAC bych rád zahájil stručným představením UAC při práci v systému, ale ještě než to udělám, zopakujeme si stručně základy zabezpečení Windows. (Omluva pro experty na zabezpečení: povaha UAC vyžaduje, aby každý čtenář správně chápal základy zabezpečení

Kapitola 2 – Řízení uživatelských účtů

Windows nebo měl alespoň příslušné texty po ruce, proto musíme chvílemi odbočit a tyto základy znovu vysvětlit a připomenout. Následující dva odstavce proto můžete v klidu přeskočit.) Když se přihlásíte k systému, dostanete přidělen tzv. token neboli identifikační data, umístěná v operační paměti počítače. Tokeny jsou velmi důležitým prvkem zabezpečení, protože obsahují seznam skupin uživatelů, do kterých patříte, a jejich oprávnění. Tento token je využit při každém spuštění programu. Ať už provádíte příkaz v okně příkazového řádku, poklepáte na ikonu umístěnou na pracovní ploše, spustíte program z nabídky Start nebo to uděláte nějak jinak, Windows zkopíruje váš token k tomu programu, který jste se rozhodli spustit. Když tedy spouštíte Microsoft Word a poté této aplikaci přikážete otevřít soubor diář.doc, Word požádá souborový systém NTFS, aby mu povolil otevřít soubor diář.doc v režimu čtení i zápisu. Vzhledem k tomu, že k souboru diář.doc patří jeho přístupová oprávnění systému NTFS, musí NTFS zkontrolovat, zda má Word právo tento soubor číst a zapisovat. Proto NTFS požádá Word o jeho token. Token Wordu je prostou kopií vašeho tokenu, proto NTFS povolí Wordu dělat se souborem přesně to, co s ním můžete dělat vy. (Kopie Wordu, kterou jste spustil, má tedy přesně stejná přístupová práva k souboru jako vy.) POZNÁMKA:

Podotýkám ještě jednou, že Windows zkopírují váš token a přidělí jeho kopii programu v okamžiku spuštění této aplikace. Jakmile je program spuštěn, není možné jeho token nijak změnit; a když píšu nijak ,je to míněno jako nijak. V případě, kdy je nutné programu přidělit větší oprávnění, musíte ho buď ukončit, odhlásit se od systému, znovu se přihlásit – ale pod jiným účtem s větším rozsahem oprávnění – a poté program znovu spustit. Vzhledem k tomu, že tento postup je zdlouhavý, je možné v libovolné verzi Windows – počínaje NT 4.0 – použít příkaz „Spustit jako“, který povoluje spustit aplikaci s tokenem mocnějšího účtu. Jak brzy uvidíte, Vista tyto možnosti doplňuje o další varianty.

Ve Vistě jsou stále přítomná oprávnění přístupu k složkám a souborům, stejně jako v předchozích verzích Windows, a když se tedy přihlásíte k systému, obdržíte token obsahující údaje o vašem členství v jednotlivých skupinách uživatelů a s tím spojená oprávnění. Od předchozích verzí Windows se však Vista liší v tom, že obsahuje také tzv. „Administrator Approval Mode“, který umožňuje správcům systému být přihlášeni na účet správce a strávit tak – jako postaru – celý den pod účtem správce, ale přitom není počítač vystaven takovému riziku jako v XP či Windows 2000. Microsoft označoval tyto účty správců, které jsou ve skutečnosti chráněny před sebou samými, jako „chráněné správce“ (protected administrators, PA), v době psaní této knihy je však aktuálním pojmem – vážně to není vtip – „správci v Režimu schválení správce“ (administrators in Administrator Approval Mode). Velmi mne to láká k používání zkratky PA, ale neudělám to … Jestliže se přihlásíte k systému jako správce v Režimu schválení správce, přidělí vám systém ne jeden, ale dva tokeny (Microsoft to označuje pojmem „rozdělený token“, někteří pracovníci Microsoftu používají také pojem „filtrovaný token“): ■

Jeden token vypadá stejně jako tokeny před nástupem Režimu schválení správce a obsahuje všechny vaše skupiny, oprávnění a jiná privilegia. V terminologii Microsoftu se tento token označován jako „administrator access token“, případně „administrator token“. Pokud jste četli starší dokumenty Microsoftu o chystaném UAC, možná jste v nich patřili frázi

Stručný přehled UAC

„privileged administrator token“, což je starší a již nepoužívaný výraz, který se ale stále objevuje na mnoha WWW stránkách. V této kapitole budu tento token označovat jako „token plného přístupu správce “. ■

Druhý token, který je novinkou Visty, je v dokumentaci označován jako „standard user access token“ nebo zkráceně „standard user token“ (česky „token uživatele se standardním oprávněním“). Z názvu tokenu se dá ihned poznat, jak se chová: Byla z něj odebrána všechna oprávnění na úrovni správce a příslušnost do administrativních skupin. (Později vám vysvětlím podrobněji, jak toto „ořezávání“ probíhá, to slibuji; nyní jen stručně nastiňuji podstatu nové technologie.) V některých dokumentech je pojem „rozdělený token“ používán pro celý princip dělení tokenu na dvě části, jinde se pojmem „rozdělený token“ označuje jen ten, který má slabší oprávnění (tedy token uživatele se standardním oprávněním).

TIP:

Připomínám část minulé kapitoly, kde jsem uváděl, že „uživatel se standardním oprávněním“ není jen hovorový výraz, ale jde o vcelku nový módní výraz Microsoftu pro ty uživatele, kteří nemají žádná práva správců. Původní pojem byl „omezený uživatel“ (restricted user), ovšem marketingoví kravaťáci toto neschválili, protože to podle nich má nevhodné vedlejší významy – „proč bych měl být na svém vlastním počítači omezován?“– a měli v tomto nejspíše pravdu.

Systém Vista tedy vidí, že máte přiděleny dva tokeny. Který z nich použije, když se o něco pokusíte? Funguje to asi tak, že systém ignoruje token plného přístupu správce a přidělí vám jen ta práva, která obsahuje token uživatele se standardním oprávněním. To znamená, že pro téměř všechny operace jste systémem považování za běžného uživatele, a to i v době, kdy jste přihlášen jako správce. Po pravdě řečeno, není to tak hrozné, jak by se dalo očekávat, protože Microsoft ve Vistě vyvinul velkou snahu a u velkého množství akcí, které předtím v XP bezdůvodně vyžadovaly práva správce, změnil jejich zařazení a umožnil je provádět i uživatelům se standardním oprávněním. (To zajisté vyvolá polemiku: co je pro jednoho řešením dlouho neřešeného nepohodlí, je pro druhého díra do systému velká jak barokní vrata od kostela.) Jak jsem již předtím podotknul, přihlášení pod účtem uživatele se standardním oprávněním je skvělá věc také z toho důvodu, když se nevědomě pokusíte spustit instalaci spywaru, který je na vás nalíčen jako část na první pohled nevinné webové stránky, dojde vám jako příloha e-mailu či je součástí nějaké aplikace. Někdy je pochopitelně nutné spustit nějakou aplikaci vyžadující práva správce, a v takovém případě je nutné, aby Windows uznaly váš token plného přístupu správce. (Tokeny jsou programům přidělovány při jejich spuštění, proto Windows musí vědět, který token přidělit v době spouštění aplikace. Jak jsem již napsal, po spuštění programu neexistuje žádný způsob, jak jeho token změnit, a nedají se ani nijak povýšit oprávnění, která jsou v tokenu uložena. Chcete-li plně porozumět tomu, jak UAC funguje, je způsob výběru jednoho z obou tokenů při spouštění programu klíčovou součástí.) Ve skutečnosti Windows nikdy nepoužijí token plného přístupu správce, i když takový token máte přidělen, s výjimkou případů, kdy (1) přikážete Windows, aby tento token použily, (2) nebo když jsou Windows dostatečně inteligentní na to, aby si mohly říci: „helemese, tady ten bazmek nebude bez tokenu plného přístupu správce fungovat a aktuální uživatel má ten token přidělen;

Kapitola 2 – Řízení uživatelských účtů

koukneme se, jestli mě nechá, abych ho tomu programu přidělil“. Jestliže k jedné z těchto dvou situací dojde, systém zobrazí Consent UI z obrázku 2.1; tímto dialogem se tedy Windows ptají: „Myslím si, že po mně chceš, abych použil tvůj token plného přístupu správce – mohu to udělat?" Jestliže nyní klepnete na tlačítko Pokračovat, mohou Windows spustit požadovanou aplikaci s tokenem plného přístupu správce namísto tokenu uživatele se standardním oprávněním. Je to dost choulostivý bod, ale důležitý, protože ho mohu využít k vysvětlení něčeho, co jsem napsal v předchozím textu. Vzpomínáte si, jak jsem na začátku kapitoly vysvětloval, co se stalo, když jsem se ve Vistě pokoušel vytvořit nový účet uživatele? Napsal jsem, že jsem se přihlásil jako správce a poté otevřel okno příkazového řádku, ve kterém jsem zkusil v programu net.exe vytvořit nový uživatelský účet. Systém Vista tento pokus zamítnul a odpověděl, že nemám právo vytvořit nový účet, i když jsem byl přihlášen jako správce. Proč se mi to nepovedlo? Protože jsem nepožádal Windows, aby net.exe spustil s mým tokenem plného přístupu správce (později vám ukážu, jak se to provádí) a protože – důvod objasním později – operační systém Windows nevěděl při spouštění programu net.exe, že tento vyžaduje ke své činnosti práva správce, a mne proto nenapadlo požádat o připojení mého tokenu plného přístupu správce. To znamená, že v době, kdy net.exe měl vytvořit účet nového uživatele, měl přidělen pouze token uživatele se standardním oprávněním a nemohl tedy požadovanou činnost povést. Výsledek: celá operace skončila neúspěchem. Když jsem ale vytvářel uživatelský účet v GUI, tak systém Windows věděl (protože tak byl navržen), že každý, kdo klepne na hypertextový odkaz „Přidat nebo odebrat uživatelské účty“, bude muset vlastnit token plného přístupu správce, jinak nemůže pokračovat. Windows tedy ví, že pokračování akce „Přidat nebo odebrat uživatelské účty“ bude vyžadovat token plného přístupu správce a ví také to, že já tento token mám. Ale ani to nestačí k tomu, aby Windows povolily akci „Přidat nebo odebrat uživatelské účty“, protože Vista nikdy nepoužije token plného přístupu správce bez svolení. Proto otevře Consent UI. Když v něm klepnu na tlačítko Pokračovat, obdrží proces „Přidat nebo odebrat uživatelské účty“ můj token plného přístupu správce, a já mohou vytvořit nový účet, aniž by docházelo k chybám. To je celý UAC v kostce.

Hlubší ponor do problematiky UAC Zopakujme si, co jste se doposud dozvěděli. Vista implicitně mění účty správců na chráněné správce a rozdělí jejich přihlašovací tokeny do plnoprávného tokenu správce (token plného přístupu správce) a tokenu standardního uživatele s omezenými právy (token uživatele se standardním oprávněním). Když spustíte nějaký program, Vista k němu implicitně připojí token uživatele se standardním oprávněním. Druhou možností je připojení tokenu plného přístupu správce k programu, ale o to je nutné buď požádat, nebo Vista dokáže odhadnout sama, že program bude tento token potřebovat a připojí ho k němu – ale v obou případech musíte s předáním tohoto tokenu vyslovit souhlas. Toto vysvětlení je sice ucházející, ale přinejmenším v mé hlavě vyvolalo více otázek, než kolik jich stačilo zodpovědět. Přidejme proto dalších pár podrobností do výsledné skládačky, aby byla problematika UAC ještě o něco srozumitelnější.

Hlubší ponor do problematiky UAC

Jak Windows vytvoří token uživatele se standardním oprávněním Jak již víte, přihlášení na účet správce v Režimu schválení správce znamená, že daný uživatel dostane přidělen token s menším rozsahem oprávnění, než kdyby byl přihlášen jako plnomocný správce. O kolik oprávnění však skutečně přijde ?

Strukturování tokenů ve Windows Vista Token je datová struktura v RAM počítače, ke kterému jste přihlášen. Tokeny Visty, velmi podobné tokenům v předchozích verzích Windows, obsahují několik položek: vaše jméno, členství ve skupinách uživatelů, vaše oprávnění a vaši úroveň integrity Windows. Na všechny složky se postupně podíváme podrobněji. (I zde platí, že pro některé čtenáře bude tato část spíš opakováním, je však velmi důležité, aby každý z vás chápal tyto základy, umožňující porozumět tomu, co se v UAC děje „pod kapotou“. Probírané věci budou potřebné i při výkladu úrovní integrity Windows ve čtvrté kapitole.)

Vaše „jméno“: váš bezpečnostní identiﬁkátor (SID) Vám přidělený token ve skutečnosti neobsahuje vaše skutečné jméno, protože různí lidé se mohou jmenovat stejně, nezávisle na tom, jak jedinečná tato jména jsou. (Před několika lety jsem se k svému překvapení dozvěděl, že existuje ještě jeden Mark Minasi, který provozuje TV obchod. Od té doby mnohem častěji používám svou prostřední iniciálu!) Windows nepotřebují něco tak neurčitého jako jméno, ale nějaký zaručeně jedinečný identifikátor vaší osoby. A již od dob NT 3.1 má proto každý uživatelský účet svůj identifikátor, kterému se říká Security ID neboli SID. SIDy uživatelských účtů a některých skupin uživatelů vypadají takto: S-1-5-21-IDdomény-relativníID

IDdomény je 96bitové číslo, identifikující umístění uživatelského účtu – buď v určité doméně nebo na konkrétním počítači, kde mohou být místní účty uloženy. Část relativníID identifikuje konkrétní účet v daném umístění. Vezmeme to více konkrétně: při každé instalaci Windows na nějakém počítači tento systém obdrží (pravděpodobně) jedinečné 96bitové číslo, které předtím neměl přidělen žádný jiný počítač (a žádný jiný už ho také nedostane). K tomuto dojde též při vytváření domény; každá doména obdrží 96bitový ID, který žádná jiná doména (ani počítač) nemá ani nebude mít. Dejme tomu, že vytvořím doménu s názvem http://www.velkafirma.cz. Při procesu vytvoření této domény je generováno náhodné 96bitové číslo; uvažujme třeba o tom, že to bude číslo 12345. (Je to sice vysoce nepravděpodobné, ale začněme menšími čísly.) Každý uživatelský účet, vytvořený v této doméně, bude mít SID ve tvaru S-1-5-21-12345-relativníID, přičemž doména začne přiřazovat relativní ID od hodnoty 1000. První vytvořený uživatelský účet tedy bude mít SID S-1-5-21-12345-1000, druhý uživatelský účet bude mít SID S-1-5-21-12345-1001 atd. Do domény http://www.velkafirma.cz může dále patřit členská pracovní stanice, na které pochopitelně mohou být umístěny místní účty uživatelů, a tato pracovní stanice může během instalace dostat přidělen náhodně vygenerovaný identifikátor 999999999999999999999999 (i tato hodnota je v praxi vysoce nepravděpodobná), takže libovolný uživatelský účet na této pracovní stanici bude mít SID ve tvaru S-1-5-21-999999999999999999999999-IDrelativní. Pokud by šlo o mou pracovní stanici, měl bych na ní asi svůj uživatelský účet se SID S-1-5-21-999999999999999999999999-1000 (opět 1000,

Kapitola 2 – Řízení uživatelských účtů

protože při vytváření uživatelských účtů se začíná od tisícovky a můj účet bude na mé pracovní stanici s nejvyšší pravděpodobností jediný) a dále samostatný doménový účet se SID S-1-5-2112345-1062. Terminologická odbočka: relativní ID se často zkracuje jako RID. Identifikátor RID mého místního účtu tedy bude 1000, a RID mého doménového účtu bude 1062. Některé uživatelské účty mají pevně dané RID a jsou označovány jako „well-known RID“ (dobře známý RID). Nejznámější ukázkou dobře známého RID je číslo 500, což je RID vestavěného účtu Administrator. Zopakujme si, že pokud se Windows týká, pro ně jste jen váš SID. O vše jméno se Windows starají asi tak jako o vaši velikost bot; je to jen jeden z atributů vašeho uživatelského účtu. Máte-li explicitně uděleno právo přístupu třeba ke složce nebo souboru, není toto oprávnění uloženo ve tvaru „Franta Vopršálek má právo úplného řízení ke složce C:\FrantovySoubory" – to v žádném případě, vypadá to spíš takto: „S-1-5-21-999999999999999999999999-1005 má právo úplného řízení ke složce C:\FrantovySoubory“. Už se vám někdy stalo, že jste otevřeli okno vlastností nějakého objektu (souboru, složky …) a na stránce Zabezpečení namísto ikonky s dvěma černovlasými a modrookými hlavami viděli jen prázdnou osnovu s otazníky? To jste zažili kvůli tomu, že do oprávnění se ukládají SID, nikoli jména. Pokud tedy otevře stránku vlastností objektu na členském serveru – který neobsahuje kopii doménových jmen uživatelů a jejich SID, protože jde jen o člena domény – musí členský server navázat spojení s řadičem domény (a nejdřív ho musí najít), kterého požádá o zaslání jmen patřících k jemu známým identifikátorům SID. Tato komunikace někdy trvá delší dobu (i pár minut), proto někdy uvidíte prázdnou osnovu s otazníky; je to důsledek pomalé sítě nebo pomale reagujícího řadiče domény. Někdy se může stát, že některé prázdné hlavy zůstanou natrvalo a nezmizí; v tomto případě jste kdysi udělili nějaké právo k tomuto objektu uživateli či skupině, který(á) byl(a) následně odstraněna. Oprávnění přístupu k souborům a složkám jsou ukládána v systému NTFS, který je spravuje. Souborový systém nemá ponětí o tom, co provádí ta část Windows, která se stará o samotné účty uživatelů, proto nemůže sama odstranit oprávnění přístupu pro zrušené účty a skupiny. TIP:

Tato osiřelá přístupová oprávnění se dají řešit a odstranit pomocí nástroje subinacl, který je součástí Resource Kitu.

Vaše skupiny: seznam SID Za vaším SID je v tokenu uložen seznam skupin, jejichž členy jste, v to počítaje ■

Doménové globální skupiny

■

Doménové universální skupiny

■

Doménové místní skupiny

■

Vestavěné místní skupiny, například Administrators a Users

■

Normální místní skupiny, například ty, které jste na stanici vytvořili vy nebo některá aplikace

Seznam skupin v tokenu však neobsahuje názvy těchto skupin, ale obdobně jako u vašeho jména jejich SIDy. Některé SID skupin začínají na S-1-5-21- stejně jako SID uživatelů (to je případ SIDů

Hlubší ponor do problematiky UAC

skupin Domain Admins a Domain Users, které skutečně vypadají jako uživatelské identifikátory SID – jejich dobře známé RIDy mají hodnotu 512 a 513). Vestavěné skupiny na místních systémech neobsahují část IDdomény, která byla vysvětlena v předchozím textu; místní skupina Users má na každé kopii Windows vždy SID s hodnotou S-1-5-32-545, a skupina Administrators má SID s hodnotou S-1-5-32-544. Existují také „dobře známé“ skupiny (well-known groups), u kterých je seznam členů budován letmo; sem patří například skupina Everyone (S-1-1-0) nebo Interactive (S1-5-4), jejímž členem se stanete, pokud fyzicky sedíte u počítače a pracujete na něm.

Vaše oprávnění: co můžete dělat Windows vám dávají právo dělat i různé jiné věci než mít právo čtení či zápisu k určitému souboru, účtu uživatele, službě apod. Nechají vás provést i některé další úlohy, které těžko zapadají do klasického způsobu klasifikace vycházejícího z oprávnění, například možnost vypnout počítač nebo změnit jeho systémový čas. Windows definují schopnost provést určité funkce buď jako právo (right) nebo jako oprávnění (permission). Výraz „právo“ se používá v případě, kdy je řeč o možnosti připojit se nebo nepřipojit k něčemu, proto schopnosti „přihlásit se místně k danému počítači“ nebo „zakázat přístup k tomuto počítači po síti“ patří mezi práva. Všem ostatním schopnostem se říká „oprávnění“. POZNÁMKA:

Na tomto místě byste mohli začít namítat, že Microsoft mohl například hodiny zpřístupnit coby objekt, ke kterému by uživatelé měli určitá oprávnění (například oprávnění změnit systémový čas nebo časové pásmo); potom by se dala tato oprávnění udělovat nebo odebírat přímo na stránce Zabezpečení v dialogovém okně vlastností namísto nutnosti upravovat privilegia, a že je proto zbytečné rozlišovat mezi právy a pravomocemi (oprávněními). Existují však určité schopnosti, které by pravděpodobně nebylo možné vtěsnat do modelu oprávnění. Vezměme si jako příklad třeba „právo převzít vlastnictví“. Toto právo umožňuje správcům převzít vlastnictví libovolného objektu nezávisle na tom, jak moc mají přístup k němu zakázán. Neexistuje způsob, jak tuto činnost implementovat jako oprávnění, aniž bychom zásadně nerozbourali celý model zabezpečení. S ohledem na podstatu věci to nikdy nemůže být oprávnění, ale jen schopnost zmocnit se postavení (vlastnictví), které by následně udělilo oprávnění pro nastavování oprávnění! V každém případě jsou práva a oprávnění ve Windows rozlišována už po delší dobu a nemyslím si, že by se to mělo brzy změnit. I když, Vienna se blíží….

Se … SeCo? Ve Vistě je definováno 34 různých typů uživatelských oprávnění (privilegií) a 10 různých typů práv pro uživatelské účty. Když vidíte popisy privilegií, mohou být vyjádřeny dvojím způsobem. V prvním případě půjde o krátký anglický popis privilegia, například „change the system time“ (změnit systémový čas). Jak je z tohoto názvu zřejmé, člověk s tímto privilegiem může změnit čas systémových hodin. Ale při nízkoúrovňovém programování bezpečnostních prvků Windows nemusí vývojáři v kódu vypisovat „change the system time“; každé privilegium má ještě svůj krátký název, který má tvar Se něco Privilege. Například krátký název privilegia „change the system time“ vypadá takto: „SeSystemtimePrivilege“. Krátké, byť kryptické názvy byly zavedeny především kvůli většímu pohodlí vývojářů, a jak jednou CEO Microsoft Steve Ballmer skvěle vysvětlil, u Microsoftu se zaměřují především na blaho vývojářů.

Kapitola 2 – Řízení uživatelských účtů

POZNÁMKA:

Ve skutečnosti to Ballmer – obecně známý pro svůj plamenný styl vystupování – vysvětlil tak, že nepříčetně vykřikoval „vývojáři, vývojáři, vývojáři …“. Tento způsob projevu má hodně v oblibě, přestože si musel nechat po jednom takovém výstupu v roce 1991 operovat hlasivky. Tehdy na konferenci v Japonsku asi milionkrát skandoval „Windows, Windows, Windows“. Podle mého odhadu to udělal pravděpodobně proto, aby obecenstvo zapomnělo na to, že ani ne před dvěma roky rozhlásil do celého světa, že tím operačním systémem, za kterým stojí na 110 procent, tím systémem, který nás slavnostně vtáhne do 21. století, je… OS/2. Je to ale zjev, který je radost poslouchat. Svůj nejoblíbenější ballmerismus jsem uslyšel, když vysvětloval davu lidí, mezi kterými jsem byl, že nová verze Office (zapomněl jsem už, která to byla) lidem umožní vytvářet ještě „údernější“ (impactful) prezentace. Jen si to představte – angličtina má celkem 411 000 slov a Steve stejně musí vytvářet další.

Pokusím se zapamatovat si, abych v následujícím textu používal jak „Se pojmy“, tak popisné fráze, protože popis sice lépe vyjadřuje účel daného privilegia, Microsoft má však tendenci používat v dokumentaci především krátké názvy. Vaše privilegia jsou součástí vašeho tokenu, z nějakého důvodu však v něm chybí vaše práva – domnívám se, že deklarovat schopnost přihlásit se do systému poté, co jste k němu již přihlášeni, je nesmyslné. Jak bylo probráno již v první kapitole, standardní uživatelé mají při zapnutém UAC celkem pět oprávnění: ■

Možnost vypnout systém (SeShutdownPrivilege).

■

Možnost manipulovat se souborem či složkou, ke které mají přístup, a to dokonce i v případě, kdy se daný soubor nebo složka nachází v hierarchii uvnitř složek, ke kterým uživatel přístup nemá. Toto oprávnění je označováno jako „bypass traverse checking“ a SeChangeNotifyPrivilege.

■

Možnost odpojit notebook z dokovací stanice, SeUndockPrivilege.

■

Oprávnění zvětšit „pracovní sadu procesu“ (process working set), což je slangová fráze pro „množství paměti, které program používá“. Jedná se o nové privilegium, které před Vistou neexistovalo a já předpokládám, že Microsoft plánuje odepřít toto privilegium některým servisním účtům, aby znemožnil službě napadené některým z buffer overflow červů začít postupně vyčerpávat volnou paměť RAM počítače. Krátký název je SeIncreaseWorkingSetPrivilege.

■

Možnost změnit časové pásmo pracovní stanice. Toto je také novinka Visty, jejímž cílem je konečné řešení starého problému. Nechceme, aby měl každý uživatel možnost měnit systémový čas, protože hodiny musí být synchronizovány se sítí, aby správně fungovala služba Active Directory, a především rozhodně netoužíme po tom, aby si různí zlí hošani mohli hrát se systémovým časem, takže by v protokolu událostí měly položky dokumentující jejich zlé skutky nesprávné a zavádějící časové údaje. Ale zaměstnanci cestující po celém kontinentu či planetě potřebují, aby hodiny v počítači souhlasily s časovým pásmem, ve kterém se právě nacházejí, proto Microsoft vyčlenil tuto funkčnost do nového oprávnění, jehož krátký název je SeTimeZonePrivilege.

Hlubší ponor do problematiky UAC

Podívejme se nyní na to, proč Vista implicitně přiděluje standardním uživatelům právě těchto pět oprávnění. Není to tak, že autoři Visty si prostě řekli: „standardní uživatelé obdrží těchto pět privilegií a basta“; ve skutečnosti jste v tomto případě byli původně přihlášeni jako člen místní skupiny Administrators, a tato skupina měla přidělena všechna uvedená oprávnění. Když vám Vista odebrala členství ve skupině Administrators, přišli jste o všechna oprávnění. Teď se zaměříme na případ standardního uživatelského účtu, kterému správce přidělil několik dodatečných oprávnění. Co když například správce vašemu účtu přidělí oprávnění „change the workstation's clock“ – bude vám toto oprávnění stále patřit, když se přihlásíte za dozoru bdělého oka UAC? Platí přece, že UAC nechce, aby standardní uživatelé měli některá privilegia, ale změna času pracovní stanice mezi ně nepatří. (Připadá mi to dost divné především s ohledem na to, co jsem před chvílí psal o novém oprávnění pro změnu časového pásma, ale tak to prostě je.) Existuje celkem 34 uživatelských oprávnění, které může libovolný uživatel nebo skupina vlastnit. UAC má námitky pouze proti devíti z nich: ■

Vytvoření objektu tokenu (create a token object) neboli SeCreateTokenPrivilege je oprávnění vytvářet tokeny typu, který byl rozebírán o několik stránek nazpátek. Je jasné, že toto privilegium může nabídnout vskutku neobyčejnou sílu, protože vám dovolí napsat si svou vlastní stvrzenku o vlastnictví práv!

■

Vystupovat jako část operačního systému (act as a part of the operating systém, SeTcbPrivilege) je oprávnění, kterému se říká „Svatý grál hackerů“. Bylo základem nástroje Resource Kitu s názvem su.exe (což byl předchůdce pozdějšího Spustit jako) a jde o nezbytnou součást procesů, při kterých předstíráte, že jste někdo jiný. Hodí se například v případech, kdy odlaďujete hardware, standardní uživatelé ho ale nepotřebují.

■

Převzít vlastnictví souborů a jiných objektů (take ownership of files and other objects, SeTakeOwnershipPrivilege) je dost známé oprávnění, ale pro ty, kteří o něm ještě neslyšeli, uvádím, že toto privilegium umožňuje jeho nositeli převzít nejen vlastnictví, ale i úplné řízení souborů, složek, služeb, součástí Active Directory a dalších věcí. Mezi „další“ v tomto případě patří i popisky integrity Windows, které budeme probírat ve čtvrté kapitole, a to je věc, se kterou by si uživatelé rozhodně neměli zahrávat.

■

Nahrávat a uvolňovat ovladače zařízení (load and unload device drivers, SeLoadDriverPrivilege) je velká zlomyslnost, protože ovladač zařízení může provádět mnohem více věcí, než jen oživit kus železa či plastu. Mnohé aplikace jsou na ovladačích závislé ne proto, že by byly závislé na speciálním kusu hardwaru, ale protože ovladač tohoto zařízení může nahlížet do libovolného místa v systému a často i měnit libovolnou datovou strukturu v systému. Chcete se kouknout na uložená hesla? Napište si ovladač zařízení. Poté ho ale musíte nainstalovat, a v tom se vám UAC pokouší zabránit.

■

Zálohovat a obnovit soubory a adresáře (back up and restore files and directories, SeBackupPrivilege a SeRestorePrivilege) tvoří dvojici oprávnění, kvůli které mnoho bezpečnostních expertů strávilo bezesné noci, věřte nevěřte. Zkuste si někdy toto: vytvořte soubor a odeberte si veškerá přístupová práv k němu. Poté spusťte některý zálohovací program (vyzkoušejte jich klidně víc). Zálohu se vám podaří vytvořit, i když záložní program

Kapitola 2 – Řízení uživatelských účtů

běží pod vaším účtem. Proč? Protože privilegia SeBackupPrivilege a SeRestorePrivilege jsou „zadní vrátka“, která vám dovolují soubory číst (SeBackupPrivilege) a zapisovat (SeRestorePrivilege) i v případech, kdy vám k souborům schází potřebná oprávnění NTFS. ■

Zosobnění klienta po ověření totožnosti (impersonate a client after authentication, SeImpersonatePrivilege) se podobá privilegiu „vystupovat jako část operačního systému“ v tom, že dovoluje hackerům skrývat během práce na počítači svou totožnost. UAC proto toto oprávnění blokuje.

■

Změnit popisek objektu (modify an object label, SeRelabelPrivilege) je oprávnění měnit úroveň integrity povinného řízení objektu. Řízení integrity Windows jsme zatím neprobírali, ale jedná se o velmi důležitou novou vlastnost Windows, na kterou se zaměříme ve čtvrté kapitole. Stručně řečeno, jde o způsob vyjádření stupně důvěryhodnosti souboru nebo uživatele, něco jako klasifikace věcí z hlediska zájmů státu, kdy jsou používány pojmy jako „důvěrné“, „tajné“, „přísně tajné“ atd. Uživatelé s tímto oprávněním mohou měnit klasifikaci objektů v podstatě libovolným způsobem, což rozhodně není moc dobrý nápad.

■

Ladit programy (debug programs, SeDebugPrivilege) nedovoluje, jak by se mohlo zdát z jeho názvu, ladit programy; to vám povolí příslušný debugger. Ale vývojáři, kteří ladění provádějí, musí mít možnost nahlížet na procesy a datové struktury programů, a tyto procesy a datové struktury jsou v podstatě vlastněny kýmkoli, kdo tyto programy spouští. Proto můžete spustit debugger a bezproblémově zkoumat vlastní programy. Ale co když potřebujete přezkoušet programy spuštěné na operačním systému, které nevlastníte (což je v praxi většina operačního systému)? To budete potřebovat o něco vyšší privilegium … konkrétně „debug programs“. Zapamatujte si, že toto oprávnění nemusíte přidělovat běžným vývojářům, pokud náhodou nepřepisují samotný operační systém!

Pravděpodobně jste se již potkali s oprávněním SeDebugPrivilege, ať už o tom víte či nikoli. Pokud jste někdy na Windows 2000 nebo pozdější verzi Windows spustili Správce úloh, možná jste si všimnuli zaškrtávacího políčka v levém dolním roku Správce s popiskem „Zobrazit procesy všech uživatelů“. Toto políčko je tu proto, že standardní uživatel má plná práva sledovat a spravovat své vlastní procesy, ale nemá žádné právo zkoumat, co dělají jiní uživatelé na jeho systému. Pokud má však přiděleno privilegium SeDebugPrivilege, může toto políčko zapnout a sledovat celý operační systém. Vzhledem k tomu, že UAC blokuje jen Notoricky Známou Devítku, máme tu celkem 25 uživatelských oprávnění, které uživatelé mohou využívat bez nutnosti žádat o povýšení privilegií svého účtu.

Vaše úroveň integrity Windows A konečně poslední věc, kterou uvidíte v tokenu na systému Vista, je vaše aktuální úroveň integrity Windows. Jedná se o zcela novou ideu, poprvé uvedenou právě ve Vistě, kterou rozebereme ve čtvrté kapitole. Nicméně v této kapitole se neobejdeme bez znalosti několika základních pojmů. Úrovně integrity Windows jsou nástrojem popisu toho, jak moc vám operační systém „důvěřuje“.

Hlubší ponor do problematiky UAC

Existuje celkem šest úrovní integrity Windows, nyní se zaměříme jen na dvě z nich: střední (medium) a vysokou (high). Standardní uživatelé dostávají střední úroveň integrity, správci vysokou. Úrovně integrity Windows jsou ve vašem tokenu vyjádřeny jako SID. Formát tohoto SIDu je S-1-16-hodnota, kde hodnota je číslo 8192 (střední úroveň) nebo 12 288 (vysoká úroveň).

Jak zobrazit údaje ze svého tokenu V tomto okamžiku máte možná chuť zjistit něco bližšího o svém tokenu. Vista nám naštěstí poskytuje příjemný nástroj příkazového řádku, ve kterém se tokeny dají prozkoumat velmi snadno: jedná se o program whoami.exe. Otevřete okno příkazového řádku a zapište whoami /user. Když jsem tento příkaz spustil pod účtem „marek“ z domény „http://www.velkafirma.cz“, whoami vypsalo tyto údaje: C:\pokusy>whoami /user INFORMACE O UŽIVATELI ---------------Uživatelské jméno SID ============ ============================================== velkafirma\marek S-1-5-21-1592023571-1864867759-2423328773-1010

První částí libovolného tokenu je – to už víte – SID uživatele, a příkaz whoami /user ho skutečně vypíše. Dále se podívejme na to, do kterých skupin uživatel je náš účet zařazen. Tyto informace vypíše příkaz whoami /groups. Když jsem ho spustil na svém systému, uviděl jsem toto: C:\pokusy>whoami /groups GROUP INFORMATION ----------------Název skupiny

Typ

Everyone Známá skupina BUILTIN\Users Alias BUILTIN\Administrators Alias NT AUTHORITY\INTERACTIVE Známá skupina VELKAFIRMA\Domain Admins Skupina Mandatory Label\Medium Mandatory Level

SID S-1-1-0 S-1-5-32-545 S-1-5-32-544 S-1-5-4 S-1-5-21... S-1-16-8192

Váš výpis bude vypadat trochu jinak, musel jsem výstup trochu upravit, aby se mi vešel na stránku. Přitom jsem vymazal některé zajímavé údaje, ale za chvíli je vrátím zpět a vysvětlím je. Už teď ale nepřehlédněte v tomto výpisu příslušnosti do skupin, že můj účet je členem jak místní skupiny správců (BUILTIN\Administrators), tak doménových správců (VELKAFIRMA\Domain Admins); vypadá to tedy tak, že tento účel nebyl zkrácen o žádná privilegia – to ale není pravda, jak za chvíli uvidíte. Všimněte si také toho, že moje úroveň integrity Windows je tu vidět jako SID s hodnotou S-1-16-8192. Operační systém toto neoznačuje přesně jako „střední úroveň integrity Windows“, ale popisuje to jako „Mandatory Label\Medium Mandatory Level“, ale v době, kdy tuto knihu čtete, snad příslušní lidé v Microsoftu tento nesoulad až trochu chaos v názvech odstraní.

Kapitola 2 – Řízení uživatelských účtů

Nyní se vrátíme k tomu, že můj token obsahuje záznam o členství ve skupině BUILTIN\Administrators, ale pokud se pokusím udělat něco souvisejícího se správou systému, buď se mi to nepodaří, nebo se objeví Consent UI, které do hry zapojí odlišný token. Výpis příkazu whoami /groups je dost široký, pokud ho posunete směrem doleva, uvidíte v pravé části sloupec, který jsem v předchozí ukázce vypustil. Jeho název je „Atributy“. TIP:

Nemáte-li náladu posouvat výpis doleva či doprava, jak to nakonec přestalo bavit i mne, můžete příkazu whoami předat argument /fo list, který zformátuje vypsané údaje jako seznam (takže příkaz bude mít tvar whoami /groups /fo list), případně se dá výstup upravit i pro načtení do sešitu Excelu jako formát CSV (argument /fo csv).

U většiny skupin najdeme atributy „Povinná skupina, Ve výchozím nastavení povoleno, Povolená skupina“, což v podstatě znamená „UAC tuto skupinu přehlíží“. Když se ale podíváte na atributy skupiny BUILTIN\Administrators, uvidíte tam „Skupina použitá pouze k odmítnutí“ Cože? Co-to-je? Inu, většinou platí, že když souboru, složce nebo něčemu jinému přidělíme oprávnění, jedná se o oprávnění „povolující“. Když říkáme, že někomu dáme „právo čtení“ pro určitou složku, znamená to ve skutečnosti, že jsme vytvořili „položku řízení přístupu“ – oprávnění – povolující oprávnění „číst“. Dá se však vytvořit také položka řízení přístupu, které oprávnění „číst“ zakazuje. Obvykle se vytvářením zakazujících oprávnění nikdo nezatěžuje, implicitně totiž platí, že když k něčemu nevlastníte žádné „povolující“ oprávnění, máte přístup k dané věci zakázán. „Zakazující“ oprávnění však někdy mají význam, takže co vlastně udělalo UAC? Nechalo mne sice zařazeného do skupiny BUILTIN\ Administrators, ale jen do té míry, že povoluje někomu zakázat mi přístup k něčemu. Řečeno jinak: pokud chci udělat něco souvisejícího se správou, nebudu to moci provést, protože z mého tokenu uživatele se standardním oprávněním byla odebrána všechna „povolující“ oprávnění zmiňující skupinu Administrators, ale pokud jsem předtím nebyl schopen něco udělat i coby člen skupiny Administrators kvůli explicitnímu oprávnění „táhněte do háje, správci!“, pak se mne toto omezení stále týká. Být správcem jsou jen samé nevýhody, výhoda žádná! Viděli jsme, že UAC odebere z tokenu standardního uživatele členství ve skupině BUILTIN\Administrators, ale není to jediná věc, která je zablokována. Abych zjistil, které skupiny byly z tokenu uživatele se standardním oprávněním vystřiženy, zkusil jsem vytvořit místního uživatele a přidat ho do všech vestavěných skupin Visty. Poté jsem spustil příkaz whoami /groups /fo a podíval jsem se, které položky řízení přístupu měly nastaven atribut „pouze k odmítnutí“. Našel jsem celkem čtyři skupiny: ■

BUILTIN\Administrators

■

BUILTIN\Backup Operators

■

BUILTIN\Power Users

■

BUILTIN\Network Configuration Operators

Členství ve všech ostatních vestavěných skupinách je předáno rovnou do tokenu uživatele se standardním oprávněním. Kromě toho jsem byl ještě překvapen tím, že v tokenu standardního uživatele zůstalo zařazeno moje členství v doménové skupině Domain Admins.

Hlubší ponor do problematiky UAC

Souhrn: Přerod ze správce ve standardního uživatele Když jsme trošku prošťourali token uživatele se standardním oprávněním, zkusme shrnout, co se přesně stane, když UAC vytvoří z účtu správce token uživatele se standardním oprávněním. ■

V tokenu uživatele se standardním oprávněním budete mít zapsán stejný SID uživatele jako v tokenu plného přístupu správce.

■

Ztratíte všechna privilegia Notoricky Známé Devítky: vytvořit token, vystupovat jako část operačního systému, přebírat vlastnictví objektů, nahrávat a uvolňovat ovladače zařízení, zálohovat a obnovit soubory a adresáře, zosobnit klienta, měnit popisek a ladit programy.

■

Vaše úroveň integrity Windows spadne z vysoké (S-1-16-12288) na střední (S-1-16-8192).

■

Udržíte si členství ve všech skupinách s výjimkou Proslulé Čtyřky (BUILTIN\Administrators, BUILTIN\Backup Users, BUILTIN\Power Users a BUILTIN\Network Configuration Operators). Členství v těchto skupinách vám bude zachováno, ale jen v případě, kdy toto členství umožní někomu zakázat vám přístup k nějakému objektu. I když vám skupina propůjčí některé oprávnění Notoricky Známé Devítky a udržíte si členství ve skupině … přesto ztratíte všechna zakázaná oprávnění, dokud si svá privilegia nepovýšíte. Pokud jste tedy členem skupiny Domain Administrators, zůstanete členem této skupiny; ztratíte však členství v místní skupině Administrators, které jste předtím obdrželi jen jako vedlejší důsledek toho, že jste byli zařazeni mezi doménové správce.

Jak říci UAC, aby použilo váš token plného přístupu správce Poté, co jsme prozkoumali token uživatele se standardním oprávněním, využijme svou plnou sílu, kterou nám dává token plného přístupu správce. Ale jak na to?

Příkaz Spustit jako umožní otevřít okno příkazového řádku s přiděleným tokenem správce Variace na nástroj, který již nejspíše znáte: příkaz Spustit jako (RunAs). Ve Windows 2000, XP a 2003 jste mohli systému přikázat při spuštění libovolného příkazu, aby spustil daný příkaz, ale nepřipojoval k němu váš token, nýbrž token jiného uživatele“. V malém dialogovém okně jste poté vybrali název účtu a zapsali jeho heslo; systém poté připojil ke spouštěnému programu token tohoto účtu. Příkaz Spustit jako (RunAs) je ve Vistě stále dostupný jako nástroj příkazového řádku, pro většinu lidí je však jednodušší klepnout pravým tlačítkem myši na položku nabídky Start nebo ikonu programu a v místní nabídce vybrat příkaz „Spustit jako správce“, který vidíte na obrázku 2.2. Jestliže jste pracovali na Windows 2000, XP nebo 2003, určitě si hned všimnete rozdílu v této místní nabídce. Ve starších Windows jste vybrali „Spustit jako…“ a poté zapsali jméno účtu, pod kterým měl být program spuštěn, a jeho heslo; Nyní je tu namísto toho jednodušší příkaz „Spustit jako správce“. Pro některé lidi to bylo velké zklamání, protože při testování zabezpečení nově konfigurovaných systémů nebo systém se změněným nastavením jste mohli velmi rychle spustit klientský program pod libovolným účtem a poté v klidu testovat daný program s jiným než normálním tokenem, zda je skutečně proti určité skupině zabezpečeno vše, co za chráněné považujete. Byl bych rád, kdyby v místní nabídce byl jak příkaz „Spustit jako správce“, tak příkaz „Spustit jako…“,

Kapitola 2 – Řízení uživatelských účtů

ale Microsoft toto přání nesplnil, proto se s tím nedá nic dělat. Stále je však možné používat nástroj příkazového řádku RunAs, který umí spustit libovolný program pod libovolným účtem uživatele. Jeho neohrabaná syntaxe se vůči systémům XP a 2003 nijak nezměnila. OBRÁZEK 2.2: Spuštění okna příkazového řádku na účet správce

V každém případě platí, že když pravým tlačítkem myši klepnete na něco a zvolíte si příkaz „Spustit jako správce“, Windows vyvolají Consent UI a poté, co tu potvrdíte své přání tlačítkem Pokračovat, Windows spustí požadovanou aplikaci a přiřadí jí token plného přístupu správce namísto tokenu uživatele se standardním oprávněním. Názorně si to můžeme předvést tak, že se přihlásíme k systému Vista jako místní správce, otevřeme prostřednictvím příkazu „Spustit jako správce“ okno příkazového řádku a zde zkusím spustit příkaz whoami /groups /fo. Většinu příkazu tohoto výstupu jsem vypustil, ale pár řádků tu zajímavých je: Název skupiny: BUILTIN\Administrators Typ: Alias SID: S-1-5-32-544 Atributy: Povinná skupina, Ve výchozím nastavení povoleno, Povolená skupina, Vlastní skupiny Název skupiny: Mandatory Label\High Mandatory Level Typ: Neznámý typ identifikátoru zabezpečení (SID) SID: S-1-16-12288 Atributy: Povinná skupina, Ve výchozím nastavení povoleno, Povolená skupina

První položka je zajímavá kvůli tomu, že tu vidíme aktivované členství ve skupině BUILTIN\ Administrators – atribut „Skupina použitá pouze k odmítnutí“ tentokrát chybí. V druhé části vidíme, že SID řízení integrity Windows má nyní hodnotu S-1-16-12288, čili vysoká úroveň integrity Windows.

Hlubší ponor do problematiky UAC

Pokud bych nyní zkusil spustit příkaz net user marek mecoun /add, neobjevilo by se hlášení „přístup byl odepřen“. (Chybové hlášení by se ovšem objevilo, protože účet marek v systému již mám … ale to je zcela o něčem jiném.) Pokud máte stále pochybnosti, spusťte příkaz whoami /priv a podívejte se, jaká privilegia nyní máte. Je to jen těch mizerných pět oprávnění? Kdepak. Já jsem se dopočítal až do třiadvaceti. (Doufám, že mi ta práva nevlezou do hlavy…). Než ukončíme tuto sekci, ještě bych se rád vrátil k jednomu termínu který jsem již zmínil, ale který bych chtěl nyní zdůraznit: „povýšený“ (zvýšený). Namísto starší fráze „spustit okno příkazového řádku pomocí nástroje Spustit jako správce“ se říci také „spustit příkazový řádek se zvýšenými právy“, nebo „spustit povýšený příkazový řádek“. „Povýšit“ zde prostě znamená „spustit s tokenem plného přístupu správce“.

Snadnější otvírání oken se zvýšenými právy Je ale možné, že s vám nechce tak často klepat pravým tlačítkem myši. Přišel tedy čas vypnout UAC? Ještě zdaleka ne. Představím vám několik možností, jak si podržet token uživatele se standardním oprávněním a tak chránit sebe sama, a přitom spouštět aplikace s tokenem plného přístupu správce.

Nechte si plnoprávný příkazový řádek stále otevřen Za velmi pohodlnou a užitečnou věc považuji neustále otevřené okno příkazového řádku, které jsem spustil příkazem „Spustit jako správce“ – mohu tak kdykoli téměř okamžitě spustit libovolný příkaz s privilegii správce. Jakmile takové okno otevřete, můžete si orientaci v prostředí značně vylepšit tak, že v řídicí nabídce tohoto okna klepnete na příkaz Vlastnosti, přejdete v okně vlastností na stránku Barvy a zde si zvolíte jinou barvu pozadí okna; osobně měním černou na tmavě modrou. Tímto způsobem se zároveň chráním před spouštěním běžných úkolů standardního uživatele v tomto okně s plnými privilegii správce, což by mohlo mít destruktivní následky, ke kterým v okně příkazového řádku s tokenem uživatele se standardním oprávněním nemůže dojít. Modré pozadí mi okamžitě říká: „bacha, tady pracuj jen tehdy, když skutečně musíš!“. POZNÁMKA:

Microsoft někdy kolem verze RC1 přidal do okna příkazového řádku jedno upozornění sdám: před název okna je přidán řetězec „Správce:“, který rovněž naznačuje, že jde o okno se zvýšenými právy. Bohužel u ostatních aplikací tento řetězec přidáván do názvu okna není.

Upravte libovolnou ikonu tak, aby automaticky otevřela Consent UI Neustále otevřený povýšený příkazový řádek je skvělá věc, ale pořád si musíte pamatovat, že je třeba v nabídce Start klepnout pravým tlačítkem myši na položku „Příkazový řádek“ a vybrat v místní nabídce položku „Spustit jako správce“. Nedaly by se ikony na pracovní ploše a položky v nabídce Start vytvářet tak, aby automaticky věděly, že mají žádat o token plného přístupu správce? Jistě, to se dá zařídit. Nejprve vytvořte novou položku v nabídce Start, a to stejným způsobem, jako ve Windows 2000, XP nebo 2003: přidáte nového zástupce do některé části složky Programy ve vašem profilu. Ukážu vám to na novém zástupci příkazového řádku, kterého nazvu „Příkazový řádek správce“:

100

Kapitola 2 – Řízení uživatelských účtů

1. Pravým tlačítkem myši klepněte na nabídku Start a v místní nabídce vyberte Prozkoumat. 2. Takto otevřete složku Průzkumníka, ve které je vidět složka Programy. Otevřete tuto složku. 3. Uvnitř složky Programy uvidíte strukturu složek, která zrcadlí hierarchii nabídky Start. Najděte složku, do které chcete umístit Příkazový řádek správce. (Já jsem ten svůj dal do Příslušenství.) Pravým tlačítkem myši klepněte tam, kde chcete mít novou ikonu a v místní nabídce vyberte příkaz Nový  Zástupce. 4. Objeví se průvodce, který se ptá, na jaký cíl má nový zástupce ukazovat. Příkazový řádek ukazuje na soubor cmd.exe ve složce c:\windows\system32, proto do pole s popiskem „Zadejte umístění položky:“ zapište tento údaj nebo klepněte na tlačítko Procházet a najděte soubor cmd.exe. Až budete mít pole správně vyplněno, klepněte na tlačítko Další. 5. Druhá stránka průvodce se ptá, jak chcete nového zástupce pojmenovat. Zde jsem zapsal „Příkazový řádek správce“, vy si však klidně vyberte ten název, který vám vyhovuje – je to jen název, nic jiného. 6. Až zapíšete název zástupce, klepněte na tlačítko Dokončit. Opět uvidíte složku Příslušenství (pokud jste si ji vybrali stejně jako já), nyní však v ní bude navíc ikona „Příkazový řádek správce“. Pravým tlačítkem myši na ni klepněte a v místní nabídce vyberte Vlastnosti. Gratuluji, máte vytvořenu novou položku nabídky Start. Ovšem tato položka ještě není dostatečně inteligentní na to, aby automaticky vyvolala Consent UI a získala tak pro sebe token plného přístupu správce. Musíte ještě pravým tlačítkem myši klepnout na položku, vybrat v místní nabídce Vlastnosti a poté se přepnout na stránku Zástupce, která je zachycena na obrázku 2.3. Prozatím se neděje nic, co byste neznali z Windows 2000, XP nebo 2003. Ale když nyní klepnete na tlačítko Upřesnit…, uvidíte to, co je a obrázku 2.4. OBRÁZEK 2.3: Stránka vlastností Zástupce v okně vlastností zástupce.

Hlubší ponor do problematiky UAC

101

OBRÁZEK 2.4: Dialogové okno Upřesnit vlastnosti

Nelze přehlédnout zaškrtávací políčko „Spustit jako správce“. Podívejte se, jak tato stránka vypadá v XP nebo 2003: najdete volbu „Spustit s použitím jiných pověření“. Microsoft tu opět o něco zredukoval infrastrukturu Spustit jako (RunAs). Zapněte políčko „Spustit jako správce“, dvakrát po sobě klepněte na tlačítko OK (tím zavřete nejdříve dialogové okno Upřesnit vlastnosti a poté okno vlastností zástupce) a zavřete okno Průzkumníka se složkou Příslušenství. Nyní vyzkoušejte postupně spustit Start  Všechny programy  Příslušenství a zde uvidíte položku „Příkazový řádek správce“. Když na ni klepnete, objeví se Consent UI; stačí jen klepnout na Pokračovat a už máte na obrazovce plnoprávný příkazový řádek. (Nevěříte? Spusťte v něm příkaz whoami /all, ale připravte se na to, že tak dlouhý výpis budete muset hodně posouvat.) Toto se dá udělat pro libovolný program; příkazový řádek je jen začátek. Jestliže budete někdy chtít spustit starší program, který vyžaduje token plného přístupu správce, ale Vista není dostatečně inteligentní na to, aby o tento token požádala, dá se takto snadno obejít nutnost klepat pravým tlačítkem myši při každém spuštění programu. TIP:

Než toto téma opustíme, měli bychom dokončit Příkazový řádek správce. Klepněte postupně na Start  Všechny programy  Příslušenství, poté pravým tlačítkem myši klepněte na položku„Příkazový řádek správce“ a v místní nabídce vyberte Vlastnosti. Přepněte se na stránku Zástupce a zde na konec pole Cíl: , ve kterém je momentálně zapsáno C:\Windows\System32\cmd.exe, přidejte /T:1F a neuzavírejte tento přepínač do uvozovek. Okno příkazového řádku se následně bude spouštět s tmavomodrým pozadím a bílým textem. Díky tomu není pak nutné nastavovat barvy ručně při každém spuštění příkazového řádku, zástupce to udělá za vás, když na jeho kartě vlastností požadované barvy zadáte jako přepínač. Na mou duši, podobné barevné odlišení speciálního příkazového řádku s povýšenými pravomocemi důrazně doporučuji – poté se mi už UAC nezdálo tak otravné …

Popsaný postup úpravy funguje velmi dobře u položek nabídky Start a zástupců, protože se jedné v podstatě o stejné objekty, ale pokud se pokusíte vyznačit potřebu povýšení práv u konkrétního souboru EXE, uvidíte něco trochu jiného. POZNÁMKA:

Píšu-li „soubor EXE“, mám na mysli většinu souborů, ve kterých jsou obsaženy programy. Když spustíte Poznámkový blok, říkáte ve skutečnosti operačnímu systému, aby nahrál do paměti a spustil soubor notepad.exe. Pokud jste nikdy takový soubor neviděli, otevřete si složku Počítač a v ní přejděte do složky Windows\ System32. Přitom je třeba přikázat Vistě, aby zobrazovala přípony souboru, jinak uvidíte jen „notepad“ namísto „notepad.exe“.

102

Kapitola 2 – Řízení uživatelských účtů

Jako příklad úpravy vlastností programu použiji simple.exe, který jsem napsal kdysi dávno, když ještě po Vistě nebylo ani vidu ani slechu. Pokud u něho chci vyznačit nutnost povýšení práv, vyvolám pravým tlačítkem myši místní nabídku a v ní se přepnu na stránku vlastností Kompatibilita, kterou vidíte na obrázku 2.5. Všimněte si zaškrtávacího políčka „Spustit tento program jako správce“. To je třeba zapnout, aby byl program spouštěn s povýšenými právy, protože stránka vlastností Zástupce zde chybí. POZNÁMKA:

Proč tu upozorňuji na to, že se jedná o aplikaci nepsanou pro operační systém Vista? Pokud nahlédnete na stránku vlastností Kompatibilita u aplikace psané pro Vistu, bude celý obsah této stránky nedostupný.

Podotýkám, že když jsem já zaškrtnul uvedené políčko, aby se UAC pokusil o povýšení práv souboru simple.exe, bude tato změna platit jen v případě, kdy já budu spouštět soubor simple.exe. Člověk přihlášený na mém počítači na jiný uživatelský účet nemá na povýšení práv příkazového řádku nárok, a jeho pokus o spuštění simple.exe by pravděpodobně kvůli nedostatečným právům úplně selhal. Tuto chybu opravíme: klepněte na tlačítko „Zobrazit nastavení pro všechny uživatele“, kterým otevřeme obdobně vypadající stránku, ve které je možné zapnout políčko „Spustit tento program jako správce“ pro všechny uživatele. OBRÁZEK 2.5: Stránka vlastností Kompatibilita u aplikace psané pro starší operační systémy

Někdy povýšení práv prostě nefunguje Jakmile jsem si zvyknul vytvářet zástupce se zapnutou volbou „Spustit jako správce“, uvědomil jsem si, že je tu jeden program, u kterého skutečně nezbytně potřebuji práva správce, aniž bych si přiděloval přes pravé tlačítko myši: Průzkumník Windows. Počítal jsem s tím, že bych ušetřil spoustu času při řešení velmi častých nedostatečných oprávnění při pohybu na svém pevném disku. Bohužel, není to možné.

Hlubší ponor do problematiky UAC

103

S ikonou Průzkumníka si sice můžete různě pohrávat a zaškrtávat v jejích vlastnostech políčko „Spustit jako správce“ jak chcete, ale nic se nestane. Při přihlášení k systému se spustí kopie Průzkumníka; to je neodmyslitelná součást přihlašovacího procesu. Když se poté pokusíte spustit druhou kopii Průzkumníka, neobjeví se druhá kopie, ale ta první. Průzkumník při své inicializaci zkoumá, zda už není spuštěna jeho jiná kopie. Pokud ano, Průzkumník se podruhé nespustí, ale otevře nové okno stejné (první) kopie Průzkumníka, která má – jak jste jistě uhodli – přidělen pouze token uživatele se standardním oprávněním. Z toho vyplývá, že neexistuje žádný způsob, jak spustit průzkumníka s tokenem plného přístupu správce. Je sice pravda, že kdysi šlo spustit více na sobě nezávislých kopií Průzkumníka, ale jak se zdá, Microsoft tuto schopnost odstranil, pravděpodobně kvůli zabezpečení. Je to smutné, ale Průzkumník s právy správce se nekoná.

Okno Consent UI se nedá obejít Jednou z rad, které tu pravděpodobně očekáváte, je návod na vytvoření ikony, na kterou stačí jen klepnout a odkazovaný program se spustí s tokenem plného přístupu správce. To nejde, jedině že byste úplně vypnuli UAC. Účelem UAC je přece zabránit vám bezmyšlenkovitě spouštět programy na úrovni správce systému.

Jak Windows poznají, kdy mají použít token plného přístupu správce Jednou z možností, jak přesvědčit Vistu k udělení tokenu plného přístupu správce vaší aplikaci namísto tokenu uživatele se standardním oprávněním, je příkaz „Spustit jako správce“, dostupný v místní nabídce. Po pár dnech práce ve Vistě ale poznáte, že tento operační systém otevírá Consent UI i v případech, kdy místní nabídku nepoužijete. Jak Windows Vista pozná ještě před spuštěním programu, že tento potřebuje token plného přístupu správce? Dokáže to celkem čtyřmi různými způsoby: ■

Pokud Vista odhadne, že má spustit instalátor aplikace, protože instalátory velmi často zapisují různé údaje do chráněných míst systémového registru a na pevný disk. V tomto případě se zeptá, zda mu má povýšit privilegia.

■

Vývojáři mohou dát operačnímu systému Vista na vědomí, že aplikace potřebuje token plného přístupu správce, vložením tzv. „manifestu“ do samotného EXE souboru, případně vložením manifestu do stejné složky, ve které se soubor EXE nachází.

■

Průzkumník a Internet Explorer ve Vistě obsahují tzv. „Pomocníka s kompatibilitou programů“, který vyhledává starší programy a zkoumá je z hlediska případných problémů s kompatibilitou (dle stručného vyjádření Microsoftu). Pokud nějaký takový diskutabilní program najde, zeptá se uživatele, zda má takovou aplikaci označit jako program vyžadující token plného přístupu správce. Jestliže uživatel s tímto návrhem souhlasí, uloží PCA do systémového registru záznam o nutnosti vybavit danou aplikaci tokenem plného přístupu správce a při každém následném pokusu o spuštění této aplikace se objeví Consent UI.

■

Vista obsahuje velkou databázi informací o starších aplikací (nazvanou Application Compatibility Database). V této databázi je seznam aplikací, které nepoběží bez tokenu plného přístupu správce. Spustíte-li jednu z těchto aplikací, UAC vyvolá Consent UI.

104

Kapitola 2 – Řízení uživatelských účtů

Není to tak komplikované, jak se zdá na první pohled, a když to pořádně pochopíte, umožní vám to řešit spoustu problémů s rozcházením starších aplikací v prostředí Visty. Podívejme se nyní na jednotlivé body podrobněji, s několika odbočkami, ve kterých uvidíte, jak Vista využívá GUI pro zpětnou vazbu směrem k uživateli, který je informován o tom, co potřebuje povýšení privilegií a co ne.

Vista hledá instalátory Jen velmi zřídka narazíte na instalátor aplikace, který nevyžaduje oprávnění na úrovni správce. Špatně navržené instalátory zapisují různé soubory do složky Windows\System32, přičemž standardní uživatelé mají ve složce System32 jen oprávnění číst, spouštět a zobrazit její obsah, proto při instalaci aplikace zapisující něco do této složky musí mít instalátor práva správce. Lépe navržené instalátory nechávají tuto složku v klidu, ale stále potřebují zapisovat do složky Program Files, ke které mají standardní uživatelé stejná oprávnění jako k System32, a dále zapisovat do větví HKEY_LOCAL_MACHINE\SOFTWARE nebo HKEY_LOCAL_ MACHINE\SERVICES systémového registru, kam standardní uživatelé opět zapisovat nesmějí. UAC proto nepovolí instalátoru zbytečně zkoušet zapisovat do daných složek a namísto toho odhaduje při spouštění programů, zda se nejedná o instalátor: v takovém případě automaticky zobrazí Consent UI. V IT odvětví ovšem nepoužíváme pojem „odhaduje“, že… to by znělo hodně potrhle. Namísto toho řekneme, že aplikace vyhodnocuje pravděpodobnosti na základě „heuristiky“. Ušetřím vám hledání slovníku v knihovně: „heuristika“ je to, co většina z nás označuje jako „empirická pravidla“. Empirická pravidla UAC pro vyčmuchání instalátorů vypadají jak? Existují dvě hlavní zásady: podívat se na název souboru EXE a rozeznat populární typy instalátorů. Pravidlo číslo jedna: pokud se v názvu souboru vyskytne řetězec „setu“, „instal“, nebo „update“, poté je třeba vyvolat Consent UI. Ano, je to velmi jednoduché, a hádání je přitom velmi úspěšné. Moment, znamená to snad, že zlých hochům stačí přejmenovat své instalační programy a tak UAC obejít? Vůbec ne – toto není prostředek pro zastrašení hackerů, ale ochrana proti některým potížím těch „dobrých“ uživatelů. Platí přece, že když přejmenuji „setup.exe“ na „pohodicka.exe“, neobjeví se mi sice Consent UI a Vista můj soubor bezproblémově spustí… jenže problémy se dostaví brzy poté, jakmile se program pokusí o zápis do složek Program Files, System32 nebo do systémového registru. Pravidlo číslo dvě: většina instalačních balíčků byla vytvořena buď pomocí instalátoru Wyse nebo instalátoru Installshield. Pokud vám tato dvě jména nic neříkají, jde o velmi populární aplikace nezávislých dodavatelů softwaru, které značně zjednodušují proces tvorba instalačních balíčků aplikací. Instalátory Wyse i Installshield se dají snadno rozeznat a UAC nemá s jejich detekcí problém. Pravidlo číslo tři: pokud je podezřelá aplikace označena „manifestem“ beroucím ohled na UAC (ten budeme probírat za chvíli), nemá význam ztrácet čas aplikací prvních dvou pravidel a program bude spuštěn s tokenem standardního uživatele. První pravidlo si můžete sami vyzkoušet. Vezměte jakýkoli neškodný soubor EXE psaný pro starší verze Windows, který běží, aniž by potřeboval token plného přístupu správce, přejmenujte ho na setup.exe a od té doby se při pokusu o jeho spuštění pokaždé objeví Consent UI. Zkuste například toto. 1. Zkopírujte program calc.exe z Windows XP do systému Vista. 2. Spusťte calc.exe; Consent UI se neobjeví, okno Kalkulačky z XP ano.

Hlubší ponor do problematiky UAC

105

3. Nyní přejmenujte calc.exe ze systému XP na setup.exe a přejmenovaný program spusťte. Okamžitě se objeví Consent UI a bude vyskakovat při každém pokusu o spuštění této přejmenované Kalkulačky z XP. Oproti tomu – v souladu s pravidlem 3 – po zkopírování calc.exe systému Vista do jiné složky a jeho přejmenování se při spouštění žádné Consent UI neobjeví a přejmenovaná Kalkulačka Visty se spustí bez jakéhokoli obtěžování uživatele. TIP:

Pokud chcete, můžete systému Vista automatickou detekci a povyšování instalačních programů zakázat prostřednictvím zásady skupiny „Řízení uživatelských účtů:Zjistit instalace aplikací a zobrazit výzvu ke zvýšení oprávnění“, jak bude uvedeno v části „Změna konfigurace UAC“.

UAC a GUI Visty Mimochodem, pokud to zkusíte, možná uvidíte dialog z obrázku 2.6. Je to jeden z příkladů toho, jak UAC využívá grafické uživatelské rozhraní Visty buď pro signalizaci toho, jak podrobně máte zkoumat výzvu Consent UI, nebo pro varování, že určitá aplikace bude vyžadovat povýšení práv. OBRÁZEK 2.6: Consent UI v jiném přestrojení

„Bdělostní varování“ Visty Co přesně míním pojmem „bdělostní varování“ (alertness warnings)? Existují celkem čtyři různá dialogová okna, která Consent UI používá, podle toho, jak moc má podle UAC uživatel dávat pozor při povyšování oprávnění aplikací. Liší se od sebe barvami, které mají naznačit uživateli, jak moc ostražitý má být. Vzhledem k tomu, že náš vydavatel tuto knihu tiskne černobíle, můžete tu vidět změny ve vzhledu dialogových oken Consent UI, ale bohužel ne změnu jejich barvy. Consent

106

Kapitola 2 – Řízení uživatelských účtů

UI z obrázku 2.1 má u horního okraje modrozelený pruh. Okno z obrázku 2.6 má u horního okraje pruh oranžový. Barvy jsou voleny takto: ■

Pokud je program podepsán a je od vydavatele, kterého jste zablokovali prostřednictvím zásad skupiny, je pruh u horního okraje dialogového okna červený a obsahuje červenou ikonu se štítem, který Microsoft používá od nástupu XP SP2 jako piktogram pro věci souvisejících se zabezpečením. Zde není tlačítko Pokračovat, jen „OK“.

■

Pokud je program vyžadující práva správce digitálně podepsán Microsoftem jako integrální součást Visty, uvidíte Consent UI z obrázku 2.1, s modrozeleným pruhem u horního okraje a červeno-zeleno-modro-žlutým štítem.

■

Pokud je program vyžadující práva správce digitálně podepsán a podpis projde kontrolou, ale nejde o podpis Microsoftu potvrzující, že jde o integrální součást Visty, uvidíte dialogové okno podrobné předchozí variantě, ale namísto modrozeleného pruhu bude u horního okraje pruh šedý. Ikona se štítem bude šedá a v dialogu jsou tlačítka Pokračovat i Storno. Toto Consent UI potkáte nejčastěji u aplikací jiných výrobců a také u mnoha věcí stažených ze stránek http://www.microsoft.com/downloads.

■

V ostatních případech uvidíte dialogové okno z obrázku 2.6, s oranžovým pruhem u horního okraje a červeným štítem. V tomto případě dialog neobsahuje klasická tlačítka, ale velké „tlačítkové plochy“ Pokračovat a Storno, doplněné o další vysvětlující text.

Budete-li vést školení pro přestup na Vistu, bylo by vhodné zařadit do výkladu i „představení různých dialogů Consent UI“. A myslím si, že to byl od Microsoftu dobrý nápad, zařadit je do Visty… jen mi není jasné, co na to řeknou barvoslepí lidé? Mimochodem, pokud jste někdy od spuštěného počítače s Vistou odešli a nechali Consent UI na obrazovce bez stisku některého z jeho tlačítek, zavře se jeho dialog po uplynutí dvou minut sám a zobrazí další dialogové okno, které zachycuje obrázek 2.7. OBRÁZEK 2.7: Konec vymezené doby pro obsluhu UAC!

Důvod pro toto chování je jednoduchý. Pokud je Consent UI vidět na obrazovce, je přihlášený uživatel správcem systému. Jestliže nikdo na zobrazený dialog Consent UI nereaguje po dobu dvou minut, je požadovaná operace buď nepodstatná, nebo – což je podstatně zneklidňující – je tento počítač s přihlášeným správcem systému bez dozoru… jejda! Microsoft proto nechá dost brzy vypršet platnost výzvy UAC.

Vodítka pro UAC: bude tento software potřebovat povýšení práv? Při návrhu UAC hrál velkou roli požadavek na jasné vymezení okamžiků, kdy uživatel má a kdy nemá vystupovat coby správce. Jak jsem již poznamenal v předchozím textu této kapitoly, součas-

Hlubší ponor do problematiky UAC

107

ný trend přesunu od celodenní práce pod účtem správce na účet uživatele s menším rozsahem oprávnění pramení mimo jiné z toho, že si dost často nejsme jistí – dobrá, vy možná ano, ale já se k tomu klidně přiznám – zda ta či ona věc vyžaduje práva a oprávnění správce. Musím mít například oprávnění správce proto, abych mohl vypnout operační systém? Odpověď zní šalamounsky: „jak kdy“. Hovoříme-li o pracovní stanici, tu zajisté může vypnout každý. Jestliže však hovoříme o řadiči domény, musí být uživatel členem jedné z několika mála skupin, aby měl právo takový počítač vypnout. Nebo jiná věc – možnost úpravy nastavení napájení počítače. Předpokládal jsem, že tuto činnost má povolen každý, ale skutečnost, že Microsoft nechal Vistu ve verzi Beta 2 přeprogramovat tak, aby povolil standardním uživatelům měnit nastavení napájení, znamená, že můj odhad byl špatný. Microsoft začal přesvědčovat vývojáře, aby přidávali čtyřbarevný štít na každé tlačítko nebo jiný typ grafiky, který po odklepnutí myší spustí akci, která vyžaduje povýšení uživatelských oprávnění. Tímto krokem se snaží posílit v uživatelích vědomí rozdílu mezi rolí správce a běžného uživatele a – jak si myslím – varovat standardní uživatele před zbytečným pokusem o provádění administrátorských operací. Na obrázku 2.8 vidíte ukázku rozdílu v ikonách určených pro administrativní a běžné úkoly. OBRÁZEK 2.8: Složka Nástroje pro správu, ikony bez a se štíty

Na obrázku jsem zachytil složku Nástroje pro správu, která je součástí Ovládacích panelů, u které jsem upravil zobrazení na Velké ikony (ve Vistě je k dispozici dokonce i variant největší ikony). Všimněte si, že na ikonách Diagnostika paměti, Konfigurace systému, Iniciátor iSCSI a Zdroje dat (ODBC) jsou položeny ještě menší čtyřbarevné štíty. Tyto ikony jsou vizuálním vodítkem – nebo varováním, podle toho, jak se na ně díváte – říkajícím, že dál cesta pro standardní uživatele nevede. Jako nápad je to sice výtečné, ale nemáte žádnou záruku, že malé štíty uvidíte všude tam, kde by měly být. Když se například podíváte na ikonu Defragmentace disku v nabídce Start  Všechny programy  Příslušenství  Systémové nástroje, budete muset hlavu nachýlit opravdu hodně blízko k monitoru, abyste si tamního mrňavého štítu všimnuli… neumím si představit, že by ji v takovém měřítku na tak malém piktogramu zaznamenala většina lidí. To samé platí, když se znovu podíváte na obrázek 2.8. Je přece nutné být správcem, abyste mohl měnit nastavení Brány firewall Windows, Správy tisku nebo zbylých položek v této skupině? Zajisté; právě proto jsou všechny iko-

108

Kapitola 2 – Řízení uživatelských účtů

ny soustředěny do zvláštní skupiny „Nástroje pro správu“, a ve skutečnosti se Consent UI s výzvou k potvrzení povýšení práv objeví, ať v této skupině poklepete na libovolnou ikonu. Jenže malé šíty jsou doplněny jen na 3 z celkového počtu 14 ikon – proč? Pravděpodobně proto, že tyto tři zvlášť označené ikony směřují na soubory EXE, zatímco zbylých 11 ikon ukazuje na soubory modulů snap-in konzoly MMC. Vista je tedy dostatečně inteligentní na to, aby si program sama obhlédla a pokud se domnívá, že něco vyžaduje povýšení práv, přidá k ikoně programu štít automaticky. Tuto heuristiku si můžete v praxi ověřit během cvičení, které jsem popsal již v předchozí části – pokud zkopírujete soubor calc.exe ze starší verze Windows na počítač se systémem Vista a tento soubor přejmenujete na setup.exe, Vista tuto změnu zaznamená a v Průzkumníkovi Visty bude k ikoně souboru setup.exe doplněn malý štít. Vista však neumí poznat, že povýšení práv vyžaduje také moduly snap-in konzoly MMC. Je to dáno tím, že Průzkumník nespouští tyto moduly přímo, to za něj dělá program MMC.EXE. V něm jsou k modulům ikony doplněny, ale to je málo platné, protože zvědavý uživatel obvykle nespustí MMC.EXE, aby mohl zkoumat moduly snap-in konzoly MMC; namísto toho vidí jejich ikony v Ovládacích panelech a nabídce Start, které přímo spustí. Je možné, že toto umístění ikon se změní v pozdějších sestaveních Visty nebo novějších verzích Windows. Třetím místem, kde jsou vidět v piktogramech malé štíty, jsou applety Ovládacích panelů. Když Ovládací panely otevřete, uvidíte to, co je na obrázku 2.9. OBRÁZEK 2.9: Otevřené okno Ovládacích panelů

Nyní se podívejte do pravého horního okraje okna do části Uživatelské účty. Zde uvidíte hypertextový odkaz „Přidat nebo odebrat uživatelské účty“, který má vedle svého názvu malý štít. Pokud vím, ten není systémem přidán automaticky. Když to celé shrnu, Vista se pokouší dát uživatelům přidáním štítu do ikony programu na vědomí, ke kterým aplikacím musí mít přidělen token plného přístupu správce. Někdy se štít v ikoně objeví proto, že Vista sama odhadne potřebu povýšení práv u dané aplikace a ikonu přidá, jindy tento štít do ikony programu doplní sám její pečlivý vývojář. Nikdy se však nelze spoléhat na to, že malý štít bude všude, kde má být. Buď jak buď, je to dobrý začátek na dlouhé cestě poznání uživatelů, kteří by měli vědět, jaké činnosti jsou správní povahy.

Hlubší ponor do problematiky UAC

109

Vista vyžaduje povýšení práv, pokud o to žádá manifest Vraťme se nyní k našemu průzkumu toho, co způsobuje žádosti o povýšení práv, a podívejme se na nejjistější způsob, jak systému Vista sdělit, že aplikace potřebuje oprávnění správce. U některých zdánlivě normálních aplikací je někdy nutné, aby systém Vista stoprocentně věděl, že daná aplikace potřebuje práva správce, protože výzvy UAC jsou sice velmi otravné, ale mnohem otravnější je pokoušet se spustit aplikaci a po nějaké době si přečíst hlášení systému „přístup odepřen“, znamenající, že aplikace nemůže dokončit svůj úkol. Budeme-li tedy UAC využívat, můžeme si zároveň zajistit „správné“ chování této služby, a nejjednodušší způsob, jak tohoto chování docílit, je prostě této službě říci, co má dělat. Vývojáři (a též my správci, pokud se naučíme pár triků) si požadovanou činnost UAC mohou zajistit prostřednictvím tzv. manifestů.

Co jsou manifesty a k čemu slouží Manifesty jsou krátké textové soubory přidružené aplikaci, které říkají operačnímu systému, jak má danou aplikaci nahrávat a spustit. Manifesty mohou být vloženy přímo dovnitř spustitelného souboru nebo jsou uloženy jako samostatné externí textové soubory, které lze upravit přímo v Poznámkovém bloku. Nehodlám o sobě tvrdit, že jsem kvalitním programátorem – tím rozhodně nejsem – a proto je možné, že problematiku manifestů vysvětlím neúplně, ale vím, že manifesty plní nejméně tři úlohy: ■

Říkají operačnímu systému, jaké verze dynamicky linkovaných knihoven (DLL) aplikace potřebuje.

■

Říkají operačnímu systému, zda má či nemá při vykreslování oken aplikace používat téma XP se zaoblenými rohy.

■

Říkají operačnímu systému, jaký token aplikace potřebuje: token uživatele se standardním oprávněním nebo token plného přístupu správce (je-li dostupný).

Manifesty se prvně objevily již ve Windows XP, společně s tzv. „Windows Side by Side“, což bylo první prostředek, který manifesty ve velké míře využíval. Side By Side mělo odstranit problém označovaný jako „DLL hell“. Než budeme pokračovat, je nutné vysvětlit některé technické záležitosti… Vývojáři při psaní programů nevkládají veškerý kód do jednoho velkého souboru. Důvodem k tomuto chování je fakt, že každý, kdo napíše více jak deset-dvacet programů, velmi rychle zjistí, že v mnoha různých programech se určitý kód opakuje: textové procesory i hry potřebují například tisknout určité věci, seřadit seznamy nebo šifrovat data (to je jen pár příkladů, praxe je mnohem bohatší). Programátoři si proto svou práci usnadňují tak, že tyto často opakovaně používané části programů vkládají do takzvaných „programových knihoven“. Vzhledem k tomu, že tyto rutiny mohou být sdíleny nejrůznějšími programy, bylo by nesmírně hloupé je kopírovat a vkládat do všech programů, které je používají. Namísto toho jsou tyto knihovny užitečných procedur umístěny do samostatných souborů, označovaných jako „dynamicky linkované knihovny“ neboli DLL. Tomuto názvu obvykle odpovídá i přípona těchto knihoven – DLL. Microsoft šíří spolu s Windows velké množství těchto knihoven, které tak značně usnadňují práci programátorů. Všimli jste si například, že dialogové okno pro otevření souboru vypadá v podstatě ve všech programech stejně? Asi by nevypadalo příliš dobře, kdyby každá aplikace měla svá vlastní, jinak vypadající okna, a navíc by to byla zbytečná zátěž programátorů. Microsoft proto do systému zabudoval knihovnu

110

Kapitola 2 – Řízení uživatelských účtů

comdlg32.dll, obsahující předem připravený kód pro několik často používaných dialogových

oken, mezi které patří i Soubor  Otevřít. Mnoho aplikací, napsaných mimo Microsoft, spoléhá na přítomnost knihovny comdlg32.dll, jejíž dialogy využívají. Knihovny DALL se však postupně modernizují, jejich kód je vylepšován, jsou opravovány nalezené chyby a je přidáván kód reagující na nástup nových operačních systémů. To je sice chvalitebné a vývojáři to ocenili například při příchodu Windows XP, kde byly zavedena tzv. témata, ve kterých bylo možné vytvářet okno se zaoblenými rohy. Tato zakulacená okna byla dostupná v knihovně comdlg32.dll pro Windows XP, a pokud jste na novém systému spustili aplikace napsané pro starší NT 4.0 nebo Windows 2000, projevila se tato změna vzhledu oken i na většině z nich. Nové vzezření však nedokázaly některé aplikace překousnout, a proto nová knihovna comdlg32.dll znamenala pro některé aplikace nepřekonatelnou překážku. Programy vyhledávají své knihovny DLL standardně podle jejich názvu, a soubor s názvem comdlg32.dll se poprvé objevil v NT 3.1 (pokud se pamatuji správně). Většina lidí považovala zakulacená okna za příjemné vylepšení vzhledu Windows, jiným to však vadilo, protože jim v XP nechodily některé důležité aplikace, a proto se začali dožadovat toho, aby Windows nechaly rohy oken tak, jak bývaly dříve – chtěli zpět původní knihovnu comdlg32.dll. Je možné mít na jednom systému dvě různé kopie souboru comdlg32.dll, aniž by se navzájem negativně ovlivňovaly? Ano, ale musel nastoupit mechanismus „Side by Side“. Předpokládejme, že jste nešťastný programátor píšící aplikaci, která se nesnesla s XP verzí dialogových oken z knihovny comdlg32.dll. Díky mechanismu Side by Side jste mohli šířit svou aplikaci se starší verzí knihovny comdlg32.dll, kterou jste buď přejmenovali, aby se nepokoušela přepsat vestavěnou knihovnu XP, nebo jste ji umístili do jiné složky; obě dvě možnosti byly plně funkční. Jak ale říci aplikaci, že má používat starší verzi comdlg32.dll a kde ji má najít? Tuto otázku řešil manifest. Když operační systém viděl, že aplikace potřebuje volat funkci z knihovny comdlg32.dll, hledal manifest, ve kterém bylo uvedeno, jakou comdlg32.dll má vybrat. Pokud s aplikací žádný manifest dodáván nebyl, nebo pokud v manifestu nebyla o knihovně comdlg32.dll žádná zmínka, byla vybrána implicitní systémová knihovna; v opačném případě byla volána starší verze této knihovny. Manifest se dá prostřednictvím různých vývojových nástrojů vložit buď přímo do EXE (nebo též do knihovny DLL), nebo se jeho obsah dá zapsat v Poznámkovém bloku do samostatného textového souboru. V tomto druhém případě je ještě nutné operačnímu systému sdělit, aby daný manifest přidružil konkrétní aplikaci. To se dá provést splněním dvou podmínek: ■

Za prvé, manifest musíte uložit se souborem EXE do stejné složky.

■

Za druhé, soubor manifestu musíte pojmenovat podle vzoru něco.exe.manifest, kde něco je název EXE souboru, ke kterému se manifest vztahuje.

Pokud bych tedy napsal program superhra.exe a instaloval ho do složky C:\Program Files\ MarkSoft\Superhra, musel by se manifest jmenovat superhra.exe.manifest a musel by být také umístěn ve složce C:\Program Files\MarkSoft\Superhra, jinak by se jeho obsah nikdy neuplatnil. Pokud je aplikace vybavena interním i externím manifestem (v textovém souboru), ignorují Windows obsah externího manifestu. Manifesty umí také řešit problémy spojené s pravidelným měsíčním vydáváním záplat. Představte si, co se stane v případě, kdy napíšete aplikaci závislou na nějaké DLL knihovně Windows,

Hlubší ponor do problematiky UAC

111

ale Microsoft následně odhalí nějakou bezpečnostní díru v této knihovně a opraví ji; tato nová verze DLL však nebude slučitelná s kódem vaší aplikace. Klientským aplikacím lze v tomto případě přikázat uložit si starší verzi dané DLL do zvláštní složky a přidat k nim manifest směrující je na starou verzi DLL (za předpokladu, že se manifest nenachází již uvnitř souboru aplikace). Tento přístup dovoluje instalovat záplatu okamžitě po jejím vydání a být chráněn před napadením při spouštění jiných aplikací, které s novou verzí knihovny nemají problémy, zároveň si však zachovat možnost provozovat nekompatibilní aplikaci až do doby, dokud nenapíšete její novou verzi. (Pročtěte si článek Microsoft Knowledge Base č. 835322, kde je tento postup rozebírán.) Postupem času se do manifestů dostávala spousta dalších záležitostí, ale o jejich správu se stále stará komponenta Windows Side by Side, proto se veškerá hlášení o chybách, související s manifesty, objevují ve složce aplikačního protokolu Prohlížeče událostí jako chyby, jejichž zdrojem je „SideBySide“.

Průzkum obsahu manifestu Podívejme se, jak takový funkční manifest vypadá. Prozkoumáme jeden z vestavěných manifestů, a to ten, který je součástí souboru net.exe. Ale než se do toho pustíme, musíme najít nějaký nástroj, ve kterém si obsah interního (vestavěného) manifestu budeme moci prohlédnout; k těmto účelům jsou určené tzv. „editory zdrojů“ (resource editor). (Když do programu vložíte nějaký soubor – například manifest – říkáme, že tento soubor je „zdrojem“, případně „prostředkem“.) Ze zdarma dostupných editorů zdrojů uvádím XN Resource Editor, který si můžete stáhnout na adrese http://www.wilsonc.demon.co.uk/d10resourceeditor.htm. Pokud tuto stránku nenajdete, najděte si přes Google pojem „XN Resource Editor“. (Budu-li parafrázovat Herakleita, „nelze dvakrát najít stejný web, protože staré odkazy mizí a jsou nahrazovány novými adresami“.) Nainstalujte si XN Resource Editor do systému a spusťte ho. Jeho okno vidíte na obrázku 2.10. OBRÁZEK 2.10: Úvodní obrazovka XN Resource Editoru

Editor zdrojů je třeba nasměrovat na soubor EXE, ve kterém editor po otevření vyhledá všechny dostupné zdroje a jestliže nějaké najde, označí je pořadovými čísly (počínaje „1“) a zobrazí. Chce-

112

Kapitola 2 – Řízení uživatelských účtů

me-li zkoumat net.exe, je třeba spustit příkaz File  Open a v dialogovém okně „File name:“ zapsat c:\windows\system32\net.exe. Po stisku tlačítka OK bude XN Resource Editor vypadat stejně, jako na obrázku 2.11. OBRÁZEK 2.11: XN Resource Editor s nahraným souborem net.exe

Po klepnutí na tlačítko plus vlevo od „XP Theme Manifest“ se objeví složka s názvem „1“ – v net. exe je pouze jeden zdroj – a klepnutím na značku plus u této složky se dostáváme k samotnému manifestu, který je vidět na obrázku 2.12. OBRÁZEK 2.12: Manifest souboru net.exe

Manifest je psán ve formátu XML, který připomíná HTML. Většinu jeho části můžeme přeskočit; rád bych se soustředil jen na část u konce manifestu, kterou jsem trochu přeformátoval a upravil: <requestedExecutionLevel level="asInvoker" uiAccess="false" />

Není nutné chápat XML, abyste tento zápis dokázali rozluštit, protože nás zajímá jen jeden řádek: level= "asInvoker"

Hlubší ponor do problematiky UAC

113

Jednu věc si je však nutné u XML zapamatovat: dělá se tu rozdíl mezi velkými a malými písmeny. Změnou „requestedExecutionLevel“ na „requestedexecutionlevel“ bychom celý manifest poškodili a v protokolu událostí by se objevila jedna z chyb Side By Side, které jsem zmiňoval. Zápis level= představuje místo, kam může vývojář (nebo správce, který je ochotný si trochu pohrát se zdroji; postup si za chvíli ukážeme) umístit návěští pro UAC, vyjadřující potřebu povýšit oprávnění aplikace. Za zápisem level= (opět upozorňuji, že je nutné dodržet malé písmeno na začátku) mohou následovat tři možné hodnoty: ■

asInvoker znamená „Dej mi stejný token, jako má osoba, která mne spustila“. Takto je to

nastaveno u net.exe, protože když chcete pomocí net.exe jen zjistit různé údaje o vaší pracovní skupině – a to může udělat každý uživatel – stačí zapsat net view a pro spuštění tohoto příkazu bohatě stačí token uživatele se standardním oprávněním. Jestliže však budete chtít provést operaci vyžadující práva správce (například vytvořit nový uživatelský účet), musíte nejprve spustit okno příkazového řádku s právy správce, a v něm spustit příkaz net user. Program net v tomto případě zdědí token okna příkazového řádku, neboli token plného přístupu správce. ■

highestAvailable znamená „prosím dejte tomuto procesu nejvyšší možný token, který uži-

vatel vlastní, a v případě nutnosti otevřete Consent UI, aby proces mohl tento token získat“. ■

requireAdministrator znamená to samé, co highest available, ale přidává k tomu ještě část

„pokud uživatel není člen skupiny Administrators, neunavuj se zbytečně, já prostě potřebuji token plného přístupu správce, a když uživatel není správce, nemůže mi v tomto ohledu nijak pomoci; proto mne prostě ukonči“. Jaký je přesný rozdíl mezi posledními dvěma variantami? Je možné, že daný účet má rozdělený token, ale žádný z nich není tokenem správce. (K takové situaci může dojít; takto spatra ne ale nenapadá, proč k tomu dochází.) Aby tedy byl soubor EXE označen jako soubor vyžadující token plného přístupu správce, zajistěte, aby měl v tomto místě manifestu zapsánu úroveň requireAdministrator. POZNÁMKA:

Vím, že existuje ještě další parametr uiAccess="false", který tu není vysvětlen. Dostanu se k němu později, zde ho popíšu jen stručně. Existuje speciální třída aplikací, která potřebuje pracovat s Consent UI. Říká se jim „aplikace UI automation“. Tyto aplikace využívají parametr uiAccess, kterým dávají UAC najevo svou příslušnost do této třídy.

Přidání manifestu pomocí editoru zdrojů Vybaveni těmito informacemi můžeme vybavit starší aplikaci neobsahující žádný zdroj manifestem, který bude obsahovat daje pro UAC. Přidání zdroje se dá ve skutečnosti provést třemi různými způsoby. Za prvé, můžeme použít náš editor zdrojů a vložit manifest s instrukcí level=requireAdministrator přímo do souboru EXE. Než začneme, musíme si opatřit soubor EXE bez manifestu. Pokud nemáte žádný po ruce, postupujte podle následujících bodů: 1. Otevřete okno příkazového řádku. (Bez práv správce.)

114

Kapitola 2 – Řízení uživatelských účtů

2. Vytvořte složku c:\pokusy (zapište md c:\pokusy a stiskněte Enter). 3. Příkazem cd c:\pokusy (plus stisk Enter) přejděte do složky c:\pokusy. 4. Otevřete Internet Explorer a zapište do adresního řádku http://www.minasi.com/vista/ vistafiles.zip. V tomto archivním balíku ZIP si stáhnete soubory a programy použitelné pro experimentování s UAC, virtualizací souboru a řízením integrity Windows. Soubor stáhněte do složky C:\pokusy. 5. V Průzkumníkovi přejděte do složky c:\pokusy. Pravým tlačítkem myši klepněte na soubor vistafiles.zip, v místní nabídce vyberte příkaz „Extrahovat vše…“ a zadejte jako cílovou složku C:\pokusy. 6. Jedním ze souborů bude program s názvem „simple.exe“, který je nejednodušším programem na celém světě, napsaným v jazyce C++. Je to program příkazového řádku, který spustíte příkazem simple. Po spuštění bude do okna příkazového řádku vypsán text This is a program that just puts this text on the screen (je mi jasné, že v oboru programování mne žádná zářná budoucnost nečeká …). Při dotazu na uložení odpovězte IE, aby to uložil do C:\pokusy. 7. Zkuste ho spustit a ověřte si, že ve své původní formě nevyvolává Consent UI. 8. Příkazem copy simple.exe mansimple.exe vytvořte kopii souboru simple.exe, která bude též bez manifestu, a následně do mansimple.exe vložíme nový manifest. Poté podle následujících bodů vložte do souboru mansimple.exe manifest: 1. Spusťte XN Resource Editor. 2. Spusťte příkaz File  Open, přejděte do složky c:\pokusy a otevřete soubor mansimple.exe. Nyní je vidět, že levý panel, ve kterém jste předtím viděli zdroj souboru net.exe, je úplně prázdný. Je to dáno tím, že mansimple.exe neobsahuje žádné zdroje. 3. Spusťte příkaz Resource  Add Resource. 4. V dialogovém okně „Add Resource“ vyberte „XP Theme Manifest“ a klepněte na tlačítko OK. V levém panelu nyní uvidíte „XP Theme Manifest“, „1“ a „Language Neutral“. V pravém panelu se objeví pár řádků kódu XML. 5. Označte text v pravém panelu a stiskem Del ho smažte. 6. Ve složce c:\pokusy\manifests najdete soubor „example.exe.manifest“. Je to ten nejjednodušší manifest na celém světě. 7. Otevřete tento soubor manifestu v Poznámkovém bloku. 8. Zkopírujte text z Poznámkového bloku do pravého panelu XN Resource Editoru. 9. Vyberte v levém panelu „XP Theme Manifest“. 10. Spusťte příkaz File  Save. 11. Ukončete XN Resource Editor. Když následně spustíte program mansimple.exe, objeví se přitom dialog Consent UI.

Hlubší ponor do problematiky UAC

115

Přidání externího manifestu Druhý postup je snadnější. Zkopírujte soubor simple.exe.manifest, který jste získali z mého webu, do stejné složky, ve které se nachází simple.exe. Nemá-li soubor simple.exe svůj vložený (interní) manifest, Vista najde, přečte a použije tento externí manifest. Externí manifest se tedy k libovolnému programu – nazvěme ho třeba ukazka.exe – připojí takto: ■

Vytvořte manifest pro soubor ukazka.exe. Pokud je jediným účelem manifestu zajistit povýšení práv, otevřete Poznámkový blok a zapište do něj: <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> <assemblyIdentity version="1.0.0.0" processorArchitecture="X86" name="Anyapp" type="win32"/> <description>Basic manifest</description> <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3"> <security><requestedPrivileges> <requestedExecutionLevel level="requireAdministrator"/> </requestedPrivileges></security></trustInfo></assembly>

Dávejte velmi dobrý pozor na to, abyste při psaní obsahu manifestu dodrželi uvedená malá a velká písmena. Při vytváření manifestu můžete také použít vzorový soubor simple.exe.manifest.

■

Uložte nový soubor manifestu jako ukazka.exe.manifest.

■

Uložte soubor do stejné složky se souborem ukazka.exe.

Tento manifest bude nyní ovlivňovat způsob spuštění souboru ukazka.exe, za podmínky, že soubor ukazka.exe neobsahuje svůj interní manifest. Jak zjistit, zda spustitelný soubor obsahuje či neobsahuje manifest? Podíváte se do souboru nějakým editorem zdrojů dle předchozího popisu. VAROVÁNÍ:

Ve verzi RC2 se občas stává, že si Vista nevšimne externího manifestu; dáte-li platný soubor ukazka.exe.manifest do stejné složky jako ukazka.exe, nemusí to fungovat. Vložené manifesty fungují vždy. Uvádím proto obezličku využívající jako ukázku jiný soubor z archivu vistafiles.zip, která se zdá být spolehlivým řešením.

V některých případech vás pokusy přimět Vistu k postřehnutí přítomnosti externího manifestu mohou pěkně rozčílit, přinejmenším ve verzi RC2. Zdá se, že se mi ale podařilo nalézt řešení: vytvořte složku, zkopírujte do ní soubor EXE i externí manifest a poté z této složky spusťte soubor EXE. Následuje bodový příklad, ve kterém používám soubor „show.exe“ (jde o jeden ze souborů, které se nacházejí v archivu vistafiles.zip). Příklad zobrazí obsah souboru na obrazovce, obdobně jako příkaz type. Pro příklad vytvoříme externí manifest. Obdobně jako předtím i nyní budeme pracovat v okně příkazového řádku bez povýšení na správce, pracovní složka je C:\pokusy. 1. Vytvořte ve složce c:\pokusy složku „test“ (příkazem md c:\pokusy\test a stiskem Enter). 2. Zkopírujte show.exe do této složky (příkazem copy show.exe test a stiskem Enter). 3. Zkopírujte ukázkový manifest do složky test a přejmenujte ho přitom na show.exe.manifest (zapište příkaz copy example.exe.manifest test\show.exe.manifest a stiskněte Enter.

116

Kapitola 2 – Řízení uživatelských účtů

4. Nyní příkazem cd test (a stiskem Enter) nastavte složku C:\pokusy\test jako pracovní. 5. Zapište show a stiskněte Enter. 6. Nyní by se mělo ukázat okno „Otevřít soubor – Upozornění zabezpečení“ s dotazem, zda skutečně chcete spustit program show.exe. Klepněte na tlačítko Spustit. UAC poté otevře Consent UI, čímž máme ověřeno, že Vista si všimla a zpracovala externí manifest. Zde klepněte na tlačítko Storno a dále se podíváme ještě na jednu věc, kterou Vista provádí, když detekuje manifest vyžadující povýšení aplikace. Otevřete Průzkumníka a přejděte v něm do složky c:\pokusy\test. Zde klepejte na tlačítko Zobrazení, dokud nespatříte ikonu souboru show.exe. A co tu vidíte? Vista přidala do ikony malý štít!

Vložení manifestu pomocí nástroje Manifest Tool Třetí způsob přidání manifestu k souboru využívá nástroj příkazového řádku, který vloží externí manifest do souboru EXE. (Případný stávající manifest v souboru je přitom přepsán.) Nástroj „Manifest Tool“ je uložen v souboru mt.exe, který si můžete stáhnout ze stránek Microsoftu, ovšem ne samotný, ale jako součást většího balíku. (Existují i jiné způsoby, jak si ho stáhnout, ale ty jsou dost komplikované, já vám předvedu nejjednodušší způsob.) Manifest Tool je součástí Windows Platform SDK, které si můžete stáhnout spolu s bezplatnou verzí Visual Studia 2005, tedy s aplikací Visual Studio Express 2005. V následujících bodech je popsán způsob jeho stažení. 1. Otevřete webový prohlížeč a otevřete domovskou stránku Visual Studia Express http://msdn.microsoft.com/vstudio/express/downloads/. Pokud toto URL nefunguje – u Microsoftu je zřejmě zaměstnán člověk, jehož úkolem je tak zhruba jednou za týden úplně změnit uspořádání celého webu této firmy – zadejte v Google hledání řetězce „download visual studio express“ a ve výsledcích bude odkaz na stránku stažení Visual Studia Express 2005 uveden. 2. Visual Studio 2005 je dostupné v několika verzích: Web Developer Edition, Visual C++ Express Edition, Visual Basic Express Edition a Visual C# Express Edition. PÉOZNÁMKA:

Nejste-li programátor, nebudete asi znát správnou výslovnost C#. Microsoft pro tohoto potencionálního nástupce C++ zvolil symbol čísla # (oktothorp), vypadající trochu jako dvě zkřížená znaménka plus. Jestliže znáte noty, víte, že podobný znak „křížek“(v angličtině „sharp“) označuje zvýšený tón. Proto se jako název této novější odrůdy C ujal výraz „C sharp“.

3. Pokusem jsem přišel na to, že ve „Visual C# 2005 Express Edition“ není nástroj mt.exe obsažen, ale ve „Visual C++ 2005 Express Edition“ ano, proto si stáhněte druhý uvedený nástroj. 4. V rámečku produktu „Visual C++ 2005 Express Edition“ ponechte zvolen jazyk English (česká verze k dispozici není) a klepněte na tlačítko Go. 5. V dialogovém okně „Otevírání souboru vcsetup.exe“ klepněte na tlačítko Spustit soubor. 6. Pokud toto provádíte v systému Vista, objeví se potvrzovací dialog UAC. Tlačítkem Pokračovat potvrďte, že chcete skutečně spustit instalační program. (Pruh nahoře je šedý, protože

Hlubší ponor do problematiky UAC

117

soubor je sice digitálně podepsán – a to přímo Microsoftem – ale nejedná se o neodmyslitelnou součást operačního systému.) 7. V průvodci instalací přejděte tlačítkem Další na druhou stránku a zde potvrďte licenční smlouvu. Tlačítkem Další přejděte na třetí stránku 8. Na stránce Installations Option ponechte vypnutá políčka SDK a SQL a klepněte na tlačítko Další. 9. Zkontrolujte, zda vám vyhovuje vybraná složka pro instalaci a poté klepněte na tlačítko Instalovat. Poté začne stahování vlastního balíku Visual Studio C++ 2005 Express Edition, který zabere asi 35 MB. 10. Po ukončení stahování klepněte na tlačítko Konec a zavřete okno Internet Exploreru. Necháte-li instalátor zkopírovat soubory do výchozího umístění, bude soubor mt.exe zapsán do složky C:\Program Files\Microsoft Visual Studio 8\VC\Bin (na 32bitové verzi Visty) nebo do složky C:\Program Files (x86)\Microsoft Visual Studio 8\VC\Bin (na 64bitové verzi Visty). Zkopírujte si ho odsud někam jinam a máte svůj Manifest Tool připraven. Chcete-li znovu získat místo, které vám zabralo Visual Studio, proveďte odinstalaci všech jeho součástí. (Proč se nedá prostě stáhnout jen mt.exe, je pro mne záhadou.) Nyní můžeme soubor mt.exe použít pro vložení souboru manifestu do existujícího souboru EXE. Potřebný příkaz vypadá takto: mt /manifest NÁZEVMANIFESTU/outputresource:NÁZEVEXESOUBORU;#1

Následující postup slouží pro vložení manifestu simple.exe.manifest do souboru simple.exe: 1. Zkontrolujte si, že máte soubory mt.exe, simple.exe.manifest a simple.exe ve složce c:\pokusy. 2. Nemáte-li otevřeno okno příkazového řádku, spusťte ho a přejděte do složky C:\pokusy. 3. Soubory v archivu vistafile.zip mají nastaven atribut „jen ke čtení“, proto se ho zbavte příkazem attrib -r * a stiskem Enteru. 4. Vytvořte si příkazem copy simple.exe nomanifest.exe zálohu simple.exe bez manifestu. 5. Spusťte příkaz mt /manifest example.exe.manifest /outputresource:simple.exe;#1. Tento příkaz mt je třeba zapsat jako jeden řádek. Všimněte si, že syntaxe příkazu mt je trochu nezvyklá, především v tom, že mezi přepínačem /manifest a hodnotou simple.exe.manifest je mezera, zatímco mezi /outputresource: a simple.exe;#1 je dvojtečka. Není to moje chyba, takto se to opravdu zapisuje. Jakmile do simple.exe vložíte manifest, bude při každém spuštění tohoto programu vyvolán dialog Consent UI, nezávisle na tom, zda se soubor simple.exe.manifest nachází ve stejné složce jako simple.exe nebo ne; vyplývá to z probraného pravidla, podle kterého Vista ignoruje všechny externí manifesty u souborů, které mají manifest zabudován přímo v sobě.

Vložení manifestu může zničit digitální podpis Když nyní znáte dokonce dva způsoby, jak do existujícího souboru EXE dostat manifest, zbývá odpovědět na otázku – máte to skutečně dělat? Někdy ne. Vložení manifestu totiž mění obsah

118

Kapitola 2 – Řízení uživatelských účtů

souboru EXE a z toho vyplývá, že tato změna zneplatní všechny digitální podpisy takového souboru. Protože jen málokdo ví, co děje při podpisu souborů programů, zkusme si to stručně přiblížit. Když Windows spouští ovladač, program nebo něco jiného, identifikují daný spustitelný soubor jeho názvem. Ale co když nějaký malware zamoří váš operační systém a nahradí důležitý systémový soubor (například RPCSS.DLL) kopií sebe sama? Protože Windows spouští knihovnu RPCSS. DLL (poskytuje službu Volání vzdálených procedur, která mimo jiné zajišťuje například komunikaci mezi Outlookem a Exchange) automaticky při svém zavádění, byla by to pro malware vynikající příležitost, jak si zajistit svou aktivaci při každém spuštění počítače. Mnohé operační systémy se proti této hrozbě brání pomocí digitálních podpisů, které vývojářům umožňují kryptograficky prokázat, kdo přesně napsal určitou část kódu. Jak to celé funguje? Vývojář dokončí práci na určitém programu, kterým může být soubor EXE, DLL, soubor ovladače nebo něco jiného. (Dejme tomu, že jde o klasický soubor EXE.) Poté použije kryptografickou funkci, která z předaných megabajtů dat vytvoří jedinečný 128bitový klíč (hash). (Ve většině případů se tyto klíče vytváří algoritmem MD5 nebo SHA-1, který patří mezi nejpopulárnější hashovací algoritmy vůbec.) Poté si již kdokoli může ověřit, zda si stáhnul skutečně ten program, který vytvořil daný vývojář. Stačí vzít daný soubor EXE a vytvořit z něj voláním stejné kryptografické funkce MD5 nebo SHA-1 hash. Hodnotu tohoto hashe poté porovnáte s hashem, který vytvořil sám vývojář. Pokud se shodují, máte téměř jistotu, že vaše kopie souboru EXE je identická s tou, kterou vytvořil onen vzdálený vývojář – během stahování tedy nedošlo k poškození souboru a především (což je ještě důležitější) se nejedná o kopii, kterou by někdo infikoval zákeřným kódem. Píšu „téměř jistotu“ namísto „stoprocentní jistotu“, protože existuje malá, opravdu velmi malá, ale přece jen možnost, že se někomu podaří změnit obsah souboru tak, že výsledný hash upraveného souboru bude shodný s hashem původního EXE, ale byl by to vskutku výjimečný případ. Toto je celá podstata digitálních podpisů, ale jistě jste si všimnuli jednoho většího nedostatku. Nikdo nemá chuť si stáhnout hash původního souboru z webu vývojáře, poté vypočíst hash pro stažený soubor a nakonec oba hashe porovnat…To je dost komplikovaná záležitost a navíc se nedá vyloučit, že se někomu podaří podvrhnout namísto původního webu vývojáře svou vlastní verzi s falešným souborem a hashem pro něj. Proto celý proces ještě doplníme o další kroky. Vývojář si od prověřeného dodavatele digitálních podpisů (VeriSign a další firmy) zakoupí určitý druh certifikátu, který je označován jako „code signing certificate“. Ve svém počítači potom na základě certifikátu vygeneruje pár veřejného a privátního klíče a ten zašle firmě VeriSign. Ve firmě VeriSign proběhne kontrola obou klíčů a pokud odpovídají vydanému certifikátu, firma vydá za poplatek několika set dolarů (platí se každý rok znovu) certifikát, do kterého je vložen veřejný klíč vývojáře. Vývojář může následně vypočítat pro svůj hotový soubor EXE hash a hodnotu tohoto hashe zašifrovat svým soukromým klíčem. Tento zašifrovaný hash a svůj certifikát s veřejným klíčem vloží do souboru EXE… a dál už vše probíhá automaticky. Jestliže na Consent UI uvidíte šedý nebo modrozelený pruh u horního okraje, znamená to, že Vista v souboru EXE, u kterého předpokládá nutnost povýšení oprávnění, našla certifikát a zašifrovaný hash. (Pokud by je tam nenašla, byl by u horního okraje Consent UI oranžový pruh.) Vista aplikuje na celý soubor (s výjimkou té části, kde je uložen certifikát a zašifrovaný hash) hashovací funkci a vypočítá nový hash. Poté veřejným klíčem vloženým do certifikátu dešifruje hash ze

Hlubší ponor do problematiky UAC

119

souboru EXE. Jestliže jeho hodnota souhlasí s hashem, který si vypočítal sám operační systém, je soubor EXE správně podepsán. V takovém případě bude mít Consent UI šedý nebo modrozelený pruh. V případě nesouhlasu bude pruh oranžový. Digitální podpisy nejsou universálním lékem, podepsaný kód může stále vyvolávat určité problémy. Za prvé, digitální podpis v žádném případě nezaručuje vysoce kvalitní kód. Ve většině kódu podepsaného samotným Microsoftem a dalšími velkými výrobci softwaru jsou někdy strašné chyby. Máte však alespoň jistotu, kdo ten kód napsal, a proto si můžete být vcelku jist, že pokud je tím tvůrcem velká firma typu Microsoft, IBM, Adobe a další, nemají v úmyslu vám do počítače záměrně nasadit malware ! Digitální podpis dále nezaručuje, že v kódu není přítomen žádný malware (škodlivý kód). Pokud programátor sestaví aplikaci na systému, který je tajně infikován určitým druhem malwaru, může se tento malware dostat i do přeložené aplikace. Ale i v tomto případě lze považovat téměř za jisté, že infekce není šířena záměrně. (To ale nemusí být pravda, protože VeriSign nekontroluje, zda osoba, které vydává „code signing certificate“, nevytvářela v minulosti malware nebo neměla záznam v trestním rejstříku. Existují dva mocné důvody, proč říci ano digitálním podpisům kódu. Za prvé, máte dost velkou, téměř stoprocentní jistotu, kdo daný kód napsal a uvolnil. (Na sto procent to nebude nikdy, protože vydavateli mohl někdo jeho certifikát ukrást.) To je velmi důležité, protože hackerovi se sice může podařit napsat nějaký malware, získat certifikát, podepsat s ním program a ten poté rozšířit, ale utéct odplatě se mu zdaří pouze jednou. (A někdy ani to ne, protože úřady ho mohou vypátrat a dopadnout na základě informací, které musí poskytnout vydavateli certifikátu.) Poté již bude mít natrvalo pověst kriminálníka a šance na to, že se mu podaří přesvědčit někoho, aby si nainstaloval jím podepsaný software, je nulová. Za druhé – a to je důležitější – operační systém si díky podpisům může ověřit, že soubory obsahující životně důležité součásti operačního systému nebyly od doby svého vytvoření nijak upraveny. Toto je obrovská bezpečnostní výhoda Visty, protože Vista kontroluje podpisy u všech nízkoúrovňových programů při každém svém zavádění. (V jedné z pozdějších kapitol bude tato látka probírána podrobněji.) Uch, byla to dost dlouhá (ale jak doufám, pro mnohé z vás poučná) odbočka, ale byl k ní důvod. Vzhledem k tomu, že vložený manifest je součástí souboru EXE, bude mít jeho úprava editorem zdrojů stejný důsledek, jako kdyby byl EXE infikován kusem malwaru: digitální podpis nebude souhlasit. Jakmile k tomu dojde, zmizí z okna vlastností souboru stránka „digitální podpisy“ a program neprojde ověřením pravosti podpisu. Co to bude znamenat v praxi? Uvědomme si, že jsme manifest přidávali do souboru EXE proto, aby operační systém věděl o tom, že je třeba zvýšit oprávnění souboru, když se někdo tento program pokusí spustit. U takového programu se dá jen těžko předpokládat, že by obsahoval digitální podpis ani manifest, a proto se přidáním manifestu nemůže nic poškodit. (Moje malé ukázkové aplikace nejsou samozřejmě také podepsány.) Nezapomeňte si to ale zkontrolovat, než přidáním manifestu vyjádříte své přání spouště nějaký program s právy správce! TIP:

Vytváření podepsaných programů znamená dodatečnou námahu spojenou se získáním certifikátu, ale postupem doby budou pravděpodobně všechny nové aplikace podepsány. Pak bude mít smysl zapnout zásadu skupiny „Řízení uživatelských účtů: Zvýšit oprávnění pouze u podepsaných a ověřených spustitelných souborů“. K tomuto tématu se vrátím podrobněji v příští části „Změna konfigurace Řízení uživatelských účtů“.

120

Kapitola 2 – Řízení uživatelských účtů

Pomocník s kompatibilitou programů a jeho vliv na UAC V předchozím textu bylo řečeno, že UAC hledá určitá slova v názvech programů nebo jiné náznaky prozrazující, že program byl generován populárním tvůrcem instalačních programů, a pokud tyto znaky najde, předpokládá, že nejde o obyčejnou starší aplikaci, ale že pracuje přímo s instalačním programem. Vista však ve snaze zajistit kompatibilitu starších aplikací jde ještě o krok dále. „Myslí“ si, že pokud tento program skutečně něco instaloval, musí o tom být někde záznam; někde musí existovat protokol změn, které takový program provedl v operačním systému, aby bylo možné zobrazit seznam instalovaných programů v appletu Přidat nebo odebrat programy Ovládacích panelů, a především aby bylo možné program ze systému odebrat. Pokud si Vista myslí, že instalace neproběhla správně, otevře dialogové okno Pomocníka s kompatibilitou programů (obrázek 2.13) a nabídne uživateli možnost změnit parametry programu. OBRÁZEK 2.13: Pomocník s kompatibilitou programů

Co se přesně stane, když klepnete na příkaz „Opětovná instalace pomocí doporučeného nastavení“? Najděte si v předchozím textu obrázek 2.5. Je na něm stránka „Kompatibilita“, kterou najdete v podstatě u každého souboru EXE, který nebyl speciálně označen jako základní program Visty – tedy u každého programu, který nemá u horního okraje svého Consent UI zelenomodrý pruh. Na této stránce vlastností lze rychle a snadno řešit většinu běžných problémů, kdy program bez problému fungující na Windows 95/Windows ME/XP neběží na systému Vista. Již od počátků výpočetní techniky se občas vyskytly aplikace psané tak, že je bylo možné spustit jen na (například) Windows 95, přestože by bez potíží pracovaly i na operačním systému Vista. Na stránce „Kompatibilita“ je mimo jiné rozvírací seznam s popiskem „Tento program spustit v režimu kompatibility“ s nabídkami systémů Windows 95, 98, Me, NT 4.0, Windows 2000, XP SP2 a Windows Server 2003 SP1; když zapnete horní zaškrtávací políčko a vyberete v seznamu „Windows 95“, měla by naše hypotetická aplikace psaná pro Windows 95 běžet bezchybně i na Vistě. Na stránce „Kompatibilita“ je dále možné přikázat snížení počtu barev nebo zjednodušit překreslování obrazovky – k tomu účelu to jsou zaškrtávací políčka pro režim 256 barev, rozlišení 640  480, zákaz rozvržení plochy (to je ta věcička, co nám ve Vistě dovoluje přetahovat okna po pracovní ploše, aniž by za nimi zůstávala „brzdná stopa“) a změnu velikosti zobrazení, případně zakázat úplně vizuální motivy. Pokud je vám některá z těchto voleb povědomá, je to v pořádku, protože ve Windows XP jste se se stránkou vlastností „Kompatibilita“ mohli rovněž setkat, i když na ní bylo méně voleb.

Hlubší ponor do problematiky UAC

POZNÁMKA:

121

Ve skutečnosti se dá kompatibilita aplikace vynucovat pomocí mnoha dalších voleb, jejichž počet jde do stovek a které jsou dostupné v nástroji ACT (Application Compatibility Toolkit). Tento nástroj je ovšem tak rozsáhlý, že ho tu nelze probírat, proto se spokojíme se stránkou „Kompatibilita“, kterou lze považovat za silně zjednodušený ACT.

Jestliže se Pomocník s kompatibilitou programů domnívá, že pokus o instalaci nějakého programu neproběhnul úspěšně, provede pár kvalifikovaných odhadů toho, co se á na stránce Kompatibilita pro daný program vylepšit. Poté znovu spustí instalační program a upraví parametry instalace na základě svých odhadů – to se stane, když klepnete na příkaz „Opětovná instalace pomocí doporučeného nastavení“. Pomocník s kompatibilitou programů by se rychle zařadil mezi otrapy, pokud by vyskakoval při každém spuštění daného programu, proto je navržen tak, aby si pamatoval, které aplikace již prozkoumal (a ty nadále ignoroval). Seznam již prozkoumaných aplikací je zapsán v klíči systémového registru HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\ AppCompatFlags\Compatibility Assistant\Persisted. V tomto klíči si Pomocník pro každou přezkoušenou aplikaci vytvoří položku typu REG_DWORD, nastaví její název na úplnou cestu k souboru EXE této aplikace a hodnotu položky na 1. Když Pomocník s kompatibilitou programů ukončí kontrolu předvoleb na stránce vlastností Kompatibilita, poznamená si to do sousedního klíče HKEY_CURRENT_USER\Software\Microsoft\ Windows NT\CurrentVersion\AppCompatFlags\Layers, kde optimalizace vytvoří samostatnou položku pro každou aplikaci (tentokrát jde ale o typ REG_SZ, nikoli REG_DWORD), jejíž název se rovná úplné cestě k souboru EXE aplikace a do hodnoty jsou zapsány názvy všech aplikovaných režimů kompatibility. Pokud se například Pomocník rozhodne vybrat režim kompatibility s XP SP2, objeví se v této položce systémového registru řetězec „WINXPSP2“. Kromě těchto klíčů jsem našel ještě jiný klíč, odpovídající klíči Layers, ale ten se nachází ve větvi HKEY_LOCAL_MACHINE, ne HKEY_CURRENT_USER. Chápu, že to bylo opět pro mnohé nepodstatné klábosení a asi nikdo z vás netouží po setkání s tímto Pomocníkem. Pokud se však chcete s ním seznámit a ověřit si, co vlastně zapisuje do systémového registru, zkuste následující postup. 1. Otevřete okno příkazového řádku a přejděte do složky c:\pokusy. 2. Budeme potřebovat kopii simple.exe bez manifestu, proto spusťte příkaz copy nomanifest. exe installer.exe. Vytvoříme si tak kopii programu simple, která bude zajímat UAC a vyvolá Consent UI. 3. Zapište installer. 4. UAC otevře dialog Consent UI s oranžovým pruhem. Zde klepněte na „Povolit/ Důvěřuji tomuto programu …“ a za oknem příkazového řádku se na okamžik objeví a hned zase zmizí další okno příkazového řádku (s právem správce). 5. Během několika sekund se objeví dialog Pomocníka s kompatibilitou programů. Zde si vyberte libovolnou z nabízených možností, ve skutečnosti nic neinstalujeme, takže je to jedno. 6. Dále si ověřte, že si Pomocník skutečně pamatuje, které programy v minulosti přezkoušel a pokoušel se pomoci řešit jejich problémy. Zapište znovu installer a poté se podle očeká-

122

Kapitola 2 – Řízení uživatelských účtů

vání objeví Consent UI, ale už ne Pomocník. Dále si podívejte na klíč systémového registru HKEY_CURRENT_ USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\ Compatibility Assistant\Persisted, kde uvidíte přibližně to, co je na obrázku 2.14. 7. Vymažte tuto položku a přejděte do klíče HKEY_LOCAL_MACHINE\Software\Microsoft\ Windows NT\CurrentVersion\AppCompatFlags\Layers, kde najdete položku pro installer. exe a hodnotu „WINXPSP2“ typu REG_SZ, která se zdá být universální používanou hodnotou v případě, kdy Pomocník ví, že něco není v pořádku, ale není si jist, co se pokazilo. Tuto položku smažte také. 8. Zavřete Editor registru. 9. Znovu spusťte installer.exe, nechte UAC, ať mu povýší oprávnění, a poté se znovu objeví Pomocník. OBRÁZEK 2.14: Jedno ze dvou míst, kam si Pomocník ukládá informace o zkoumaných aplikacích

Takto tedy funguje Pomocník s kompatibilitou programů. Jen jedna věc se tu lišila od předchozího výkladu: psal jsem, že může způsobit aktivaci UAC, které si vyžádá souhlas s udělením práv správce, ale to jsme neviděli; kdy k tomu může dojít? Inu, jak jste sami viděli, úkolem Pomocníka s kompatibilitou programů není říkat UAC, aby si vyžádalo souhlas s povýšením práv, ale jen analyzovat možné příčiny nesprávného chodu programu a uzpůsobit podle toho předvolby ve stránce vlastností Kompatibilita. Jak mi bylo řečeno – osobně jsem to neviděl, ale koneckonců jsem měl čas vyzkoušet na vistě jen pár desítek programů – u některých programů může Pomocník s kompatibilitou programů sám zapnout políčko „Spustit tento program jako správce“. V takovém případě se objeví výzva Consent UI k souhlasu s povýšením oprávnění při každém spuštění programu. Pomocník přitom není příliš inteligentní – pokud byste si umístili druhou (jinak identickou) kopii souboru installer.exe do jiné složky a pokusili se ji poprvé spustit, Pomocník by neměl tušení o tom, že stejný program už analyzoval v jiné složce. Oproti tomu manifest přidaný k souboru vyžadujícímu práva správce bude fungovat nezávisle na tom, do které složky oba soubory přesunete nebo zkopírujete.

Hlubší ponor do problematiky UAC

POZNÁMKA:

123

Nepleťte si Pomocníka s kompatibilitou programů a Průvodce ověřením kompatibility programů. Průvodce je ikona, která se objeví na levé straně vaší pracovní plochy při prvním spuštění Visty. Průvodce ověřením kompatibility programů je v podstatě velmi jednoduchý průvodce, který nasměrujete na nějaký program, průvodce vám poté položí několik otázek a na základě vašich odpovědí zapne některé volby na stránce vlastností Kompatibilita daného programu. Nic moc, že? Souhlasím a byl bych rád, kdyby tato věcička zbytečně nezabírala místo na pracovní ploše, když se dá jednoduše nahradit vlastní obsluhou stránky vlastností Kompatibilita.

Také úpravy Application Compatibility Toolkitu mohou mít vliv na UAC Poslední věcí, která může UAC přimět požádat uživatele o souhlas s povýšením oprávnění procesu, je tzv. „shim“ (česky „úpravy systémové kompatibility“), vytvářený programem Application Compatibility Toolkit. Před chvílí jste četli o Pomocníkovi s kompatibilitou programů, což je v podstatě proces spuštěný za určitých podmínek, který na základě sady daných pravidel mění předvolby na stránce Kompatibilita u souborů EXE, které mají problémy s kompatibilitou při běhu na Windows Vista. Je skvělé, že například zapnutím režimu kompatibility „XP SP2“ a zaškrtávacího políčka „Spustit tento program jako správce“ mohu zprovoznit určitý starší program na nové Vistě – skvělé především z toho hlediska, že tak mohu provozovat programy, kterým sice příliš nedůvěřuji, ale je to pořád lepší než kupovat novější verzi programu, kterou až tak moc nepotřebuji, protože současná verze svým rozsahem funkcí stačí. Ale představte si, že tuto úpravu nastavení budete muset provést na řádově tisíci PC, případně co dělat, když budu muset upravit nějakou jinou vlastnost programu, která se na stránce vlastností Kompatibilita nevyskytuje? V těchto případech je třeba vpustit na scénu Application Compatibility Toolkit, což je sada programů, které na starší aplikace umí aplikovat nejrůznější „online záplaty“, kterými vyřeší potíže s kompatibilitou (takže Vista i starší program začnou perfektně spolupracovat). Těmto „úpravám kompatibility“ se oficiálně říká „shim“. Úpravy Application Compatibility Toolkitu se liší od předvoleb na stránce Kompatibilita v tom, že se dají ukládat do balíčků a tyto balíčky pro konkrétní aplikace lze poté distribuovat z centrálního umístění pomocí zásad skupiny na jednotlivé pracovní stanice. Dále platí, že na stránce Kompatibilita je přibližně deset možných předvoleb (úprav, zatímco Application Compatibility Toolkit jich obsahoval více než 210 (v době, kdy jsem to naposledy kontroloval), i když je nutné uznat, že mnohé z nich jsou už dnes zbytečné, protože jsou přímo součástí Visty a v ní platí automaticky. Application Compatibility Toolkit vytváří databáze úprav, které lze rozpoznat podle jejich přípony .SDB (System DataBase). Přímo s Vistou je například dodávána rozsáhlá databáze úprav sysmain.sdb. Implicitní si Vista tyto databáze ukládá do složky \Windows\AppPatch. Součástí Visty není žádný nástroj, který vám umožní zkoumat obsah této databáze a osobně bych se velmi divil, kdyby to Microsoft myslel vážně s podporou ACT na 64bitové platformě, protože ACT 5.0 (verze určená právě pro Vistu) neběží na 64bitové verzi tohoto systému Jestliže však máte 32bitovou verzi Visty, můžete si aktuální verzi Application Compatibility Toolkitu stáhnout ze stránek Microsoftu a v ní si prohlédnout obsah sysmain.sdb. Nepřeháním, když zde napíšu, že tam jsou evidovány doslova tisíce aplikací, a vsadil bych se s vámi o co chcete, že jste o 90% z nich doposud neměli ani ponětí… proto vám také nemohu říci, u kterých aplikací bude mít jejich záznam v sysmain.sdb za následek vyvolávání žádostí UAC o přidělení práv správce. Application Compatibility Toolkit je

124

Kapitola 2 – Řízení uživatelských účtů

samostatně stáhnutelný balíček od Microsoftu, a představuje příliš velké téma na to, abychom se mu v této kapitole mohli věnovat.

Změna konfigurace služby Řízení uživatelských účtů Zkoumali jsme společně, jakým způsobem UAC zkoumá jednotlivé aplikace a reaguje na jejich inicializaci, a dál jsem vám ukázal, jak lze změnit nastavení aplikací z hlediska řízení této reakce UAC. V této části se podíváme na změnu nastavení samotné služby UAC. Na rozdíl od mnoha jiných technologií Windows se UAC dá velmi dobře ovládat prostřednictvím zásad skupiny. Mezi zásadami najdeme pestrou paletu voleb pro řízení UAC, v GUI a okně příkazového řádku je to mnohem horší, což rozhodně není optimální situace – ale když bych si měl vybrat mezi ovládáním z GUI, příkazy v okně příkazového řádku a nastavováním přes zásady skupiny, vybral bych si poslední variantu, a to především proto, že mám takové neurčité podezření … podle mne UAC prostě patří mezi ty záležitosti, které budou ve velkých firmách určitě řízeny centrálně. Všechny zásady skupiny, které se týkají služby Řízení uživatelských účtů, najdeme v uzlu zásad Konfigurace počítače  Nastavení systému Windows  Nastavení zabezpečení  Místní zásady  Možnosti zabezpečení. Na začátku názvů všech zásad je předpona „Řízení uživatelských účtů:“ a celkem je tu devět voleb, které umožňují konfiguraci UAC zpřísnit nebo uvolnit.

Jak se dá motor UAC zapnout nebo vypnout, případně přetočit První otázkou, kterou každý položí, jakmile se začneme bavit o UAC, je klasické: „Jak se ta věc dá vypnout“? Doufám, že jsem vás předchozím výkladem přesvědčil o tom, že UAC je dobrá věc a že se vyplatí dát jí šanci, ale pokud s touto službou prostě nedokážete žít, dá se vypnout či zapnout prostřednictvím zásady skupiny „Řízení uživatelských účtů: Chování výzvy ke zvýšení oprávnění pro správce v Režimu schválení správce“, která má tři možné hodnoty: ■

Zvýšit bez zobrazení výzvy

■

Vyzvat k zadání pověření

■

Vyzvat k zadání souhlasu (výchozí hodnota).

„Zvýšit bez zobrazení výzvy“ znamená v člověčině toto: „když je třeba zeptat se správce, jestli má proces dostat oprávnění správce, neptej se ho a rovnou oprávnění uděl“. Toto „neotravování“ správce je ovšem skoro to samé, jako úplné vypnutí služby Řízení uživatelských účtů (drobné rozdíly vysvětlím za chvíli), a pokud skutečně zapnete tuto hodnotu zásady, objeví se u hlavního panelu bublina s varováním: „Zkontrolujte nastavení nástroje Řízení uživatelských účtů. Nástroj Řízení uživatelských účtů je vypnutý“. „Vyzvat k zadání souhlasu“ je výchozí konfigurace služby Řízení uživatelských účtů. Když správce pracující v Režimu schválení správce spustí aplikaci, která vyžaduje práva správce, objeví se na obrazovce jedno ze čtyř možných dialogových oken Consent UI, a ve většině případů bude moci správce v tomto okně vyjádřit svůj souhlas či nesouhlas s povýšením aplikace. Jestliže vám tato úroveň interakce mezi uživatelem a UAC nestačí, zkuste zvolit třetí hodnotu „Vyzvat k zadání

Změna konfigurace služby Řízení uživatelských účtů

125

pověření“, která posouvá souhlas správce o jeden krok dále a UAC se poté neptá se jen na to, zda uživatel-správce souhlasí, ale chce po něm ještě něco jiného, jak je vidět na obrázku 2.15. Jedná se o oranžové okno Consent UI, ale – jak jste si v obrázku zajisté všimnuli sami – tentokrát s jinou otázkou než předtím; nyní UAC prostě chce, aby uživatel-správce zapsal svoje heslo a tlačítkem OK vyjádřil svůj souhlas s povýšením oprávnění programu. Je opravdu nutné vyhnat motor Consent UI do takových otáček, aby po vás pokaždé chtěl zadat heslo namísto obyčejného klepnutí na tlačítko „Pokračovat“? Pravděpodobně ne, ale umím si představit situaci ve firmě, kde budou správci líní a nebudou pracovní stanice před svým odchodem o nich řádně zamykat. V takovém případě je třeba správcům pořádně domluvit a pokud by se jejich chování nezměnilo, bylo by vhodné pomoci jim urychleně ukončit pracovní poměr. Není-li toto drastické řešení možné (třeba kvůli tomu, že nelze sehnat náhradu), dá se nebezpečí zneužití účtu správce eliminovat tak, že aplikaci bude možné povýšit jen v případě, kdy bude zadáno heslo správce. Volba neustálého zadávání hesla je vhodná také pro ty, kteří jsou řádným zabezpečením přímo posedlí. (Osobně se domnívám, že Microsoft tuto variantu přidal kvůli tomu, aby uspokojil potřeby vedení jednoho nejmenovaného výrobce letadel, jehož areál se nachází v Seattle hned vedle Microsoftu, a který má hodně zakázek z ministerstva obrany. Je to samozřejmě jen můj odhad.) OBRÁZEK 2.15: Consent UI vyžadující více informací

Vzhledem k tomu, že si člověk nikdy není jist, jak rychle se změna v nastavení zásady skupiny uplatní, otestoval jsem všechny varianty v praxi, abych viděl, co vše je nutné udělat pro jejich zprovoznění. Když jsem změnil objekt místní zásady na svých počítačích s Vistou, začalo nové nastavení platit okamžitě po klepnutí na OK; nebyl nutný ani restart, ani příkaz gpupdate /force. POZNÁMKA:

Vrátím se nyní k tomu drobnému rozdílu mezi tím, co jsem označil jako vypínač UAC, a skutečným vypnutím této služby. Pojem „vypínač“ není stoprocentně správný, protože služba Řízení uživatelských účtů není úplně vypnuta. Existuje ještě jedna zásada skupiny „Řízení uživatelských účtů: spustit všechny správce v režimu schválení správce“, kterou budeme probírat za chvíli. Nemůžeme se jí věnovat ihned, protože dokud neprobereme některé další zásady, nemohu tu vysvětlovat rozdíly mezi touto zásadou a zásadou „Řízení uživatelských účtů: Chování výzvy ke zvýšení oprávnění pro správce v Režimu schválení správce“.

126

Kapitola 2 – Řízení uživatelských účtů

Nastavení „mladého“ UAC: UAC pro uživatele Během všeho předchozího povídání o tom, jak služba Řízení uživatelských účtů ovlivňuje práci správců, jsem nedopatřením přehlédnul to, co může být asi nejvýhodnějším aspektem UAC. Až doposud jste viděli UAC jen v režimu opakovaných dotazů „jste si opravdu jist“?. Nyní se seznámíte s přátelštější částí této služby. Předpokládejme, že dodržujete to, co jsem vám navrhoval již na začátku kapitoly: dodržujte starou osvědčenou zásadu pracovat co největší část pracovní doby na účet standardního uživatele. Náhle je však třeba provést něco, co vyžaduje oprávnění správce. Obvykle v těchto případech stačí klepnout pravým tlačítkem myši na ikonu programu, který chcete spustit a v místní nabídce vybrat příkaz Spustit jako správce. Díky UAC to však není nutné. Pokud plníte hodně úkolů – ne všechny, ale přesto hodně – vyžadujících oprávnění, která váš aktuální účet nemá a zkusíte spustit některý z takových úkolů, poté se ve většině případů objeví dialog, ve kterém můžete zapsat jméno účtu správce a jeho heslo, což vás chrání před nutností použít nástroj Spustit jako. Tento dialog se hodně podobá tomu z obrázku 2.15. Jak již bylo řečeno, Vista není dostatečně inteligentní na to, aby zobrazila sama Consent UI, ve kterém budete moci zapsat své pověřovací údaje (credentials), u většiny úkolů se však potřebný dialog objeví. Platí to pro většinu souborů EXE a samozřejmě příkaz „Spustit jako správce“ okno Consent UI vyvolá vždy. Když si projdete Ovládací panely, najdete v nich hypertextové odkazy s obrázkem štítu, které po poklepání na ně také zobrazí výzvu UAC. Problémy jsou jedině s moduly snap-in MMC. Jestliže nechcete, aby se Řízení uživatelských účtů takto chovalo, změňte jeho chování jednou ze zásad skupiny. Jde o zásadu „Řízení uživatelských účtů: Chování výzvy ke zvýšení oprávnění pro standardní uživatele“. Obdobně jako u předchozí probírané zásady tu najdeme hodnotu „Vyzvat k zadání pověření“, ale hodnota „Vyzvat k zadání souhlasu“ tu schází a hodnota „Zvýšit bez zobrazení výzvy“ se tu jmenuje jinak: „Automaticky zamítnout požadavky na zvýšení“ a její význam je rovněž zcela jiný, jak je zřejmé již z tohoto názvu – namísto potlačení UAC je žádost uživatele odmítnuta. Implicitní hodnotou je „Vyzvat k zadání pověření“. Nejsem si jistý, proč byste toto měli dělat, i když se to některým z vás možná bude hodit. Výchozí nastavení je ve skutečnosti přínosné i pro správce, když se nad ním zamyslíte. Dejme tomu, že stojíte za zády uživatele a pokoušíte se řešit nějaký jeho problém. Náhle potřebujete provést něco, co vyžaduje privilegium správce. Je přece příjemné vědět, že nemusíte uživatele odhlásit a přihlásit se na svůj účet – stačí klepnout na potřebného zástupce a ve výzvě zapsat název svého účtu správce a heslo. Vyřešit se dá dokonce i spouštění modulů snap-in MMC s právy administrátora: najděte prostě MMC.EXE ve složce System32, pravým tlačítkem myši na něj klepněte a v místní nabídce vyberte „Spustit jako správce“ – a hned tu je MMC s povýšenými privilegii. Moduly otevřené v této konzole budou dědit token správce. Obdobně jako u sousední zásady i zde začíná změna platit okamžitě po stisku tlačítka OK. Není nutný restart počítače ani odhlašování uživatele, je ovšem pravda, že pokud jste přihlášeni jako standardní uživatel, budete se muset hodně snažit, aby se vám povedlo tuto zásadu změnit!

Změna konfigurace služby Řízení uživatelských účtů

127

Odbočka: Jak moc velký správce musíte být, aby se vás UAC týkalo? Předchozí část mi připomíná, že jsem některé záležitosti trochu příliš zjednodušil, proto bych nyní rád některé díry zaplnil. Popisoval jsem tu svět tak, jako by se v něm vyskytovaly jen dva druhy uživatelů: ti, co mají token plného přístupu správce, a uživatelé s „omezeným“ tokenem uživatele se standardním oprávněním. Dále jsem tu psal o tom, že UAC dělí u uživatelů s právy správců jejich token na dvě části. Zeptejme se ale takto: kolik práv správce musíte mít, aby si vás služba Řízení uživatelských účtů všimla a považovala vás za správce? U standardních uživatelů k dělení tokenu nedochází, u členů skupiny Administrators je token rozdělen vždy. Ale co když budete standardní uživatel, kterému bylo uděleno jedno zvláštní oprávnění, například oprávnění měnit systémový čas pracovní stanice? Bude to stačit k tomu, aby váš token byl během přihlášení k systému rozdělen na dvě části? K zodpovězení této otázky je nutné znát pár podrobností. Budeme-li vycházet z některých záležitostí, které byly vysvětleny v předchozím textu, je možné říci, že UAC se probudí a rozdělí token uživatele na dvě části, pokud je splněna alespoň jedna z těchto podmínek: ■

Jste členem nejméně jedné místní skupiny uživatelů z Proslulé Čtyřky (Administrators, Backup Users, Power Users a Network Configuration Operators), nebo

■

Máte uděleno nejméně jedno z devíti dříve zmíněných oprávnění, které UAC zakazuje.

Následuje stručný příklad: dejme tomu, že jsem vytvořil uživatele SNO („správce s nízkým oprávněním“), který není členem ani jedné ze čtyř vyjmenovaných skupin, ale dostane jedno oprávnění, které schází standardním uživatelům – například oprávnění obnovovat soubory a složky. Bude to jediné oprávnění nad rozsah toho, co si může dovolit standardní uživatel. V tomto případě UAC při každém přihlášení tohoto uživatele vytvoří dva tokeny: token uživatele se standardním oprávněním, obsahující pět oprávnění běžného uživatele a členství ve všech skupinách), a dále token „střední úrovně integrity“. Tento uživatel tak bude mít svůj „správcovský“ token, ke kterému se dostane tak, že v místní nabídce libovolného programu zvolí příkaz „Spustit jako správce“. Tento token správce se bude od jeho tokenu uživatele se standardním oprávněním lišit ve dvou ohledech: bude obsahovat oprávnění pro obnovu souborů a složek a „vysokou úroveň“ integrity. A co když má tento uživatel provést něco, k čemu potřebuje práva úplného správce? UAC s touto možností počítá a proto po volbě příkazu „Spustit jako správce“ v místní nabídce udělá něco zajímavého: namísto obyčejného Consent UI s tlačítkem „Pokračovat“ nabídne uživateli možnost povýšit volaný proces jeho vlastním tokenem, nebo zvolit jiný účet, který má stejná oprávnění jako plnohodnotný místní správce.

Vyloučení vestavěného správce Upřímně řečeno, někdy mi výzva UAC připadá dost vlezlá a byl bych moc rád, kdybych systému Windows mohl říci: „UAC mne nezajímá, to si nech pro jiné správce; já to nepotřebuji a proto mne těmi výzvami neotravuj“. Řečeno jinak, chtěl bych, aby první skupina nastavení zásad, o které tu byla řeč, byla konfigurovatelná pro každého uživatele zvlášť. (Koneckonců, mám v tomto ohledu

128

Kapitola 2 – Řízení uživatelských účtů

velký vzor. Sám svatý Augustin v dobách svého nevázaného mládí se jednou modlil k nebesům a žádal: „Bože, sejmi ze mne mé hříchy a ukaž mi pravou cestu … ale teď ještě ne, prosím?“ UAC tato má přání vyslyšelo, ale trochu jinak – jak už to tak často bývá – než jsem očekával. Existuje zásada skupiny „Řízení uživatelských účtů: Režim schválení správce pro integrovaný účet správce“, kterou lze povolit či zakázat, přičemž implicitně je zakázána . Toto nastavení umožňuje vestavěnému účtu Administrator úplně se vyhnout působení UAC, a platí výhradně pro tento účet. Ve výchozím nastavení tedy uživatel přihlášený na účet Administrator nikdy nenarazí na výzvy služby Řízení uživatelských účtů, což je z hlediska zabezpečení hodně problematické – a vždy bylo – ale je to vyváženo faktem, probraným již v první kapitole, že tento vestavěný účet Administrator je ve Vistě implicitně zakázán.

Jak přikázat služba UAC vynechat heuristiku V jedné z předchozích částí jsme viděli, že UAC disponuje jednou zajímavou vlastností: kdykoli se pokusíte spustit program a nepožadujete přitom zvýšení jeho pravomocí, UAC se pokusí odhadnout, zda se náhodou nejedná o instalátor aplikací. Vzhledem k tomu, že instalace aplikací často zahrnuje operace vyžadující práva správce a bez zvýšení pravomocí by tedy instalace mohla skončit chybou, UAC se tomu pokusí zabránit výše uvedeným odhadem povahy spouštěného programu. Připomínám, že UAC umí poznat instalátory Wyse a Installshield, a dále za takový program považuje každý soubor EXE, v jehož názvu se vyskytuje řetězec „instal“, „setu“ nebo „update“. Pokud z nějakého důvodu nechcete, aby Vista prováděla tyto heuristické průzkumy souborů EXE, změňte zásadu skupiny „Řízení uživatelských účtů: Zjistit instalace aplikací a zobrazit výzvu ke zvýšení oprávnění“. Tato zásada je implicitně zapnuta, dá se však vypnout. Na rozdíl od většiny ostatních zásad ovlivňujících UAC je po změně této zásady nutný restart počítače, aby změna začala platit.

Řízení zabezpečené plochy Pokud jste se již s Consent UI setkali při práci v systému, určitě jste si všimnuli, že kromě dialogu, který se objevil na obrazovce, došlo ještě k jedné změně: služba Řízení uživatelských účtů ztmavila zbytek pracovní plochy, do které se po celou dobu přítomnosti Consent UI na obrazovce není možné dostat. Spuštěné aplikace dále běží, ale na šedé pracovní ploše se neprojevují žádné změny. Pokud byste měli například spuštěný nějaký film v přehrávači (nebo na pracovní ploše) a rozhodli se podívat na zásady skupiny příkazem Start  Všechny programy  Spustit  zápis gpedit.msc a stisk OK, pracovní plocha zešedne, objeví se dialogové okno Consent UI a video se zastaví. Počkáte-li však pár sekund, než klepnete na Pokračovat, obrazovka se opět rozzáří a film bude dále přehráván (i když určitá jeho část bude přeskočena). Je tedy jasné, že film byl přehráván i při ztmavené obrazovce, ale změny přitom nebylo možné vidět.

Co je zabezpečená plocha Proč pracovní plocha zešedla? Tomuto jevu se říká „zabezpečená plocha“. Je to jeden z prostředků Visty, využívaný službou Řízení uživatelských účtů a přinejmenším jednou další aplikací Visty

Změna konfigurace služby Řízení uživatelských účtů

129

s názvem CardSafe (systém pro online identifikaci) pro zabezpečení některých druhů interakcí na pracovní ploše. Klíčem k pochopení celé úlohy Zabezpečené plochy je zodpovězení důležité otázky, týkající se funkčnosti UAC: jak může hacker tuto ochranu kompromitovat? Jak by mohl nějaký budoucí „kvalitně“ napsaný malware obejít UAC a buď ošálit uživatele tak, aby namísto na Storno klepnul na Pokračovat, nebo jak by dokázal klepnout na toto tlačítko sám? Autor takového malwaru, psaného s ohledem na Vistu a funkční UAC, velmi dobře ví, že nejdříve musí získat práva správce a teprve poté se dá způsobit nějaká škoda. Proto musí spustit nějaký soubor EXE a vyžádat si zvýšení jeho pravomocí, přičemž uživatel bude muset klepnout na „Pokračovat“ nebo podobné tlačítko. Předpokládejme, že náš hypotetický malware počká, než systém zobrazí Consent UI, a poté vytvoří obrázek pracovní plochy a Consent UI který bude upraven tak, aby si uživatel myslel, že klepá na tlačítko „Storno“… jenže ve skutečnosti klepne na „Pokračovat“. Jinou možností v tomto směru je náhrada ukazatele myši za jiný, vlastní ukazatel, podobající se vestavěnému ukazateli Windows. Takto se dá vytvořit například ukazatel myši, který bude zobrazovat šipku třeba 40 pixelů vlevo od místa, kam myš ukazuje ve skutečnosti. Při běžné práci je takový ukazatel samozřejmě na nic, museli byste si totiž zvyknout na to, že ukazatel nesmíte umístit nad tlačítko, které chcete stisknout, ale přibližně o 40 pixelů směrem doprava od něj (a taková vzdálenost se nedá odhadnout jen tak snadno!). Zákeřný program však může předpokládat, že se při pokusu o provedení určité činnosti zobrazí Consent UI, které by poučený uživatel zavřel tlačítkem Storno, protože v daném okamžiku neprovádí nic, co by vyžadovalo povýšení práv aplikace. Malware proto tiše změní ukazatel myši a podsune namísto výchozího ukazatele třeba právě ten, který jsme si popsali před chvílí. Dejme tomu, že tlačítko Storno je právě 40 pixelů vpravo od tlačítka Pokračovat. Uživatel se domnívá, že stisknul tlačítko Storno – a ve skutečnosti klepnul na Pokračovat. Slabinou zabezpečení bylo v obou případech rozhraní mezi uživatelem a počítačem; v prostředí standardní plochy Windows je velmi snadné ošálit uživatele a přinutit ho udělat něco, co vůbec provést nechtěl. Jak se s tímto nebezpečím vypořádat? Microsoft by samozřejmě mohl zrušit možnost přiřazovat myši vlastní ukazatele, výrazně omezit typy obrázků, které by aplikace mohly vykreslovat na obrazovce, a mohl by si dovolit spoustu dalších změn, které by (1) v podstatě na Vistě znemožnily chod většiny aplikací – především her – a (2) značně zredukovaly možnost úpravy vzhledu Windows, což by se odrazilo na mnohem menší atraktivitě Windows pro vývoj aplikací. Je jasné, že touto cestou se Microsoft dát nemohl, a proto přišel se Zabezpečenou plochou. Když je Zabezpečená plocha aktivní, je vidět pouze okno jednoho programu, a tento program má jen velmi omezená práva, takže okruh jeho povolených činností je velmi stručný. (Programátoři her zapláčou – žádný Tetris pro zabezpečenou plochu nikdy nenapíšou. Smůla, hoši.) Během těch pár okamžiků, kdy je Zabezpečená plocha aktivní, máte před sebou takto omezený operační systém. Nad Zabezpečenou plochou mohou ve skutečnosti pracovat jen ty aplikace, které jsou digitálně podepsány jako součást samostatné Visty (například consent.exe, program vyvolávající různá UI). Žádný malware nemá šanci získat takový digitální certifikát a pokud by se snad takový někdy našel, je jasné, kdo je jeho autorem… Microsoft.

130

Kapitola 2 – Řízení uživatelských účtů

Vypnutí Zabezpečené plochy Když tedy UAC vyzve uživatele k souhlasu se zvýšením práv procesu, stanou se dvě věci. Za prvé, Vista aktivuje Zabezpečenou plochu, za druhé vyvolá dialogové okno Consent UI. Jedná se o dvě různé operace a ta první se dá v případě zájmu vypnout. Přeskočením fáze aktivní Zabezpečené plochy se teoreticky vystavujete nebezpečí oklamání chytře napsaným malwarem, který vás může přimět k souhlasu s jeho instalací Je však možné, že budete mít spuštěnu nějakou aplikaci, která se při aktivaci Zabezpečené plochy kousne nebo spadne, a tato aplikace přitom musí být z nějakého důvodu neustále spuštěna. (V příští části bude řeč o celé třídě takových aplikací.) V takovém případě je možné aplikaci buď záplatovat či inovovat, nebo přikázat službě Řízení uživatelských účtů, aby neaktivovala Zabezpečenou plochu. Zabezpečená plocha se dá vypnout prostřednictvím zásady skupiny „Řízení uživatelských účtů: při zobrazení výzvy ke zvýšení oprávnění přepnout na zabezpečenou plochu“, kterou lze povolit nebo zakázat, přičemž implicitně je povolena. Tuto zásadu zakazuji v jednom konkrétním případě: když chci snímat obrazovky s dialogem Consent UI, protože jinak mi Zabezpečená plocha nepovolí v žádném programu získat snímek obrazovky. (To je samozřejmě očekávané chování, jinak by Zabezpečená plocha byla k ničemu.) Povolení nebo zákaz této zásady se projeví okamžitě po změně v gpedit.msc. Jestliže zásadu změníte, nemá to vliv na jiné aplikace, využívající Zabezpečenou plochu, například CardSafe.

Povolení některých aplikací při aktivní Zabezpečené ploše Právě jste si přečetli, že Zabezpečená plocha ve spolupráci s Consent UI zajišťuje v prostředí Visty získání jednoznačné odpovědi na otázku „Zvýšit oprávnění nebo ne?“. Přitom jsou dočasně zženy všechny interakce a programovací operace na jediné dvě možné operace – klepnutí myší na tlačítko v Consent UI a stisk klávesy na klávesnici. Obdobně jako Perry Mason před soudem nekompromisně vyslýchá důležitého svědka, Vista v tomto případě uživateli dává jasně najevo, že se od něj očekává jen jedna z uvedených dvou věcí, a že na to má jen dvě minuty, takže by neměl moc váhat… V některých případech však takové omezení není přípustné: pokud uživatel používá některý z nástrojů pro usnadnění přístupu tělesně postižených. Ve Vistě jsou některé takové nástroje přímo vestavěny, například Klávesnice na obrazovce nebo Narrator (čtečka obrazovky) … je tedy jasné, že Zabezpečená plocha musí s těmito alternativními metodami vstupu uživatele počítat a povolit je. Obecně se tyto nástroje označují pojmem „UI automation tools“ (nástroje pro automatizaci UI). Některé z nich – například Klávesnice na obrazovce a Narrator – jsou součástí Windows a jsou proto digitálně podepsány, přičemž je podepsal dodavatel, kterému Microsoft důvěřuje nejvíc – on sám. Zabezpečená plocha proto mezi přípustné formy vstupu a výstupu dat automaticky zahrnuje i Narrator a Klávesnici na obrazovce. Co však dělat v případě, kdy začne nějaký jiný dodavatel prodávat neobyčejně spolehlivý systém pro hlasové ovládání systému nebo ústní tyčku pro lidi, kteří mohou hýbat jen svaly nad krkem, případně kdyby došlo ke splnění jednoho z mých největších snů a na trhu se objevilo něco, co by mi umožnilo ovládat počítač jen myšlenkami – jak takový nástroj jiného výrobce bezpečně napojit na Zabezpečenou plochu? Nástroje pro automatizaci UI musí udělat tři věci, aby mohly spolupracovat se Zabezpečenou plochou. Za prvé, musí uvědomit UAC, že potřebují přistupovat k uživatelskému rozhraní Za-

Změna konfigurace služby Řízení uživatelských účtů

131

bezpečené plochy. K tomu účelu slouží určité parametry v manifestu souboru. Připomeňme si, že manifest lze vložit do libovolného souboru EXE a dát jeho prostřednictvím službě Řízení uživatelských účtů na vědomí, že tento soubor EXE vyžaduje oprávnění správce. Příslušná část manifestu vypadala takto: <requestedExecutionLevel level="asInvoker" uiAccess="false" />

V předchozím textu byl vysvětlen význam parametru "asInvoker", druhý parametr uiAccess jsem si však nechal až do této části. Právě zde může tvůrce aplikace službě Řízení uživatelských účtů sdělit, že jde o aplikaci uživatelského rozhraní, sloužící pro zadávání nebo výstup nějakých dat a proto musí být povolena i nad Zabezpečenou plochou. Je zřejmé, že tento parametr bude mít u nástrojů pro automatizaci UI tvar uiAccess="true". Dále platí, že vývojář musí svůj nástroj pro automatizaci UI digitálně podepsat a nechat si ji Microsoftem schválit. Jak bylo uvedeno v první kapitole, toto schvalování probíhá v rámci programu Windows Hardware Quality Testing Labs a vyžaduje splnění určitých kritérií a zaplacení poplatku. Poté, co vývojář označí svůj nástroj parametrem manifestu uiAccess="true", přidá k němu svůj digitální podpis a nechá si ho digitálně podepsat ještě v laboratořích Microsoftu, musí splnit ještě třetí podmínku, aby jeho nástroj nebyl Zabezpečenou plochou odmítnut. Veškeré nástroje pro automatizaci UI musí být uloženy v jedné z přesně vymezených složek, které Microsoft označuje jako „zabezpečená umístění“ (secure locations). Celkem existují tři taková umístění: ■ ■ ■

\Windows\System32 a její podsložky, \Program Files a její podsložky, na 64bitových Windows pak ještě \Program Files (86) ( 86) a její podsložky.

POZNÁMKA:

Pro ty, kteří nikdy neměli možnost pracovat na 64bitových Windows, uvádím, že složka Program Files (86) funguje jako klasická složka Program Files, ale Windows do ní vkládají 32bitové aplikace. Nativní 64bitové aplikace jsou umístěny ve složce Program Files.

Dá se některý z těchto požadavků vynechat? První dva (parametr manifestu a digitální podpis) ne, ale třetí ano, protože existuje zásada skupiny „Řízení uživatelských účtů: Zvýšit oprávnění pouze u aplikací UIAccess, které jsou nainstalovány v zabezpečených umístěních“. Pokud tuto zásadu vypnete (implicitně je zapnuta), můžete nástroje pro automatizaci UI umístit i do jiných složek. Nemohl jsem bohužel otestovat, zda změna této zásady vyžaduje restart systému či nikoli, protože nemám možnost získat žádnou z podobných aplikací

Podepiš si kód nebo táhni: jak si vyžádat jen podepsané aplikace Z důvodů které jsem již popsal, velmi oceňuji koncepci digitálně podepsaného softwaru. Dokud budou firmy prodávající certifikáty pečlivě kontrolovat, že certifikát vydaný na jméno Franty Vo-

132

Kapitola 2 – Řízení uživatelských účtů

máčky byl skutečně prodán Frantovi Vomáčkovi, poté sice nemůžeme zabránit tomu, že Franta napíše a rozšíří škodlivý program, ale budeme schopni prokázat, že to je jeho práce. Samozřejmě tento krok není schopen zajistit dokonalou bezpečnost, ale je to velmi důležitý krok správným směrem. Anonymita Internetu je jeho nejlepší i nejhorší vlastností: jak to krásně vyjádřila jedna starší kreslená anekdota v New Yorker – „na Internetu nikdo neví, že jste ve skutečnosti pes“. To má své přednosti i zápory, a tyto zápory se projevují jako velmi důležité faktory při vzniku světa plného škodlivého kódu, se kterým se dnes musíme vyrovnat. Budeme-li vědět, kdo napsal ten skvělý nebo naopak hrozný kód, pomůže nám to zavést něco, co podle mého názoru Internet nezbytně potřebuje: metodu pro udržování „reputace“ neboli možnost říci: „aha, tohle napsal Jirka Slavík; to je dobrý programátor“. Dobré jméno je fundamentální součástí naší interakce s jinými lidmi a je velmi vhodné si takové dobré jméno získat. Proč tedy to samé nerealizovat na úrovni kódu? Proto mne tak udivuje, jak málo firem ve skutečnosti podepisuje své aplikace. Otevřete si složku Program Files a zkuste si tam najít několik souborů EXE a DLL; pravým tlačítkem myši vyvolejte jejich místní nabídku, otevřete okno vlastností a hledejte stránku „Digitální certifikáty“. U většiny programů ji nenajdete, a to ani u programů Microsoftu, natož pak u programů jiných firem. Je to ostuda, digitální podpisy totiž slouží i jiným účelům než jen jako doklady o identitě autora kódu. Zašifrovaný hash, uložený v digitálním podpisu, umožňuje operačnímu systému rychle ověřit, že kód nebyl od okamžiku svého podepsání změněn. Při vyhledávání malwaru je tedy možné správně podepsané soubory vynechat, protože ty budou „čisté“ (za předpokladu, že můžeme důvěřovat osobě či firmě, která program podepsala. Znám však jeden důvod, který vysvětluje, proč tolik programů není podepsaných: získání potřebného certifikátu trvá delší dobu a stojí dost peněz, lidé přitom tyto digitální podpisy nevyžadují. U programů poskytovaných zdarma nebo za nízký poplatek je tento důvod dostatečný, u velkých softwarových firem se to ale dá pochopit jen stěží nebo vůbec ne. U 64bitové verze Visty je tato argumentace ve prospěch podpisů prakticky vyjádřena tím, že při spouštění systému jsou kontrolovány povinné digitální podpisy u všech ovladačů zařízení a programů zaváděných spolu se systémem. Jakmile je však zaváděcí fáze ukončena, netrvá už Vista x64 na tom, aby spouštěné aplikace byly digitálně podepsány. Nelíbí se vám to a stojíte jen o digitálně podepsané aplikace? To se dá zařídit prostřednictvím další zásady skupiny: Řízení uživatelských účtů: pouze spuštěné aplikace, kterého jsou podepsané, jsou validovány. Je-li tato zásada zapnuta, mění poněkud způsob činnosti UAC. Zatímco až doposud jste četli o tom, že UAC po obdržení souhlasu od uživatele povýšilo oprávnění aplikace (podle pravidla „chce-li správce s rozděleným tokenem udělit svůj token plného přístupu správce aplikaci ABC. EXE, ať to udělá“), nyní je však uvedené pravidlo rozšířeno a kromě souhlasu uživatele-správce musí být soubor EXE také podepsán. Tato zásada skupiny nevyžaduje, aby byly podepsány všechny programy, ale jen ty, které mají být spuštěny s tokenem plného přístupu správce. Microsoft to takto nastavil nejspíše proto, že malware běžící pod účtem standardního uživatele nebude schopen napáchat tolik škod jako malware disponující tokenem plného přístupu správce. Když se pokusíte spustit nepodepsanou aplikaci, která vyžaduje zvýšení pravomocí, Vista vám sdělí, že tento program nespustí, ale jak je vidět na obrázku 2.16, není toto dialogové okno příliš výstižné.

Změna konfigurace služby Řízení uživatelských účtů

133

OBRÁZEK 2.16: Dialog Visty vysvětlující, že program nelze spustit, protože není podepsán

Než se přesuneme k nastavení dalších zásad skupiny, rád bych ještě upřesnil, co byste podle mne měli v nastavení této zásady skupiny změnit. Na jedné straně platí mé přání, že by někdy mělo dojít k zákazu nepodepsaných aplikací s pravomocemi správce, ale realita je v tomto směru neúprosná. Mnozí vývojáři své výtvory momentálně nepodepisují, a proto požadavek na nasazení jen podepsaných aplikací by velmi nepříznivě ovlivnil jejich nasazení na vašich počítačích. Nedávno jsem například kontroloval aplikace používané v jedné menší síti, abych zjistil, o co všechno bych přišel, kdybych vyžadoval jen podepsané spustitelné soubory. V podstatě všechny provozované programy, nevyžadující povýšení práv, nebyly podepsány; výjimku tvořil jen balík programů Microsoft Office. Digitální podpis scházel u programů na zpracování fotografií, nebyl v Adobe Readeru ani v Quicken. To pravděpodobně není problém s výjimkou Quicken, protože Intuit se vyskytuje ve všech Top Ten Most Wanted – a zde nemíním „wanted“ v tom dobrém významu slova – pro jejich neschopnost napsat aplikaci se kterou by mohl pracovat „normální“, standardní uživatel. Ano, je to tak: pokud si projdete miliony uživatelů důvěřujících osobnímu přihlašování ke Quicken, zjistíte, že byste mohli používat aplikaci Quicken jako: Spustit jako správce ("Run as administrator"). Ale pokud nastavíte User Account Control: Only execute executables that are signed and validated, dostanete se do problémů, protože Quicken neobsahuje dosud digitální podpis. A to je důležité: přemýšlíte-li o tom, že budete u aplikací povinně vyžadovat digitální podpis, nesmíte kontrolovat jen nástroje pro správu, ale musíte si uvědomit, že existuje i množství jiných jednoduchých programů, u kterých není žádný důvod k tomu, aby pro svůj běh vyžadovaly token plného přístupu správce – ale ony ho přitom vyžadují Pokud se týká nástrojů pro správu systému, používám ty programy, které jsou přímo součástí Windows, a také množství dalších pomůcek, které si mohu stáhnout přímo z jejich webu. Bohužel však mnohé z těchto souborů nejsou podepsány . Různé užitečné nástroje, se daly sehnat i na webu Sysinternals (který je po odkoupení firmy Wininternals nyní již součástí webu Microsoftu); zde byla většina souborů podepsána, ale opět ne všechny. Ještě jeden faktor není možné ignorovat, a tím jsou náklady na digitální podpisy. Kdybych se věnoval psaní miniaturních nástrojů příkazového řádku, investoval bych stovky dolarů do jejich podpisů jen proto, abych je potom mohl volně šířit? Na 99% ne. Celé se to dá shrnout do jediné závěrečné věty: pokud nespouštíte jen omezenou sadu nástrojů pro správu, které jsou digitálně podepsány, a používáte také různé produkční aplikace nevyžadující ke svému spuštění oprávnění správce, je nevhodné zapínat zásadu skupiny „User Account Control: Only execute executables that are signed and validated“.

134

Kapitola 2 – Řízení uživatelských účtů

Co dělat s aplikacemi, které ukládají data na nesprávná místa Po mnoho let si aplikace (přesněji řečeno jejich tvůrci) myslely, že je možné ukládat data i tam, kam uživatelé nic ukládat nemají. S nástupem Visty je těmto praktikám konec, protože složky \Program Files, \Program Files (x86) a \Windows jsou proti zápisům chráněny, obdobně jako větev systémového registru HKEY_LOCAL_MACHINE\SOFTWARE. Starší aplikace, které se nadále budou pokoušet o zápis do těchto umístění, však nemusí hlásit chybu, díky novému nástroji Visty, označovanému jako „virtualizace souborů a registru“. Toto téma je probíráno v jedné z pozdějších kapitol, ale když už probíráme zásady skupiny ovlivňující službu Řízení uživatelských účtů, rád bych se zmínil o tom, že tato virtualizace se dá vypnout pomocí zásady skupiny „Řízení uživatelských účtů: Virtualizovat chyby zápisu do souboru a registru do umístění jednotlivých uživatelů“. Změna této zásady vyžaduje restart počítače.

Velký skok: Úplné vypnutí UAC Pro ty, kteří se navzdory všem argumentům podaným v této kapitole rozhodli, že UAC prostě na svém systému nesnesou a hodlají se ho úplně zbavit je určena tato část kapitoly. Chápu, že chcete věci tak, jak fungovaly až doposud: když se o něco administrátorského pokusí standardní uživatelé, nepovede se jim to, když to bude dělat uživatel-správce, tak „se to prostě stane“. (Tak za dvacet let se možná pamětníci budou vytahovat před svými dětmi, jak to bylo skvělé „v těch dobách, kdy ještě správci byli správci… a skoro nikdo nebyl jen obyčejným uživatelem“. A děti se možná zlomyslně ušklíbnou a odpoví: „no jo, to byly staré zlaté doby… plné rootkitů, spamu, zombie počítačů, otevřených relay serverů… takové časy si strčte za klobouk“.) Samozřejmě můžete mít velmi dobrý důvod k tomu, proč je právě na vašem počítači nutné UAC vypnout, protože ho nemůžete používat, případně se pokoušíte přijít na to, proč některé starší aplikace na Vistě nechodí, a chcete zjistit, zda na tom nemá svůj podíl UAC, nebo jste jen něco opomněli během instalace a úvodní konfigurace. Nastavení zásady „Řízení uživatelských účtů: Chování výzvy ke zvýšení oprávnění pro Správce v režimu schválení správce“ na hodnotu „Zvýšit bez zobrazení výzvy“ není to samé, co úplné vypnutí služby Řízení uživatelských účtů, kterého dosáhnete tak, že zásadu skupiny „Řízení uživatelských účtů: Spustit všechny správce v Režimu schválení správce“ nastavíte na hodnotu „Zakázat“ a restartujete systém. UAC je pryč, včetně virtualizace souborů a systémového registru.

Prosadí se UAC v praxi? Jak jsem napsal na začátku této kapitoly, je trochu divné vystupovat jako příznivce prostředku, na který podle mne bude naprostá většina lidí reagovat stejně záporně, jako kdysi já sám. „Možná je to užitečné, ale mně se to prostě nelíbí!“ Asi tak nějak. Ale také jsem vám vysvětlil, že mi všechno došlo v jednom okamžiku někdy v červnu 2006, když jsem pomáhal svému známému (ale mohl být klidně i člen rodiny nebo soused) odstraňovat z jeho počítače 10 – nevymýšlím si, bylo jich skutečně 10 – různých kusů spywaru. A přitom to byl inteligentní člověk, žádný přízemní klikač. Technik, který nepracuje přímo s počítači, ale určité

Prosadí se UAC v praxi?

135

zkušenosti má …a podařilo se mu Pandořinu skříňku plnou překvapení nejen otevřít, ale ještě pro její obyvatele nechtěně vytvořil ideální prostředí k životu. Domnívám se, že UAC potřebují skoro všichni uživatelé, kteří na jedné straně s počítači pracují téměř každý den, a na straně druhé nejsou tak zdatní, aby chápali nebezpečí, která na ně v prostředí zasíťovaných počítačů čekají. Běžní uživatelé mají matné tušení o tom, že je třeba mít nainstalován antivirový program a osobní firewall, a že k napadení počítačů opravdu dochází, ale nechápou, jaké činnosti na počítači mohou bezprostředně ohrozit jejich soukromí a případně i majetek. Téměř nikdo z nich pak nerozumí tomu, jak se na jejich počítače mohou dostat různí červi a boti, kteří pak vzdáleně napadají další počítače a mohou zpomalit jejich přístup k Internetu. Byl bych moc rád, kdybyste správně chápali to, co říkám: nehodlám nikoho zesměšňovat kvůli tomu, že se nevyzná v útrobách počítače, ani neočekávám, že by normální uživatel měl být bezpečnostním expertem, ale určitě je nutné, aby si všichni uvědomovali, které činnosti jsou rizikové. Vážné problémy si žádají pořádnou medicínu. I mne UAC původně hodně otravoval, ale časem jsem si na něj zvyknul a mám tušení, že ostatní si zvyknou také. Ale z principu se mi podobné bezpečnostní pásy prostě nelíbí. Jako člověk, který získal řidičský průkaz v roce 1974 – pouhých šest let poté, co vláda USA rozhodla o tom, že bezpečnostní pásy budou povinnou výbavou všech vozů – si ještě pamatuji jízdu autem bez pásů a trochu mne dopaluje, že jsem si na ně zvyknout musel. Obdobně mám rád, když mohu co nejvíce snížit spotřebu svého vozu – ne kvůli úspoře pár dolarů, ale jen kvůli čiré radosti z optimalizace: jezdím ve starém autu Volkswagen Brouk, který ujede asi tak 50 mil na jeden galon, a to se mi zdá dost málo. Je ovšem nutné přiznat, že dnešní auta mohou těžko dosáhnout tak nízké spotřeby jako auto z roku 1962, protože jako součást povinné výbavy musí převážet desítky kilogramů nárazníků, bočních nosníků, airbagů a počínaje rokem 1986 také zadní přídavná brzdová světla… a tyto nadbytečné součásti prostě nejdou dohromady s mojí ujetou vzdáleností. Co to má společné se službou Řízení uživatelských účtů? To je velmi jednoduché: všechny tyto ochrany jen zpomalují můj auťák a nutí mne platit víc peněz za ujetou vzdálenost, a to z jednoho jediného důvodu: abych byl lépe chráněn, ať už se mi to líbí nebo nelíbí, přestože patřím mezi ty řidiče, kteří jezdí vždy bezpečně. Je proto logické, že lidé, kteří chápou, jak operační systém funguje, se nad těmito novotami rozčilí. Microsoft ovšem nevyrábí operační systémy jen pro mne; jsou vytvářeny tak, aby je zvládnul průměrný Franta a Mařka. Ani Honda nevyrábí auta určená přímo pro mne (i když moje 67 MPG 2000 Honda Insight vypadá skoro stejně jako auto, které bych si pro sebe navrhnul sám), ale pro hromadný trh. Tento trh je regulován vládou. Výrobci aut montují zmíněné bezpečnostní prvky do svých automobilů především proto, že to od nich požaduje vláda. A vláda to požaduje kvůli tomu, že jejím členům je sice jasné, že většina řidičů jezdí bezpečně, ale celkový počet zranění na silnicích, smrtelných nehod a majetkových ztrát byl prostě příliš velký. Microsoft nebyl nikým nucen zabudovat do Visty službu Řízení uživatelských účtů, ale je jasné, že bezpečnostní rizika jsou ve srovnání se situací před deseti lety (v době nástupu NT 4.0 Workstation) řádově vyšší. Nikdy jsem na silnici bezpečnostní pásy nevyužil (havárie se mi díky Bohu vyhýbají), ale to neznamená, že se mi někdy nebudou hodit, a někde uvnitř sebe tuším, že se cítím bezpečněji, když jedu připoután. Stejně tak si myslím, že bych se nenechal ošálit tak, abych si do systému

136

Kapitola 2 – Řízení uživatelských účtů

nainstaloval nějaký spyware či jiný malware, ale možné to je. Časem se zřejmě ukáže, že důrazná varování, která UAC opakovaně „vyhazuje“ na obrazovky našich počítačů, jsou ke prospěchu věci. Počet zlých hochů „tam venku“ se – bez přehánění – zvyšuje každý den. UAC nám může pomoci udržet je co nejdál. (Někdy se však bojím, že to nakonec skončí špatně a uživatelé začnou dialogy UAC bezmyšlenkovitě potvrzovat, aniž by vůbec četli, jaký program se pokouší zvýšit si svá oprávnění.)

Souhrn Rád bych celou kapitolu ukončil několika posledními návrhy pro ty z vás, kteří UAC nesnášejí. Za prvé vám důrazně radím, abyste tento nástroj vyzkoušeli, a to pořádně. Dle mé vlastní zkušenosti se po pár týdnech ze zlého vlka stane neškodný beránek. A najděte si čas vysvětlit svým přátelům i rodinným příslušníkům, co tato věc dělá a k čemu je určena. Prosím, abyste na otázku ohledně UAC nereagovali okamžitým „to je ta stupidní novinka, ukážu vám, jak se to dá vypnout“, především ne u těch uživatelů, kteří nejsou příliš technicky zdatní. Za druhé, než prohlásíte, že by UAC mělo fungovat úplně jinak a „mělo by si to nějakou dobu pamatovat, že já jsem sakra admin a ne že mne to bude otravovat každé dvě minuty“, vzpomeňte si, co víte o různém škodlivém softwaru a jak se tento projevuje a funguje. Když vezmete do úvahy, že Microsoft musel přijít se Zabezpečenou plochou, protože by vás jinak zlí hošani mohli přimět nainstalovat něco, co by zfalšovalo vaši myš nebo možná i klávesnici, a vy byste pak potvrdili něco, co jste ve skutečnosti chtěli zrušit, pochopíte sami, že konkurence na opačné straně hřiště je velmi tvrdá, a Microsoft proto musí být ještě tvrdší. Malware je čím dál tím chytřejší! A co je vůbec nejhorší, kdyby služba Řízení uživatelských účtů dokázala zachytit jen 80 procent běžných druhů škodlivého kódu, měli bychom tu něco, co nás bude pořád otravovat a přitom nás to neochrání. (Jak všichni víme, takový druh zabezpečení se vyskytuje jinak jen na letištích – a tamní lidé jsou za to přitom placeni.) A konečně je dobré nezapomenout na to, že UAC se dá vždy vypnout, ať už z GUI nebo prostřednictvím zásad skupiny. Když zjistíte, že s tímto nástrojem skutečně nedokážete vyžít, až poté je čas se ho zbavit… ale díky tomu, že je standardně zapnuté, může UAC uchránit jednoho z vašich přítel nebo člena rodiny před velkými problémy!

3 Nápověda pro virtualizaci souborů a registru U některých aplikací nesouvisejících se správou systému – především tzv. produkčních aplikací a her – je nutné zvýšení jejich pravomocí, přestože z titulu jejich účelu by neměly provádět žádné operace správní povahy. Program pro osobní účetnictví, technické kreslítko nebo e-mailový klient (tyto tři případy mě napadly z hlavy, může jít samozřejmě i o jiné druhy programů) někdy požaduje práva správce proto, že jde – není důvod si brát servítky – o zcela špatně napsanou aplikaci. U některých programů se potkávám s tím, že zapisují své uživatelské nastavení do větve registru HKEY_LOCAL_MACHINE namísto správné větve HKEY_CURRENT_USER. Jiné aplikace se zase instalují do složky Program Files, což je zcela správné chování, ovšem následně se pokouší zapsat datové soubory vytvořené uživatelem do stejné programové složky v Program Files, a to už je naopak totálně špatně, protože přístupová oprávnění NTFS pro složku Program Files a její podsložky nepovolují uživatelům zapisovat sem soubory. Je velmi frustrující sledovat desítky a desítky takových programů, psaných různými nezávislými softwarovými firmami, ale oni nejsou v žádném případě jediným viníkem – jedním z nejhorších porušovatelů těchto zásad je sám Microsoft, i když o sobě tvrdí, že se polepšil. Přesto však Visual Studio Express ukládá uživatelské projekty implicitně do složky Program Files a SQL Server 2000 (nebo 2005) ukládají soubory databází rovněž do podsložek Program Files. Fuj. Zmínil jsem složky System32 a Program Files, to ale nejsou jediné zakázané oblasti souborového systému pro uživatele. Ve Windows XP byla skupině Everyone zakázána možnost vytvářet soubory v kořenové složce počítače (na disku, kde je instalován systém) a Vista v tomto omezujícím trendu pokračuje. POZNÁMKA:

Vista ve skutečnosti omezuje přístup do složek Windows v takovém rozsahu, že pro skoro každou změnu v těchto složkách je potřebné zapnout výchozího správce systému, ale tomuto tématu se budeme věnovat v příští kapitole.

Základy virtualizace souborů a registru Co z předchozího textu vyplývá? V podstatě to, že i některé velmi jednoduché aplikace, které se na Windows používají, nemusí na Vistě vůbec fungovat. Microsoft samozřejmě velmi dobře ví, že

138

Kapitola 3 – Nápověda pro virtualizaci souborů a registru

kdyby na Vistě nechodilo větší množství aplikací, poté by se lidé mohli rozhodnout takový systém nekoupit či nepoužívat. Proto do systému přidali zajímavou záplatu, která zachytává pokusy těchto „vadných“ aplikací o zápis do chráněných složek a přímo za běhu ho koriguje. Této záplatě se oficiálně říká „virtualizace souborů a registru“. Podívejme se ve stručnosti, jak tato virtualizace souborů a registru funguje. Pokud se aplikace bez práv správce pokusí o zápis do jedné ze tří složek – Program Files, Program Files (x86) a \Windows – je tento zápis souboru automaticky přesměrován do složky v profilu uživatele, a aplikace přitom nemá vůbec ponětí o tom, že k tomuto přesměrování došlo. Něco podobného se stane při každém pokusu aplikace o zápis do větve HKEY_LOCAL_MACHINE\SOFTWARE systémového registru, protože takové zápisy jsou automaticky přesměrovány do větve HKEY_CURRENT_USER. Starší aplikace nemá nejmenší ponětí o tom, že se jí nepodařil zápis do chráněné složky nebo větve systémového registru, data se nenacházejí v chráněné systémové oblasti, takže je spokojena aplikace i ti, kteří chtějí standardním uživatelům zabránit v zápisu dat do určitých míst. Hmmm … zní to velmi dobře, ale pořád je řeč o zápisu dat, jak to vypadá při jejich čtení? Co se stane, když se aplikace pokusí přečíst data, která má podle ní zapsána dejme tomu ve složce C:\Windows? Soubor s daty pochopitelně není ve složce C:\Windows, ale někde jinde, bude tedy pokus o jejich přečtení neúspěšný? Naštěstí ne. Když se starší aplikace pokusí číst z chráněného umístění, Vista nejprve tiše zkontroluje místo, kde ukrývá virtualizovaná data, a pokud najde soubor, který aplikace hledá, poté jí ho doručí a tvrdí přitom, že „to je ta věc ze složky C:\Windows, kterou jsi po mně chtěla“. Jestliže se soubor ve virtualizované datové oblasti nenachází, poté se Vista podívá do chráněného umístění, zda soubor náhodou není uložen tam. Aplikace nemá o těchto krocích ani potuchy, ona prostě požádala o soubor nebo položku registru, a ten/tu získala.

Virtualizace souborů v akci Neznámým věcem porozumím lépe, když vidím jak fungují, proto si nyní virtualizaci souborů vyzkoušíme v praxi. Abychom to mohli udělat, potřebujeme pochopitelně nějakou starší aplikaci, psanou bez ohledu na systém Vista. Nevím jak vy, ale mně takové právě došly. Proto jsem si napsal několik legacy prográmků, které použijeme pro otestování virtualizace souborů (a později i registru). Chcete-li si celý příklad vyzkoušet sami, stáhněte si z mého webu dva programové soubory a uložte je do složky C:\pokusy, kterou jste vytvořili pro příklady v předchozí kapitole. Soubory najdete na adresách http://www.minasi.com/vista/show.exe a http://www.minasi.com/ vista/createfile.exe.

Program createfile.exe přebírá jako svůj jediný argument název souboru. Tento soubor poté vytvoří a vloží do něj text „Hello, World!“. Tento program použijeme k předvedení toho, co se stane při pokusu o zápis do chráněného umístění, v našem případě půjde o složku C:\Windows. Poté použijeme soubor show.exe, což je legacy aplikace opět přebírající název souboru jako svůj jediný argument, a obsah tohoto souboru vypíše na obrazovku. Program show.exe v podstatě jen duplikuje nástroj příkazového řádku type, který je tu s námi již od dob DOSu 1.0.

Virtualizace souborů v akci POZNÁMKA:

139

Proč tedy nepoužijeme přímo příkaz type? Vista ví, že tento nástroj v ní obsažený je pro ní také napsán. U programů psaných přímo pro Vistu není nikdy použita virtualizace souborů a registru. Později – až vysvětlím, jak Vista rozhoduje o tom, kdy virtualizaci povolí a kdy ne – uvidíte, že většina aplikací výhody virtualizace souborů a registru nepozná. Microsoft označuje aplikace, které Vista v tomto ohledu sleduje, jako „virtualizované“, proto můžeme říci, že pokusný program createfile je virtualizovaný, zatímco type ne.

Zkontrolujte, že jste přihlášeni buď na účet standardního uživatele nebo jako správce v Režimu schválení správce; následující příklady nebudou fungovat v případě vypnutého UAC nebo při přihlášení na vestavěný účet Administrator. Otevřete okno příkazového řádku, příkazem cd c:\pokusy se přepněte do složky C:\pokusy a poté spusťte následující dva příkazy: createfile c:\windows\testfile.txt show c:\windows\testfile.txt

Do okna příkazového řádku by měl být vypsán řetězec Hello, World!, který potvrzuje úspěšný průběh obou programů. Nyní zkuste toto: type c:\windows\testfile.txt

Jak již víte, Vista ví, že type není legacy aplikace, a proto ji nevirtualizuje. Příkaz type proto neodpoví výpisem Hello, World!, ale lehce mrzutým hlášením „Systém nemůže nalézt uvedený soubor“. Proč příkaz type selhal? To je velmi jednoduché: protože jsme mu řekli, aby ve složce Windows našel soubor testfile.txt, a ten se tam nenachází! Nevěřte mi tak lehkomyslně… podívejme se do složky C:\Windows a schválně, co tam najdeme. Než to však uděláme, budeme muset zviditelnit některé skryté složky, abychom dokázali odhalit skutečné umístění souboru testfile.txt, proto nyní musíte – pokud jste to ještě neudělali – přikázat Vistě zobrazit skryté soubory a složky a dále zobrazovat přípony souborů. Neumíte-li se ještě rychle orientovat v rozhraní Visty, uvádím stručný návod: 1. Klepněte na Start  Počítač. 2. V levém horním rohu složky Počítač najdete pravoúhlé tlačítko s ikonou „Uspořádat“. Klepněte na ni a tak otevřete nabídku. 3. V nabídce klepněte na Možnosti složky a Hledání. 4. Objeví se stránka vlastností Možnosti složky; přepněte se na stránku Zobrazení. 5. V rámečku Upřesnit nastavení najděte položku „Skryté soubory a složky“ a zapněte její přepínač „Zobrazovat skryté soubory a složky“. 6. Nad položkou „Skryté soubory a složky“ vypněte políčko s popiskem „Skrýt příponu souborů známých typů“. 7. Tlačítkem OK zavřete dialog Možnosti složky. 8. V okně průzkumníka otevřete disk C:. 9. Přejděte do složky C:\Windows.

140

Kapitola 3 – Nápověda pro virtualizaci souborů a registru

POZNÁMKA:

Jsou chvíle, kdy z celého srdce nenávidím GUI. Proč není možné prostě v příkazovém řádku napsat folderview hidden=yes nebo něco podobného, stisknout Enter a být hotov?. Nebo ještě lépe, proč nemůžeme zobrazit skryté soubory prostřednictvím zásady skupiny?

10. Prozkoumejte obsah této složky a zjistíte, že se v ní žádný soubor testfile.txt nenachází, takže příkaz type měl pravdu. Ale kde tedy je? 1. Zůstaňte v průzkumníkovi a najděte ve složce C:\Users složku, jejíž název odpovídá vašemu uživatelskému jménu. 2. Tuto složku otevřete. Uvnitř ní najdete složku AppData. Otevřete ji. 3. Dále otevřete složku Local, ve které uvidíte složku VirtualStore. A v této složce bude složka s názvem Windows …ve které je náš soubor testfile.txt. Pořád tomu nevěříte? Upravte obsah souboru testfile.txt v Poznámkovém bloku a nahraďte v ní výchozí Hello, World! Jiným textem. Soubor uložte a zavřete a poté znovu v okně příkazového řádku spusťte příkaz show c:\windows\testfile.txt. Uvidíte ten text, který jste před chvílí vložili do souboru testfile.txt.

Úvahy nad virtualizací souborů a registru Když jsme si ověřili, že se pod pokličkou Windows skutečně děje něco zajímavého, pojďme se na celou věc podívat blíže. Zatím víte, že virtualizace souborů a registru funguje tak, že odhadne příliš velké stáří některých aplikací a poté, jakmile Vista rozhodne, že taková aplikace má být „virtualizována“, začne Vista špehovat její pokusy o čtení a zápis, aby rozpoznala pokusy o zápis uživatelských dat do chráněných systémových složek a větví registru. Když Vista takový pokus opravdu zachytí, tiše přesměruje čtení i zápis do jiné složky v profilu uživatele. Tento popis je sice dostatečný, ale hodně obecný. Zkusme nyní klást určité konkrétnější otázky: ■

Kam přesně ukládá služba Řízení uživatelských účtů virtualizovaná data?

■

Vista nešpehuje každou aplikaci; jak ví, který program má být virtualizován a který ne? A co se stane, když se o zápis do chráněné oblasti pokusí aplikace psaná pro operační systém Vista?

■

Které složky a větve (klíče) registru patří pod ochranu služby virtualizace souborů a registru? Dá se do tohoto seznamu přidat nová složka či klíč?

■

Dá se virtualizace souborů a registru nějak sledovat?

■

Můžete službu virtualizace souborů a registru plně zastavit?

Po obecném úvodu se můžeme pustit do hledání odpovědí na tyto otázky, a během následující cesty vám samozřejmě předvedu ještě další ukázky toho, jak virtualizace souborů a registru funguje.

Které oblasti jsou chráněny a kde jsou virtualizovány

141

Které oblasti jsou chráněny a kde jsou virtualizovány Stále tu píšu pojem „virtualizace souborů a registru“ dohromady, jako by šlo o jednou uniformní operaci, ale ve skutečnosti se jedné o dvě poněkud odlišné komponenty. Virtualizace souborů je jednodušší, a proto začneme zkoumat nejprve ji.

Jak virtualizace zachází se soubory Virtualizace souborů chrání na 32bitové verzi Visty pouze dvě složky, na 64bitové verzi to jsou složky tři: ■

\Windows a podřízené složky

■

\Program Files a podřízené složky

■

\Program Files (x86) a podřízené složky

Jak víte, složka „Program Files (x86)“ se vyskytuje jen na 64bitové verzi Visty. (Zdůrazňuji, že těch 64 bitů se týká systému, nikoli procesoru: na počítači s 64bitovým procesorem spustíte libovolné provedení 32bitové Visty, a systém se tam bude cítit jako ryba ve vodě. Nebude tam ovšem složka „Program Files (x86)“.) Všimněte si, že seznam složek, které chrání virtualizace souborů, odpovídá téměř přesně seznamu „bezpečných umístění“, na které se služba Řízení uživatelských účtů odkazuje v zásadě skupiny „Řízení uživatelských účtů: Zvýšit oprávnění pouze u aplikací UIAccess, které jsou nainstalovány v zabezpečených umístěních“, shoda však není úplná; z určitého důvodu považuje tato zásada skupiny za bezpečnou jen složku \Windows\System32, zatímco virtualizace souborů chrání celou složku \Windows.

Zápisy souborů pod dohledem virtualizace Pokaždé, když se virtualizovaná aplikace pokusí o zápis do jedné z uvedených dvou nebo tří složek, přesměruje virtualizace souborů tyto zápisy do oblasti v profilu uživatele, neboli do složky \Users\jméno uživatele\AppData\Local\VirtualStore. Pokud tedy budu k systému přihlášen na svůj účet „Marek“, skončí mé přesměrované soubory někde uvnitř složky \Users\Marek\ AppData\Local\VirtualStore. Uvnitř virtuálního úložiště vytvoří služba virtualizace souborů podřízené složky, jejichž názvy odpovídají názvům chráněných složek, do kterých legacy aplikace zkoušejí zapisovat (Windows, Program Files apod.). Jestliže se nějaká legacy aplikace pokusí zapsat soubor appsettings.ini do složky \Windows\System32, skončí tento soubor ve skutečnosti ve složce \Users\Mark\AppData\Local\ VirtualStore\Windows\Settings\appsettings. ini; zkontrolujte to vůči příkladu z předchozí části kapitoly a uvidíte, že Vista se tam chovala podle očekávání. POZNÁMKA:

Samozřejmě platí, že pokud má token virtualizované aplikace z nějakého důvodu právo zapisovat do chráněné složky, poté do zápisu virtualizace souborů nijak nezasahuje a povolí aplikaci do chráněné složky soubor zapsat.

142

Kapitola 3 – Nápověda pro virtualizaci souborů a registru

Čtení souborů pod dohledem virtualizace Pokaždé, když se virtualizovaná aplikace pokusí načíst soubor umístěný v jedné z chráněných složek, Vista předpokládá, že se stejná aplikace pokusila do této složky daný soubor zapsat a byla přesměrována. Z tohoto důvodu Vista na každý pokus legacy aplikace o načtení souboru reaguje tak, že se nejdříve podívá do složek VirtualStore a teprve poté kontroluje skutečná umístění. Pokud se například uživatelka Marie pokusí spustit legacy aplikace, která požádá Vistu o otevření souboru \windows\system32\appsettings.ini, bude Vista nejprve hledat soubor \Users\Marie\AppData\Local\ VirtualStore\Windows\System32\appsettings.ini a pokud tento existuje, otevře ho a vrátí aplikaci. Jestliže soubor není nalezen, Vista bude hledat soubor \Windows\System32\appsettings.ini a v případě jeho existence bude aplikaci tento soubor vrácen. Tato pravidla Visty pro vyhledávání souborů znamenají, že operační systém nepotřebuje žádnou „paměť“, ve které by měl uložen seznam souborů uložených ve VirtualStore. Jeho pravidlo „jak zapisovat soubory“ prostě říká: „pokud jde o požadavek virtualizované aplikace a cílová složka je chráněna, zapiš soubor do VirtualStore“. Pravidlo „jak číst soubory“ říká: „pokud jde o požadavek virtualizované aplikace a složka souboru je chráněna, podívej se nejdříve do VirtualStore a pokud tam soubor není, prohledej chráněnou složku“. POZNÁMKA:

Můžete změnit seznam chráněných složek a přidat ke dvěma (třem) výchozím další složky? Ne, bohužel to není možné. Microsoft považuje virtualizaci souborů a registru za krátkodobý můstek, který mohou lidé využívat pro dočasné provozování starých aplikací, dokud si nepořídí jejich aktualizované verze, a proto nehodlá nijak povzbuzovat uživatele k prohlubování jejich závislosti na ní. Kdyby bylo možné seznam složek upravit, docházelo by k tomu.

Jak virtualizace zachází s registrem Vista virtualizuje také systémový registr, ale jen klíč HKEY_LOCAL_MACHINE\SOFTWARE. Základní funkčnost virtualizace je stejná: ■

Pokud se starší aplikace bez příslušného oprávnění přístupu k registru pokusí zapsat údaj do klíče HKEY_LOCAL_MACHINE\SOFTWARE, zapíše virtualizace registru data do alternativního umístění a oznámí aplikaci, že zápis proběhnul úspěšně.

■

Jestliže se starší aplikace pokusí načíst libovolný údaj v klíči HKEY_LOCAL_MACHINE\SOFTWARE, Vista nejprve hledá požadovaný údaj v alternativním umístění registru. Když tam data najde, načte je a vrátí aplikaci. V případě, kdy se data nenachází v alternativním umístění, prohledává Vista původní klíč a jestliže v něm data najde, vrátí je aplikaci.

Virtualizace registru se však v několika faktorech liší od virtualizace souborů. Za prvé, alternativním umístěním samozřejmě není složka v profilu uživatele, ale nový klíč HKEY_CURRENT_USER\ Software\ Classes\VirtualStore\MACHINE\SOFTWARE. Když se tedy aplikace pokusí vytvořit nový klíč HKEY_LOCAL_MACHINE\SOFTWARE\Mynewkey, bude tento ve skutečnosti vytvořen jako HKEY_ CURRENT_USER\Software\Classes\VirtualStore\MACHINE\SOFTWARE\Mynewkey.

Které oblasti jsou chráněny a kde jsou virtualizovány

143

Můžete si to vyzkoušet na mé další podomácky vytvořené starší aplikaci, kterou si stáhněte z adresy http://www.minasi.com/vista/regwritekey.exe. Uložte soubor stejným způsobem jako předtím do složky c:\pokusy. Poté v okně příkazového řádku přejděte do této složky, zapište regwritekey a stiskněte Enter. Zkušební aplikace se pokusí vytvořit nový klíč systémového registru HKEY_LOCAL_ MACHINE\SOFTWARE\Testkey. Zda se jí to podařilo, zjistíte v Editoru registru, kde prohledejte klíč HKEY_LOCAL_MACHINE\SOFTWARE; klíč Testkey tam nebude. Pak se podívejte do složky HKEY_ CURRENT_USER\Software\Classes\VirtualStore\MACHINE\SOFTWARE a – vida! – klíč Testkey tam bude, jak dosvědčuje i obrázek 3.1. OBRÁZEK 3.1: Virtualizovaný klíč Testkey

Obdobně jako u virtualizace souborů není možné rozšířit seznam chráněných klíčů, ale můžete upřesnit seznam klíčů uvnitř chráněného umístění, které chráněny jsou a které ne. Pro libovolný klíč uvnitř větve HKLM\Software se dá stanovit, zda ho Vista bude či nebude virtualizovat. Tyto změny se provádí v aplikaci reg.exe, kterou možná znáte z předchozích verzí Windows, ve Vistě do ní přibyl nový parametr „flags“. Pokud Vista nemá určitý klíč virtualizovat, přikážete jí to následujícím příkazem: reg umístěníklíče dont_virtualize [/s]

Nepovinný přepínač /s rozšiřuje účinek příkazu i na všechny podřízené klíče. Jestliže má být tedy z virtualizace vyloučen klíč HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft a všechny klíče uvnitř něj, zapište v okně příkazového řádku s povýšenými právy správce příkaz reg hkey_local_machine\software\microsoft\ dont_virtualize /s

Celý příkaz musí být na jednom řádku, i když v této knize je zalomen. Co je tu důležité, je význam této volby: „nevirtualizovat“ neznamená „nechat staré aplikace bez práv správce měnit klíč dle libosti“, ale „ignorovat pokusy starších aplikací o změnu daného klíče“.

144

Kapitola 3 – Nápověda pro virtualizaci souborů a registru

Co přesně znamená pojem „starší“ (legacy) aplikace? Prozatím jsme viděli, že Vista virtualizuje v případě, kdy: (1) se aplikace pokusí o zápis do chráněné oblasti, (2) aplikaci schází přístupové oprávnění NTFS nebo registru k zápisu a (3) jedná se o legacy aplikaci. První dvě podmínky jsme probrali, nyní se podíváme na třetí podmínku. Vista bude virtualizovat každý požadavek aplikace na čtení nebo zápis, s výjimkou případů, kdy aplikace: ■

Je spuštěna s tokenem plného přístupu správce. Vista předpokládá, že pokud jste přihlášení jako správce a máte spuštěn nějaký druh starší aplikace, musíte si být vědomi toho, co děláte. V takovém případě Vista povolí aplikaci pokus o zápis do souboru nebo klíče registru. Jestliže uživatel-správce nevlastní potřebné oprávnění k zápisu do souboru nebo klíče registru, operace selže.

■

Je spuštěna s tokenem, který má oprávnění zápisu do souboru nebo klíče registru. Toto jsme již probírali.

■

Běží v režimu jádra. Ve světě Windows programy běží buď v „režimu uživatele“ nebo „režimu jádra“. Drtivá většina programů, které stiskněte Enter si do Windows nainstalovali, běží v režimu uživatele: textové procesory, webové prohlížeče, e-mailové klienti, hry, tabulkové procesory, databáze atd. … to vše běží v režimu uživatele. Půvab tohoto režimu spočívá v tom,, že každá taková aplikace je umístěna ve svém vlastním paměťovém prostoru, mimo který nemůže do paměti zapisovat. Je tedy nemožné, aby například chyba v Poznámkovém bloku způsobila, že Poznámkový blok přepíše část paměti vyhrazené například pro Kalkulačku; pokud by se o to Poznámkový blok pokusil, vyvolalo by to chybu, po které by Windows tuto aplikaci ukončily a zeptaly by se aktuálního uživatele, zda si přeje hlášení o této chybě odeslat do Microsoftu. Kód běžící v režimu jádra má oproti tomu právo přístupu do libovolné části paměti, takže chybně napsaný program běžící v tomto režimu může natropit spoustu škod. Jako příklad programů běžících v režimu jádra, se kterými se potkáte nejčastěji, uvádím základní součásti operačního systému, ovladače zařízení a velkou část malwaru. (Jednou z nejsnazších cest, jak vyvolat nestabilitu systému, je instalace vadného ovladače zařízení. Anebo nějakého škodlivého kódu!) Z toho vyplývá, že pravděpodobně jediným druhem kódu běžícího na úrovni jádra, na který si budete muset dávat pozor, aby vám neproniknul do systému, je ovladač zařízení. Nevidím ovšem jediný důvod k tomu, aby se ovladač zařízení stažil instalovat se do jednoho z těchto chráněných umístění. Virtualizace bývá u ovladačů zařízení stejně zcela nepotřebná, protože tento kód běží obvykle s tokenem účtu LocalSystem, který si v systému může dělat co chce a přitom nespadá pod Režim schválení správce. (Pokud by se musel tímto režimem řídit, čekaly by vás tisíce dialogů Consent UI jen během zavádění operačního systému při spouštění počítače!)

■

Má manifest s parametrem level=. Pokud má aplikace manifest, považuje to Vista za „generální pardon“ a virtualizaci neprovádí. (Zjistil jsem však, že od verze RC1 má přítomnost externího manifestu z hlediska rozhodování o provedení virtualizace jiný dopad, než existence vestavěného manifestu přímo v aplikaci. Toto může být v době, kdy čtete tuto knihu, již opraveno.)

Ukázka virtualizace souborů a registru u standardních uživatelů a správců

145

■

Token uživatele je získán zosobněním. Pojem „zosobnění“ znamená ve světě Windows v podstatě to, že token aplikace pochází od uživatele přihlášeného po síti. Jinými slovy, aby mohla aplikace využívat výhod virtualizace, musí být uživatel, který tuto aplikace spustil, přihlášen místěn, nikoli po síti.

■

Je 64bitová. Virtualizace souborů a registru je míněna víceméně jako dočasná záplata. Microsoft počítá s tím, že libovolná 64bitová aplikace je natolik moderní, že si její vývojář uvědomuje, co standardní uživatelé mohou a co nemohou provádět, a proto virtualizaci nepotřebuje.

■

Chce změnit klíč registru, který je označen příznakem „dont_virtualize“. Toto jsme již probírali.

Aplikace nesplňující ani jedno z těchto kritérií bude moci využívat výhod virtualizace souborů a registru.

Ukázka virtualizace souborů a registru u standardních uživatelů a správců Z teoretického hlediska jsme virtualizaci probrali již dostatečně podrobně, proto si myslím, že následující praktickou demonstraci její činnosti uvítáte. V této ukázce vás nechám vytvořit soubor testfile.txt jak ve složce Program Files, tak ve složce VirtualStore. Oba soubory se od sebe budou lišit svým obsahem, proto je bude možné snadno rozlišit. Poté požádáme program show.exe, aby za různých podmínek (na účet uživatele, na účet správce, s manifestem, bez manifestu apod.) zobrazoval obsah souboru c:\program files\testfile.txt. Postupujte podle následujícího návodu: 1. Přihlaste se k systému Vista jako správce a zkontrolujte si, že jde o účet s rozděleným tokenem, čili že pracujete v Režimu schválení správce. (Nelze tedy použít vestavěný účet Administrator.) 2. Otevřete příkazem Start  Všechny programy  Příslušenství  Příkazový řádek „obyčejné“ (bez zvýšených práv) okno příkazového řádku. 3. Jestliže na počítači ještě nemáte vytvořenu složku c:\pokusy, vytvořte ji příkazem md c:\ pokusy. 4. Příkazem cd pokusy nastavte tuto složku jako pracovní. 5. Zkopírujte program show.exe do složky c:\pokusy, pokud ho tam ještě nemáte. Jestliže jste si ho ještě nestáhli, najdete ho na adrese http://www.minasi.com/vista/show.exe. 6. Nastavte možnosti složky tak, abyste viděli v Průzkumníkovi i skryté soubory a aby operační systém zobrazoval přípony souborů. Dále v dialogu Možnosti složky zapněte políčko „Zobrazovat úplnou cestu v záhlaví (pouze klasické složky)“. 7. Otevřete okno průzkumníka a přejděte do složky c:\users\vašejméno\AppData\ Local\VirtualStore. Složka AppData je skrytá, proto bylo nutné zapnout zobrazování skrytých souborů a složek.

146

Kapitola 3 – Nápověda pro virtualizaci souborů a registru

8. Ve složce VirtualStore vytvořte novou složku „Program Files“, název zapište přesně dle tohoto textu, včetně mezery mezi slovy. 9. Do složky VirtualStore\Program Files uložte soubor testfile.txt, který vytvoříte v Poznámkovém bloku. Do souboru zapište text „Pozdrav z virtuálního úložiště“. 10. Otevřete okno příkazového řádku s právy správce. 11. Do okna zapište tyto řádky: cd \pokusy copy con "c:\program files\testfile.txt" Pozdrav ze složky Program Files!

12. Po stisku Enteru na konci řádku „Pozdrav ze složky Program Files!“ stiskněte klávesu F6. Příkazový řádek odpoví hlášením 1 file(s) copied. 13. V okně příkazového řádku s právy správce zapište show “c:\program files\testfile.txt” a stiskněte Enter. Objeví se hlášení „Pozdrav ze složky Program Files!“ To znamená, že požadavek na čtení souboru c:\program files\testfile.txt nebyl virtualizován, protože program byl spuštěn s vaším tokenem správce. 14. Nyní se přesuňte do okna příkazového řádku s tokenem standardního uživatele a zde spusťte stejný příkaz show. Tentokrát uvidíte hlášení „Pozdrav z virtuálního úložiště“, protože program show.exe byl spuštěn s tokenem standardního uživatele. 15. Dále se podívejme, jaký vliv na virtualizaci bude mít manifest. Nemáte-li ještě stažen můj ukázkový kousek, udělejte to (http://www.minasi.com/vista/simple.exe.manifest). Je to krátký textový soubor, uložíte ho do složky c:\pokusy. Po uložení ho otevřete v Poznámkovém bloku a změníte řádek level="requireAdministrator"

na level="asInvoker"

Dávejte přitom bedlivý pozor na to, abyste dodrželi malá a velká písmena, uvedená zde v textu, čili ve středu „asInvoker“ je nutné zapsat velké „I“. Tato úprava je nutná z toho důvodu, že manifest neotevře dialog Consent UI, ale je to manifest psaný s ohledem na systém Vista a měl by tudíž přimět Vistu, aby pro jemu přidružený program nepoužila virtualizaci souborů a registru. 16. Přejmenujte simple.exe.manifest na show.exe.manifest. Tato akce je dána tím, že název externího manifestu musí odpovídat názvu asociovaného programu, ke kterému je na konec přidána přípona „.manifest“. 17. Vraťte se do okna příkazového řádku s tokenem standardního uživatele a znovu zde spusťte příkaz show “c:\program files\testfile.txt”. Tentokrát uvidíte hlášení „Pozdrav ze složky Program Files!“, protože přítomnost manifestu je pro Vistu signálem k tomu, aby nepoužila virtualizaci.

Sledování virtualizace VAROVÁNÍ:

147

Jestliže v 17. bodu uvidíte pozdrav ze složky VirtualStore, nepanikařte; zdá se, že tady to trochu haprovalo ještě ve verzi RC2. Manifesty vložené přímo do souboru EXE fungují vždy, proto se v případě potřeby zaměřte na tento typ manifestu. Můžete také vyzkoušet to, co jsme dělali v předchozí kapitole, kdy jsme vytvořili novou složku a do ní zkopírovali soubor EXE a jeho manifest. Při společném vložení obou souborů do složky si Vista zřejmě manifestu „všimne“, zatímco při dodatečném vložení manifestu její reflexy nefungují.

Jak je vidět, pokud určitou aplikaci nechcete ve Vistě virtualizovat, stačí pro ni vytvořit manifest. Ještě lepší je vložit tento manifest přímo do souboru EXE a pak již můžete aplikaci přesouvat ve složkách jak chcete – k její virtualizaci docházet nebude.

Sledování virtualizace Jak jsem již několikrát uvedl, Microsoft se na virtualizaci souborů a registru dívá jen jako na dočasnou záplatu, kterou tento systém z jistých přechodových důvodů bohužel potřebuje, a nikdo by ji proto neměl považovat za dlouhodobější řešení. Z tohoto důvodu by bylo vhodné, kdybychom si mohli v praxi po určité době ověřit, jak moc důležitá tato virtualizace pro síť i uživatele je; jak často je používána. Vista naštěstí zapisuje do protokolu některé údaje o virtualizaci, i když jich není tolik, jak by si asi mnozí přáli. První možností, jak si zpětně ověřit důležitost virtualizace souborů a registru, je prostý průzkum složky \Users\jméno uživatele\AppData\Local\VirtualStore a klíče systémového registru HKEY_CURRENT_USER\Software\Classes\VirtualStore\MACHINE\ SOFTWARE. Vzhledem k tomu, že vývojáři ukládají informace v registru do klíčů, v jejichž názvech jsou uváděny názvy aplikace a v klíči nadřízeném název vývojářské firmy, najdete-li v registru složku „JiriHorak\mujstaryprogram“, je to doklad toho, že někdo z vašich uživatelů používá aplikaci „mujstaryprogram“, kterou vydala firma „JiriHorak“. V takovém případě lze tuto firmu kontaktovat a zjistit, zda nemají aktualizovanou verzi aplikace… pokud ji neseženete, počítejte s tím, že přibližně za pět let – až si nainstalujete další verzi Windows – nebude tato aplikace použitelná. Kromě virtuálních složek a klíče registru můžete aplikace využívající virtualizaci souborů a registru odhalit i v systémovém protokolu. V prohlížeči událostí najdete jeden protokol, vyhrazený právě pro virtualizaci souborů a registru: 1. Spusťte Prohlížeč událostí. 2. V levém panelu otevřete ve větvi „Prohlížeč událostí: (Místní)“ složku „Protokoly aplikací a služeb“. 3. Uvnitř této složky rozbalte složku Microsoft. 4. Uvnitř složky Microsoft rozbalte složku Windows. 5. A na závěr rozbalte složku UAC-FileVirtualization. V této poslední složce najdete jednu událost – obvykle s ID 4000 – pro každé použití virtualizace souborů. Obdobný protokol pro virtualizaci registru neexistuje, ale přesto se dají z protokolu zjistit některé užitečné údaje alespoň pro virtualizaci souborů. Ukázku události vidíte na obrázku 3.2.

148

Kapitola 3 – Nápověda pro virtualizaci souborů a registru

Na první stránce moc informací nenajdete, mnohem zajímavější data jsou umístěna na stránce Podrobnosti, kterou zachycuje obrázek 3.3. OBRÁZEK 3.2: Typická událost virtualizace souborů

OBRÁZEK 3.3: Podrobnosti o události virtualizace souborů

Aha! Tady vidíte nejen název souboru, který musí být virtualizován, ale také to, která aplikace tuto virtualizaci požadovala. Když v duchu přičtete tyto užitečné události k novým možnostem generování akcí na základě výskytu určité události, dokážeme si jistě představit, že nebude příliš těžké napsat nástroj, který databázi „problémových“ aplikací sestaví automaticky.

Řízení virtualizace

149

Možné potíže s virtualizací Virtualizace souborů a registru sice představuje elegantní online řešení některých problémů se staršími aplikacemi, může ale vyvolat zcela nové druhy potíží. Dejme tomu, že ve firmě provozujete nějakou hodně starou aplikaci, které budeme pracovně říkat „Staroch“. Staroch je tak starý nebo tak špatně napsaný, že si neukládá uživatelská nastavení do registru, ale do textového souboru staroch.ini, a tento soubor umisťuje do složky C:\Program Files\OldSoft\staroch.ini. Z toho vyplývá, že každý uživatel pracující s aplikací Staroch, bude mít na stejném místě ve své složce Program Files soubor staroch.ini. S nástupem virtualizace souborů a registru se ve Vistě toto umístění pochopitelně změní. Namísto zápisu do složky C:\Program Files\OldSoft skončí inicializační soubor Starocha ve složce C:\Users\jméno uživatele\AppData\Local\ VirtualStore\Program Files\OldSoft. Tady ale přece nemůže dojít k potížím? Zdánlivě ano, ale Staroch pravděpodobně nespolupracuje s žádným nástrojem pro centrální správu (například se zásadami skupiny), proto ve firmách využívajících tuto aplikaci bude pravděpodobně toto centrální řízení prováděno formou pravidelné distribuce souboru staroch.ini, obsahujícího standardní firemní nastavení pro všechny pracovní stanice. Distribuci bude zajišťovat přihlašovací skript, SMS nebo jiný podobný nástroj. Všichni, kdo budou s aplikací Staroch pracovat na Windows XP, musí mít soubor staroch.ini umístěn ve stejném místě uvnitř složky Program Files. Pro člověka starajícího se o centrální distribuci INI souboru se s nástupem Visty celá úloha komplikuje, protože bude muset napsat příslušný kód tak, aby tento dokázal ■

Detekovat operační systém na pracovní stanici, protože na všech starších operačních systémech musí být soubor staroch.ini zapsán do složky Program Files;

■

Detekovat jméno uživatele, by bylo možné ve skriptu složit z různých údajů cestu do příslušné složky uživatele ve VirtualStore; a také

■

Hledat na Vistě soubory staroch.ini v obou místech, protože i na Vistě může být soubor staroch.ini zapsán ve složce Program Files, pokud se některý uživatel přihlašuje jako Administrator nebo pokud je virtualizace souborů a registru či UAC úplně vypnuta.

Nic z toho není v praxi nepřekonatelnou překážkou, ale hlava z toho někdy rozbolet může.

Řízení virtualizace Jestliže je třeba z nějakého důvodu virtualizaci souborů a registru vypnout, připomínám, že v předchozí kapitole jsme se potkali se dvěmi zásadami skupiny, které lze zakázat: ■

„Řízení uživatelských účtů: spustit všechny správce v režimu schválení správce“ vypne v případě svého zákazu všechny součásti UAC,včetně virtualizace souborů a registru.

■

„Řízení uživatelských účtů: Virtualizovat chyby zápisu do souboru a registru do umístění jednotlivých uživatelů“ vypne v případě svého zákazu jen virtualizaci souborů a registru.

Změny obou zásad skupiny vyžadují restart počítače, aby změna začala platit.

150

Kapitola 3 – Nápověda pro virtualizaci souborů a registru

Budoucnost virtualizace Podle prohlášení Microsoftu virtualizace souborů a registru žádnou budoucnost nemá. Microsoft ji považuje za krátkodobou záplatu, která nebude součástí nástupce Vista. Jak jsem se již zmínil, mezi vydáním XP a Visty uplynulo pět let, a osobně nebudu překvapen, když se nástupce Visty objeví až po dalších pěti letech. To znamená, že virtualizace souborů a registru je v podstatě výstraha, upozorňující na to, že máme jen asi pět let na podrobnou revizi kompatibility aplikací, protože Windows Vienna – aktuální kódový název pro nástupce Visty a Serveru 2007 – tento starý kód již asi vůbec nedovolí provozovat, a pokud ano, jen v případě výrazného osekání bezpečnostních prvků Windows. Představa, že budoucí Windows nás donutí zbavit se veškerého softwaru, který po celá léta používáme bez obtíží, je sice frustrující, ale nakonec – věřte nevěřte – pochopíte, že je to tak nejlepší. Windows velmi naléhavě potřebují vyšší hladinu bezpečnosti, a ta bude vyžadovat výrazné strukturální změny, které nevyhnutelně vedou k tomu, že některé starší aplikace již nebudou fungovat. Kromě toho platí, že dnes zakazované aktivity jsou těmi aktivitami, od kterých Microsoft programátory odrazoval již od dubna 1992; pokud jsou tato pravidla vynucována po uplynutí 14 let, nelze to považovat za omezující. Přišel prostě čas, kdy stařičký Ford T už není dostatečně bezpečný, aby mohl jezdit po nových dálnicích… Co dělat v případě, kdy je nezbytně nutné nějakou starší aplikaci provozovat i nadále? Použijte virtuální počítač. VMWare uvolnilo v době psaní této knihy zdarma svůj VMWare Server, Microsoft uvolnil zdarma jak Virtual Server, tak Virtual PC. Jestliže s aplikacemi tohoto typu nemáte zkušenosti, pokusím se je stručně představit. Správci virtuálních počítačů jsou programy, ve kterých lze vytvářet imaginární počítače, běžící uvnitř operačního systému a napodobující téměř dokonale celý počítač včetně hardwaru. Do těchto virtuálních počítačů se poté nainstaluje vybraný operační systém, který následně běží uvnitř virtuálního počítače v chráněném prostředí a ve kterém lze pak provozovat libovolnou aplikaci. Virtuální počítače mají i své virtuální síťové karty, takže mohou komunikovat s jinými počítači po síti. Technologie virtuálních PC se velmi hodí například pro testování nebo provozování starších aplikací. Virtualizace souborů a registru je nesmírně užitečnou součástí služby Řízení uživatelských účtů a dle mého názoru zjednoduší provozování starších aplikací. POZNÁMKA:

Rád bych ještě podotknul, že Vista není prvním systémem Windows, ve kterém se potkáváme s virtualizací souborů a registru. Volitelně tento nástroj nabízel již Application Compatibility Toolkit od počátků svého vydání, pokud si pamatuji dobře. Dle mých zkušeností však její implementace v prostředí ACT byla méně srozumitelná a je mnohem lepší, když je přímo součástí operačního systému.

Souhrn

151

Souhrn Zkuste na Vistu nainstalovat své starší programy a poté z obsahu protokolu UAC-FileVirtualization a obsahu své složky VirtualStore zjistíte, co tento software potřebuje ke své práci. Sami poznáte, že virtualizace souborů a registru je užitečná jak coby nástroj pro zajištění kompatibility aplikací, tak i coby prostředek pro inventarizaci starších aplikací a rozpoznání „potížistů“!

152

Kapitola 3 – Nápověda pro virtualizaci souborů a registru

4 Kontrola integrity windows Nástup a rozvoj Internetu znamenal velký poplach v odděleních Microsoftu zaměřených na bezpečnost, a je vcelku jasné proč. Windows XP jsou dostatečně stabilním a bezpečným operačním systémem… ale jen pokud pravidelně instalujete jeho záplaty, nepovolíte průnik žádných škodlivých programů – a když už se to stane, nesmí mít takový malware oprávnění na úrovni správce. Jenže to samozřejmě píšu o tom, k čemu v praxi dochází téměř automaticky, protože chceme-li ve Windows XP a starších verzích něco dělat či instalovat, potřebujeme k tomu účet správce pro sebe i pro aplikace. Jak jste se v této knize doposud dozvěděli, Microsoft zkouší svému systému naordinovat řádnou léčebnou medicínu a to v takovém rozsahu, který ovlivňuje i způsob práce uživatelů, abychom se dokázali vyhnout různým virům, červům, botům a trojským koním. Jestliže si myslíte, že tou revoluční změnou v chování Visty bylo Řízení uživatelských účtů (User Account Control, UAC), připravte se na ještě větší vichřici, který přináší řízení integrity Windows (Windows Integrity Control, WIC). V rámci WIC uvádí Microsoft na scénu novou součást infrastruktury Windows, která je stejně důležitá a všudypřítomná jako přístupová oprávnění NTFS, a která se již v minulosti objevila v jiných operačních systémech – ovšem to byly operační systémy armádní! POZNÁMKA:

Během vývoje Visty bylo původně řízení integrity Windows označováno pojmem „mandatory integrity control“ a poté „Windows Integrity Mechanism“. Na konci září 2006 již však platil tento finální název .

Úkolem řízení integrity Windows je definice několika různých úrovní „důvěryhodnosti“, kterou ovšem Microsoft neoznačuje jako důvěryhodnosti, ale jako „integritu“. Procesy se stejnou úrovní integrity spolu komunikují úplně stejně, jako v předchozích verzích Windows. Řízení integrity Windows však mění zažitý způsob fungování věcí v těch případech, kdy se proces s nižší úrovní integrity (integrity level, IL) pokouší číst, zapisovat nebo spustit objekt (například soubor) s vyšší úrovní integrity. V tomto případě vstoupí do hry WIC a může – může, chování WIC se dá změnit, když víte, jak se to dá provést – tento pokus zablokovat. Takto to vypadá jako drobná změna, ale jak v této kapitole poznáte, má to několik obrovských důsledků na činnost celého systému.

154

Kapitola 4 – Kontrola integrity windows

Přehled řízení integrity Windows Primárním cílem Microsoftu při návrhu WIC bylo úplné oddělení Internetu a všech věcí z Internetu stažených do samostatného „vesmíru“ neboli „úrovně integrity“ (terminologie WIC), odděleného od uživatelských dat a systémových souborů. Řízení integrity Windows definuje celkem šest úrovní integrity Windows, které budeme později rozebírat. Soubory stažené z Internetu patří do druhé nejnižší, tzv. „nízké“ (low) úrovně. Standardní uživatelé jsou oproti tomu umístěni do vyšší, „střední“ (medium) úrovně integrity. Díky tomu nemohou žádné soubory ani jiné věci stažené z Internetu začít mazat lokální soubory ani měnit nastavení systému bez toho, že by – přinejlepším – byly systémem prostě „odstřeleny“ nebo – přinejhorším – aktivovaly službu Řízení uživatelských účtů, která by se vás zeptala, zda skutečně chcete, aby ta právě stažená super hra začala odesílat vaše uložená hesla na e-mailové účty někde v Číně. WIC je jednou z metod, které implementují v systému to, co je ve světě zabezpečení označováno pojmem izolace procesů. Podstata této izolace spočívá v tom, že když už nejsme schopni vytvořit z Internetu bezpečnější prostor, můžeme alespoň lépe sledovat, o co se ty věci, které si odtamtud stáhneme, pokoušejí. Procesy a objekty umístěné v různých úrovních integrity spolu mohou komunikovat, ale tak, aby uživatel mohl omezit jejich práva a sledovat je (pravděpodobnější je však situace, kdy necháte Windows, aby toto sledování prováděly za vás). Předpokládejme například, že na nějaké webové stránce klepnete na hypertextový odkaz, kterým stáhnete a spustíte z Internetu nějaký program. Uvažujme dále o tom, že se bude jednat o nějaký škodlivý kód (malware). Většina malwaru se při své aktivaci stará především o to, aby si dokázala zajistit své spuštění při každém dalším zavedení operačního systému. To znamená, že musí zapsat určitou hodnotu do systémového registru. Protože jde o věc staženou z Internetu, poběží daný malware – jak již víte – v úrovni integrity celého Internetu (tedy v úrovni low). Přibližně 99,9 % systémového registru má však přiřazenu vyšší úroveň integrity. Z toho vyplývá, že když se malware pokusí změnit něco v systémovém registru, aby byl spouštěn spolu se systémem, dojde ke dvěma možným reakcím – buď se zápis vůbec nepodaří, nebo služba Řízení uživatelských účtů vyvolá dialog Consent UI. Která reakce proběhne, to záleží na tom, jak přesně je daný škodlivý kód napsán. Prozatím jsem řízení integrity Windows popisoval jen jako nástroj pro udržení kontroly nad obsahem Internetu, ale to jen první možné využití této komponenty. Až budeme podrobněji probírat způsob činnosti WIC, napadnou vás pravděpodobně další způsoby, jak řízení integrity Windows použít k ochraně systému. Uvádím nyní základní koncepty WIC, které budeme postupně probírat v dalších částech kapitoly: Šest úrovní Řízení integrity Windows definuje šest různých úrovní integrity, popsaných dále ve stejnojmenné části „Šest úrovní integrity Windows“. Úroveň integrity je povinná, nikoli volitelná Úroveň integrity objektu, procesu nebo uživatele připomíná prostě další druh oprávnění, se kterými se na NT potkáváme již od verze 3.1, ale není to klasické oprávnění. Tradiční oprávnění NT jsou po technické stránce označovány pojmem „výběrové řízení přístupu“ (discretionary access controls), protože výběr jejich hodnoty je ponechán na uvážení vlastníka, kterým může být i standardní uživatel. Úrovně integrity však vychází z principu „povinného řízení přístupu“, protože je nenastavuje běžný uživatel, ale operační systém nebo správce (a v některých případech oba).

Srovnání povinného a výběrového řízení POZNÁMKA:

155

Ve světě povinného řízení přístupu, ovládaného částečně operačním systémem (jak je tomu u Visty) se lze často dopracovat k nepříjemné představě souboru, který bude uložen na vašem počítači, vy budete jeho vlastníkem a máte k němu úplná přístupová oprávnění NTFS… ale přesto vám systém nepovolí tento soubor smazat, a to i v případě, kdy jste správce. Taková představa je skutečně logickým důsledkem podobného přístupu, ale Vista nevytváří soubory s tak vysokou úrovní integrity, aby je správci nemohli smazat.

Objekty „důvěřují směrem nahoru, nikoli dolů“ Hlavním úkolem řízení integrity Windows je vystupovat jako ochranná struktura ve všech případech, kdy se proces s nižší úrovní integrity pokouší číst, zapisovat nebo spustit objekt s vyšší úrovní integrity. (Implicitně služba WIC sleduje jen pokusy o zápis, dá se ale nastavit tak, aby hlídala i čtení a spouštění objektů, jak uvidíte později.) Když k tomu dojde, WIC většinou zašle procesu chybu „přístup odepřen“, vývojář aplikace určené pro systém Vista však může této chybě zabránit tak, že nechá aplikaci požádat o povýšení oprávnění daného procesu běžícího v nízké úrovní integrity. Tímto způsobem je možné vyvolat dialog Consent UI a nabídnout uživateli možnost toto povýšení povolit nebo zakázat. Ať tak či tak, objekt s vyšší úrovní integrity – databáze, soubor, složka, klíč registru nebo nějaká jiná věc – je chráněn před procesem s nižší úrovní integrity. Základní směrnice WIC zní: „abys na mne mohl působit, musí být tvoje úroveň integrity vyšší nebo stejně velká jako ta moje“. Úrovně integrity mají přednost před normálními oprávněními Vrátím se nyní k příkladu uvedenému o několik odstavců dříve, kde jsem uváděl, co by se stalo v případě náhodného klepnutí na hypertextový odkaz v Internet Exploreru 7, běžícím na systému Vista. Psal jsem tam, že pokus malwaru o zápis do klíče systémového registru se střední (medium) úrovní integrity by neprošel z důvodu jeho nižší úrovně integrity. Nyní bych rád prozradil něco navíc a zdůraznil to, co při prvním vysvětlení nebylo zřejmé. Když se malware pokusí o zápis do registru, bude jeho pokus zamítnut i v případě, kdy by z nějakého důvodu měl k tomuto klíči registru oprávnění úplného řízení. Řízení integrity Windows tedy „přetrumfne“ klasická přístupová oprávnění NTFS a registru. Kontrola integrity proběhne ještě před kontrolou přístupových oprávnění a v případě záporného výsledku je následná kontrola přístupových oprávnění k NTFS, registru či dalším objektům prostě anulována. Když tedy přístupové oprávnění NTFS říká „jasně, jen do toho!“ a porovnání úrovní integrity skončí hlášením „v žádném případě!“, vyhraje vždy služba WIC.

Srovnání povinného a výběrového řízení Už jsem tu psal, že nápad na zřízení úrovní integrity byl převzat z technologie, která je označovaná jako „povinné řízení přístupu“ (mandatory access control), což je něco podstatně jiného než řízení přístupu založené na volném uvážení uživatele (discretionary access control). Tyto pojmy nevymyslel Microsoft, jedná se o standardní fráze ve světě IT zabezpečení, popisující různé metody ochrany součástí operačních systémů. Zajímá-li vás jejich původ, dovolte mi nastavit na ciferníku stroje času počátek 80. let 20. století. Disco právě umřelo, v Praze byl otevřen komplex „Paláce kultury“, nikdo ještě netušil o existenci Miroslava Sládka nebo Lubomíra Zaorálka, a v USA se prezidentem stal Reagan a zároveň se tam všechny vládní úřady mohly přímo přetrhnout, aby nakoupily co nejvíc počítačů…

156

Kapitola 4 – Kontrola integrity windows

Oranžová kniha Koncem 70. a začátkem 80. let začaly vládní úřady v USA houfně nakupovat počítače. V porovnání se situací na začátku 70. let to byl obrovský nárůst, částečně díky nižším cenám počítačů, částečně díky stále vzrůstající závislosti vlády – v okolním světě to nebylo jiné – na tunách čísel, neustále přežvykovaných a omílaných v různých sestavách a dokumentech. Úřady si proto nakoupily mainframy od firem typu IBM, CDC, Burroughs nebo Univac. Dále se nakupovaly minipočítače (DEC, Data General, Harris). Kupovaly se i samostatné systémy pro zpracování textu od firem Wang a Four-Phase… a samozřejmě v 80. letech se začaly nakupovat i první desktopové počítače od Apple, IBM a dalších výrobců. Vedoucí bezpečnostních oddělení IT brzy začali říkat, že by lidé kupující tyto navzájem hodně lišící se systém měli víc přemýšlet o jejich zabezpečení – ovšem jak určit potřebnou míru zabezpečení a jak si tito lidé mohou ověřit, že jí skutečně dosáhli? Někteří lidé by na otázku „Jak moc mají být počítače zabezpečeny?“ reflexivně odpověděli „jako by tam byly přísně tajné materiály“ nebo „co nejvíc to jde“, ale takový stupeň ochrany by pravděpodobně znamenal jen zbytečně vyhozené peníze. Je jasné, že vojenské a špionážní agentury musí být dobře jištěny, ale většina státních úřadů nepotřebuje nijak zvláštní ochranu. Někdy v té době jsem pracoval jako dodavatel pro Ministerstvo energetiky, kde jsem pomáhal s tvorbou ekonomických modelů pro předpovídání krátkodobých dodávek a cen různých druhů energie. Skupina, ve které jsem byl, pracovala na mainframu IBM. Každý z nás měl vlastní prostor na pevných discích mainframu, ale disky nebyly nijak zabezpečeny a každý mohl otvírat i měnit data ostatních pracovníků. Vedoucí IT se nakonec rozhodli nainstalovat balík ACF/2, který umožňoval chránit vybrané nebo všechny soubory, ale panovala mezi námi obecná shoda ve smyslu „proč ztrácet čas studiem toho, jak se to nastavuje“ a „kdo by tak mohl stát právě o moje soubory?“. Chtěl jsem udělat analýzu na základě veřejně dostupných shromážděných dat, a chtěl jsem také napsat programy, které by z těchto dat vytvářely veřejně dostupné předpovědi. Kód, data i předpovědi byly zaplaceny z kapes daňových poplatníků, takže pokud by teoreticky některý občan požádal, abych mu ta data ukázal, nedokázal jsem přijít na důvod, kterým bych takovou žádost mohl zamítnout. (Samozřejmě se nikdy nenašel někdo, kdo by něco takového chtěl.) Můj odhad však nebyl úplně přesný, protože vložení všech dat, vytvořených a udržovaných několika desítkami lidí, do společného zásobníku, který by mohl libovolný člen týmu změnit nebo smazat, by bylo hodně nebezpečné. Bezohledný člen týmu, který by hledal možnost, jak zdiskreditovat některého kolegu, by mohl změnit data takovým způsobem, že by veškerá práce přišla vniveč a přitom by podezření padlo na nevinného. Důsledek? Bezohledný pracovník by mohl uniknout odplatě a daňoví poplatníci by museli zaplatit náklady na rekonstrukci dat a kódu. Nic podobného se za mé přítomnosti nestalo, ale mohlo by, proto je vhodné data nějakým způsobem zabezpečit. Ale je k tomu nutná ochrana na rovni běžné v Pentagonu? Stálo by to jen spoustu peněz a pro agenturu i daňové poplatníky by byl přínos minimální nebo žádný. Většina z nás si také domů nepořizuje titanové dveře, neprůstřelná skla a dělové věže, protože by to bylo nesmírně drahé zabezpečení. Stejně tak je zbytečné, aby analytici na ministerstvu energetiky museli každý den procházet detekčními rámy. Ve vládě však jsou lidé, kteří skutečně potřebují chránit vrcholně tajná data. Je vcelku přirozené, že různé státní úřady mají různé požadavky na úroveň zabezpečení svého softwaru; tady žádné universální řešení neexistuje.

Srovnání povinného a výběrového řízení

157

Na základě těchto úvah došli někteří lidé v NSA k závěru, že by se značně usnadnila práce vedoucích, kteří mají na starosti testování a nákup počítačového softwaru, pokud by existovala sada předem jasně definovaných standardů, popisujících požadavky na různé úrovně zabezpečení. Šlo by o kolekci sad požadavků, které musí software splnit, má-li být zařazen do seznamu programů vyhovujících té či oné úrovni zabezpečení. Pak by osoba starající se například o National Crime Information Center (NCIC) v FBI nebo osoba starající se o online systém záznamů zasedání Kongresu v systému knihovny THOMAS nemusela začínat pokaždé od čistého stolu a vymýšlet kompletní sadu bezpečnostních požadavků pro určitou operaci. Namísto toho se vedoucí NCIC podívá do seznamu vlastností, vyžadovaných pro jednotlivé úrovně zabezpečení a řekne si: „aha, máme tu celkem sedm úrovní, ty dvě nejvyšší vůbec nepotřebuji; stály by majlant a my tu přece nemáme klíče k rampám raket Titan II… ale ta třetí úroveň vypadá zajímavě". Vedoucí oddělení knihovny THOMAS zase řekne: „hele, my potřebujeme zajistit k těmto věcem přístup zvenčí, ale kaštani nesmí mít možnost měnit obsah, takže nám by měla vyhovovat ta druhá roveň odspodu“. Skupina NSA s názvem „National Computer Security Center“ navrhla celkem čtyři „skupiny“ důvěryhodnosti v operačních systémech, každá skupina je přitom ještě hlouběji dělena do tzv. „tříd“, kterých je celkem sedm. Tyto skupiny a třídy byly popsány v dokumentu označovaném obvykle názvem „Orange Book“ (kvůli barvě obalu), jeho skutečný název je však „Trusted Computer System Evaluation Criteria“. Skupina National Computer Security Center tento dokument zveřejnila v prosinci1985.

Certiﬁkace C2 a Windows NT NSA označila čtyři definované skupiny zabezpečení písmeny D, C, B a A, a to podle zvyšující se úrovně zabezpečení. Sedm tříd požadavků na software bylo – opět vzestupně dle přísnosti požadavků – označeno D, C1, C2, B1, B2 a A. Všechny třídy i skupiny jsou popsány v Orange Book. Toto však byl jen začátek. Jakmile se náš imaginární vedoucí oddělení FBI nebo THOMAS rozhodne pro určitou skupinu zabezpečení, jak se dozví, zda ten či onen výrobek splňuje požadavky dané skupiny? NSA po vypracování standardu začala sama provádět certifikace různých systémů. Díky jejich úsilí je práce nákupčích ve státních úřadech značně zjednodušena, protože jim stačí zeptat se: „Máme tu něco, co vyžaduje specifikaci C1 nebo C2… který operační systém se na to dá nasadit?“ Ted bych se vsadil, že ve vás specifikace „C2“ vyvolala matnou vzpomínku – ano, správně, tato třída zabezpečení byla často zmiňována v 90. letech v souvislosti s Windows NT. Je pravda, že trochu zjednodušuji celý proces, když říkám, že nějaký operační systém lze certifikovat na třídu B1, C2 apod., protože NSA ve skutečnosti vyhodnocuje celé systémy a bere do úvahy také hardware a aplikace. Neformálně je však běžné slyšet spoustu lidí mluvit o tom, že ten a ten operační systém „vyhovuje certifikaci C2“ (C2 compliant), jak se to jistou dobu říkalo o Windows, když NSA certifikovala několik specifických konfigurací NT na třídu C2. Tuto frázi dnes již neuslyšíte, protože celý program Trusted Computer System Evaluation Criteria byl zahrnut do mezinárodní sady standardů „Common Criteria“.

158

Kapitola 4 – Kontrola integrity windows

C a B: Výběrový vs. povinný Ze všech čtyř skupin se nejvíce mluví o B a C, protože D neznamená nic jiného než to, že daný operační systém „není zabezpečen“ a A je to samé, co B3, vyžaduje však formální testy zabezpečení, které jsou nechutně drahé. Hlavní rozdíl mezi C a B je v tom, že C zahrnuje „výběrovou ochranu“, a B vyhovuje přísnějším požadavkům, označovaným jako „povinná ochrana“.

Přehled a terminologie výběrového přístupu V těch dávných dobách, kdy jsem pracoval na Ministerstvu energetiky, jsme se potřebovali nějak zabezpečit, ale ne zase moc. Všichni jsme vytvářeli a starali se o nějaké datové a programové soubory, a proto jsme oceňovali výhody systému, na kterém jsme mohli sdílet své soubory v rámci společných projektů. Tyto soubory přitom ostatní uživatelé mohli jenom číst, ne měnit. Díky tomu se v analýzách (potřebných v rámci různých projektů) dalo snadno pracovat s daty či programy, a přitom si každý byl jist, že nemůže dojít k poškození či nechtěné změně souborů, za které jsme zodpovídali. Opět říkám, že jsme toto ve skutečnosti nikdy nepotřebovali, ale kdyby k tomu došlo, jednalo by se o případ využití modelu zabezpečení s výběrovým přístupem. Nikdo z nás nebyl ani správcem celého mainframu, na kterém jsme pracovali, a na mou duši si ani nevzpomínám na to, že bych se někdy s některým ze správců setkal. To je důležitá součást systémů s výběrovým přístupem: správci udělí běžným uživatelům dostatečně široká práva řízení svých prostředků, aniž by bylo nutné povyšovat je na správce v rámci celého systému.

Části systému s výběrovým přístupem Systém řízení s výběrovým přístupem se skládá z uživatelských účtů, přihlašovacích procedur, objektů, vlastníků a oprávnění. Ve třídě zabezpečení C2 je výběrový přístup realizován tak, že každý objekt (například složka nebo soubor) má svého vlastníka. Vlastníkem je obvykle osoba, která objekt vytvořila, ale není to nezbytně nutné. Vlastník objektu má oprávnění vytvořit seznam uživatelských účtů a skupin, kterým je udělen nebo zakázán přístup k objektu. C2 vyžaduje uživatelské účty, aby vlastník mohl jmenovitě určit, kdo bude mít přístup povolen a kdo zakázán, proto je také nutná přihlašovací procedura, která prověří, zda člověk prohlašující o sobě, že má právo přístupu k určitému objektu, je skutečně tím, za koho se vydává. Máte toto zažité? Měli byste. Microsoft použil specifikaci C2 jako výchozí bod pro to, co bylo původně systémem řízení přístupu k souborům a složkám, a co se později rozšířilo na další typy objektů. Specifikaci C2 si Microsoft zvolil proto, že usiloval o její získání pro Windows. Ústřední myšlenkou ve výběrovém systému je to, že vlastník – libovolný uživatel, kterému se poštěstilo být vlastníkem, nemusí jít o správce systému – uděluje a zakazuje přístup ke svým objektům. Jestliže se vlastník rozhodně udělit právo úplného řízení (Full Control) účtu Guest a tak zpřístupnit daný soubor všem uživatelům na celé planetě, je to jeho právo a nic mu v tom nesmí bránit. V „čistokrevném“ výběrovém modelu může každý uživatel ukládat své dokumenty ve složkách, které vlastní (například ve složkách svého profilu Windows), právo řízení přístupu k těmto složkám má opět jen a jen vlastník. Ve Windows toto samozřejmě tak úplně neplatí, protože účet LocalSystem a místní skupina Administrators obvykle implicitně získávají právo úplného řízení nad všemi složkami počítače. Přesto však Windows až po verze XP a 2003 nabízí něco hodně podobného definici výběrového přístupu podle specifikace C2.

Srovnání povinného a výběrového řízení

POZNÁMKA:

159

Kromě vlastníků objektů, výběrových oprávnění, účtů uživatelů a přihlašovacích procedur vyžaduje specifikace C2 také nějaký mechanismus pro evidenci (audit), který bude sledovat využití výběrových oprávnění, což Windows samozřejmě nabízí formou svých funkcí pro audit zabezpečení.

„Chranitelné“ objekty: co se dá pomocí výběrových oprávnění chránit Podívejme se nyní na třídy objektů, které lze ve Windows chránit. I když Windows používají výběrový model, existují v nich také věci bez možnosti přiřadit oprávnění. Mohu vám například udělit oprávnění změnit na mém počítači adresu protokolu IP, aniž bych vám tím zároveň neudělil právo změnit masku podsítě, výchozí bránu a další parametry sítě? (Nevím sice, proč bych měl o něco podobného stát, ale jde jen o příklad.) Nemohu, protože Microsoft se rozhodl zabudovat podporu pro výběrová oprávnění jen do některých částí Windows, u zbytku se tím neobtěžoval. Microsoft označuje typy objektů, kterým se dají přiřadit oprávnění, pojmem „securable objects“ (chranitelné objekty). Úplný seznam těchto objektů zahrnuje podle článku MSDN „Securable Objects“ (http://www.windowssdk.msdn.microsoft.com/en-us/library/ms723270.aspx): ■

Soubory a složky

■

Pojmenované roury (metoda vzájemná komunikace procesů)

■

Procesy

■

Vlákna

■

Přístupové tokeny (data, které systém přijímá po ověření totožnosti uživatele)

■

Objekty správy Windows – označované rovněž jako „jmenné prostory WMI“ – v současné době nejdůležitější nástroj pro programové řízení téměř všech součástí Windows

■

Klíče systémového registru

■

Služby Windows

■

Místní a vzdálené tiskárny

■

Síťová sdílení

■

Objekty meziprocesové synchronizace (Způsob, jak může jeden proces kontaktovat jiný proces a o něco ho požádat)

■

Objekty úloh (nástroj dostupný již od Windows 2000, který umožňuje přikázat systému: „spusť takovouto sadu programů, pokud by však vyžadovaly více procesorového času než tolik a tolik, nebo více jak tolik a tolik RAM, úlohu ukonči“)

■

Objekty adresářové služby (uživatelské účty, účty počítačů, objekty zásad skupiny, domény)

Oprávnění objektů jsou hodně často ukládána přímo v souboru samém. Jestliže například nastavíte určitý soubor na souborovém systému NTFS tak, abyste k němu měl oprávnění Úplné řízení, poté je toto oprávnění uloženo v oblasti tzv. „metadat“ souboru. Z technického hlediska je každé vámi vytvořené výběrové oprávnění označováno jako DACE (discretionary access control entry, položka řízení výběrového přístupu). Pro úplný seznam těchto řídících položek je používán pojem DACL (discretionary access control list). Ve světě Windows však obvykle úvodní D vypouštíme

160

Kapitola 4 – Kontrola integrity windows

a hovoříme o ACL (access control list, seznam řízení přístupu), obsahujícím položky ACE. Podotýkám, že mnoho lidí zde ještě více zjednodušuje a používají výraz „ACL“ jako pro vyjádření celého seznamu (ACL), tak jedné položky (ACE). Jestliže někdo řekne: „Nastavil jsem ACL pro soubor ucto.dat tak, aby ho skupina Uctarna mohla číst“, znamená to ve skutečnosti, že daný člověk přidal do DACL souboru ucto.dat položku DACE, která uděluje skupině Uctarna právo čtení. (To asi víte, ale trocha opakování nikdy neškodí, protože za chvíli bude řeč o odpovídajících pojmech pro systémy povinného řízení přístupu.)

Přehled a terminologie povinného přístupu Dejme tomu, že už tolik nedůvěřujeme uživatelům, abychom každému z nich povolili udělovat oprávnění. Zjistili jsme například, že několik uživatelů nastavilo oprávnění ke složkám svých profilů tak, že nad těmito složkami měl právo úplného řízení účet Guest. To je ovšem děs! V takovém případě budeme pravděpodobně zvažovat omezení rozsahu oprávnění, které budou uživatelé moci v systému řízení výběrového přístupu použít, a uvalit určitá omezení na jejich schopnost otevírat bránu do interního systému zvenčí. V tomto případě bude potřebovat určitý druh povinného řízení přístupu. Abychom získali podle specifikací Orange Book certifikaci „B“, musí operační systém obsahovat nějaký druh povinného řízení přístupu. U povinného řízení přístupu jde v podstatě o to, že vedení organizace navrhne určité zásady zabezpečení na úrovni celého podniku, obsahující pravidla typu „hesla musí být nejméně 7 znaků dlouhá“ nebo „žádné oprávnění nesmí nic povolit účtu Guest“. O praktické vynucování těchto zásad se poté postará určitá součást operačního systému. Slovo „povinný“ (mandatory) namísto „výběrový“ (discretionary) je tu používáno proto, že v teoretickém výběrovém modelu je uživatel králem, zatímco v povinném modelu jsou jeho pravomoci sníženy na úroveň lokálního barona. Jak víme, ve Windows je implementováno výběrové řízení přístupu; je tu i povinné řízení? Ano, něco takového tu najdeme; věřím tomu, že byste tomu přisoudili vyšší stupeň certifikátu než pouhé „C“, nejspíš „C+“ nebo „B–“. Je například možné zakázat uživatelům udělovat přístup účtu Guest, což naplňuje znaky povinného přístupu: počínaje Windows 2000 má správce domény možnost vytvořit objekt zásady skupiny, který aplikuje oprávnění na všechny diskové jednotky C: v doméně, a toto oprávnění explicitně zakáže účtu Guest jakýkoli přístup k disku C:\. Takové oprávnění je na uživatele uvaleno „zvenčí“ a omezuje jeho schopnosti. Na Windows však toto ještě neznamená, že bychom mohli hovořit o skutečně přínosném „povinném řízení“. Smutným faktem je například to, že na Windows často nelze rozlišit obyčejného uživatele od správce, jak jsem to zažil již v éře mainframů, protože na většině počítačů pracuje jen jeden člověk, který je po celý den přihlášen jako administrátor. Dále platí, že na starších verzích Windows (před nástupem Visty) mohl správce systému dělat cokoli, takže mohl i zrušit vliv doménových zásad skupiny na místní počítač, které tak nemohly uplatňovat zásady „povinného“ řízení. Pokud však má libovolný druh povinného řízení přístupu skutečně účinně chránit uživatele před napadením ze strany malwaru, nesmí být vynucováno správcem systému (který nemusí mít dostatečný přehled v problematice zabezpečení, takže nedokáže správně ochránit sám sebe), ale přímo operačním systémem, a toto se právě mění ve Vistě, kde nastupuje řízení integrity Windows. Systém řízení integrity Windows ve Vistě je tedy implementace standardního pojmu systému povinného řízení přístupu.

Součásti WIC POZNÁMKA:

161

Přesně řečeno, není to skutečný systém povinného řízení kontroly, protože mu schází pružnost a hojnost různých vlastností, které známe z DACL. Jeho účelem je hlavně zabránit nízkoúrovňovým procesům v poškození objektů běžících na vyšší úrovni, proto Microsoft používá raději pojem „integrita“ než „přístup“.

Direktivní povaha WIC je dána tím, že implicitně nastavuje pravidla dodržování integrity sám operační systém namísto správce, a tento operační systém nyní může vytvářet i objekty s takovou úrovní integrity, že ani správce systému k nim nemůže nijak přistupovat. Z pojmového hlediska ukládá objekt – stejně jako soubor – svou úroveň integrity prakticky stejným způsobem jako svůj DACL a jméno svého vlastníka, tedy v metadatech souboru. Říkal jsem si, že by se tento kus dat, který říká „mám střední (medium) úroveň integrity“, mohl označovat pojmem MACE (mandatory access control entry), ale autoři Orange Book tuto informaci označují jako „popisek citlivosti“ (sensitivity label) nebo někdy jen jako „popisek“ (label). Microsoft používá pojem „mandatory labels“, osobně bych dal přednost pojmu „integrity labels“, byl by vhodnější. V každém případě si zapamatujte toto: ■

„úroveň integrity“ odkazuje na procesy, uživatele a úroveň důvěryhodnosti objektů.

■

„mandatory label“ je pouze název pro data připojená k procesu, uživateli nebo objektu, která ohlašují jeho úroveň integrity.

Součásti WIC Díky za to, že jste vydrželi tuto nepříliš záživnou teorii; přišel čas přesunout se k vlastní implementaci. Spojíme-li terminologii a koncepci, můžeme zatím říci, že Řízení integrity Windows aplikuje mandatory labels na ochranitelné objekty a deklaruje tak jejich úroveň integrity coby měřítko důvěryhodnosti. Dále také víte, že hlavním smyslem úrovní integrity je to, že u libovolného objektu můžete zapnout ignorování pokusů o čtení, zápis nebo spuštění, pokud tyto požadavky pocházejí od objektu s nižší úrovní integrity.

Šest úrovní integrity WIC Microsoft si zvolil šest úrovní integrity. Pokud vím, jsou všechny z nich v implicitní instalaci Visty využívány, nejčastěji se však vyskytuje nízká (low) úroveň integrity. Momentálně se mi zdá – ale pozor, zjednodušuji – že většina práce WIC spočívá v udržování tenké, ale přesné hranice mezi „nízkým“ a vším ostatním na vyšších úrovních. Tím nechci říci, že by se ostatní úrovně od sebe nijak nelišily nebo že byste je nemohli zužitkovat, až pochopíte rozdíly mezi nimi, proto si je nyní představíme. Každý proces, uživatel nebo objekt může teoreticky patřit do libovolné z těchto šesti úrovní integrity, které jsou v následujícím seznamu seřazeny vzestupně podle jejich hladiny důvěryhodnosti: Nedůvěryhodný (Untrusted) Podle dokumentace Microsoftu je tato úroveň integrity přiřazena libovolnému procesu přihlášenému na anonymní účet. Nenašel jsem způsob, jak si toto vyzkoušet v praxi, až na jednu výjimku. Jak vám ukážu později, přiřadíte-li úroveň integrity „untrusted“ programovému souboru (libovolnému EXE) a pokusíte se ho poté spustit, Windows vám oznámí „přístup odepřen“.

162

Kapitola 4 – Kontrola integrity windows

Nízká (low) Tato úroveň integrity je implicitně přidělena všemu, co do systému přichází z Internetu. Internet Explorer sám běží na nízké úrovní integrity, přestože se toto dá potlačit zákazem „chráněného režimu“ (nové vlastnosti Internet Exploreru 7). Při konfiguraci svého profilu Vista vytvoří několik složek s nízkou úrovní integrity – například složku Temporary Internet Files. Také několik klíčů systémového registru dostane přidělenu nízkou úroveň integrity, protože nový Internet Explorer by jinak nebyl schopen uložit svá nastavení. Střední (Medium) Standardní uživatelé jsou přihlášení na této úrovní integrity. Ve skutečnosti má střední úroveň integrity skoro každý soubor na počítači, protože tuto úroveň získává vše, co nemá explicitně přidělen mandatory label. Takové nastavení je výhodné vzhledem k prvotnímu úkolu služby Řízení integrity Windows, totiž ochraně souborů proti malwaru staženému z Internetu. Výraz „Bez mandatory label“ zde znamená „střední“, a proto budou pokusy většiny škodlivého kódu o změnu souborů či složek na počítači zamítnuty. (Hovoříme o škodlivém kódu staženém z Internetu. Pokud si nějakého „brouka“ přinesete do práce na CD nebo flash disku, bude spuštěn se střední nebo vysokou úrovní integrity, podle toho, s jakými oprávněními budete přihlášeni k systému při jeho neopatrné instalaci!) Vysoká (High) Na této úrovní integrity jsou k systému přihlášeni jeho správci. Pokud by tuto vysokou úroveň integrity neměli, nemohli by pravděpodobně provést většinu svých úkolů, alespoň tak to při představení WIC vypadalo. Jak mi bylo řečeno, v první verzi WIC bylo nutné mít vyšší úroveň integrity než objekt, do kterého jste chtěli zapisovat. Správci proto potřebují vyšší úroveň integrity než standardní uživatelé. Systém Uživatelé (lidé) tuto úroveň integrity nedostávají, nebo spíš se mi nepodařilo přijít na žádný způsob, jak je do této úrovně integrity povýšit. Na této úrovní integrity běží zřejmě všechny systémové služby a většina jádra. To je samozřejmě zcela v pořádku a ve skutečnosti to pomáhá zvýšit odolnost služeb proti malwaru, kterému neopatrný správce povýší jeho práva. Znepokojující je však to, že se možná někdy nějakému hackerovi podaří napsat zákeřný kód, který se dokáže do systému zapsat s touto úrovní integrity. Jen si to představte: malware, který ani správce nemůže ze systému odstranit. Instalátor (Installer) Když vycházíme z předchozího bodu, je jasné, že Microsoft potřeboval, aby instalátory měly ještě vyšší úroveň integrity než všechno ostatní, aby mohl odebrat instalované programy (s ohledem na původní specifikaci WIC, podle které proces potřebuje vyšší úroveň integrity než měněný objekt). (V praxi nevím o žádném případu, kdybyste viděli něco pracovat na úrovni integrity instalátoru.) Při pohledu „pod kapotu“ však poznáte, že úrovně integrity nejsou v praxi tak jednoduché, aby je bylo možné stručně popsat slovy „systémová“ nebo „vysoká“. Každou úroveň integrity lze vyjádřit jako SID ve tvaru S-1-16-číslo, kde číslo nabývá hodnot 0 až 16384. Každá úroveň integrity dostává také svůj název, který vypadá třeba takto: „Mandatory Label\ Level Mandatory Level“, kde je jako Level (úroveň integrity) uvedeno Untrusted, Low, Medium apod. Většina úrovní integrity má přidělen také kód z dvou písmen, ve kterém jsou zakódovány informace psané v SDDL (Security Descriptor Definition Language).

Součásti WIC

163

Chápu, že těch pojmů je najednou moc, ale slibuji, že budu srozumitelnější, až se dostaneme k nějakým reálným příkladům mandatory labels, řetězců SDDL a další záležitosti … určitě budeme vše pořádně probírat. Prozatím shrnu všechny základní informace o typech úrovní integrity v tabulce 4.1, která vám bude sloužit jako referenční příručka zachycující možné proměny různých úrovní integrity, se kterými se v této kapitole setkáme. TABULKA 4.1: Souhrn typů úroveň integrity Název

Název účtu

Untrusted

Low

SID

Hexadecimálně

SDDL SID řetězec

Poznámky

Mandatory S-1-16-0 Label\Untrusted Mandatory Level

Žádný

Anonymní

Mandatory Label\Low Mandatory Level

S-1-16-4096

1000

Chráněný režim Internet Exploreru běží na této úrovní integrity, všechny objekty stažené z Internetu do složky Temporary získávají tuto úroveň integrity.

S-1-16-8192 Medium Mandatory Label\Medium Mandatory Level

2000

Uživatelé a všechny věci bez návěští (tedy systémové soubory). Dále tuto úroveň integrity získávají soubory stažené z Internetu příkazem „Uložit jako“.

High

Mandatory Label\High Mandatory Level

S-1-16-12288 3000

Správci systému.

System

Mandatory Label\System Mandatory Level

S-1-16-16384 4000

Většina systémových služeb.

Jak objekty získávají a ukládají své úrovní integrity: Mandatory Labels Vista ukládá úrovně integrity u objektů, procesů a uživatelů různým způsobem. U objektů je úroveň integrity uložena uvnitř speciální položky SACE (System Access Control Entry), která je zařazena do seznamu SACL (System Access Control List).

164

Kapitola 4 – Kontrola integrity windows

SACL: už nejen pro audity Zkratky „SACL“ a „SACE“ – nic vám to nepřipomíná? Nebo vám v hlavě sice sepnulo, ale jen na vteřinku? Když uvážíme, jak málo se s nimi setkáváme, i když jsou mezi námi již od dob NT 3.1, není divu. Určitě jste je však používali, pokud jste někdy prováděli audit přístupu k objektům. Kromě prostoru pro výběrový ACL (DACL) má každý ochranitelný objekt ještě vyhrazen prostor pro systémový ACL (SACL). Nechoďte si do knihovny pro Orange Book ani pro Common Criteria, nikde tam zmínku o SACL nenajdete. Kdysi dávno si v Microsoftu při návrhu NT 3.1 vývojáři řekli: „Hele, když už vytváříme místa pro ukládání DACL, které potřebujeme pro certifikaci C2, proč si nenechat místo i pro další vlastní ACL, který využijeme podle našich potřeb?“. A jak řekli, tak udělali a na světle božím se objevil SACL. Microsoft předvídal, že bude SACL a jeho položky SACE využívat pro nejrůznější záležitosti, ale v praxi SACL obsahoval až do nástupu Visty jen instrukce pro auditovací nástroj (co má sledovat). Větší část z Auditovatelné Devítky (přihlášení k systému, využití oprávnění, výskyt systémových událostí apod.) měla prostě v zásadách skupiny jen přepínač zapnuto/vypnuto, které povolovaly či zakazovaly určité třídy auditu. Ale i kdybyste zásadu „Auditovat přístup k objektům“ zapnuli, nebudou do protokolu událostí Zabezpečení zapisovány žádné informace, protože nejdřív musíte projít všechny objekty, u kterých mají Windows sledovat přístup k nim a určit, jak moc do hloubky má být přístup sledován. Dejme tomu, že chcete, aby Windows sledovaly přístupy k určitému souboru. Operačnímu systému nestačí říci jenom „sleduj všechny pokusy o přístup k souboru test.txt“ – to není ani polovina toho, co Windows chtějí vědět. Windows dotírají spoustou otázek: „Komu máme podat zprávu? Jaké aktivity máme sledovat – pokusy o čtení? zápis? změnu atributu? Máme sledovat úspěšné pokusy, neúspěšné, nebo obojí?“ Jak ví každý, kdo už někdy audity přístupů k objektům prováděl, buď hodně přesně vymezíte, co chcete mít v protokolech zapsáno, nebo se budete muset vypořádat s megabajty auditovacích protokolů. V každém případě platí, že všechny tyto atributy zpřesňující vlastní auditování jsou zapisovány na úrovni objektů do jejich SACL jako jedna či více položek SACE, a od roku 1993 až do nástupu Visty to je jediné reálné využití těchto speciálních metadat objektů. TIP:

Položky SACE se dají u každého objektu zobrazit tak, že vyvoláte místní nabídku daného objektu, příkazem Vlastnosti otevřete dialogové okno vlastností a v něm se přepnete na stránku Zabezpečení, kde klepnete na tlačítko Upřesnit. V dialogovém okně Upřesnit nastavení zabezpečení se přepněte na stránku Auditování (ve Vistě musíte ještě zavřít tlačítkem Pokračovat dialog Consent UI) a zde uvidíte položky SACE daného objektu, pokud existují. Ve většině případů však bude tato stránka prázdná, protože auditování objektů má zapnuté jen minimum lidí.

Mandatory Labels Řízení integrity Windows: Lost in SACE „Pozor, POZOR, Wille Robinsone!“ (Promiňte, nemohu odolat.) Po přečtení předchozího tipu vás nejspíše něco zarazí. Koneckonců jsem již řekl, že: (1) ve Vistě má všechno svou úroveň integrity, (2) ta je uložena jako nový druh položky řízení přístupu a říká se jí „mandatory label“, (3) tento mandatory label ACE je ve skutečnosti speciální SACE, a… (4) právě jste si přečetli, že s velkou

Součásti WIC

165

pravděpodobností je SACL – tedy seznam položek SACE – libovolného souboru prázdný. V pořádku, Robote, můžeš mluvit. Jen do toho…. „Toto nejde vypočítat, Wille Robinsone! Pokud všechny objekty mají mandatory label, která jsou ve skutečnosti SACE, jak může být seznam SACL prázdný …“ (ozve se rána, jak Robotova hlava spadne dopředu a jeho kontrolky zhasnou, protože mu nějaký zlosyn vypne hlavní vypínač). Při sledování seriálu Lost In Space jsem vždy toužil toho robota vypnout. Ale náš ocelový přítel má pravdu, nebo přinejmenším jeho logická jednotka, protože jsem zatím neuvedl dvě důležité skutečnosti. ■

Za prvé, Microsoft se z nějakého důvodu rozhodnul neukazovat mandatory label SACE na stránce Auditování. Pokud je mi známo, neexistuje žádný vizuální nástroj GUI, který by tyto položky SACL zobrazil. Existuje nástroj příkazového řádku, který budeme probírat později, ale jeho možnosti jsou omezené. Napsal jsem vlastní nástroj příkazového řádku, který umí to samé, co tento vestavěný program, a ještě pár věcí navíc… ale k němu se dostaneme za chvíli.

■

Za druhé, Ve skutečnosti má drtivá většina objektů svou úroveň integrity, ale pouze jednu implicitní. Většina věcí nemá přiřazenu žádnou mandatory label SACE kvůli Druhé Direktivě WIC.

POZNÁMKA:

Druhá Direktiva Řízení integrity Windows zní: „pokud objekt nemá explicitně přiřazen mandatory label, je objekt chápán tak, jako by měl přiřazen label střední úrovně integrity“.

Ukládání úrovní integrity jako součást SACL objektu byl od Microsoftu byl pravděpodobně velmi dobrý krok, protože seznamem SACL byla vybavena velká část objektů. Aniž by tedy bylo nutné vyměňovat příliš velké množství interní armatury Windows, máme nyní k dispozici infrastrukturu povinného řízení jako doplněk infrastruktury výběrového řízení.

Prohlížení úrovní integrity objektu: seznamte se s chml a icacls Jak se tedy můžeme podívat na mandatory label objektu? Windows neobsahují žádný nástroj, který by toto uměl. (Nebo alespoň pár týdnů před uvolněním Visty žádný takový nástroj v systému nebyl.) Proto jsem ho napsal.

Nástroje icacls a chml Když jsem se prvně seznamoval s celým Řízením integrity Windows, ptal jsem se všech lidí v Microsoftu, kteří byli ochotni poslouchat: „V čem si mohu prohlédnout úroveň integrity objektů? Kde ji mohu změnit?“ Oslovení reagovali téměř vždy strnulým pohledem a po chvíli se vzmohli na něco jako „taková věcička neexistuje“. Částečně měli pravdu, protože ve Vistě sice je nástroj, který umožňuje změnit úroveň integrity, ale prohlížení stávajících úrovní je možné jen někdy. Zdá se však, že skoro nikdo u Microsoftu o tomto programu neví. Jde o nástroj příkazového řádku icacls, který Microsoft vyvinul jako nástupce staršího cacls, který se poprvé objevil již v NT 3.1, pokud si pamatuji správně. Já sám jsem icacls poprvé objevil až při průzkumu RC1 verze Visty, a to ještě ke všemu jeho dovednosti vůbec neodpovídaly tomu, o čem se psalo v jeho

166

Kapitola 4 – Kontrola integrity windows

Nápovědě. Až nakonec jsem v Microsoftu našel jednoho znalého člověka, který mi vysvětlil, že icacls bude ve finální verzi Visty funkční, i když v RC1 není dokončen. Nástroj byl opraven až v sestavení č. 5744, které Microsoft uvolnil v polovině října 2006. Já jsem však nemohl čekat tak dlouho, proto jsem napsal vlastní program, provádějící to samé co icacls, a doplněný o některé funkce navíc. Nazval jsem ho „chml“ neboli „change mandatory label“ (změna povinných návěští). Můžete si ho stáhnout z mého webu: 1. Spusťte program Internet Explorer. 2. Do adresního řádku zapište http://www.minasi.com/vista/chml.htm. 3. Klepnutím na hypertextový odkaz stáhnete soubor chml.exe. 4. Ve výzvě Internet Exploreru klepněte na tlačítko Uložit. 5. Soubor uložte do složky, ke které máte právo zápisu; zde budeme používat zkušební složku C:\pokusy. 6. Otevřete okno příkazového řádku s právy správce. POZNÁMKA:

Probírám to tu takto podrobně namísto jedné věty „otevřete si to a to URL a stáhněte si soubor do C:\windows“ proto, že Internet Explorer běží na nízké úrovní integrity a Průzkumník na střední úrovní integrity, a oba nemají právo zapisovat do složky Windows, zatímco v příkazovém řádku s právy správce je tento zápis možný. Berte to jako součást návyku na Vistu. Jiný správný přístup je uložení souboru chml.exe do nějaké složky a úprava systémové cesty, do které danou složku přidáte.

7. Příkazem cd \pokusy nastavte jako aktivní složku C:\pokusy.

Prohlížení úrovní integrity v nástroji chml 1. V příkazovém řádku s právy správce spusťte příkaz copy chml.exe C:\windows, abyste nástroj umístili do složky, která je v systémové cestě a tedy dostupná z libovolného pracovního adresáře. 2. Poté prozkoumáme úroveň integrity souboru notepad.exe příkazem chml C:\windows\notepad.exe: C:\pokusy>chml C:\windows\notepad.exe -b C:\windows\notepad's mandatory integrity level=unlabeled (medium)

Všimněte si, že podle chml má notepad.exe střední úroveň integrity, to je však dáno tím, že tato úroveň integrity je implicitní. 3. Chcete-li vidět nějaký program s explicitně přiřazenou úrovní integrity, zapište chml C:\ users\vaše jméno\appdata\locallow -b a stiskněte Enter. Namísto části vaše jméno zapište jméno svého uživatelského účtu. Pokud jste přihlášeni třeba na účet „marek“, bude příkaz vypadat takto: C:\pokusy>chml C:\users\marek\appdata\locallow -b C:\users\marek\appdata\locallow's mandatory integrity level=low

Součásti WIC

167

Dvě věci stojí za povšimnutí: ■

Za prvé – v souladu s předchozím slibem – v systému lze najít věci, které mají přiřazenu nízkou prioritu už ve výchozí instalaci. (A když píšu „nízká “, nemám na mysli morálku prodejců, kteří vám nabízí počítačovou sestavu. Ach Bože, ta děsná verze Vista Home Basic.)

■

Za druhé v tomto případě chybí v hlášení řetězec „unlabeled“ (bez popisku).

Prohlížení úrovní integrity v nástroji icacls Dále si předvedeme tyto úlohy s vestavěným nástrojem icacls. Chcete-li ho vidět v akci, postupujte podle následujících bodů: 1. Otevřete příkazový řádek (je jedno, zda s právy správce nebo ne). 2. Zapište příkaz icacls C:\windows\notepad.exe a stiskněte Enter. 3. Zapište icacls C:\users\vaše jméno\appdata\locallow (namísto části vaše jméno uveďte název svého uživatelského účtu) a stiskněte Enter. Výpis bude vypadat podobně jako obrázek 4.1, který zde uvádím namísto výpisu, protože formát výstupu icacls má tendenci se na stránce zalamovat a je pak v podstatě nečitelný. OBRÁZEK 4.1: Čtení mandatory labels v nástroji icacls

Vypadá divně, ale tento výstup příkazu icacls se musíte naučit interpretovat, protože jde o jediný vestavěný nástroj (textový i GUI) pro zobrazení a změnu úrovní integrity, který je součástí Visty. Výstup příkazu icacls je neurovnanou kupou informací o různých oprávněních, protože: ■

Ukazuje jen obsah výběrového ACL a všechna případná povinná mandatory labels; Neukáže nic z toho, co je zapsáno v systémovém ACL a nemá mandatory label. To znamená, že i kdyby Poznámkový blok či LocalLow měli nastaveny auditovací položku SACE, icacls by údaje o nich nevypsal.

■

Vzhledem k tomu, že icacls ukazuje jen explicitně přiřazené ACE, nemůže vám sdělit například to, že u Poznámkového bloku je předpokládána střední úroveň integrity. Stačí si jen zapamatovat, že pokud ve výpisu nevidíte žádný řádek začínající na „Mandatory Label“, nemá daný soubor žádný explicitně přidělený mandatory label a proto je mu udělena automaticky střední úroveň integrity.

168 ■

Kapitola 4 – Kontrola integrity windows

Části řádků, které vypadají jako (OI)(CI)(NW), jsou zkráceným zápisem oprávnění, které ACE uděluje. V tomto případě je třeba tuto část dekódovat takto ■ „Udělte všem souborům v této složce nízkou úroveň integrity, kterou má i nadřízená složka“. (OI) ■ „Udělte všem podřízeným složkám v této složce nízkou úroveň integrity, kterou má nadřízená složka“. (CI) ■ „Nepovolte žádnému procesu s nižší úrovní integrity změnit obsah této složky“. (NW) Tyto zkrácené zápisy jsou definovány v jazyku SDDL (Security Descriptor Definition Language), o kterém jsem se zmínil v předchozím textu a jehož stručný popis bude následovat.

Dekódování Mandatory Labels Nástroj icacls popisuje návěští integrity příkazu LocalLow v tomto tvaru, protože se jedná o oficiální formát Microsoftu pro zobrazování návěští. Vypadá to podobně, jako návěští „Mandatory Label\Low Mandatory Level“, na které jsme již narazili, ale které jsem prozatím podrobně nevysvětloval. Interpretujeme ho takto: ■

„Doménová“ část názvu objektu je „Mandatory Label“. Tento název je odvozen z rozhovorů kolem Orange Book.

■

Část „název objektu“ má jednu z následujících hodnot: ■ System Mandatory Level ■ High Mandatory Level ■ Medium Mandatory Level ■ Low Mandatory Level ■ Untrusted Mandatory Level

POZNÁMKA:

Existuje ještě úroveň „Installer“ nebo „Trusted Installer“, o které již byla zmínka, ale ta se v tomto posledním seznamu neobjevuje. Osobně jsem nikdy neviděl objekt, který by běžel na této úrovni – ta je podle mého názoru určena jen procesům – proto nemohu uvést, co by icacls vypsal pro objekt takové úrovně integrity. Ostatní návěští jsem však u objektů viděl.

V případě, kdy řádek „Mandatory Label\Low Mandatory Level“ nedává smysl, porovnejte ho s jiným ACE ve výpisu z icacls, s prvním řádkem výpisu pro LocalLow. Nástroj icacls zde vypisuje Vista64\Mark:(F)

Oproti tomu je mandatory label v icacls vypsána takto: Mandatory Label\Low Mandatory Level:(OI)(CI)(NW)

Položky ACE obecně delegují oprávnění, které je složeno – zjednodušeně řečeno – ze dvou části: kdo oprávnění dostane (v terminologii Microsoftu „vykonavatel“ čili „trustee“) a jakou úroveň oprávnění dostane („úplné řízení“, „číst“ apod.). Ve výstupu icacls je vykonavatel uveden vlevo

Součásti WIC

169

od dvojtečky (například „Vista64\Mark“) a úroveň oprávnění vpravo od dvojtečky, například jako „(F)“ nebo „full control“ (úplné řízení“). Mandatory labels neboli položky SACE, ve kterých Microsoft ukládá údaje o úrovních integrity, nezapadají do tohoto modelu dokonale, protože vykonavatel (který získává label) je zřejmý: je jím libovolný objekt, který má danou položku SACE. V zápisu „Vista64\Mark“ je „Vista64“ nezbytnou částí, protože identifikuje počítač, na kterém je umístěn Markův účet. Mandatory labels jsou ale vytvářeny na úrovni domény a nejsou závislé na konkrétním počítači. Z toho vyplývá, že mandatory label musí zprostředkovat jen úroveň integrity, kterou objekt má. Protože se však Microsoft pokusil využít pro mandatory labels využít stávající úložný mechanismus (SACE), musel data vytvořit tak, aby vyhovovala existujícím pravidlům daného kontejneru. A ta říkají, že ACE musí obsahovat minimálně dva základní údaje: „kdo oprávnění získá“ a „co získá“. Normálně je tato první část vyjádřena jako kombinace názvu uživatelského účtu a názvu domény nebo místního systému, na kterém je účet umístěn. Tato kombinace však zde nemá význam a Microsoft sem proto umisťuje „název domény“ ve tvaru „Mandatory Label“. POZNÁMKA:

Z technického hlediska je ta část celého řetězce, která je umístěna vlevo od zpětného lomítka (ať už jde o název místního systému, doménu nebo „Mandatory Label“), označovaná jako „autorita“, která vystavila daný název.

Změna úrovní integrity objektu Už od počátku mne trochu znervózňovala celá idea něčeho, co nijak nemohu změnit, proto jsem byl velmi zvědavý, zda se mi podaří objevit nějaký způsob změny úrovně integrity objektu. Uvádím zkráceně mé poznatky v této oblasti: ■

Uživatelé mohou měnit úroveň integrity objektu v případě, kdy mají oprávnění SeRelabelPrivilege (novinka Visty), které jim povoluje změnit mandatory label objektu.

■

Libovolný uživatel s tímto oprávněním dostane během přihlášení rozdělený token, protože dané oprávnění patří mezi Notoricky Známou Devítku, se kterou jste se seznámili ve druhé kapitole.

■

Každý, kdo chce přečíst mandatory label objektu, k tomu potřebuje jen právo „Čtení oprávnění“. Pro změnu úrovně integrity, provedenou jako změna mandatory label, potřebuje daný uživatel rovněž privilegium „Měnit oprávnění“ a „Přebírat vlastnictví“.

■

Uživatelé s oprávněním SeRelabelPrivilege mohou úroveň integrity zvyšovat nebo snižovat, ale nemohou povýšit úroveň integrity nad tu, kterou vlastní oni sami.

Proberme nyní postupně jednotlivé body, abychom si mohli začít hrát s úrovněmi integrity.

Nové oprávnění „měnit vlastnosti označení objektu“ Připomeňme si, že povinné řízení, tak jak bylo popsáno v Orange Book a podobných standardech, může mít různé úrovně své „povinnosti“. V té nejslabší formě se může jednat jen o jednoduchá pravidla vytvořená správcem, která omezují výběrová oprávnění standardních uživatelů; opačným extrémem jsou ocelově tvrdá pravidla vestavěná přímo do operačního systému, která nemůže změ-

170

Kapitola 4 – Kontrola integrity windows

nit vůbec nikdo. Implementace řízení integrity ve Windows je někde mezi těmito oběma extrémy a umožňuje správcům systému implicitní pravidla poněkud uvolnit nebo zpřísnit. Přímo z výroby je řízení integrity Windows ve Vistě velmi umírněné – má-li něco nastavenu střední úroveň integrity, nebude se tato úroveň měnit. To se však změní, jakmile udělíte někomu právo měnit úrovně integrity – a proč byste tím někým nemohli být právě vy? Proč si toto právo neudělit? Anglický název nového privilegia je „Modify an object label“ (změnit označení objektu), krátký název je SeRelabelPrivilege. Jak se dá toto privilegium získat? VAROVÁNÍ:

Pro změnu svých uživatelských oprávnění potřebujete účet místního správce, což platí již od dob Windows 2000. Jestliže je váš testovací počítač členem domény Active Directory a správce domény uzamknul vaše oprávnění, budete si s ním muset promluvit, vystačit si se sledováním sejmutých obrazovek v této knize, nebo si připravit samostatný testovací systém, který není členem domény. Osobně pro podobné testy doporučuji virtuální počítače, a firmy Microsoft a VMWare nabízí pro tyto účely vynikající a bezplatné správce virtuálních počítačů. Přednost dávám aplikaci VMWare Workstation, i když ta není zdarma a její cena patří mezi vyšší (190 dolarů). Ovšem vynaložené peníze se mi již mnohokrát vrátily…

1. Otevřete na svém systému lokální Editor zásad skupiny. (Zapište v okně příkazového řádku gpedit.msc nebo postupně klepněte na Start  Všechny programy  Příslušenství  Spustit…, zde zapište gpedit.msc a klepněte na tlačítko OK. 2. V zobrazeném dialogu Consent UI klepněte na tlačítko Pokračovat (platí jen v případě, kdy jste nevypnuli UAC nebo nespustili gpedit.msc z příkazového řádku s právy správce. 3. Přejděte do větve Konfigurace počítače  Nastavení systému Windows  Nastavení zabezpečení  Místní zásady  Přiřazení uživatelských práv. 4. Posouvejte obsah okna dolů, dokud nenajdete „Změnit označení objektu“. Poklepejte na tuto zásadu. 5. Ve výsledném dialogovém okně „Změnit označení objektu – vlastnosti“ klepněte na tlačítko Přidat uživatele nebo skupinu. 6. Ve výsledném poli s popiskem „Zadejte názvy objektů k výběru“ zapište své uživatelské jméno, nebo sem případně zapište natvrdo Administrators a dejte tak toto oprávnění všem lokálním správcům. (Pokud však zapíšete skupinu Administrators, nezapomeňte klepnout na tlačítko Typy objektů po pravé straně dialogového okna a poté zapněte tlačítko Skupiny. Z určitého důvodu je implicitně oblast zásad skupin User Rights Assignment nastavena tak, že přebírá jen jména účtů jednotlivců, nikoli skupin. Teprve po zapnutí tohoto políčka je možné zapsat i název skupiny.) Postupně se klepáním na tlačítka OK vraťte se do okna Editoru objektů zásad skupiny. 7. Zavřete Editor objektů zásad skupiny. Nyní má váš účet přidělené oprávnění, ale nemáte ještě potřebný token. Musíte se proto odhlásit a přihlásit, aby Windows mohli do vašeho tokenu přidat nové oprávnění.

Součásti WIC

171

Oprávnění potřebná pro změnu úrovně integrity Než budete moci změnit úroveň integrity, potřebujete určitá oprávnění – ale kolik a jaká to jsou? Připomeňme si, že úrovně integrity jsou implementovány jako položky řízení přístupu k systému a „položka řízení přístupu“ je jen jiný výraz pro „oprávnění“. Možná také víte, že soubory mají 12 typů nízkoúrovňových oprávnění (složky 13), a u souborů i složek existují specifická oprávnění s názvy „Číst oprávnění“ a „Měnit oprávnění“ – tedy oprávnění k oprávněním. Nemůže být tedy pro vás žádným překvapením, že k přečtení úrovně integrity objektu potřebujete jen oprávnění „Číst oprávnění“. Změna úrovně integrity je však něco trochu jiného. Zde potřebujete oprávnění „Měnit oprávnění“ – to je jasné – ale také oprávnění „Přebírat vlastnictví“. Proč? Protože jedním z oněch zmíněných 12 (nebo 13) nízkoúrovňových oprávnění je právě „Přebírat vlastnictví“. Proto každý, kdo může změnit oprávnění objektu, může převzít vlastnictví souboru, a vlastnictví je už dost silný šálek kávy. Vista proto vyžaduje pro změnu úrovně integrity nejen oprávnění „Měnit oprávnění“, ale také oprávnění „Přebírat vlastnictví“.

Změna integrity objektu pomocí nástroje chml Jakmile získáte oprávnění SeRelabelPrivilege a máte dostatečná další oprávnění (už je máte, proto není potřeba v tomto případě nic dělat), můžeme začít testovat nástroj chml.exe. Ten jste si umístili do složky C:\Windows, takže je v systémové cestě. Tentokrát však nebudeme úrovně integrity jen prohlížet, ale změníme je. V rámci tohoto cvičení budeme mít nadále nastavenu složku C:\pokusy jako pracovní. Otevřete okno příkazového řádku právy správce a dále okno příkazového řádku s tokenem standardního uživatele, a v obou oknech příkazem cd \pokusy přejděte do složky C:\pokusy. Poté ze souboru vistafiles.zip (ten jste si stáhli v druhé kapitole z adresy http://www.minasi.com/vista) rozbalte program createfile a postupujte podle následujících bodů: 1. V okně příkazového řádku bez práv správce zapište createfile hltest.txt a stiskněte Enter. Tím jste vytvořili jednoduchý textový soubor hltest.txt. 2. Otevřete tento soubor v Poznámkovém bloku a zkontrolujte, zda můžete změnit jeho obsah. (Přepište jeden či dva znaky, uložte soubor a zavřete Poznámkový blok. 3. Nyní příkazem chml hltest.txt -b zjistěte jeho úroveň integrity. Uvidíte, že má přiřazenu střední úroveň integrity, protože jsme mu prozatím nepřidělili mandatory label. 4. Nyní se přepněte do okna příkazového řádku s právy správce. 5. Zvyšte úroveň integrity souboru hltest.txt na vysokou (high) příkazem chml hltest.txt -i:h -b a následným stiskem Enteru. Nástroj chml by měl reagovat hlášením Integrity level of hltest.txt successfully set to high.

POZNÁMKA:

Syntaxe příkazu chml pro změnu úrovně integrity vypadá takto: „chml jménosouboru -i: úroveň“. Jako úroveň lze zadat u, l, m, h nebo s (untrusted, low, medium, high, system). Volba „s“ však nebude fungovat, protože vy jako správce máte jen úroveň integrity „high“. (Zařadil jsem ji do programu jen proto, že se mi snad někdy podaří vyřešit, jak ji zprovoznit.

172

Kapitola 4 – Kontrola integrity windows

6. V nástroji icacls si ověřte, že jste skutečně zvýšili úroveň integrity souboru hltest.txt (spusťte příkaz icacls hltest.txt a všimněte si řádku s popiskem „Mandatory Label/High Mandatory Level“). Obdobný test se dá provést i příkazem chml hltest.txt -b.

Změna integrity objektu pomocí nástroje icacls Nástroj icacls byl konečně od sestavení 5744 plně funkční. V této době jsem knihu ještě neměl dokončenou, mohu vám proto ukázat, jak se dá změnit úroveň integrity souboru nebo složky v tomto nástroji. Syntaxe vypadá takto: icacls jménosouboru /setintegritylevel H|M|L

Na tento příkaz icacls odpoví výpisem Zpracovaný soubor: jménosouboru Počet úspěšně zpracovaných souborů: 1; Počet souborů, které nelze zpracovat: 0.

Pro nastavení nízké úrovně integrity souboru hltest.txt je tedy nutné spustit příkaz icacls hltest.txt /setintegritylevel L

Obdobně jako u chml i zde je nutné pro úspěšnou změnu úrovně integrity vlastnit oprávnění SeRelabelPrivilege, mít spuštěn příkazový řádek s právy správce a mít oprávnění „Měnit oprávnění“ a „Přebírat vlastnictví“ k souboru hltest.txt.

Testování základní direktivy WIC Úplně na začátku tohoto tématu jsem napsal, že hlavním přínosem WIC je to, že procesy nižší úrovně integrity nemohou měnit objekty s vyšší úrovní. Právě jsme vytvořili soubor s vysokou úrovní integrity, můžeme tedy prozkoumat, co se bude dít při pokusech o neoprávněné změny v tomto souboru. 1. Spusťte Poznámkový blok přes nabídku Start (nikoli z okna příkazového řádku s právy správce) a otevřete soubor C:\pokusy\hltest.txt. Poznámkový blok má přidělen token uživatele se standardním oprávněním (za předpokladu, že jste nevypnuli UAC – pokud ano, nebude vám fungovat většina zde uváděných příkladů…) Omlouvám se, že ženu trochu rychle dopředu, ale věřte mi, že Poznámkový blok nyní běží na střední úrovní integrity. 2. Upravte text souboru. 3. V nabídce Soubor klepněte na tlačítko Uložit. Poznámkový blok si postěžuje, že „Soubor C:\pokusy\hltest.txt nelze vytvořit. Ujistěte se, že cesta i název souboru jsou správné“. To je velmi nejasné hlášení, které ve skutečnosti znamená: „operační systém mi při pokusu o zápis nové verze souboru hltest.txt oznámil, že mám odepřen přístup“. Dále si ukážeme, že Poznámkový blok může uložit změněnou verzi souboru hltest.txt, ale musí mít správnou úroveň integrity. 4. Tlačítkem OK zavřete chybové hlášení, klávesou Esc zrušte dialogové okno Uložit jako a zavřete Poznámkový blok, přičemž dotaz na uložení změn zavřete tlačítkem „Neukládat“.

Součásti WIC

173

5. Nyní spustíme Poznámkový blok jinak. V nabídce Start zvolte postupně Všechny programy  Příslušenství, pravým tlačítkem myši klepněte na položku Poznámkový blok a v místní nabídce vyberte příkaz „Spustit jako správce“. 6. Výzvu UAC zavřete tlačítkem Pokračovat. Opět si toto probereme později podrobněji, ale zatím mi věřte, že Poznámkový blok je nyní spuštěn s vysokou úrovní integrity. 7. Otevřete souboru C:\pokusy\hltest.txt. 8. Znovu upravte text. 9. Klepněte na příkaz Soubor  Uložit. Tentokrát nebude oznámena žádná chyba, protože proces (Poznámkový blok) má stejnou nebo vyšší úroveň integrity než objekt (hltest.txt). 10. Ukončete Poznámkový blok. Shrňme si nyní, co jsme viděli v této sekci a co jste si procvičili: ■

Úroveň integrity objektu je možné snížit nebo zvýšit, máte-li uděleno oprávnění SeRelabelPrivilege a jste přihlášen jako správce. Okno příkazového řádku musí být spuštěno příkazem „Spustit jako správce“, protože oprávnění SeRelabelPrivilege patří mezi Notoricky Známou Devítku, která je z vašeho tokenu uživatele se standardním oprávněním odebrána.

■

Pro změnu i prohlížení úrovně integrity objektu musíte k němu mít oprávnění „Číst oprávnění“, „Měnit oprávnění“ a „Přebírat vlastnictví“.

■

Změna úrovně integrity se dá provést v nástrojích chml nebo icacls.

■

Úroveň integrity objektu je možné zvýšit maximálně na tu úroveň integrity, kterou máte vy sami.

Mimochodem, pokud si pročtete některý z nejdříve vydaných materiálů Microsoftu o Řízení integrity Windows, možná jste se tam dočetli, že uživatelé s oprávněním „změnit označení objektu“ mohou úroveň integrity jen snížit. Toto platilo u prvních beta verzí Visty, nyní už to neplatí. Jak se dozvíte později, může uživatel získat nejvýše úroveň integrity High (Vysoká), proto není možné u žádného objektu zvýšit úroveň integrity nad tuto úroveň. VAROVÁNÍ:

Vím přesně, na co teď mnozí „bezpečnostní experti“ mezi vámi myslí: „Nemám problém, prostě příkaz pro změnu úrovně integrity naplánuji jako úlohu a nechám ho spustit příkazem at.exe – ten běží pod účtem LocalSystem, který má systémovou úroveň integrity a může proto zvýšit úroveň integrity jak chce až na úroveň systému. Anebo ho zkusím spustit v přihlašovacím skriptu, ten rovněž běží pod účtem LocalSystem“. Zapomeňte na to. V Microsoftu očividně četli několik známých knih s návody „jak hacknout Windows“ a tyto díry bezpečně ucpali. Domnívám se, že by možná šlo napsat službu – služby mají také systémovou úroveň integrity – ale nejsem tak dobrý programátor, abych se do toho pustil. Kromě toho mám dojem, že na to v Microsoftu mysleli také.

Výchozí složky s nízkou úrovní integrity Než se přesuneme dál k průzkumu toho, jak uživatelé a procesy získávají úrovně integrity, rád bych zmínil pár případů, kde návrháři Visty využili své schopnosti a explicitně nastavili úrovně integrity u složek. Udělali to proto, aby podpořili Chráněný režim Internet Exploreru:

174

Kapitola 4 – Kontrola integrity windows

■

\Users\ jméno uživatele \AppData\LocalLow,

■

\Users\ jméno uživatele \AppData\Local\Temp\Low a ještě

■

několik objektů v souboru \Users\ jméno uživatele \AppData\Local\Microsoft\Temporary Internet Files \Low (jedná se o systémový soubor, který normálně nevidíte)

Úrovně integrity uživatelů Po výkladu získávání a ukládání úrovní integrity u objektů nyní přijdou na řadu uživatelské účty. Podíváme se, odkud berou své úrovně integrity.

Úrovně integrity uživatelů závisí výhradně na oprávněních Pokud je mi známo, uživatelé systému Vista mohou získat jen vysokou či střední úroveň integrity, i když si umím představit případy, kdy se někdo přihlásí k Vistě anonymně a v tom případě by dostal nejnižší úroveň integrity „untrusted“. Kterou z těch dvou ale dostanete, vysokou nebo střední? V zásadě platí, že uživatel s tokenem standardního uživatele bude mít přidělenu střední úroveň integrity, a uživatel s tokenem plného přístupu správce dostane vysokou úroveň integrity. Ale proč to tak probíhá? Vzpomeňte si na druhou kapitolu, kde byla řeč o tom, že Řízení uživatelských účtů rozdělí token uživatele, který se přihlásí jako člen jedné lokální skupiny Proslulé Čtyřky nebo jako uživatel s jedním z Notoricky Známé Devítky oprávnění. Očekával jsem proto, že když úplně vypnu UAC, vytvořím uživatele a přidám ho – dejme tomu – do skupiny Network Configuration Operators (jedna z Proslulé Čtyřky), budu mít po přihlášení na účet tohoto uživatele vysokou úroveň integrity. (Za chvíli ukážu, jak si zjistíte vlastní úroveň integrity.) Byl jsem překvapen, když jsem zjistil, že daný účet má střední úroveň integrity. Stejný výsledek mělo i přidání účtu uživatele do skupiny Power Users – další člen Proslulé Čtyřky. Člen skupin Power Users a Network Configuration Operators má prostě přidělenu střední úroveň integrity. Když ale přidáte uživatelské účty do skupin Backup Operators nebo Administrators, jejich úroveň integrity poskočí výš… a je vysoká. Pravidla pro přidělování úrovně integrity uživatelům jsou tedy dost jednoduchá: ■

Při určování úrovně integrity vašeho uživatelského účtu není brán ohled na členství ve skupinách. Členové Proslulé Čtyřky nehrají žádnou roli, protože…

■

Rozhodující je sada uživatelských oprávnění, které získáte. Jestliže váš uživatelský účet zahrnuje libovolné oprávnění Notoricky Známé Devítky, obdržíte při přihlášení vysokou úroveň integrity pro danou relaci a všechny následné relace. V opačném případě bude vaše úroveň integrity střední.

Kde jsou ukládány úrovně integrity uživatelů Přestože uživatelské účty patří mezi ochranitelné (securable) objekty, nezdá se, že by existoval nějaký způsob, jak na ně aplikovat mandatory labels. Kam si tedy uživatelské účty ukládají úrovně integrity? Vista přiřadí úroveň integrity tokenu uživatele při jeho přihlášení. Ve druhé kapitole bylo uvedeno, že během přihlašování získáte token obsahující

Součásti WIC

■

Váš SID

■

SIDy všech globálních a universálních skupin, jejichž členy jste

■

Vaše oprávnění

175

Jak jsem stručně zmínil ve druhé kapitole, Vista rovněž označí váš token střední či vysokou úrovní integrity (teoreticky i jinak). Toto značení je provedeno přidáním jakéhosi „falešného“ SID skupiny k identifikátorům SID vašich skupin v tokenu. Zatímco mnohé SIDy jsou dlouhé řetězce čísel, „SID integrity“ vypadá mnohem jednodušeji: S-1-16-hodnota

Jako hodnota je uvedeno doplňkové číslo. V tabulce 4.1 najdete tyto hodnoty vyjmenovány: 0 platí pro nejnižší nedůvěryhodnou úroveň integrity, 4096 vyjadřuje nízkou úroveň integrity, 8192 střední, 12288 vysokou a 16384 systémovou. Ale odkud se tato čísla vzala? Ti z vás, kteří často převádějí čísla z desítkové do šestnáctkové soustavy a naopak, si určitě rychle vzpomenou. Řada čísel 0, 4096, 8192, 12288 a 16384 sice není na první pohled nijak souvislá, ale když je převedeme do hexadecimální soustavy, dostaneme 0, 1000, 2000, 3000 a 4000 – a to už je jasná řada! Konečně se dostáváme ke skrytému úložišti naší úrovně integrity.

Prohlížení úrovní integrity uživatelů Svou aktuální úroveň integrity si můžete prohlédnout v nástroji příkazového řádku whoami (se kterým jsme se již setkali ve druhé kapitole), spuštěný buď s přepínači /group s nebo /all. Jsem-li například přihlášen k systému Vista, mohu spustit nepovýšené okno příkazového řádku a v něm spustit příkaz whoami /groups /fo list

Ve výstupu uvidím mj. toto: Název skupiny: Mandatory Label\Medium Mandatory Level Typ: Neznámý typ identifikátoru zabezpečení SID: S-1-16-8192 Atributy: Povinná skupina, Ve výchozím nastavení povoleno, Povolená skupina

Příkaz whoami to označuje jako „skupinu“ a odkazuje se na její jméno nám již známým řetězcem „Mandatory Label\Medium Mandatory Level“ nebo trochu rozvleklým vyjádřením střední úrovně integrity. Všimnete si také identifikátoru SID 8192; toto číslo lze najít v tabulce 4.1, kde je přidruženo střední úrovni integrity. Zkuste si to na svém počítači s Vistou sami. Jakmile uvidíte SID s hodnotou S-1-16-8192, vyvolejte okno příkazového řádku s právy správce a příkaz zopakujte; tentokrát se ukáže S-1-16-12288

Úrovně integrity procesů Víme-li, že podle Hlavní direktivy Řízení integrity Windows nesmí žádný proces nikdy změnit objekt s vyšší úrovní integrity, hrají větší roli ve WIC úrovně integrity procesů, nikoli uživatelů, proto se nyní na ně podívejme.

176

Kapitola 4 – Kontrola integrity windows

Jak procesy získávají své úrovně integrity Tokeny procesů vznikají smícháním dvou věcí, které jsme v této knize již probírali. Ve druhé kapitole byla řeč o tom, že procesy v podstatě získávají své tokeny od toho, kdo je spustil; Jestliže je Word spuštěn Honzou, přihlášeným na účet standardního uživatele se střední úrovní integrity, bude mít Word obvykle přidělen též token se střední úrovní integrity. Vzpomeňte si ale, že proces není nic jiného než kopie souboru EXE běžícího v paměti, a v této kapitole jste se naučili, že každý soubor může mít úroveň integrity zabudovánu přímo v sobě. Vista při spuštění procesu používá pro určení přidělení úrovně integrity následující algoritmus. ■

Pravidlo 1: Jestliže proces spustí někdo s vysokou úrovní integrity, proces poběží s touto (vysokou) úrovní.

■

Pravidlo 2: pokud spustíte proces příkazem „Spustit jako správce“, poběží proces s vysokou úrovní integrity.

Jste-li však při spouštění procesu přihlášen jako standardní uživatel, pravidla se poněkud změní. ■

Pravidlo 3: Jestliže proces spustí standardní uživatel, proces buď získá úroveň integrity rovnou jednomu z tokenů (střední), nebo svého souboru EXE (ta je nižší).

■

Pravidlo 4: proces může vždy spustit jiný proces s nižší úrovní integrity, aby však mohl spustit proces s vyšší úrovní integrity, potřebuje k tomu souhlas uživatele, vyjádřený prostřednictvím UAC.

Vysvětlíme si to na několika příkladech: Příklad 1: „Spustit jako správce Pravým tlačítkem myši klepnu na ikonu Poznámkového bloku a v místní nabídce vyberu příkaz „Spustit jako správce“. Objeví se dialog Consent UI, ve kterém klepnu na Pokračovat. Poznámkový blok běží s vysokou úrovní integrity. Příklad 2: Spuštěn správcem Dejme tomu, že jsem přihlášen k Vistě jako člen místní skupiny Administrators. Poklepu na ikoně Poznámkového bloku. Co se stane? Za předpokladu, že máte zapnuté UAC, máte rozdělený token; pokud nepožádáte o zvýšení práv, dostane Poznámkový blok token uživatele se standardním oprávněním. Skutečný soubor notepad.exe nemá mandatory label a proto získá střední úroveň integrity. Vzhledem k tomu, že token uživatele se standardním oprávněním i samotný soubor EXE mají střední úroveň integrity, běží proces – Poznámkový blok – ve střední úrovni integrity. Příklad 3: Spuštěn z příkazového řádku s právy správce Spustil jsem okno příkazového řádku (příkazem „Spustit jako správce“ v místní nabídce zástupce) a dialog Consent UI zavřel tlačítkem Pokračovat. V okně příkazového řádku jsem zapsal notepad a stisknul Enter. Co se stane? Poznámkový blok bude spuštěn v okně příkazového řádku s právy správce, proto zdědí můj token „vysoké integrity“ se SID S-1-16-12288. Do hry vstupuje pravidlo č. 1, proto Poznámkový blok poběží s vysokou úrovní integrity. Příklad 4: Spuštění souboru EXE s nízkou úrovní integrity Dejme tomu, že jsem pomocí nástroje icacls nebo chml souboru EXE přiřadil nízkou úroveň integrity. Pracuji s tokenem standardního uživatele a poklepu na ikonu tohoto programu (nevybírám tedy příkaz „Spustit jako správce“ v místní nabídce). Vista nyní musí spustit proces, který zdědí token střední úrovně integrity, ale

Součásti WIC

177

jeho soubor EXE má přidělenu integritu nízkou. Co se stane? Proces poběží s nízkou úrovní integrity. Za chvíli si toto ověříme v několika cvičeních, ale ještě předtím uvedu opět pár technických detailů.

Prohlížení úrovní integrity procesů Kde si proces ukládá svou úroveň integrity a jak se dá zobrazit? Je jasné, že proces má svou úroveň integrity uloženu ve svém souboru EXE, ale jak jsme viděli před chvílí, toto je pouze jeden z faktorů, podílející se na určení konečné úrovně integrity, kterou získá. Proces navíc získává různé úroveň integrity v různý čas, to záleží na osobě spouštějícího a způsobu spuštění. Nestačí tedy se jen podívat na mandatory label souboru EXE. Proces si ukládá svou úroveň integrity ve svém tokenu, který může při každém spuštění vypadat jinak. Chcete-li tedy vidět aktuální úroveň integrity procesu, musíte prozkoumat jeho token, umístěný jen v operační paměti počítače. POZNÁMKA:

To samozřejmě neplatí v případě, kdy je aplikace napsána tak, že umí načíst svůj vlastní token a po zadání určitého příkazu ho vypsat. Jediná taková aplikace, kterou znám, je whoami.exe.

Jestliže vás napadlo, že úrovně integrity budou zobrazitelné ve Správci úloh, nebyl to špatný nápad, ale bohužel Správce úloh toto nedokáže. Musíme tedy vymyslet něco jiného. Programování aplikace, která umí zkoumat tokeny v RAM, by bylo nejspíše velmi zajímavým cvičením, ale naštěstí není nutné se do toho pouštět, protože Mark Russinovich již napsal Process Explorer, který si můžete stáhnout na adrese http://www.microsoft.com/technet/sysinternals/utilities/ProcessExplorer.mspx. Spusťte tento nástroj příkazem „Spustit jako správce“, jinak nebude mít potřebná oprávnění pro nahlížení na jiné procesy. Okno běžícího Process Exploreru vidíte na obrázku 4.2. OBRÁZEK 4.2: Spuštěný Process Explorer v prostředí operačního systému Vista

178

Kapitola 4 – Kontrola integrity windows

Vaše kopie Process Exploreru bude vypadat trochu jinak, vzhledu z obrázku se dá dosáhnout úpravou počtu sloupců (příkaz View – Select Columns). Já jsem zapnul navíc sloupce „Integrity Level“ a „Virtualized“. (V této kapitole s virtualizací nepracujeme, ale tento sloupec vás může zajímat v souvislosti s předchozí kapitolou. Ve sloupci je vyznačeno, zda daný proces využívá virtualizaci souborů a registru.) Všimněte si, že na mém počítači běžely procesy s úrovní nízkou (Internet Explorer), střední, vysokou a systémovou.

Sledování běžících procesů Po hlubším seznámení se způsoby, kterými objekty, uživatelé a procesy získávají své úrovně integrity, se pokusíme je vyzkoušet, abychom viděli, jak to funguje v praxi. Následuje několik postupných demonstrací úrovní integrity u procesů.

Příprava Postup provádění příkladů je téměř stejný jako u předchozích ukázek. Kromě systému budete potřebovat chml.exe a Process Explorer. Až je budete mít nainstalované, můžete se pustit do následujících bodů: 1. Otevřete dvě okna příkazového řádku: jedno s právy správce, druhé nepovýšené. 2. V obou oknech změňte pracovní složku na C:\pokusy. 3. Spusťte Process s tokenem vysoké integrity (v místní nabídce jeho položky vyberte příkaz „Spustit jako správce“). 4. Prohlédněte si v okně Process Exploreru výchozí nastavení příkladu. Uvidíte tu dvě instance cmd.exe neboli okna příkazového řádku. Jedna bude běžet se střední úrovní integrity, druhá s vysokou.

Příklad: Spuštění aplikace s nízkou úrovní integrity Nyní si ukážeme, jak vytvořit proces s nízkou úrovní integrity, a zároveň vám dokážu, že úroveň integrity samotného souboru EXE není někdy jediným rozhodujícím činitelem pro stanovení výsledné úrovně integrity procesu. Kupodivu neexistuje žádný jednoduchý nástroj příkazového řádku pro spuštění libovolné aplikace coby procesu s nízkou integritou – osobně bych očekával, že cmd.exe nebo příkaz start budou mít takovou možnost implementovánu jako přepínač. Naštěstí však máme nástroj, který to umí: chml. 1. V okně příkazového řádku s právy správce zkopírujte cmd.exe do složky pokusy (zapište příkaz copy C:\windows\system32/cmd.exe a stiskněte Enter. 2. Poté vytvořte ještě několik dalších kopií příkazy copy cmd.exe lcmd.exe copy cmd.exe hcmd.exe

Sledování běžících procesů

179

3. Dále nastavte jejich mandatory labels na hodnoty „low“ a „high“ pomocí příkazů chml lcmd.exe -i:l -b chml hcmd.exe -i:h -b

Není-li to ze zápisu díky použitému fontu zcela jasné, za přepínačem -i: prvního příkazu chml je malé „L“. Oba příkazy by měly projít bez chyby, pokud je spustíte v okně příkazového řádku s právy správce. Nyní máme k dispozici cmd.exe s vysokou úrovní integrity a druhou kopii téhož souboru s nízkou úrovní integrity. V okně příkazového řádku s právy standardního uživatele zapište hcmd a stiskněte Enter. Výstup bude obsahovat jen jeden či dva řádky s copyrightem a informacemi o verzi Windows: Microsoft Windows [Version 6.0.9421] Copyright © 2006 Microsoft Corporation. Všechna práva vyhrazena. C:\pokusy>

V prostředí příkazového řádku se střední úrovní integrity jsme spustili kopii příkazového řádku, jehož soubor má vysokou úroveň integrity… jakou úroveň integrity bude tento nový proces mít? Logicky sice očekáváme, že cokoli spuštěného z procesu se střední úrovní integrity nedokáže získat vyšší úroveň než tuto, protože UAC nezobrazil potvrzovací dialog Consent UI, ale pro jistotu si to zkontrolujeme: zapište whoami /groups /fo list a stiskněte Enter. Co se stane? Jako poslední bude nejspíše vypsána sekce Mandatory Label, kde vidíme hlášení „Mandatory Label\Medium Mandatory Label“, takže vše funguje dle očekávání a vidíme, že soubor hcmd.exe byl spuštěn se střední úrovní integrity nezávisle na své přidělené úrovni. 4. Nyní zkusíme lcmd; V okně příkazového řádku s právy standardního uživatele, ve kterém jsme před chvílí spustili příkaz whoami, zapište lcmd a stiskněte Enter. Opět uvidíte hlášení o copyrightu a údaje o verzi Windows, za kterými bude následovat výzva příkazového řádku. Za výzvu opět zapište whoami /groups /fo list a stiskněte Enter. Co jste uviděli tentokrát? Pokud vše proběhlo dobře, uvidíte v poslední skupině řádek „Mandatory Label\Low Mandatory Label“ a SID ve tvaru S-1-16-4096. Mise splněna, máme spuštěn příkazový řádek s nízkou úrovní integrity! TIP:

Mimochodem, pokud nechcete při spouštění příkazu whoami /groups /fo list vyhledávat v delším vypsaném seznamu skupin tu s popiskem „Mandatory Label“, upravte příkaz do tvaru whoami /groups /fo list | find “Label”. Filtr „find“ rozlišuje malá a velká písmena, proto napište „Label“, nikoli „label“.

Chráněný režim Internet Exploreru a WIC Určitě už víte, že Internet Explorer 7, který je součástí Visty, obsahuje funkci označovanou jako „Chráněný režim“, která je podle mých současných vědomostí jedním z hlavních důvodů toho, že služba Řízení integrity Windows existuje.

180

Kapitola 4 – Kontrola integrity windows

Internet Explorer 7 ve Vistě – to „ve Vistě“ je zde obzvláště důležité, protože IE 7 běžící na systémech XP SP2, 2003 SP1 a 2003 R2 se takto nechová – je rozdělen do dvou samostatných procesů iexplore.exe a ieuser.exe. (Najděte si o pár stránek zpět obrázek 4.2, tam jsou oba procesy vidět.) Soubor iexplore.exe má přidělenu nízkou úroveň integrity, soubor ieuser.exe střední. Většinu surfování na Internetu probíhá v procesu iexplore.exe, který nesmí zapisovat jinam než do složky Temporary Internet Files a dalších složek s nízkou úrovní integrity, které jsem vyjmenoval v předchozím textu. Toto platí i pro doplňky IE 7, takže i když byste si nahráli jako doplněk nějaký škodlivý kód, běžel by jen s nízkou úrovní integrity a jeho schopnosti něco poškodit by byly velmi omezené – mohl by však číst libovolný soubor, ke kterému by měl prostřednictvím seznamu výběrových oprávnění čtení. (Později uvidíte, jak se toto dá změnit a tak trochu posílat zabezpečení počítače.) Dále platí, že IE 7 implicitně nenahraje do paměti žádný nepodepsaný ovládací prvek ActiveX, takže i zde platí, že v případě spuštění škodlivého kódu budete vědět, kdo je jeho tvůrcem! Microsoft sice horlivě vychvaluje všechny tyto přednosti nového Internet Exploreru 7, ale už moc nezdůrazňuje, že všechny tyto ochrany jsou aktivní jen v případě, kdy Internet Explorer běží v Chráněném režimu, proto se třeba si dávat bedlivý pozor, pokud v tomto režimu náhodou nejste. Aby bylo jasné, co mám na mysli, podívejte se na obrázek 4.3. To podstatné je tu vidět ve spodní části obrázku, ve stavovém řádku Internet Explorer, kde vidíte panel s nápisem „Chráněný režim: Zapnuto“. Režim je implicitně zapnut, je ale možné ho vypnout v dialogovém okně Nástroje – Možnosti Internetu, kde na stránce vlastností Zabezpečení najdete volby z obrázku 4.4. OBRÁZEK 4.3: Internet Explorer 7 v Chráněném režimu

Sledování běžících procesů

181

OBRÁZEK 4.4: Povolení/zákaz Chráněného režimu Internet Exploreru 7

Obsah obrázku vypadá na první pohled stejně jako stránka Zabezpečení ve starších verzích Internet Exploreru, ale když se podíváte pod jezdce na levé straně obrázku, najdete tam zaškrtávací políčko „Povolit chráněný režim (vyžaduje restartování aplikace Internet Explorer)“. Jeho vypnutí je velmi snadné, ovšem vaši uživatelé by ho rozhodně vypínat neměli. Myslím, že nebude dlouho trvat a objeví se weby zkoušející nalákat uživatele k vypnutí Chráněného režimu pobídkami typu „je nám líto, ale ty fotky nahotinek neuvidíte, protože je blokuje Chráněný režim Internet Exploreru. Vypněte ho prosím tímto způsobem…“ Uživatelům se naštěstí dá tato změna nastavení prohlížeče zakázat, a to zapnutím zásady skupiny Konfigurace počítače  Šablony pro správu  Součásti systému Windows  Internet Explorer  Ovládací panel Možnosti Internetu  Stránka Zabezpečení  Zóna Internet  Zapnout chráněný režim. Pomocí našich dvou oken příkazového řádku z předchozího příkladu, která máme stále spuštěna, si můžeme ověřit hlavní důsledek vypnutí Chráněného režimu: iexplore.exe již nepoběží jako proces s nízkou úrovní integrity: 1. Spusťte Internet Explorer. 2. Podívejte se v Process Exploreru (jestliže jste ho již vypnuli, spusťte ho znovu s právy správce) a najděte si soubor iexplore.exe, který tu bude mít uvedenu nízkou úroveň integrity. 3. Poté v Internet Exploreru klepněte v nabídce Nástroje na Možnosti Internetu a přepněte se na stránku vlastností Zabezpečení. 4. Vypněte zaškrtávací políčko „Povolit chráněný režim (vyžaduje restartování aplikace Internet Explorer)“. 5. Klepněte na tlačítko OK a poté tlačítkem OK zavřete následně zobrazené okno hlášení, které říká „Při aktuálním nastavení zabezpečení bude váš počítač ohrožen“.

182

Kapitola 4 – Kontrola integrity windows

6. Zavřete a znovu spusťte IE. 7. V Process Exploreru načtěte znovu klávesou F5 informace o procesech. 8. Sami si nyní můžete ověřit, že s vypnutým Chráněným režimem běží obě komponenty IE se střední úrovní integrity. Co je tu nutné dvakrát podtrhnout, je fakt, že vypnutím Chráněného režimu Internet Exploreru v podstatě eliminujete tu největší část vylepšeného zabezpečení Visty, které chrání proti spywaru a jinému škodlivému kódu. Pokud potřebujete otevírat specifické webové stránky, nefungující v Chráněném režimu, zařaďte je do zóny Důvěryhodné servery. Když se znovu podíváte na stránku Zabezpečení v dialogu Možnosti Internetu, najdete nahoře několik zón zabezpečení (Internet, Místní intranet, Důvěryhodné servery a Servery s omezeným přístupem). Pro každou z nich je možné samostatně zapnout či vypnout Chráněný režim a jak si sami snadno ověříte, zóna Důvěryhodné servery má implicitně Chráněný režim vypnut. TIP:

Další možnost, jak vypnout Chráněný režim, představuje spuštění Internet Exploreru v okně příkazového řádku s právy správce.

Rébus základní direktivy: WIC a mazání souborů Pamatujete si ještě, co jsem označil jako Hlavní Direktivu Řízení integrity Windows? Je to zásada, podle které žádný proces nesmí změnit objekt s vyšší úrovní integrity. Prakticky jsme si to předvedli na příkladu, ve kterém jsme vytvořili soubor hltest.txt, nastavili mu vysokou úroveň integrity a poté ho otevřeli v Poznámkovém bloku. Kdy jsme se poté pokusili změněný soubor uložit, nešlo to, protože Poznámkový blok byl spuštěn jako proces se střední úrovní integrity a pokoušel se změnit proces běžící na vysoké úrovni integrity. Byla to velmi pěkná ukázka Hlavní direktivy. Teď ale zkuste něco jiného. Pokud máte hltest.txt stále někde uložen, je to dobře; v opačném případě zopakujte potřebné kroky zadané ve starším cvičení. Poté spusťte okno příkazového řádku s tokenem standardního uživatele a v něm: 1. Zapište whoami /groups /fo | find “Label” a stiskněte Enter. Tak si ověříte, zda máte přidělenu střední úroveň integrity. 2. Složku C:\pokusy jste vytvořili vy, můžete si tedy k ní udělit oprávnění Úplné řízení. Zapište příkaz icacls C:\pokusy/grant vašejméno:(f) a stiskněte Enter. 3. Na závěr zapište erase hltest.txt a stiskněte Enter. Objevilo se hlášení „Přístup byl odepřen“? Ne! Vypište si obsah složky a uvidíte, že hltest.txt je pryč, pryč, skutečně pryč! Pro ty z vás, kteří knihu jen čtou a nezkoušejí, a jsou proto skeptičtí, přikládám obrázek 4.5, který vše dosvědčuje.

Testujeme oprávnění k mazání souborů v nástroji icacls Jak se to ksakru mohlo stát? Nejedná se o nějakou další novinku Visty ani její chybu, ale o starý známý fakt ze světa oprávnění: oprávnění smazat soubory je totiž volnější než většina ostatních

Sledování běžících procesů

183

oprávnění NTFS. Přestože je možné někomu velmi jednoduše a natrvalo zakázat čtení nějakého souboru aplikací jediné položky ACE na daný soubor, není toto možné provést u operace mazání souboru. OBRÁZEK 4.5: Proces střední úrovně integrity smazal objekt s vysokou úrovní integrity!

Uvádím ještě jeden příklad který si můžete vyzkoušet na libovolném operačním systému Windows, počínaje NT 3.1 a Vistou konče: 1. Vytvořte složku. 2. Protože jste vlastníkem složky, můžete si k této složce udělit oprávnění Úplné řízení; udělejte to. 3. Uvnitř této složky vytvořte soubor. 4. Protože jste soubor vytvořil, můžete si odebrat oprávnění ke smazání tohoto souboru; udělejte to. 5. Pokuste se vytvořený soubor smazat; podaří se vám to. Celý příklad můžete udělat přímo v GUI, ale kdybych tu měl přesně popisovat celý průběh příkladu, vystačilo by klepání na různá tlačítka a jiné ovládací prvky a přetahování objektů myší na několik stránek … kromě toho jsem milovníkem příkazového řádku. Pokud si tedy tento příklad chcete vyzkoušet, spusťte okno příkazového řádku s tokenem standardního uživatele a v něm zapište následující příkazy. Namísto „mark“ (název mého účtu uživatele) zapište název svého účtu. Jako pracovní adresář si nechte nastavenu složku C:\pokusy, abyste nemuseli zadávat celou cestu k souboru createfile. md C:\test icacls C:\test /grant mark:F createfile C:\test\killtest.txt

184

Kapitola 4 – Kontrola integrity windows

icacls C:\test\killtest.txt /deny mark:(D) erase C:\test\killtest.txt

Většinu příkazů není nutné vysvětlovat – md vytváří adresáře (od nástupu Windows 2000 jme si zvykli používat pro ně výraz „složky“), createfile vytvoří jednoduchý textový soubor, erase smaže soubor. Nástroj icacls umožňuje změnit oprávnění všech typů a jeho syntaxe vypadá takto: icacls názevobjektu /grant|/deny jménouživatele :oprávnění

Takový zápis vypadá dost nezvykle, proto si ho trochu rozebereme. Část názevobjektu je prostě název souboru nebo složky, kterou má icacls zpracovat. Přepínač /grant slouží pro vytvoření nového „povolujícího“ ACE, přepínačem /deny vytvoříme nové „zakazující“ ACE. Část jménouživatele říká, na koho se nová položka ACE vztahuje a – toto bude jediná problémová část – jako oprávnění zadáme jeden či více jedno- a dvouznakových „kódů“, které reprezentují jedno z dvanácti nízkoúrovňových oprávnění k souborům nebo jedno z třinácti nízkoúrovňových oprávnění ke složkám. Kódy jsou vyjmenovány v následující tabulce 4.2. TABULKA 4.2: Kódy oprávnění Pokud se vztahuje k souboru, znamená … Pokud se vztahuje ke složce, znamená …

Kód

Jde-li o spustitelný soubor, povol uživateli jeho spuštění

Vynechat kontrolu oprávnění při průchodu složkami

Oprávnění číst data v souboru

Oprávnění vypsat seznam souborů a slo- RD žek v dané složce

Oprávnění číst základní atributy souboru (systémový, skrytý, jen ke čtení, archivovat)

Oprávnění číst základní atributy složky (systémový, skrytý, jen ke čtení, archivovat)

Oprávnění měnit základní atributy Oprávnění měnit základní atributy souboru (systémový, skrytý, jen ke čtení, složky (systémový, skrytý, jen ke čtení, archivovat) archivovat)

Oprávnění číst rozšířené atributy souboru (autor, copyright, popis, hodnocení – v podstatě libovolné „značky“ neboli „metadata“ Visty)

Oprávnění číst rozšířené atributy složky (autor, copyright, popis, hodnocení – v podstatě libovolné „značky“ neboli „metadata“ Visty)

REA

Oprávnění měnit rozšířené atributy souboru (autor, copyright, popis, hodnocení – v podstatě libovolné „značky“ neboli „metadata“ Visty)

Oprávnění měnit rozšířené atributy slož- WEA ky (autor, copyright, popis, hodnocení – v podstatě libovolné „značky“ neboli „metadata“ Visty)

Oprávnění změnit oprávnění k danému souboru

Oprávnění změnit oprávnění k dané složce

WDAC

Oprávnění číst oprávnění k danému souboru

Oprávnění číst oprávnění k dané složce

Oprávnění smazat tento soubor

Oprávnění smazat tuto složku

Sledování běžících procesů Oprávnění zapisovat nebo měnit data v tomto souboru

Oprávnění vytvořit nový soubor v této složce

Oprávnění přidat data do existujícího souboru

Oprávnění vytvořit novou podsložku v dané složce

Oprávnění změnit vlastníka tohoto souboru

Oprávnění změnit vlastníka této složky

Oprávnění smazat soubory a složky v této složce (zkráceně „delete child“)

185

Při volání příkazu lze specifikovat víc oprávnění, které v tomto případě oddělíte čárkami. Chcete-li například přidělit účtu uživatele „jana“ možnost číst oprávnění, měnit oprávnění a přebírat vlastnictví (což je sada oprávnění potřebná pro změnu mandatory label), zapište icacls c:\test /grant jana:(WO,RC,WDAC)

Stejně jako v předchozím příkladu projde tento příkaz bez chyby. Pro pochybovače nabízím opět sejmutou obrazovku s oknem příkazového řádku (obrázek 4.6). Doplnil jsem tu ještě příkaz whoami/groups, který opět dokazuje, že jsem přitom měl přidělen token uživatele se standardním oprávněním, nikoli token správce. OBRÁZEK 4.6: Mark překvapivě smazal soubor, i když měl odebráno oprávnění „smazat soubor“!

Zákaz smazat soubor se liší od zákazu jiných činností Nejde tu o žádnou chybu Windows, ale o promyšlený návrh. Když smažete soubor, proběhnou ve skutečnosti dvě změny. Za prvé smažete skutečný objekt (soubor). Zároveň však měníte jiný objekt (složku).

186

Kapitola 4 – Kontrola integrity windows

POZNÁMKA:

Pokud vám to není jasné, zkuste popřemýšlet o tom, co je složka. Není to nic jiného než seznam souborů a podřízených složek uvnitř ní. Přidání souboru znamená přidání položky do seznamu, smazáním souboru jednu položku odeberete. V obou případech však dojde ke změně seznamu, a tento seznam patří mezi ochranitelné objekty …proto je nutné mít patřičná oprávnění.

Pokud tedy operace smazání souboru znamená dvě různé akce (smazání souboru a změna informací ve složce, která daný soubor obsahovala), vede to nutně k závěru, že pro smazání souboru potřebuji dvě oprávnění: ■

Oprávnění „mazat“ k objektu souboru

■

Oprávnění „mazat soubory a podsložky“ ke složce, která soubor obsahuje

Podle mého názoru byste pro smazání souboru měli mít obě tato oprávnění. S tím ale někteří jiní lidé nesouhlasí; viděl jsem například unixové systémy, na kterých mohl člověk s administrátorskými privilegii ke složce smazat soubor, i když daný účet neměl žádné oprávnění k danému souboru. Kdybych měl udržovat složku obsahující velké množství domovských adresářů uživatelů a měl v ní mazat nedovolené typy souborů a nelegální materiál, ale přitom bych nemohl mít nebo z legálních důvodů neměl mít právo přístupu k určitým souborům, považoval bych za zcela logické, abych mohl smazat soubory typu „ukradené písnička vyhlášené skupiny.mp3“ nebo „mokrý bobr. jpg“ i v případě, kdy bych tyto soubory nemohl otevřít. (Dalším důvodem pro toto chování je fakt, že standardní souborová oprávnění systémů Unix/Linux nejsou tak pružná jako souborová oprávnění NTFS; podrobnější diskusi na toto téma najdete v šesté kapitole mé knihy Linux for Windows Administrators. Toto omezení možná motivovalo tvůrce daného systému Unix při implementaci možnosti správců smazat i takový soubor, ke kterému nemají žádná oprávnění.) Ať už je ale příčina jaká chce, již o dob NT 3.1 je ve Windows možné smazat soubor, ke kterému má uživatel alespoň jedno ze dvou zmíněných oprávnění. Zkuste si například vytvořit další novou složku a v ní soubor, a poté si udělte oprávnění smazat tento soubor, ale odeberte si oprávnění „smazat soubory a podsložky“ pro složku C:\test (a v Průzkumníkovi potvrďte, že toto oprávnění chcete aplikovat jen na danou složku, nikoli rekurzivně na podřízené složky). Tyto příkazy můžete spustit i v okně příkazového řádku podle následujícího vzoru obdobně jako předtím (nyní si však odebírám oprávnění „DC“ čili „smazat soubory a podřízené složky“). Začněte odznova smazáním složky C:\test, a poté zapište md C:\test icacls C:\test /grant mark:F createfile C:\test\a.txt icacls C:\test\a.txt /deny mark:(DC) erase C:\test\a.txt

I tato posloupnost na mém počítači proběhla bezchybně a mohl jsem tak smazat soubor killtest. txt. Jedině v případě, kdy bych svému účtu odebral oprávnění smazat soubor k danému souboru a oprávnění smazat soubory a podsložky k složce souboru, bych nedokázal soubor killtest.txt smazat.

Sledování běžících procesů

187

Kdy a jak může blokování mazání souborů prostřednictvím WIC selhat Výborně, víme tedy, že k zákazu smazání souboru na souborovém systému NTFS musíme od července 1993 uživateli odebrat dvě oprávnění, probraná v předchozí části. Ovšem původní otázka se netýkala oprávnění NTFS, že? Původní otázka přece zněla takto: „pokud mám soubor hltext.txt s vysokou úrovní integrity, jak je možné, že ho mohl smazat proces se střední úrovní integrity?“ A nyní se dozvíte konečně odpověď: ■

Stejně jako předtím i nyní je pro blokaci smazání souboru nutné zakazující oprávnění k souboru i složce. Windows vás nechají smazat soubor, pokud máte povolující oprávnění ho smazat nebo povolující oprávnění měnit jeho složku. V modulu oprávnění Windows neexistuje – pokud vím – žádný případ, kdy by celá operace byla zrušena, jakmile Windows poprvé narazí na zakazující oprávnění.

■

V příkladu se souborem hltest.txt nevystupovalo žádné oprávnění „zákaz mazání“ souboru. Byl tu jen rozdíl v úrovních povinné integrity, který fungoval jako „zákaz“ a přetrumfnul každý výběrový seznam ACL. Není možné vidět, co se děje pod pokličkou (uvnitř souborového systému), ale tato část fungovala dle očekávání, a proces střední úrovně integrity měl zakázáno smazat soubor hltest.txt…

■

…ale Vista ví – stejně jako všechny předchozí verze NT – že zákaz smazání souboru ještě neznamená, že je hotovo. Vista se proto zeptá složky obsahující soubor hltest.txt: „Máš nějaký námitky proti tomu, aby ti tady ten proces se střední úrovní integrity smazal jeden z tvých souborů?“ Složka má implicitní střední úroveň integrity (danou tím, že nemá explicitní mandatory label), a taková složka nemá nikdy námitky proti tomu, aby ji změnil proces se stejnou úrovní integrity. Výsledek? Soubor hltest.txt je fuč.

Stručně řečeno, Řízení integrity Windows sice přetrumfuje DACL, ale jen jeho souborovou část, u složky mu trumfy scházejí.

Řešení: je nutné zajistit, aby služba WIC chránila objekty Máme připravenou půdu pro tvorbu konečného řešení problému „jak použít Řízení integrity Windows pro úplný zákaz mazání objektů s vyšší úrovní integrity ze strany procesů s nižší integritou“. Nejlepším řešením je umisťování položek dané integrity do složek se stejnou integritou. V tom případě se pak pokus o „smazání souboru“ musí zarazit na vyšší prioritě mazaného souboru a pokus o „smazání souborů a podsložek složky“ narazí na vyšší úroveň integrity složky. Toto řešení si nyní opět vyzkoušíme. Stejně jako v předchozích příkladech začneme se dvěma okny příkazového řádku (jedno s právy správce, druhé s tokenem standardního uživatele), v obou nastavíme C:\pokusy jako pracovní složku. V okně příkazového řádku s právy správce vytvoříme složku C:\pokusy\vysoka. Poté svému účtu uživatele přidělíme oprávnění Úplné řízení ke složce C:\pokusy\vysoka a celému jejímu obsahu. Poté povýšíme integritu složky C:\pokusy\vysoka na vysokou úroveň. Následně vytvoříme v této složce soubor test.txt, který zdědí vysokou úroveň integrity. Nakonec ve druhém příkazovém řádku – se střední úrovní integrity – zkusíme soubor test.txt smazat a ověříme si, že tento pokus selže.

188

Kapitola 4 – Kontrola integrity windows

Nejprve se přesuňte do příkazového řádku s právy správce a v něm spusťte tyto příkazy: md C:\pokusy\vysoka icacls C:\pokusy\vysoka /grant vašejméno:(OI)(CI)F chml C:\pokusy\vysoka -i:h -b createfile C:\pokusy\vysoka\test.txt

Poté se přesuňte do příkazového řádku s tokenem standardního uživatele a zde zapište příkaz erase C:\pokusy\vysoka\test.txt. Soubor smazán nebude a objeví se hlášení z obrázku 4.7.

OBRÁZEK 4.7: Povinná integrita nakonec zvítězila!

Mravní ponaučení celého příběhu je jednoduché: integrita Windows chrání nejlépe ty věci, které jsou umístěny ve složce se stejnou úrovní integrity.

Jak použít ACE služby Řízení integrity Windows pro omezení přístupu Viděli jsme pár příkladů toho, jak Řízení integrity Windows umí zakázat programu změnit nebo mazat soubor. Toto je výchozí chování WIC, ale není to všem, co může Řízení integrity Windows omezit. Umí též zabránit procesu s nižší úrovní integrity číst objekt s vyšší integritou, nebo – pokud je objektem soubor EXE či příbuzný typ souboru – umí zakázat procesu s nižší integritou tento objekt spustit.

Jak použít ACE služby Řízení integrity Windows pro omezení přístupu

189

Popisoval jsem už, že pro zákaz zápisu do souboru nebo složky procesem nižší úrovně integrity stačí tomuto souboru či složce přidat speciální typ ACE (čili mandatory label), který říká: „toto je objekt takové a takové úrovně integrity“ a tak zabráníte nežádoucímu zápisu. Neřekl jsem vám ale všechno, protože ve skutečnosti neexistuje žádný typ ACE, který by jen deklaroval úroveň integrity objektu; ACE ve skutečnosti říká „tento objekt má takovou a takovou úroveň integrity“, ale všechny položky ACE, které jsme prozatím objektům přiřazovali, říkají navíc ještě „a není žádoucí, aby sem zapisovaly položky s nižší úrovní integrity“. V položce ACE je volné místo, do kterého můžete přidat svůj požadavek na zákaz čtení nebo spouštění daného objektu. Nástroj chml má pro tento účel připraveny přepínače -nr, -nx a -nw. NR, NW a NX jsou, jak jste asi sami uhodli, Microsoftem vytvořené zkratky vyjadřující zákaz čtení, zápisu a spouštění. Chceme-li tedy souboru test.txt přidělit vysokou úroveň integrity a sdělit operačnímu systému, že nechceme, aby procesy nižší úrovně integrity tento soubor četly, stačí spustit příkaz chml test.txt -i:h -nr -b

POZNÁMKA:

Nástroj icacls nedokáže vytvářet zásady Řízení integrity Windows NX a NR, umí vytvářet jen položky NW.

Prozatím jste se o zapínání voleb -nr, -nw a -nx nemuseli nijak starat, protože jsem, nástroj chml napsal tak, aby automaticky zapnul volbu NW, pokud nebyla zadána ani jedna z těchto voleb. Interní struktura ACE povinné integrity ponechává prostor pro všechny tři volby, proto se dá soubor test.txt úplně zamknout takto chml test.txt -i:h -nr -nx -nw -b

(Na pořadí voleb -nr, -nx a -nw nezáleží; nutné je pouze uvést název souboru nebo složky jako první argument.) Ukážeme si vše opět na jednoduchém příkladu. Jako předtím začneme spuštěním dvou oken příkazového řádku (jedno s právy správce, druhé s tokenem standardního uživatele) a v obou nastavíme složku C:\pokusy jako pracovní. Poté v příkazovém řádku s právy správce proveďte tyto příkazy: createfile a.txt chml a.txt -i:h -nr -nx -nw -b

Následně v druhém okně příkazového řádku spusťte příkaz type a.txt. Systém odpoví hlášením Přístup byl odepřen. Kde se dá toto prakticky použít? Inu, pokud skutečně chcete utáhnout šrouby a posílit ochranu systému proti různému svinstvu z Internetu (kvůli tomu služba Řízení integrity Windows očividně vznikla), můžete nastavit NR ACE na celý pevný disk C: s výjimkou několika málo vestavěných složek s nízkou úrovní integrity. VAROVÁNÍ:

Toto je prosím jen návrh; neměl jsem čas na testování, proto se do ničeho podobného nepouštějte, dokud si to pořádně neotestujete!

190

Kapitola 4 – Kontrola integrity windows

POZNÁMKA:

Při psaní těchto řádků si uvědomuji, že toto je jedna z částí WIC, které mne na mou duši rozčilují. Co když se nějakému zlému hošanovi povede nainstalovat nějaký malware co cizího (vašeho) systému a poté se mu podaří přijít na to, jak povýšit úroveň integrity všech pro daný malware důležitých souborů, složek a klíčů registru na systémovou úroveň? Nejsem tak dobrý programátor, abych toto dokázal, ale předpokládám na základě toho, že systémové služby běží na systémové úrovni integrity, že se teoreticky dá najít způsob, jak napsat službu manipulující s úrovněmi integrity až po tu nejvyšší. To ale ukáže čas.

Co ACE řízení integrity Windows nedokáže Když jsem se seznamoval s Řízením integrity Windows, byl jsem fascinován tímto novým rozměrem zabezpečení Windows… ale očekával jsem víc. Proto jsem strávil určitý čas i průzkumem některých slepých uliček. V této části bych vás rád ušetřil toho, abyste se do nich pouštěli také.

Mandatory labels se nedají aplikovat prostřednictvím zásad skupiny Celé pojetí mandatory labels a jejich aplikace pravidla „do vyšší úrovně nesmíš“ v masovém měřítku v rámci celého operačního systému na mne velmi zapůsobila, protože se mi velmi zalíbila představa, jak například nasměruji svůj nástroj chml na složku se svým účetnictvím a provedu asi takovýto příkaz: chml C:\personalfinance -i:m -nr

Díky tomu bych si mohl být téměř jistý, že se žádnému škodlivému kódu z Internetu nepodaří přečíst si soubory s mými finančními daty, a to nezávisle na tom, po jakých webech bych se pohyboval. Tento nápad mě dále přivedl na myšlenku, že by stálo za to připravit si celou strukturu atributů NR, NX a NW pro všechny složky na mém počítači. A na základě toho mne zase napadlo, že bych podobnou strukturu NR, NX a NW atribut mohl aplikovat na více systémů v síti. Jak to ale provést? Jeden z nejlepších způsobů distribuce sady nových oprávnění NTFS na všechny počítače v síti představují zásady skupiny. Proto jsem byl zvědav, zda je možné použít zásady skupiny pro distribuci mandatory labels. Bohužel toto možné není; vyzkoušel jsem takovou aplikaci pomocí šablony zabezpečení a nestalo se vůbec nic (s výjimkou několika chyb). Jak se ukázalo, byl to dost hloupý nápad. Když jsem se na možnost distribuce integrity labels pomocí zásad skupiny zeptal přímo v Microsoftu, dozvěděl jsem se, že s podporou podobných věcí se vůbec nepočítá. Uším, že jsem pravděpodobně byl příliš horlivý a chtěl jsem od svých nových nástrojů příliš. Přesto si však myslím, že by se taková možnost mnoha lidem hodila; možná se toho dočkáme ve Windows Vienna?

Co ACE řízení integrity Windows nedokáže

191

Nelze vytvořit standardní oprávnění, která jmenují mandatory labels Na jedné z prvních konferencí o WIC jsem se dozvěděl, že úrovně integrity je možné použít v klasických starých položkách řízení přístupu (tedy v zakazujících nebo povolujících oprávněních). To mne vedlo k domněnce, že možná budu moci vytvořit soubor, ke kterému bude možné přistupovat výlučně na základě nastavení úrovně integrity a nebude tedy nutné být členem skupin Users, Administrators a dalších podobných. Abych něco podobného vytvořil, odebral jsem nejdříve ze souboru všechna stávající oprávnění, takže v něm nebylo ani jedno výběrové ACE. Poté jsem napsal program umožňující přidat k vybranému souboru v podstatě libovolný typ ACE. Díky tomu jsem měl dostatečný prostor pro úpravu souboru do takového tvaru, že měl přiděleno jen pět výběrových ACE, která vypadala takto: ■

Mandatory Label\System Mandatory Level: Full Control

■

Mandatory Label\High Mandatory Level: Full Control

■

Mandatory Label\Medium Mandatory Level: Full Control

■

Mandatory Label\Low Mandatory Level: No Access

■

Mandatory Label\Untrusted Mandatory Level: No Access

Když jsem se ve Vistě na oprávnění k tomuto souboru podíval na stránce Zabezpečení dialogového okna vlastností souboru, uviděl jsem to, co vidíte vy na obrázku 4.8. OBRÁZEK 4.8: Soubor, který má jen oprávnění pro mandatory label

192

Kapitola 4 – Kontrola integrity windows

A opět – toto může přinést úsměšky, protože je to druh bezpečnostního výzkumu podobného tomu, co ukazovaly obrázky ve stylu „těžší než letadlo“, které dokumentovaly snahu lidí vytvořit na sklonku 19. a počátku 20. století superstroje, které však nikdy nevzlétly (narážka na „těžší než vzduch“, argument odpůrců letadel). Toto cvičení mi však přece jen ukázalo jednu užitečnou věc, týkající se icacls. Strávil jsem pár dní psaním programu, který by mi dovolil vložit do ACE oprávnění libovolný SID, abych mohl vytvořit chiméru z obrázku 4.8, později jsem však zjistil, že to samé se dá provést i nástrojem icacls. Jak již víte, icacls vytváří oprávnění pomocí přepínačů /grant a /deny, zatím jste ale neviděli jednu parádní vlastnost těchto voleb. Namísto uvádění uživatele nebo jména skupiny je možné v ACE zadat SID, před který přidáte hvězdičku. Chcete-li tedy vytvořit oprávnění, které by skupině Everyone udělilo Úplné řízení souboru a.txt, dá se to řešit tímto příkazem icacls a.txt /grant *S-1-1-0:F

(V předchozím textu bylo uvedeno, že S-1-1-0 je SID skupiny Everyone.) Kdybych to věděl, nemusel jsem ztrácet čas vytvářením programu pro přidávání ACE, protože icacls by tuto úlohu splnil také, pokud bych mu jako argument předal SIDy ve tvaru *S-1-16-0 (nedůvěryhodná úroveň integrity), *S-1-16-4096 (nízká úroveň integrity) atd.: icacls icacls icacls icacls

cokoli.txt cokoli.txt cokoli.txt cokoli.txt

/grant /grant /grant /grant

*S-1-16-0 *S-1-16-4096 *S-1-16-8192 *S-1-16-12288

V každém případě jsem se snažil zbytečně, protože Microsoft se podle mne rozhodl nevyužít plný potenciál WIC. Vy jste však chráněni před zbytečnými pokusy v tomto směru a já jsem měl ještě příležitost vysvětlit vám další část syntaxe příkazu icacls.

Poznámka k modifikacím systémových souborů Během páce s jednou z ranných beta verzí Visty jsem se dozvěděl – tehdy jsem ještě neměl čas na průzkum Řízení integrity Windows, proto jsem si to osobně neověřoval –že Microsoft přidělil všem systémovým souborům „systémovou“ úroveň integrity (což asi těžko někoho překvapí). Z toho měli velkou radost především beta testeři, protože při vydání nové beta verze Visty nemohli smazat starý operační systém (byli přihlášeni jako správci a měli tudíž o něco nižší úroveň integrity). Jeden z pracovníků mi řekl, že někdo (nejspíše jeden z testerů) vytvořil dokonce zvláštní aplikaci obliterate.exe, jejímž jediným úkolem bylo vymazat soubory starší verze Visty z pevného disku. Není třeba říkat, že nutnost spouštět nepodporovanou podomácku vyrobenou aplikaci jen kvůli takové trivialitě jakou je smazání souborů na pevném disku, nevyvolávala nadšené ohlasy. Především proto, že miliony beta testerů kopii tohoto sporného nástroje stejně nikdy nezískali, se Microsoft pokusil o nový směr při ochraně systémových souborů, který by byl dost významný, kdyby byl proveden tiše: úplně předělali výchozí oprávnění NTFS k souborům a složkám ve složce \Windows.

Poznámka k modifikacím systémových souborů

193

Na systémech Windows Server 2003 a XP měla skupina Administrators ke složce \Windows nastaveno implicitní oprávnění „Úplné řízení“. Vlastníkem složky \Windows byla místní skupina Administrators. Ve Vistě se však v tomto ohledu spousta věcí měnila, jak je zřejmé z obrázku 4.9. OBRÁZEK 4.9: Nová výchozí oprávnění ke složce \Windows

Za prvé platí, že složka \Windows ve Vistě nedědí žádná oprávnění kořenové složky. Microsoft (nejspíše dost moudře) nastavil pevný disk operačního systému tak, aby veškeré případné rozvolnění přístupových oprávnění na kořenovou složku C: (nebo kořenovou složku jiného disku, na který systém nainstalujete) neovlivnilo oprávnění k složce \Windows, ve které má místní skupina Administrators téměř úplné řízení, scházejí jí však oprávnění ke ■

Smazání podsložek a souborů

■

Změně oprávnění

■

Přebírání vlastnictví

Toto je delikátní, ale přesto z mnoha ohledů velmi zásadní změna. Za prvé, tato oprávnění nejsou děděna podřízenými složkami, jak tomu je normálně; řeč je jen a jen o složce \Windows. Microsoft tuto změnu provedl v rámci velmi detailního ladění oprávnění NTFS je složce Windows. Všimněte si posledních dvou položek z tohoto seznamu: „změnit oprávnění“ a „přebírat vlastnictví“. Kde jsme se s tímto už setkali? Ano, správně – jsou to oprávnění potřebná pro změnu úrovně integrity souborů. Domnívám se, že cílem Microsoftu zde bylo nastavit oprávnění tak, aby v případě, kdy správce pracující v Režimu schválení správce náhodně spustí nějaký škodlivý kód, který se pokusí snížit úroveň integrity (nebo jinak uvolnit oprávnění) libovolného systémového souboru ve složce \Windows, byly vyvolány chyby, kterých by si správce všimnul. (Když jsem se poprvé pokoušel změnit úroveň integrity souboru notepad.exe po jeden ze zdejších příkazů, dostal jsem kvůli této změně málem infarkt!)

194

Kapitola 4 – Kontrola integrity windows

Zde to ale nekončí. Jste duševně připraveni na opravdu velkou změnu? Skupina Administrators už není vlastníkem složky \Windows – to se ve světě Windows ještě nikdy předtím nestalo. (To je to, z čeho mi ve Vistě naskakuje husí kůže. A je mi jasné, že tyto systémy mě nebudou brát jako neomezeného pána, tak jak to dělaly systémy staré.) Tyto změny pokračují i ve složce System32. Microsoft u této složky opět vypnul dědění oprávnění a vyladil jejich nastavení ručně. To samé se stalo i u dalších složek, včetně složky Drivers. Jak je vidět, Microsoft si myslí, že vypnutím dědění oprávnění a rozpojením jejich závislosti významně zpomalí činnost malwaru, který dříve díky právům správce mohl rychle napadnout celou hierarchii složky \Windows. V všech složkách s ručně upravenými privilegii nemá skupina Administrators oprávnění mazat soubory a podřízené složky, měnit oprávnění a přebírat vlastnictví. Je to změna k lepšímu? Někteří říkají ano, jiní ne, jedno však vím: vyvolá to určitě spoustu vzrušených diskusí ve firemních kuchyňkách nebo – pravděpodobněji – v hospodách. Zkusím proto shrnout, jaké dva pohledy na věc budou asi v diskusích převládat. Ti, kteří tyto změny považují za špatné, budou uvádět zřejmě tyto důvody: ■

Za prvé, vestavěná oprávnění, která nepovolují správcům být vlastníky systému, jsou osinou v zadku správců zvyklých na to, že mohou ve svých systémech dělat cokoli se jim zachce. (Živě si přitom představuji zdůrazněné slovo „svých“, doprovozené bouchnutím do stolu.) Svůj odpor vyjadřují velmi stručně větami typu: „zatraceně, tohle mi jen zkomplikuje práci“. A protože správce dělám už několik desítek let, dávám jim v tomto případě za pravdu.

■

Za druhé (půjde opět o správný argument), každý počítačový kriminálník, který za něco stojí, prostě převezme vlastnictví složky \Windows, udělí si oprávnění úplného řízení, a poté se přesune do složky \Label\system32 a tam udělá to samé, a poté se přesune do složky \Label\system32\drivers a tam … atd. V podstatě neexistuje žádná systémová bariéra, která by správci zabránila převzít řízení nad celým systémem Windows, pouze nesmírně iritující mezikroky, které je nutné projít, namísto možnosti okamžitě převzít celé řízení. Pro skutečné hackery bude nová Vista výzvou, které jistě neodolají a pokusí je si rozlousknout. Tímto argumentem si nejsem už tak jist, ale slyšel jsem ho.

Naopak, ti, kteří tyto změny vítají, budou argumentovat asi takto: ■

Tyto bariéry nejsou nepřekonatelné, ale existují. Připomínají nám nástražné dráty kolem budov; nezastaví vás sice, ale po kontaktu s nimi začnou řvát klaksony ohlašující, že se pokoušíte v systému udělat Něco Špatného. Co je ještě lepší: jedná se o jednoduché bariéry, které nám připomínají, že se pouštíme do nebezpečných vod, prostě takové jednoduché připomenutí pro správce, kteří to sice myslí dobře, ale ndávají si někdy pozor: „bacha, toto bys neměl dělat“. Když už je řeč o nástražných drátech, možná jde o jednu z věcí, kvůli které byly do prohlížeče událostí zabudovány nové schopnosti spouští událostí.

■

Překážky nemusí být dokonalé, aby byly účinné, protože dokonalá překážka stejně neexistuje. Většinu útoků na systém nepodnikají specializovaní hackeři, ale neinteligentní červi a roboti, nebo nějaké skripty, které na Internetu našla -náctiletá děcka a rozhodla si je vyzkoušet a hacknout vás, protože máte prostě smůlu a jste na stejném segmentu sítě poskytovatele.

Tvorba vlastních mandatory label

195

Kdo z nich má pravdu? Nevím, ale sympatizuji s druhou skupinou. Starý vtip říká, že „mýlit se je lidské, ale chcete-li něco opravdu pořádně zkomplikovat, potřebujete k tomu počítač“. I malý špatné kroky mohou mít za následek vážné škody, proto tvrdím, že příležitostné dotazy „jste si jistý?“ nejsou tím nejhorším, co nás může potkat. A kromě toho přece nejde o to, že byste ztratili vládu nad systémem. Pokud chcete vrátit Vistu do stavu, kdy jste byli vlastníkem složky \Windows a měli oprávnění úplného řízení nad všemi podřízenými složkami, je to klidně možné – nic vám totiž nemůže zabránit převzít vlastnictví těchto složek, protože toto privilegium správci vždy měli.

Tvorba vlastních mandatory label V poslední části této kapitoly se chci podívat podrobněji na jedno pokročilé téma – nízkoúrovňové řízení úrovní povinné integrity. V průběhu této kapitoly jste viděli, že objekty dávají najevo svou úroveň integrity prostřednictvím speciálních položek řízení přístupu, kterým se říká „mandatory labels“. Budete-li vědět, jak se dají sestavit a aplikovat vlastní popisky, budete moci ovládat nejen úrovně integrity, ale i to, zda bude úroveň integrity složek aplikována automaticky na obsah složek, jaké typy omezení budou uplatňovány apod. Znalost problematiky vám také umožní mandatory labels úplně odstranit.

Co jsou řetězce SDDL Když říkám, že budeme přímo manipulovat s mandatory labels, mám tím na mysli spouštění nástroje chml s přepínačem -wsddl: sloužícím pro přímé skládání řetězce jazyka SDDL (Security Descriptor Definition Language) a jeho zápis do objektu. Nejlepší bude, když si ukážeme stručný příklad. Jestliže například spustíte příkaz chml testslozka -wsddl:S:P(ML;CIOI;NWNR;;;HI)

říkáte tím systému Vista toto: „V systému existuje složka s názvem „testslozka“. Najdi ji a přiřaď ji vysokou úroveň integrity. Dále přikaž této složce, aby ignorovala veškeré pokusy procesů s nižší úrovní integrity o zápis nebo čtení. Zajisti, aby tyto instrukce dostaly i všechny objekty uvnitř této složky, ale zablokuj všechny popisky integrity z rodiče této složky“. To je celkem dost dlouhý text, odvozený z pouhého "S:P (ML;CIOI;NWNR;;;HI)", že? Tato skupina velkých písmen, dvojteček, středníků a uvozovek představuje kompaktní způsob vyjádření položek a seznamů řízení přístupu v řetězci SDDL, o kterém jsem psal dříve. Pro rozluštění tohoto kódu se musíte naučit jazyk SDDL, a této činnosti bude věnována tato část kapitoly. Přepínač -wsddl je zkratka fráze „write SDDL strings“ čili „zapsat řetězec SDDL“. Díky přepínači -wsddl můžete aplikovat řetězce SDDL, kterými lze dosáhnout různých změn v nastavení přístupu, probíraných v rámci této kapitoly, ale i jiné věci. (Nástroj icacls nepovoluje zadávání vlastních řetězců SDDL, i když byl v posledních fázích vývoje Visty opraven!)

196

Kapitola 4 – Kontrola integrity windows

Tajemství jazyka kategorie B: syntaxe popisků SDDL (Tím „B“ mám na mysli kategorii B z Orange Book – systémy s povinným řízením přístupu. Koneckonců bez mandatory labels nelze žádný systém s povinným řízením přístupu sestavit.) Když se objevily Windows NT 3.1, bylo možné přístupové oprávnění přidělit jen tiskárnám, souborům, složkám, sdíleným prostředkům a klíčům systémového registru (pokud mi paměť dobře slouží). Postupem doby Microsoft přidával v novějších verzích Windows další a další „ochranitelné“ objekty, tedy místa se svým seznamem řízení přístupu. Ale výpis všech informací z jedné jediné položky řízení přístupu by byl nesmírně dlouhý, zvláště když uvážíte nejrůznější typy oprávnění, které složka či soubor nabízí, nebo veškeré možné volby pro dědění oprávnění (ty se objevily ve Windows 2000). Microsoft proto vyvinul „těsnopisný“ způsob zápisu vlastníka objektu, jeho primární skupiny (o tu jste se nejspíše nikdy nemuseli zajímat, a ani v budoucnosti to pravděpodobně nebudete muset udělat; ta je přítomna jen kvůli kompatibilitě s POSIXem), seznamu výběrového řízení přístupu a seznamu systémového řízení přístupu. Zaměříme se na tento seznam systémového řízení přístupu, protože v něm je uložen mandatory label. Popisek Řízení integrity Windows (SACE) má jako řetězec SDDL tento tvar: S:příznaky_sacl(ML;příznaky ace;zásada řízení integrity;;;úroveň integrity nebo SID)

Například v řetězci SDDL S:AI(ML;CIOI;NR;;LW) má příznak SACL hodnotu AI, příznaky ACE hodnotu CIOI, zásada Řízení integrity Windows je NR a úroveň integrity je LW. Způsob dekódování celého řetězce budeme provádět postupným rozborem jednotlivých částí. VAROVÁNÍ:

Pozor, řetězce SDDL jsou psány vždy velkými písmeny. Zápis malého písmene v tomto řetězci skončí dle mých zkušeností vždy chybou.

Označovač (designat or) SACL První část řetězce SDDL ve tvaru S: znamená „následující údaj je SACL“. Podrobnější řetězce SDDL mohou mít také označovač O:, vyznačující vlastníka objektu, dále G: (primární skupina objektu) nebo D: (DACL objektu). Označovač SACL S: má vždy stejný tvar a musí být vždy psán velkým písmenem. Pro jeden objekt existuje jen jeden SACL, přestože programovací rozhraní Visty rozlišuje mezi SACE určenými čistě pro auditování a SACE v úloze mandatory labels. Proto při spuštění příkazu chml názevsouboru -sddl uvidíte vypsány jen SACE pro mandatory label a ne auditovací SACE.

Příznaky SACL Seznamy SACL a DACL se významně změnily s příchodem Windows 2000, a to díky zabudované dědičnosti. Tu však není nutné používat a přikázat libovolnému objektu ignorovat zděděné položky ACE a používat jen explicitně definované vlastní ACE. Na obrázku 4.10 vidíte, co mám na mysli.

Tvorba vlastních mandatory label

197

OBRÁZEK 4.10: Typický seznam DACL

Jedná se o výběrový, nikoli systémový ACL, ale zvolil jsem si ho za příklad proto, že patří mezi ty „podrobnější“, takže poslouží jako dobrá ilustrace toho, co se pokouším vysvětlit. Nejdříve si zopakujeme rozdíl mezi ACE a ACL: máme tu jeden seznam (ACL), obsahující čtyři položky (ACE). Jedná se o ACL objektu, konkrétně souboru test.txt. A nyní jeden důležitý bod: všimněte si zaškrtávacího políčka v levém spodním okraji s popiskem „Zdědit po nadřazeném objektu položky oprávnění…“. Když toto políčko vypnete, budou všechny DACE objektu zrušeny, protože jak je vidět ve sloupečku „Zděděno od“, jsou všechny zděděny. V jazyku SDDL se vypnutí políčka „Zdědit po nadřazeném objektu položky oprávnění…“ vyjádří příznakem P, což je podle dokumentace Microsoftu zkratka fráze „protect this object from inherited SACEs“ (chránit před zděděnými SACE). Pokud bych tedy souboru přiřadil SACL ve tvaru S:P(ML;;NR;;;LW), říkal bych tím souboru, aby ignoroval všechny položky SACE svého rodiče. POZNÁMKA:

Pojmem „rodič“ je míněna složka, ve které je soubor umístěn. Naopak souborům a složkám uvnitř nějaké složky se říká někdy „synovské objekty“.

Existují ještě dva další možné příznaky SACL: AI a AR, ovšem ten druhý jste pravděpodobně nikdy nespatřili. P se dá snadno pochopit, protože přímo odpovídá zaškrtávacímu políčku v uživatelském rozhraní, tam ale nenajdete nic, co by odpovídalo příznakům AI nebo AR. Připomeňme si, že většina podřízených objektů – složek a souborů – implicitně dědí DACE a SACE svého rodiče (složky, ve které jsou umístěny). Jak jsou ale ve skutečnosti tyto DACE a SACE kopírovány (často je u dědičnosti používán výraz „propagovány“) do podřízených objektů? Když měníte oprávnění rodiče, není nutné klepat na žádné tlačítko „aktualizovat oprávnění“ a přesto jsou podřízené objekty téměř okamžitě aktualizovány … jak to tedy proběhne? V systému

198

Kapitola 4 – Kontrola integrity windows

Windows běží na pozadí procedura, která sleduje změny oprávnění složek, a když k nim dojde, zasáhne a zkopíruje všechny nové DACE a SACE do podřízených objektů. To samozřejmě může vyvolat následnou reakci a propagaci oprávnění do podřízených objektů další úrovně, pokud u těchto není blokováno dědění oprávnění. Takto se celý proces opakuje až do průchodu celou hierarchií podřízených složek – na velkých systémech se složitou strukturou složek a pomalým procesorem či pevným diskem může tento proces trvat delší dobu. (Nikdy jsem to nenažil, ale možné to je.) Aby si Windows udržely přehled o tom, které ACE již byly úplně zkopírovány a které ještě ne, přidávají automaticky na každý změněný seznam ACL zvláštní příznak AR, který v podstatě říká toto: „Hej systéme, já jsem změněný seznam ACL, můžete mě zkopírovat do mých podřízených objektů?“ AR je tedy příznak vkládaný systémem a určený pro systém. Jakmile Windows dokončí propagaci ACL na jeho podřízené objekty, změní příznak AR na AI. Z těchto důvodů najdete u mnoha SACL objektů příznak AI; ten dává najevo, že SACL objektu obsahuje jednu či více zděděných položek SACE a že Windows dokončily propagaci těchto položek. Můžete si to prakticky vyzkoušet v okně příkazového řádku s právy správce, ve kterém přejdete do složky C:\pokusy. Zde vytvořte novou složku C:\pokusy\testslozka a nastavte jí vysokou úroveň integrity. Implicitně chml vytváří oprávnění složek se zapnutým děděním na podřízené objekty. Poté vytvořte uvnitř složky testslozka soubor s názvem test.txt a podívejte se na jeho SDDL; uvidíte tu příznaky S:AI. Příkazy pro celý příklad vypadají takto: md testslozka chml testslozka -i:h -b createfile testslozka\test.txt chml testslozka\test.txt -sddl -b

Na poslední příkaz zareaguje chml výpisem SDDL string for testslozka\test.txt's integrity label=S:AI(ML;ID;NW;;;HI)

U libovolného seznamu SACL tedy můžete najít žádné příznaky nebo příznak P (při vypnutém dědění oprávnění). Kromě P se dá vidět také příznak AI a teoreticky i AR, ale o tom posledním silně pochybuji.

Typ SACE Po průzkumu označovače a příznaků SACL přišel čas na jedinou položku řízení přístupu, týkající se zabezpečení (SACE, security access control entry). V jazyku SDDL jsou položky ACE – a to jak výběrové, tak systémové – zvýrazněny pomocí závorek. Dalším znakem v řetězci SDDL je tedy levá závorka. SACE má šest částí, používat budeme v této části čtyři z nich: typ SACE, jeho příznaky dědění, zásadu úrovně integrity, dvojici částí týkajících se objektů Active Directory a úroveň integrity. Probereme je postupně. První částí SACE je tzv. „typ SACE“. Po mnoho let se při auditování položky SACE dělily na tyto varianty: „audit“, „object audit“, „object alarm“ a „alarm“. („Alarmové“ položky jsem tuším nikdy v praxi nevyužil.) Řízení integrity Windows přichází s novým typem „mandatory label“. SDDL rozlišuje typy SACE pomocí jedno- či dvojpísmenných zkratek, přičemž ML vyjadřuje mandatory label. Každá úroveň integrity má tedy stejný typ SACE, který vždy začíná levou závorkou a ML.

Tvorba vlastních mandatory label

199

Příznaky SACE Příznaky může vlastnit jak seznam SACL, tak jednotlivé položky SACE v něm. U mandatory label neuvidíte buď žádné příznaky, nebo uvidíte kombinaci následujících pěti příznaků, které tu rozlišuji jejich dvojpísmennými SDDL zkratkami: ■

CI neboli „container inherit“ (dědění kontejneru)

■

OI neboli „object inherit“ (dědění objektu)

■

NP neboli „inherit but do not propagate“ (zdědit, ale nepropagovat dál)

■

ID čili zděděné SACE

■

IO neboli „inherit only“ (jen zdědit)

S těmito příznaky jste se již dříve pravděpodobně setkali, i když jste si to neuvědomili. Podívejte se opět na obrázek (4.11), kde je znázorněno, co mám na mysli. Na obrázku 4.11 vidíte dialogové okno, se kterým se potkáte při každém pokusu vytvořit ručně doladěné oprávnění ke složce. Jedná se samozřejmě o výběrový seznam ACL, nikoli systémový, ale oba dialogy fungují stejně. Popisek rozvíracího seznamu „Použít pro“: by měl spíš mít tvar „Instrukce pro dědění“. Je tu celkem sedm možností a k tomu ještě jeden důležitější ovládací prvek – zaškrtávací políčko „Použít tato oprávnění pouze pro objekty a kontejnery obsažené v tomto kontejneru“. Jak uvidíte, každá z těchto osmi funkcí odpovídá různým kombinacím pěti příznaků SACE. OBRÁZEK 4.11: Standardní dialogové okno „vytvořit novou položku ACE“ s viditelnými volbami „Použít pro“

200

Kapitola 4 – Kontrola integrity windows

Žádné příznaky: „Použij pouze na mne“ Položka SACE bez příznaků, patřící složce, nemůže být zděděna, proto takovou SACE nedostane žádný soubor ani podřízená složka. Složka sama však tuto SACE obdrží. Varianta „bez příznaků“ má smysl spíše u souborů než u složek, protože soubory nikdy nemohou mít podřízené objekty. (Ve skutečnosti nemá u souborů význam většina příznaků SACE, a to ze stejného důvodu – soubory nemohou mít podřízené objekty.) Stručně řečeno, implicitně je SACE použito na ten objekt, na který je aplikován. Až v případě, kdy začnete přidávat příznaky, se toto výchozí chování mění.

CI: „Zkopírovat do podřízených složek“ Příznak CI („Container Inherit“) říká systému Windows, že má danou položku SACE aplikovat nejen na tento objekt, ale propagovat ho i na všechny kontejnery uvnitř tohoto objektu. Dejme tomu, že aplikujete mandatory label SACE nízké úrovně s příznakem CI na složku C:\slozka1. Všechny složky uvnitř C:\slozka1 zdědí tento mandatory label nízké úrovně, stejně jako všechny složky uvnitř nich. Soubory ve složce C:\slozka1 však popisek libovolného druhu nezdědí. CI nemá význam u souborů, protože u nich není kam toto oprávnění propagovat.

OI: „Zkopírovat na soubory“ Příznak OI („Object Inherit“) funguje podobně jako CI, ale dědění je tu omezeno na soubory. Když vytvoříte soubor, platí implicitní dědění Windows (CIOI), takže oprávnění ke složce dědí soubory i složky v ní. OI nemá význam u souborů, protože u nich není kam toto oprávnění propagovat.

IO: „Já to nechci, ale potomci to mohou mít, pokud chtějí“ Příznak IO („Inherit Only“) říká systému Windows toto: „Tato položka SACE je aplikována na danou složku, ale neúčinkuje na ni“. Chápu, že to zní dost nesmyslně, a ve skutečnosti by to také žádný smysl nemělo, kdyby se jednalo o jediný příznak dané položky SACE. Ale co třeba kombinace příznaků CI, OI a IO? CI a OI aplikují položku SACE na všechny podřízené složky a soubory ve složce, IO říká „ale na mne tato položka aplikována nebude“. IO zcela určitě nemá význam používat na soubory, protože ty nemají žádné potomky (podřízené objekty) a tudíž by daná položka SACE nebyla použita ani u souboru, ani nikde jinde.

NP: „Děti to dostanou, ale vnuci ne“ Příznak NP („inherit but do not propagate“) slouží k propagaci SACE na složky a soubory uvnitř dané složky, ale ne dále směrem do dalších úrovní souborové hierarchie. Jestliže zapnete v dialogovém okně oprávnění zaškrtávací políčko „Použít tato oprávnění pouze pro objekty a kontejnery obsažené v tomto kontejneru“, získáte tak pro dané SACE příznak NP.

ID: „Já s tímto nezačal, já to pouze zdědil“ Na rozdíl od některých jiných operačních systémů Windows propagují zděděné položky ACE jejich fyzickým kopírováním do podřízených objektů. Objekty Windows tedy mohou mít ACE explicitně aplikovány nebo zkopírovány z rodiče. Příznak ID v SACE říká, že tento objekt danou položku SACE zdědil.

Tvorba vlastních mandatory label

201

Po tomto výkladu je již jasné, jak fungují jednotlivé volby v rozvíracím seznamu z obrázku 4.11: ■

„Jen tato složka“ říká, že oprávnění bude aplikováno jen na objekt složky, na nic dalšího. Žádné dědění znamená žádné příznaky.

■

„Tato složka, podsložka a soubory“ znamená aplikaci SACE na objekt složky (implicitní chování) a jeho následnou propagaci na všechny podřízené složky a soubory. CI kopíruje oprávnění na složky, OI na soubory, takže příznaky mají tvar CIOI. (Nebo OICI.)

■

„Jen podsložky a soubory“ – kurzívu jsem přidal sám a jsem si vědom toho, že tuto položku uvádím mimo pořadí… ale chtěl jsem ji schválně postavit proti položce předchozí. Je tu jasně znát, že budou použity příznaky CIOI, ale co tu znamená to „jen“? Znamená to „…neaplikuj tuto SACE na mne, nadřízenou složku“. To zajistíme přidáním příznaku IO (Inherit Only), takže celková sada příznaků má tvar CIOIIO.

■

„Tato složka a soubory“ znamená „tuto složku“ (což je implicitní chování bez příznaků) a „soubory“ (neboli OI). Celkový příznak SACE je tedy v tomto případě jen OI. Podřízené složky nejsou zmíněny, proto tu není ani příznak CI.

■

„Tato složka a podsložky“ je přesný opak předchozího případu: podřízené složky, ale ne soubory. Podřízené složky jsou kontejnery, proto zde postačí příznak CI.

■

„Jen soubory“ je jasný příznak OI, přídomek „jen“ značí IO, takže výsledné příznaky jsou OIIO.

■

„Jen podsložky“ je interpretovatelné obdobně a dává výsledné CIIO.

Ukázkový výstup, který jsem nabídnul v předchozím textu, má řetězec SDDL ve tvaru S:AI(ML;ID;NW;;;HI). Příznak ID říká, že dědění není nastaveno a soubor test.txt získal tento

příznak díky dědění z nadřízeného objektu. Kdyby jazyku SDDL scházely některé příznaky, vypadalo by to asi takto: S:AI(ML;ID;NW;;;HI ).

Práva SACE Až doposud jsme zkoumali jeden z typů SACE – mandatory integrity label – a jeho příznaky pro dědění. Nyní se podíváme na to, jaké vyžaduje typy zásad úrovně integrity. Připomeňme si, že Řízení integrity Windows umožňuje blokovat pokusy procesů s nízkou úrovní integrity o čtení, zápis nebo spuštění objektů s vyšší úrovní. Řetězce SDDL tyto blokace vyjadřují prostřednictvím následujících příznaků: ■ NR = zamítnout požadavky objektů s nižší úrovní integrity na čtení. ■ NW = zamítnout požadavky objektů s nižší úrovní integrity na zápis. ■ NX = zamítnout požadavky objektů s nižší úrovní integrity na spuštění. SACE povinné integrity musí mít přinejmenším jeden z těchto příznaků, ale může mít i všechny tři. Všechny následující ukázky SACE jsou proto legální: ■ ■ ■

S:(ML;CIOI;NW;;;HI) blokuje jen čtení. S:(ML;CIOI;NRNW;;;HI) blokuje čtení i zápis. S:(ML;CIOI;NWNRNX;;;HI) blokuje čtení, zápis i spouštění.

202

Kapitola 4 – Kontrola integrity windows

Jakmile do SACE přidáte zásady integrity, přidejte za ně tři středníky, protože tento druh SACE nevyžaduje následující dvě pole. A jsme skoro hotovi!

Vykonavatel SACE: úroveň integrity Položky ACE obvykle odkazují na účet, který má udělen nebo odepřen určitý typ přístupu. V bezpečnostní terminologii Microsoftu se odkazovaný účet uživatele nebo skupiny nazývá „trustee“ (vykonavatel). Mandatory label obsahuje SID, ale to je jeden z předdefinovaných SIDů, které oznamují úroveň integrity a jejich možné hodnoty byly uvedeny v tabulce 4.1. Chceme-li tedy sestavit mandatory label SACE vztahující se na soubor – a tedy nevyžadující žádné pravidlo dědičnosti – se zásadou zakazující spouštění objektu a přiřazující souboru vysokou úroveň integrity, stačí v tabulce 4.1 vyhledat řádek pro vysokou integritu a získané SID ve tvaru S-1-16-12288 SID zapsat do integritního řetězce SDDL: S:(ML;;NX;;;S-1-16-12288)

Tato položka SACE nemá žádné příznaky SACL, jedná se o mandatory label (ML), schází tu příznaky SACE (za ML následují jen středníky ;;), je zakázáno spouštění objektu (zásada NX). Dále jsou dvě pole vynechána a na konci je SID vysoké integrity. Funguje to skvěle, ale SIDy se velmi obtížně pamatují (a zapisují), proto Microsoft definoval zkratky LW, ME, HI a SI, vyjadřující nízkou, střední, vysokou a systémovou úroveň integrity. Výše uvedený řetězec SDDL se tedy dá zkrátit bez změny funkčnosti do tohoto tvaru: S:(ML;;NX;;;HI)

Jak nastavit úroveň integrity prostřednictvím řetězců SDDL Jakmile máte sestaven výsledný řetězec SDDL, můžete ho předat příkazu chml za přepínačem -wsddl:. Předchozí ukázkový řetězec SDDL se dá na složku C:\noex aplikovat následujícím pří-

kazem: chml c:\noex -wsddl:S:(ML;;NX;;;HI)

Chcete-li vypsat řetězec SDDL pro nějakou existující složku či soubor, použijte přepínač –sddl: chml c:\noex -sddl

Pokusy zjistíte, že většina souborů a složek nemá přiřazen žádný řetězec SDDL, nebo že mají prázdný SACL, zděděný odkudsi z vyšších úrovní souborového systému (to v případě, kdy chml vypíše řetězec SDDL ve tvaru S: nebo S:AI – v prvním případě jde o SACL bez položek SACE, v druhém případě o prázdný SACL). A toto je vhodné vědět pro případ, kdybyste chtěli objektu odebrat mandatory label, protože nevím o tom, že by to dokázal některých z vestavěných nástrojů Microsoftu. V nástroji chml se to dá provést takto: chml c:\noex -wsddl:S:

Co ještě můžete dělat, když si umíte ručně upravit řetězce SDDL? Inu, volby příkazu chml předpokládají, že pokud chcete označit složku, chcete také toto označení propagovat na všechny podřízené objekty. Nechcete-li nově vytvořenou mandatory label propagovat vůbec, přidejte příznak

Souhrn

203

-noinherit. Ale co když jste chtěli složce C:\Dokumenty přidělit mandatory label střední úrovně

integrity, která brání v jejím čtení, a dědit mají jen přímí potomci? Ve volbách chml se toto nastavit nedá, ale naštěstí lze sestavit řetězec SDDL: chml c:\documents -wsddl:S:(ML;CIOINP;NR;;;ME)

Souhrn V této kapitole jsme probrali spoustu nových podnětů, které bych nyní rád shrnul: ■

Jednou ze součástí Visty je tzv. Řízení integrity Windows, které je v podstatě druhou (paralelní) sadou přístupových oprávnění, která mají přednost před standardními oprávněními k souborům.

■

Řízení integrity Windows označuje každý objekt, token uživatele a proces jednou z šesti „úrovní integrity“ (untrusted, low, medium, high, system, a trusted installer, seřazeno od nejnižší po nejvyšší důvěryhodnost).

■

Soubory, složky a jiné ochranitelné objekty získávají svou úroveň integrity coby položku řízení přístupu, který je v podstatě druhem oprávnění NTFS, ale je uložena v SACL, nikoli v DACL.

■

Popisky úrovní integrity uživatelů a procesů jsou uloženy b jejich tokenech jako SID skupiny ve tvaru S-1-16-číslo.

■

Ve výchozím nastavení je hlavním úkolem řízení integrity Windows blokování libovolného procesu nižší úrovně integrity, který se pokusí o změnu objektu vyšší úrovně integrity. WIC však umí zakázat i čtení nebo spuštění takových objektů.

■

Objekty bez popisků mají implicitně přiřazenu střední úroveň integrity.

■

Aby proces s nižší úrovní integrity nemohl smazat objekt vyšší úrovně, je nutné uchovávat objekty ve složkách, které mají stejnou úroveň integrity jako samy objekty.

■

Pro správu a zobrazování mandatory labels potřebujete nástroje whoami, icacls, Process Explorer a můj program chml.

Řízení integrity Windows je v určitém smyslu jednou z největších strukturálních změn ve Windows v delším časovém rámci. Jeho základní úlohou je ochrana proti škodlivému kódu z Internetu. Podle mého odhadu však Řízení integrity Windows zaujme své místo i v arsenálu běžně používaných bezpečnostních nástrojů Microsoftu.

204

Kapitola 4 â&#x20AC;&#x201C; Kontrola integrity windows

5 Bitlocker – řešení problémů se zabezpečením přenosných počítačů Šifrování disků BitLocker (BitLocker Drive Encryption) je jednou z nejužitečnějších součástí systému Windows Vista v provedení Enterprise a Ultimate. Pro mnoho firem může být právě BitLocker tím jediným důvodem, proč přejít z Windows XP na novější verzi Windows. Co může být tak nesmírně důležité? Řešení problémů se zabezpečením notebooků. Za chvíli rozebereme, o jaký problém se jedná a samozřejmě i to, jak ho BitLocker pomáhá řešit. Nejdříve je však nutné říci, co vlastně BitLocker je… BitLocker provádí dvě hlavní věci: ■

Šifruje všechny sektory na diskové jednotce operačního systému Windows.

■

Umí zkontrolovat – pomocí hardwarového čipu TPM (Trusted Platform Module) – integritu součástí, které se účastní prvních fází zavádění systému.

Tato kombinace chrání operační systém a data před tzv. offline útoky – tedy před typem útoku, kdy je obcházen operační systém, nebo útokem prováděným v době, kdy je operační systém ve stavu offline. Dejme tomu, že máme notebook, připojený do domény Active Directory. Uživatelé se musí přihlásit k doméně a teprve poté mohou na notebooku pracovat, přičemž soubory s citlivými daty jsou chráněny také seznamem položek v seznamu ACL systému NTFS. Jestliže však notebook někdo ukradne, stačí zloději prostě vyndat pevný disk a přesunout ho do jiného počítače s jiným operačním systémem. (Kterým může být jak zcela jiný typ operačního systému (například Linux), tak jiná instalace Windows.) Heslo uživatele a seznamy ACL už pak neochrání vůbec nic a zloděj si může v klidu číst jakákoli nezašifrovaná data. Škody se dají na současné verzi Windows zmírnit pomocí několika nástrojů, především šifrovaného souborového systému EFS (Encrypting File System) a Služeb správy přístupových práv RMS (Rights Management Services), které jsou ve Vistě stále přítomny (a vylepšeny), ale stále je u nich nutná složitější úvodní konfigurace a průběžná péče, přičemž tyto služby nechrání vše, co na disku je. Pojďme se ale podívat na to, jak velkým problémem je zabezpečení notebooků v běžném životě.

206

Kapitola 5 – Bitlocker – řešení problémů se zabezpečením přenosných počítačů

Zabezpečení notebooků v dnešní době Nedostali jste náhodou v poslední době dopis od své banky, ve kterém vám bylo oznámeno, že nešťastnou náhodou došlo ke ztrátě, úniku, krádeži nebo jinému poškození vašich osobních údajů (a banka samozřejmě v dopise popřela svou vinu na této události …)? Mně se to stalo a tím se moje jméno dostalo mezi přibližně 93 milionů záznamů o zneužití osobních dat, které od roku 2005 sleduje společnost Privacy Rights Clearinghouse. To máme 93 milionů lidí (ve skutečnosti o něco méně, někteří nešťastníci jsou evidování vícekrát) za méně než 2 roky! (http://www.privacyrights.org/ar/ChronDataBreaches.htm) Plně chápu, že čtení podobného dopisu není nic příjemného, ale ani IT profesionálové a ředitelé IT oddělení (CIO), kteří tyto dopisy musí psát, se přitom nijak dobře necítí… chtěli byste si to s nimi vyměnit? Součástí naší práce je ochrana osobních informací (personally identifiable information, PII), duševního vlastnictví (intellectual property, IP) a business intelligence (BI), uložených na našich počítačových systémech … a když se nám to nepodaří, má to stále horší důsledky. Tyto důsledky spadají do jedné ze třech hlavních oblastí: finanční pokuty, právní nebo zákonné reakce a negativní image firmy (spolu se sníženou důvěryhodností). Někdy má druhá a třetí oblast zásadní vliv na výši té první. Za prvé, ztráta dat něco stojí. Ministerstvo spravedlnosti USA předpokládá, že hodnota ukradeného duševního vlastnictví stála americké firmy jen v roce 2004 asi 250 miliard dolarů. Do těchto ztrát je možné započítat ztrátu příjmů, sníženou tržní kapitalizaci, a případně i ztrátu konkurenceschopnosti. Za druhé, neustále se zvyšuje počet různých právních norem a směrnic. Mezi právní předpisy, týkající se mezinárodních podniků, patří například: ■

Health Information Portability and Accountability Act (HIPAA)

■

Sarbanes-Oxley Act (SBA)

■

Gramm-Leach-Bliley Act (GLBA)

■

California Senate Bill 1386

■

Securities Exchange Commission (SEC) Rule 17a

■

The Organisation for Economic Co-Operation and Development (OECD) Fair Information Practices

■

Evropské směrnice o ochraně dat a U.S. Safe Harbor Principles

■

Kandské Personal Information Protection a Electronic Documents Act (PIPEDA)

■

Australský Federal Privacy Act

Roztřídění tohoto seznamu podle důležitosti pro vaši firmu přenechejte raději vašim právníkům. Uvádím ho tu proto, abyste si uvědomili, že pokud ještě nejste z právního či morálního hlediska nuceni chránit citlivá data, za pár měsíců (let) budete. Z toho vyplývá jeden nehezký důsledek: náklady na splnění výše uvedených právních norem sice mohou dosáhnout značné výše, ale ještě vyšší bude cena za to, když tato nařízení nedodržíte (postih může být jak občanskoprávní, tak trestní).

Šifrování disků BitLocker – přehled

207

Třetí faktor, který je pro mnohé CEO tím nejhorším vůbec a často jim nedovolí usnout, je strašná představa jejich fotografie na titulní stránce Financial Times s palcovým titulkem ve smyslu „Dalším trulantům unikla data!“. Reputace a věrohodnost jsou nesmírně důležité faktory úspěšného vývoje firmy, které ovlivňují úplně všechno, počínaje cenou akcií a výškou prodeje konče. Jeden z průzkumů (prováděný již v roce 2001) například zjistil, že 64 procent online prodejců neodebírá zboží od určitých výrobců právě kvůli jejich potížím při ochraně soukromých dat. V zájmu spravedlnosti je třeba uvést, že skutečných i potencionálních příčin úniků dat je hodně, ale jedna z nich mezi ostatními jasně vyniká: pracovníci stále více cestují a na tyto služební cesty si sebou berou ve svých firemních noteboocích stovky gigabajtů důvěrných dat. V mnoha případech se po odcizení (případně ztrátě) notebooku tyto citlivé údaje dají z notebooku velmi snadno vytáhnout. Podle odhadů se jen v USA ztratí každý rok asi 600 000 firemních notebooků – některé jsou ukradeny, hodně často je ale lidé prostě zapomenou v taxíku nebo na letištích. Jedna velká mezinárodní firma soukromě přiznává, že průměrně přichází o jeden notebook denně, a to prosím jen v taxíkách jednoho města. Katastrofa podobného druhu může postihnout i vás, jak se to stalo například firmám v New Orleans, které měly své kanceláře hlídány soukromou bezpečnostní službou až do doby, kdy počítače i data byly snadno zcizitelné v době chaosu po průchodu hurikánu Katrina městem. Nezávisle na tom, jak o své notebooky přijdete, musíte očekávat, že obsahují data, která mohou potopit firmu i vaši kariéru. Možná, že si vzpomínáte na známý případ, kdy jeden ze zaměstnanců úřadu péče o armádní veterány velmi svérázným způsobem poděkoval těm, kdo během několika posledních desetiletí bránili naši zem (vzal si domů notebook obsahující databázi jejich osobních údajů, který mu byl doma okraden. Data „samozřejmě“ nebyla zašifrována. (Koneckonců, nic neříká „díky za ochranu bezpečí“ lépe než usnadnění krádeže identity.) I když podobné kalamity přežijete ve zdraví, stejně jednou přijde doba, kdy končí životnost vámi spravovaných počítačů a je nutné je nějakým způsobem vyřadit. Přitom je nutné bezpečně smazat nebo úplně odstranit data, která jsou na nich uložena. Odpověď? Zašifrujte úplně celý disk a šifrovací klíč ukryjte někde, kde ho nikdo nenajde. K tomu účelu je součástí Visty novinka BitLocker. Ve zbývající části kapitoly budeme zkoumat, jak BitLocker začíná řešit problémy se zabezpečením notebooků.

Šifrování disků BitLocker – přehled Před několika lety se Microsoft pustil do projektu Next Generation Secure Computing Base, jehož výsledkem je právě BitLocker. Při návrhu BitLockeru dbal tým systémového zabezpečení Windows na to, aby přišel s řešením zahrnujícím přenosné počítače (notebooky), pracovní stanice i servery, a tak nabídnul možnost ochrany proti zlodějům, kteří zkouší v prostředí jiných operačních systémů nebo softwarových nástrojů prolomit ochranu na úrovni operačního systému Windows a souborového systému. Tento typ ochrany vyžaduje šifrování disků. BitLocker je navržen tak, aby byl z hlediska uživatele zcela transparentní. Na rozdíl od EFS nebo RMS tu tedy uživatel nemusí nic komplikovaně nastavovat, aby tento typ ochrany mohl používat, a má přitom jistotu, že je všechno zašifrováno (tutéž jistotu pak máte i vy a firemní právníci).

208

Kapitola 5 – Bitlocker – řešení problémů se zabezpečením přenosných počítačů

POZNÁMKA:

Co v tomto případě znamená slovo vše? Ve Windows Vista je nástrojem BitLocker možné zašifrovat celou diskovou jednotku OS Windows (tedy jednotku, na které jsou Windows nainstalovány). Později si popíšeme přesně způsob šifrování jednotlivých sektorů a probereme způsob práce s aktivním oddílem (používaným pro zavádění systému). Přídavné diskové jednotky pro data nejsou BitLockerem oficiálně ve Vistě podporovány, tato podpora však přibude ve Windows Serveru 2008 a Vista Service Packu 1.

Když Microsoft začal prvně hovořit o technologii BitLocker (tehdy ještě pod názvem „secure startup“), vypadalo to jako sice užitečná, ale nepříliš praktická záležitost, protože vyžadovala speciální čip TPM (Trusted Platform Module), vestavěný do počítače. Ve Vistě je naštěstí BitLocker implementován trochu jinak, zde je možné celý disk zašifrovat nejen pomocí zmíněného čipu TPM, ale také v případě, kdy máte k dispozici kombinaci kompatibilního USB flash disku, USB portu a BIOSu. (BIOS a kompatibilita USB je součást testovacího procesu, který musí výrobce podstoupit, pokud si chce dát na počítač logo OS Vista.) Díky tomu je možné používat BitLocker na mnoha existujících počítačích, i když je nutné očekávat výskyt problémů. Proto je velmi vhodné otestovat různé kombinace systému, BIOSu a USB flash disků, než se pustíte do hromadného zavádění BitLockeru. Je jasné, že začít je třeba u notebooků, protože ty jsou ztráceny nebo ukradeny nejčastěji. Pracovní stanice jsou také někdy ukradeny nebo umístěny do málo zabezpečeného prostředí (například sdílených prostorách nebo kanceláří s neuzamykatelnými dveřmi). BitLocker bude součástí i chystaného Windows Serveru 2008 (kódové jméno Longhorn), kde bude ještě doplněn o další vlastnosti. Přestože doufám, že nepatříte mezi ty, co dokážou umístit server na nesprávné místo, upozorňuji na to, že především servery jsou vysoce ceněným cílem zlodějů. Citlivé údaje, například duševní vlastnictví nebo osobní informace, však najdeme na všech typech počítačů.

Součásti BitLockeru BitLocker obsahuje čtyři hlavní součásti: ovladač TPM od Microsoftu, API s názvem TBS (TPM Base Services), vlastní šifrování disku (BitLocker Drive Encryption) a poskytovatele WMI. Obdobně jako většina hardwaru i čip TPM vyžaduje ovladač, který ho zpřístupní operačnímu systému a aplikacím. Microsoft dodává ovladač TPM jako součást operačního systému Windows Vista a tak dosahuje požadované stability a snadného využívání bezpečnostních prvků TPM. Pokud chcete zkombinovat TPM a BitLocker, musíte systému Vista povolit používat ovladač Microsoftu, který spolupracuje s čipy TPM verze 1.2 nebo novějšími verzemi. (Více informací najdete dále v této kapitole, v části věnované čipu TPM.) TPM Base Services (TBS) jsou rozhraní pro programování aplikací (API), umožňující aplikacím přístup ke službám čipu TPM. Z tohoto hlediska je BitLocker jen „aplikací“ využívající TBS, i když jde o součást operačního systému. Výhodou této architektury je fakt, že TPM mohou využívat i jiné aplikace. Až bude Vista na trhu delší dobu, objeví se podle mého názoru další bezpečnostní aplikace, které budou volat funkce rozhraní TBS. TBS umožňuje také spravovat TPM přímo v prostředí Windows Vista, kde je k dispozici konzola Správa čipu TPM (TPM Management Console), a uživatelé proto nemusí procházet různé nekonečné obrazovky BIOSu, aby mohli změnit parametry ochrany.

Šifrování disků BitLocker – přehled

209

Šifrování disku BitLocker je samo o sobě součást operačního systému, která šifruje a dešifruje data na diskové jednotce a využívá TPM pro kontrolu součástí, která se podílí na úvodních fázích startu počítače, před spuštěním zavaděče OS. BitLocker má různé volby, kterými lze měnit jeho implicitní chování; většina z nich je dostupná formou zásad skupiny. BitLocker je rovněž možné úplně řídit prostřednictvím skriptů. Kromě voleb zásad skupiny nabízejí BitLocker i TBS své poskytovatele pro WMI (Windows Management Interface). WMI je specifická implementace obecného standardu WBEM (Web-Based Enterprise Management) ve Windows, proto lze BitLocker ovládat v libovolné konzole WBEM. V praxi se však více hodí možnost skriptovat BitLocker právě přes rozhraní WMI a Vista v tomto směru nabízí skriptovací pomůcku manage-bde.wsf, která dovoluje správcům nastavit a řídit BitLocker v okně příkazového řádku nebo z dávkového souboru, a to buď lokálně nebo vzdáleně. Za zmínku stojí také to (i když to budeme podrobněji probírat dále v této kapitole), že BitLocker spolupracuje s doménovými službami Active Directory a ukládá v nich informace o TPM a sobě tak, aby je bylo možné použít pro obnovení po havárii.

Co je TPM? TPM (Trusted Platform Module, modul důvěryhodné platformy) je mikročip poskytující některé základní bezpečnostní funkce, většinou vyžadující přítomnost šifrovacích klíčů. Aby mohl být považován za skutečně bezpečný, je TPM instalován trvale na základní desce počítače a se zbytkem systému komunikuje po hardwarové sběrnici. Klasickým problémem při nasazení libovolného softwarového bezpečnostního řešení je to, že pokud se útočníkovi povede spustit zákeřný kód ještě před spuštěním programu zajišťujícího bezpečnost, je možné celou ochranu obejít. Jen velmi těžko lze také důvěřovat softwaru, že jím ohlášený vlastní stav je skutečně platný. Například rootkity dokážou změnit operační systém tak, aby lhal. Jestliže můžete zfalšovat operační systém, tak komu se vlastně dá věřit? Tento problém pomáhá řešit právě TPM, který umí sestavit řetěz důvěryhodnosti, začínající samotným hardwarem. Jestliže tento řetěz začíná na hardwarové úrovni, neexistuje žádný praktický způsob, jak vložit zákeřný kód „před“ TPM. Čip TPM ve skutečnosti velmi spolehlivě prověřuje součásti hardwarové platformy (počítače) a celou úvodní fázi zavádění počítače. BitLocker na toto ověření spoléhá. TPM se v mnoha ohledech podobá známým „smart cards“. Přestože na TPM nejsou uloženy žádné certifikáty, umí tento čip vytvořit kryptografické klíče a uchovávat v sobě trvale klíče soukromé. Jestliže nějaký klíč vytvořený v TPM není nikdy zpřístupněn žádné jiné součásti, softwaru, procesu nebo osobě, je skutečně velmi těžké ho nějak kompromitovat (a privátní klíč není nikdy vypuštěn mimo TPM). Čip TPM používá svůj vlastní interní firmware a logické obvody pro zpracování instrukcí, není proto nijak závislý na operačním systému a je odolný proti chybám externího softwaru. TPM umí také šifrovat data, která mu předá OS, například symetrické klíče pro šifrování velkých bloků dat. Pokud je tento typ dat zašifrován čipem TPM, může být dešifrován opět jen tímto čipem. Tento proces je v literatuře často označován jako „wrapping a key“ nebo „binding a key“ (zabalení klíče) a pomáhá chránit klíč před prozrazením. (Samotným zabaleným datům se někdy říká blob dat, ale slovo „blob“ má různé významy.)

210

Kapitola 5 – Bitlocker – řešení problémů se zabezpečením přenosných počítačů

Každý TPM má hlavní „wrapping key“, označovaný jako Storage Root Key (SRK), který je uložen uvnitř samotného čipu. TPM musí mít také tzv. Endorsement Key (EK), který je pro něj jednou trvale (doživotně) nastaven. Jiné klíče jsou odvozeny z tohoto klíče nebo jím alespoň podepsány. Každý TPM má hlavní „wrapping key“, označovaný jako Storage Root Key (SRK), který je uložen uvnitř samotného čipu. TPM musí mít také tzv. Endorsement Key (EK), který je pro něj jednou trvale (doživotně) nastaven. Jiné klíče jsou odvozeny z tohoto klíče nebo jím alespoň podepsány. Při každém spuštění počítače probíhají určitá měření, jejichž výpočty jsou uloženy v platformových řídicích registrech TPM (PCR, platform control register). PCR jsou podrobněji probrány dále v této kapitole. Počítače obsahující čip TPM tedy mohou vytvářet i klíče, které nejsou jen „zabaleny“, ale také úzce vázány k výsledkům měření určité platformy, uloženým v PCR. Tento typ klíče lze „rozbalit“ jen v případě, kdy změřené hodnoty pro danou platformu jsou stejné jako hodnoty platné při vytvoření klíče. Celému procesu se říká „zapečetění“ (sealing) klíče do TPM. Pro dešifrování se vžil pojem „rozpečetění“ (unsealing). TPM umí zapečetit a rozpečetit také data generovaná mimo TPM. Se zapečetěným klíčem a softwarem typu BitLocker se dají data zašifrovat tak, aby je bylo množné znovu přečíst jen při splnění určitých hardwarových a softwarových podmínek. Tento proces je základem celého ověřování komponent zaváděných před operačním systémem, které provádí BitLocker. A nyní špatné zprávy. Aby bylo možné BitLocker použít v kombinaci s TPM, musí být tento čip vyroben podle specifikace standardu verze 1.2 nebo verze novější (verze vytváří Trusted Computing Group). Pokud byl váš počítač vyroben před rokem 2006, je velmi nepravděpodobné, že by v něm byl čip TPM ve verzi 1.2 (většina současných počítačů tento čip neobsahuje vůbec). Kromě kompatibilního TPM musí mít počítač ještě kompatibilní BIOS. Většina počítačových výrobců uvolňuje aktualizace svých BIOSů, zajišťujících kompatibilitu s Vistou na počítačích vybavených čipem TPM ve verzi 1.2. Další údaje o specifikacích TPM najdete na stránce https://www.trustedcomputinggroup. org/specs/TPM. Výrobci čipů TPM spolupracují s výrobci počítačů a starají se o to, aby jejich čipy TPM vyhovovaly restrikcím na vývoz šifrovacích zařízení; velmi často si také své čipy nechávají certifikovat od různých institucí a úřadů. Jako ukázku běžně používaného čipu TPM uvádím výrobní řadu firmy Infineon, která je popsaná na webu firmy (http://www.infineon.com (http:// www.infineon.com/cgi-bin/ifx/portal/ep/channelView.do?channelId=-84648&channelPage=%2Fep%2Fchannel%2FproductOverview.jsp&pageTypeId=17099).

Nezoufejte: počítače nevybavené kompatibilním čipem TPM mohou také využívat šifrovací nástroje BitLockeru, za předpokladu, že jejich BIOS umožňuje během prvních fází spouštění počítače načítat údaje z USB flash disku. Takových počítačů je kolem nás dost.

Šifrování celého pevného disku Od nástupu Windows 2000 je možné šifrovat soubory na pevném disku prostřednictvím souborového systému EFS. Jeho použití je však omezeno několika faktory, které mu zabránily stát se universálním řešením při zabezpečení notebooků. EFS vyžaduje interakci uživatele, který musí zadat, jaké soubory mají být šifrovány. Ačkoliv nové zásady skupiny Visty umožňují, aby šifrované složky vybral přímo správce (například složku

Šifrování celého pevného disku

211

Dokumenty uživatele), zbývá stále ještě spousta jiných míst, kde mohou být ukládány citlivé údaje – například Temporary Internet Files nebo automaticky vytvářené záložní kopie dokumentů Office. Je velmi náročné najít všechna taková místě a zajistit jejich zašifrování. BitLocker oproti tomu prostě zašifruje každý datový sektor na diskové jednotce. Tomu se říká „šifrování celého disku“ nebo také „šifrování celé jednotky“ (full disk encryption, full volume encryption). Technické pojmy jsou někdy používány až příliš volně, proto bychom se mohli dohodnout na jejich konsistentním používání Diskový oddíl (partition) je struktura na fyzickém disku, obvykle definovaná v tabulce oddílů disku (partition table), což je specifická datová struktura, uložená na několika prvních sektorech disku. Jednotka (volume) je logická struktura ve Windows, složená z jednoho nebo více oddílů. Na systému Vista je stejně jako v předchozích verzích Windows jednotce přiřazeno písmeno disku, čili to, co normálně označujeme pojmem „disk C:“, je ve skutečnosti jednotka C:. Správce jednotek (logických disků ) je součást Windows, která sestavuje oddíly do jednotek, a zbytek Windows pak nepracuje přímo s oddíly, ale jednotkami. Téměř ve všech případech bude systém Vista uložen na jednotce tvořené jediným oddílem; tomuto uspořádání se říká „simple volume“ (jednoduchá jednotka). Na serverech se často nachází i jiné typy jednotek. Jedna jednotka může být například uložena na více oddílech a tak má zajištěnu redundanci dat nebo vysoký výkon (typické pro pole RAID). BitLocker funguje na úrovni jednotky, nikoli oddílu. Ve Vistě BitLocker pracuje jen s jednoduchými jednotkami. Jeden oddíl na disku je označen jako aktivní. Jedná se o oddíl, ze kterého je zaváděn operační systém (Microsoft píše v dokumentaci toto: „systémový oddíl označuje diskový svazek obsahující soubory specifické pro konkrétní hardware, které jsou potřebné ke spuštění systému Windows“. Používaná terminologie se bohužel od nástupu Windows NT mění: aktivní oddíl byl nazván systémovým, a oddíl s nainstalovanými Windows byl označen jako spouštěcí (boot partition) neboli „oddíl, na kterém jsou uloženy soubory operačního systému Windows (typicky složka Windows) a jeho podpůrné soubory (typicky složka Windows\System32)“. Nejsnadněji si tento rozdíl zapamatujte tak, že oba pojmy prostě prohodíte: „počítač je spouštěn ze systémového oddílu, systém je nainstalován na spouštěcím oddílu“. V mnoha případech – před nástupem Visty ve většině případů – byl systémový oddíl shodný se spouštěcím. (Další informace na toto téma najdete v dokumentu http://www.support.microsoft.com/kb/314470/.) V dokumentaci Windows Vista najdete nový pojem jednotka OS Windows (Windows OS Volume), který vyjadřuje dřívější spouštěcí oddíl a je tudíž jednotkou, na které je OS nainstalován; aktivní oddíl je nový pojem pro dřívější systémový oddíl neboli jednotku, ze které je počítač spuštěn. Máte-li na počítači nainstalováno více operačních systémů, máte nejspíše více jednotek OS Windows, aktivní však může být vždy jen jeden oddíl současně. Pojmy disk a drive mohou v anglické dokumentaci (v češtině v obou případech „disk“) znamenat různé věci podle aktuálního kontextu. Disk se může vztahovat na fyzickou jednotku („pevný disk selhal“) nebo logickou strukturu („disk C:“). Pokusím se tomuto pojmu vyhnout s výjimkou případů, kdy ho použiji při odkazu na jednotku s přiřazeným písmenem disku. Koncoví uživatelé jsou zvyklí používat slovo „disk“, nikoli „jednotka“. A samozřejmě BitLocker Drive Encryption má slovo „drive“ (disk) přímo v názvu.

212

Kapitola 5 – Bitlocker – řešení problémů se zabezpečením přenosných počítačů

Sektor je nejmenší adresovatelný blok prostoru na disku. Téměř všechny sektory současných disků mají velikost 512 bajtů, ale s postupným růstem velikosti disků bude tato velikost pravděpodobně stoupat také. Cluster (alokační jednotka) je skupina sektorů, tvořící nejmenší blok prostoru pro jeden soubor. Velikost clusterů se liší podle kapacity jednotky, ale protože dnes už snadno nikdo nepoužívá pevné disky menší než 2 GB, vyskytuje se dnes především velikost clusteru 4 096 bajtů (tedy 4 KB neboli 8 sektorů). Pokud tedy chcete uložit soubor o velikosti 1 bajt, bude mít tento soubor stejně pro sebe vyhrazen celý cluster, a zabere tak 4 KB místa na pevném disku. (Další informace na toto téma najdete v článku Microsoft Knowledge Base na adrese http://www.support.microsoft.com/kb/314878/.) Prvnímu sektoru jednotky se říká zaváděcí sektor (boot sector) a obsahuje kód použitelný pro spuštění počítače, pokud je daná jednotka zároveň aktivním oddílem. Předchozí text píšu proto, aby mi pomohl vysvětlit vám, co BitLocker nešifruje a jak šifrovací algoritmus BitLockeru funguje. Co tedy není zašifrováno? Za prvé, BitLocker vyžaduje nejméně dvě diskové jednotky. Aktivní oddíl bude tvořen menší nešifrovanou jednotkou, použitou ke spuštění počítače. Vzhledem k tomu, že není šifrovaná, neukládejte na ni žádná citlivá data. TIP:

V praxi by správci měli nastavit přístupová oprávnění NTFS tak, aby uživatelé na tuto jednotku vůbec zapisovat nemohli.

Druhou jednotkou bude jednotka OS Windows, na které bude nainstalována Vista. Jednotka OS Windows bude úplně zašifrována BitLockerem, s výjimkou následujících částí: ■

Zaváděcího sektoru

■

Všech poškozených sektorů (označených souborovým systémem jako nečitelné)

■

Metadat jednotky

Metadata jednotky jsou tvořena datovou strukturou, kterou BitLocker používá k uložení zašifrovaných klíčů potřebných pro dešifrování dat a některých dalších statistických a referenčních údajů o jednotce. Systém BitLocker zapíše celkem tři redundantní kopie těchto metadat, aby si zajistil, že v případě znepřístupnění jedné (nebo i dvou!) kopie metadat kvůli vadnému sektoru bude stále možné načíst data z disku. Jednotka zašifrovaná BitLockerem bude tedy vypadat jako na obrázku 5.1 Přestože sektory s metadaty nejsou šifrovány jako celek, jsou všechny klíče uložené v metadatech silně šifrovány jinými klíči. K tomu se za chvíli vrátíme. Z této architektury vyplývá, že všechna data zapsaná na disk budou zašifrována. V některých případech to znamená dokonce dvojí šifrování. Jestliže například soubor na šifrované jednotce zašifrujete systémem EFS, bude nejdříve šifrován systémem EFS a poté BitLockerem. Pro úplné zašifrování disku BitLocker používá ovladač filtru, což je software běžící v režimu jádra, který komunikuje se správcem jednotek a souborovým systémem. Zjednodušený pohled na architekturu ovladače filtru BitLockeru vidíte na obrázku 5.2.

Šifrování celého pevného disku

213

OBRÁZEK 5.1: Typické rozvržení jednotky zašifrované BitLockerem Boot Sector (Plaintext)

Sectors: Windows, applications, data (encrypted)

OBRÁZEK 5.2: Schéma ovladače filtru BitLockeru Application User Mode Kernel Mode I/O Manager

File System

BitLocker Filter Driver (fvevol.sys)

Volume Manager

Partition(s) on disk

Ve Windows Vista není možná komunikace s jednotkou OS Windows, o které by BitLocker nevěděl.

Algoritmus šifrování Až doposud jsme mluvili o tom, že data jsou prostě „šifrována“, aniž bychom si tento pojem vysvětlili podrobněji. Uděláme to v této části. V roce 2006 napsal Niels Ferguson – jeden z vývojářů BitLockeru – podrobný článek o průběhu výběru nejlepšího šifrovacího algoritmu pro BitLocker, na základě předem daných kritérií. Microsoft tento dokument publikoval ve formátu PDF a vy si ho můžete stáhnout na adrese http:// www.microsoft.com/downloads/details.aspx?FamilyID=131dae03-39ae-48be-a8d6-8b0034c92555&DisplayLang=en.

Vybraný šifrovací algoritmus musel splnit tyto podmínky: ■

Šifrování a dešifrování sektorů o velikosti 512 bajtů a větších (se kterými se během životnosti Visty musí počítat).

214

Kapitola 5 – Bitlocker – řešení problémů se zabezpečením přenosných počítačů

■

Schopnost použití různých algoritmů pro různé sektory.

■

Ochrana důvěryhodnosti dat ve formátu prostého textu.

■

Dostatečná rychlost, aby uživatelé nevnímali jeho činnost.

■

Ověření spolehlivosti algoritmu důkladnou veřejnou kontrolou a jeho obecně uznávanou bezpečností.

■

Útočník nesmí být schopen řídit ani odhadnout žádný prostý text změnou šifrovaného textu.

Výsledný zašifrovaný text také nesměl zabírat více místa na pevném disku (protože když zašifrujete celý pevný disk, nemáte už žádné místo „navíc“). Microsoft se nakonec rozhodnul pro algoritmus AES (Advanced Encryption Standard), který je považován za jeden z nejbezpečnějších a nejrobustnějších šifrovacích algoritmů vůbec. Microsoft si to ještě pojistil tím, že do procesu šifrování přidal pár dodatečných prvků. Za prvé, pro každý sektor disku je použit odlišný klíč. Jedna část tohoto klíče je odvozena z čísla sektoru. Díky tomu se tyto klíče dají snadno vytvářet a není nutné je nikde ukládat ani spravovat, přitom se však ze zašifrovaných dat nedají snadno odvodit. Za druhé, BitLocker ještě před vlastní šifrování AES přidává dvouprůchodový difuzor (rozptylovač). Podstatu difuzoru je téměř nemožné vysvětlit bez podrobného výkladu některých kryptografických principů. V našem případě difuzor změní uspořádání bajtů tak, aby vyloučil možnost prolomit šifru sledováním rozdílů, které má změna prostého textu na podobu šifrovaného textu. Šifrování se tedy díky difuzoru ještě posiluje. Výsledný šifrovací algoritmus je schematicky zachycen na obrázku 5.3 Algoritmus je navržen tak, aby používal 512bitový klíč, označovaný jako FVEK (full volume encryption key, klíč pro šifrování celé jednotky). Klíč FVEK je rozdělen do dvou částí (každá je jedinečná a odlišná). Jedna část je použita pro odvození klíče sektoru používaného difuzorem, druhá část slouží jako šifrovací klíč AES. BitLocker je navržen tak, aby pro každou část vyhradil 256 bitů, implicitně však používá 128bitové klíče. Delší klíče sice významně posilují zabezpečení, ale značně zvyšují zátěž počítače. V případě potřeby je možné BitLocker nastavit tak, aby pracoval s klíči větší délky. OBRÁZEK 5.3: Přehled šifrovacího algoritmu BitLockeru Encrypted Sector (Plaintext)

Full Volume Encryption Key (FVEK)

Derive Sector Key

Diffuser

AES

Encrypted Sector (Ciphertext)

Šifrování celého pevného disku

215

Ukládání klíčů Když už tak hovoříme o klíčích… kde je získáme a kam budou uloženy? V předchozí části byly zmíněny dva klíče: FVEK a klíč sektoru, ale to je jen vrcholek ledovce. Začneme jednoduše: klíč sektoru není nutné nikde ukládat. Namísto toho je při každém použití znovu vytvořen na základě FVEK a čísla šifrovaného nebo dešifrovaného sektoru. Tato „komplikace“ je velmi jednoduše zdůlvodnitelná. Pokud by totiž všechny sektory používaly stejný klíč, mohl by útočník zapsat větší počet identických sektorů známých dat a pokusit se z výsledného zašifrovaného textu zjistit informace o klíči. Klíče pro jednotlivé sektory však zajišťují, že i stejná data ve formátu prostého textu, zapsaná do různých sektorů, budou po zašifrování vypadat úplně jinak. Nesmírně důležitým klíčem je FVEK. Připomíná hlavní klíč, kterým lze otevřít libovolné dveře ve velké kancelářské budově. FVEK je vytvořen pro každou jednotku šifrovanou BitLockerem zvlášť a je používán při šifrování každého sektoru na této jednotce. BitLocker ukládá tento klíč do metadat jednotky (vskutku šikovně zvolené místečko!). To znamená, že jsou uloženy jeho tři redundantní kopie a že cestuje spolu se zašifrovanou jednotkou. Kdyby tedy jednoho dne vaše základní deska zkolabovala a museli jste disk přenést do jiného počítače, zůstane klíč FVEK uložen na disku. Samozřejmě není žádoucí ukládat FVEK do metadat jednotky jako prostý text, to by úplně zničilo celé zabezpečení. Proto je FVEK sám zašifrován jiným klíčem, který je označován pojmem VMK (volume master key, hlavní klíč jednotky). Takže dospíváme k závěru, že pro šifrování dat klíčem FVEK musíme mít ještě klíč VMK. A ten je uložen kde? VMK je ve skutečnosti také uložen v metadatech jednotky. Díky tomu může BitLocker ve své výchozí konfiguraci nastartovat a přistupovat k zašifrované jednotce bez jakéhokoli zásahu uživatele. Ani VMK není samozřejmě uložen ve formátu čitelného textu; je zašifrován (v jazyku BitLockeru „chráněn jedním nebo několika ochránci klíčů [key protectors]). V BitLockeru musí existovat množství způsobů, jak načíst zašifrovaná data. Důležitou částí jakéhokoli schématu nasazení kryptografických metod ve firmách je pečlivé plánování postupů v případě nutnosti obnovit data v situaci, kdy není možné normálně přistupovat k šifrovacím klíčům. Pro každý způsob přístupu k datům – ať již v normálním režimu nebo při obnově po havárii – je k dispozici klíč VMK, zašifrovaný a uložený trochu jiným způsobem, s jiným ochráncem klíče. Ve výchozím nastavení vytvoří BitLocker heslo pro obnovení (recovery password) a použije také TPM. Takto jsou vytvořeny dva ochránci klíčů („TPM Only" a „numeric password“). Nejdříve se podíváme na ochránce klíčů TPM Only. Možná už jste slyšeli zjednodušené tvrzení, že VMK je „uložen v TPM“, ale to není přesné. Z hlediska TPM je BitLocker prostě jedna z mnoha možných aplikací. BitLocker předloží čipu TPM „blob“ dat (obsahující VMK) a požádá TPM, aby ho „zabalil“ (zašifroval pomocí svého SRK) a zapečetil (umožnil jeho dešifrování jen v případě, kdy kontrolní hodnoty uložené v PCR odpovídají nově naměřeným hodnotám). TPM vrátí BitLockeru zašifrovanou, zapečetěnou a zabalenou verzi dat, která poté BitLocker uloží do metadat jednotky. V tomto případě data balí i pečetí čip TPM.

216

Kapitola 5 – Bitlocker – řešení problémů se zabezpečením přenosných počítačů

Klíč VMK je tedy chráněn čipem TPM. Čip TPM je vyhazovačem v exkluzivním nočním klubu. Nikdo se nedostane dovnitř, pokud to on neschválí; ukážete-li však správnou VIP kartičku (průkaz integrity), odstoupí stranou a nechá vás projít. Kdykoli je řeč o obnově zašifrovaných dat, je nutné myslet na to, jak data vydolujete zpět, pokud se něco pokazí. V terminologii BitLockeru se tento postup nazývá obnovení (recovery). Obnovení umožňuje druhý ochránce klíče. V grafickém uživatelském rozhraní hovoříme o heslu pro obnovení (recovery password), přestože interně jsou použity dvě varianty: číselné heslo pro obnovení nebo binární klíč pro obnovení. „Klíč pro obnovení“ a „heslo pro obnovení“ se sice navzájem trochu liší, uživatelské rozhraní BitLockeru však používá jen „heslo pro obnovení“, aby uživatelé nebyli zmateni. Vy se zmást nedáte, že ne? Když zapnete BitLocker, musíte vytvořit heslo pro obnovení, které lze uložit v doménových službách Active Directory (AD DS), na USB flash disku, v textovém souboru nebo si ho můžete vytisknout. Toto heslo pro obnovení je vaše bezpečnostní pojistka, využitelná pro opětovné získání přístupu k disku nezávisle na stavu, a to i v případě, že jste si nastavili PIN a ten zapomenuli. Obnovu probírám podrobněji o něco dále v této kapitole. Jestliže si vyberete volbu pro uložení hesla pro obnovení do složky nebo jeho vytištění, případně když je kvůli nastavení zásady uloženo jen skupiny heslo do AD DS, je vytvořeno heslo pro obnovení složené jen z číslic 0 až 9 a to slouží jako ochránce klíče. Když si v nabídce vyberete uložení hesla na USB flash disk, nebo když zásada skupiny ukládá do AD DS úplný balíček pro obnovení, je vytvořena binární verze využívající plných 256 bitů a ta slouží jako ochránce klíče. Protože si uživatel (ve výchozím nastavení) musí vybrat nejméně jednu metodu uložení klíče pro obnovení, je generován alespoň jeden z těchto ochránců klíče (a mohou být vytvořeny oba dva, to záleží na volbách uživatele). V každém případě je v metadatech jednotky uložena další kopie VMK, zašifrovaná („chráněná“) pomocí hesla pro obnovení nebo klíče pro obnovení. Používání hesla pro obnovení bude probráno dále v této kapitole. Vzájemné vztahy jsou zachyceny na obrázku 5.4. Možná se divíte, proč se Microsoft vůbec zatěžoval přidáváním klíče VMK. Bylo by přece možné prostě aplikovat ochránce klíčů na FVEK a ten uložit, ale to by vedlo k riziku příliš častého provádění některých vysoce náročných výpočetních operací. VMK tomuto zabraňuje tak, že poskytuje potřebnou úroveň abstrakce, která je podstatná pro efektivní ukládání zašifrovaných dat na disku. Co míním „úrovní abstrakce“? Jedním ze základních principů zabezpečení a šifrování je to, že v případě kompromitace klíče je nutné všechna data, která jím byla zašifrována, zašifrovat znovu (samozřejmě pomocí jiného klíče). Představte si situaci, kdy někdo ztratí heslo pro obnovení a všichni mají obavu, aby se nedostalo do špatných rukou. Jestliže klíč pro obnovení odemknul FVEK, měli byste vytvořit nový FVEK a znovu zašifrovat všechna data. Ale pozor, zamyslete se nad tím ještě jednou. Jak velký pevný disk máte? Jak dlouho asi dešifrování a opětovné zašifrování dat potrvá? Jedná se o velmi časově náročnou operaci, proto lidí mají tendenci se jí vyhnout. Jestliže je použit ještě mezilehlý klíč (v tomto případě VMK), snižuje se pravděpodobnost toho, že by disk bylo nutné znovu zašifrovat. Ve skutečnosti se nám díky VMK zpřístupňují nové zajímavé vlastnosti. Někdy třeba budete chtít BitLocker kvůli něčemu vypnout. Dešifrování disku, provedení požadované operace

Šifrování celého pevného disku

217

OBRÁZEK 5.4: Výchozí ochránci klíčů

Data

Encrypt with FVEK

FVEK

Encrypt with VMK

Encrypted sectors on disk

Seal and Wrap via TPM VMK

Volume metadata Encrypt with Recovery Password

Recovery password stored in location set by user or administrator

3 copies on disk

a následné zašifrování by opět trvalo velmi, velmi dlouho. Namísto toho je možné BitLocker jen dočasně zastavit. V tomto případě je VMK zašifrován novým klíčem a tento klíč je zapsán do metadat jednotky jako prostý text. (Není proto divu, že se mu říká „clear key“.) Pro přístup k datům v tomto případě snaží velmi jednoduše načíst klíč (není nutný zásah TPM, vstup uživatele ani žádné ověřování) a použít ho k dešifrování klíče FVEK. Jedná se stále o druh ochránce klíče, přestože je explicitně navržen tak, aby přístup k datům nijak nechránil. Když znovu zapnete BitLocker, je vygenerován nový VMK, ochránce „clear key“ je smazán a na nový VMK jsou znovu aplikovány jiní ochránci klíče (například TPM a heslo pro obnovení), včetně opětovného zapečetění čipem TPM. To znamená, že data není nutné dešifrovat a znovu zašifrovat, uživatel nemusí vytvářet nová hesla pro obnovení, nebo se – například – učit nový PIN. Abstrakce je užitečná věcička…

218

Kapitola 5 – Bitlocker – řešení problémů se zabezpečením přenosných počítačů

POZNÁMKA:

Ano, je tu nepatrné riziko, že klíče mohou být zcizeny v době, kdy nedůvěryhodná osoba získá přístup k počítači v době, kdy je BitLocker vypnut. Proto se používání „clear“ klíče – čili vypnutí BitLockeru a šifrování – a následné obnovení původních klíčů nedoporučuje v prostředích s požadavky na vysokou úroveň zabezpečení. Rozhodně se také nepovažuje za vhodné, aby BitLocker zůstával vypnut po delší dobu.

BitLocker se dá vypnout například v době, kdy úmyslně provádíte větší zásah do hardwaru počítače, který by při zapnutém BitLockeru znamenal zneplatnění digitálních podpisů uložených v PCR TPM. Sem patří například výměna základní desky nebo přesun šifrovaného disku z jednoho počítače na jiný

Ověřování nebo řízení přístupu BitLocker nenahrazuje ověřování totožnosti (Autentikaci) ani řízení přístupu a přidělování práv (autorizaci). Ve své výchozí konfiguraci TPM zajišťuje ověření neporušitelnosti procesů spouštěných před začátkem zavádění operačního systému – což je věc, které se může velmi hodit – ale bezpečnost vašich systémů absolutně závisí také na zabezpečení samotného operačního systému. Proto musíte správně nastavit uživatelské účty, požadavky na silná hesla a oprávnění NTFS. BitLocker žádnou z těchto položek zabezpečení nenahradí. Jestliže je notebook například nastaven tak, aby se automaticky přihlásil na účet určitého uživatele, nemá tato volba na BitLocker žádný vliv. Když takový uživatel zapomene vypnutý notebook v hotelové hale, jsou data na něm uložená zašifrovaná, ovšem jakmile počítač někdo zapne, proběhne automatické přihlášení, ať už u něj daný uživatel je či není. BitLocker ve své výchozí konfiguraci však nedovolí útočníkovi přenést pevný disk do jiného počítače a tam ho připojit jako datový disk, čímž by obešel přihlašovací obrazovku Windows Vista. Není pochyb o tom, že výchozí konfigurace je výsledkem různých bezpečnostních kompromisů. Mnoho uživatelů prostě není ochotno provádět při spouštění systému žádné přídavné kroky, které předtím nedělali; budete proto muset řádně vyhodnotit prostředí a určit, zda výchozí konfigurace vyhovuje vašim potřebám.

Zvýšení bezpečnosti pomocí dalších ochránců klíčů V mnoha případech bude ochrana nabízená BitLockerem v jeho výchozí konfiguraci velkým zlepšením oproti původní situaci, a pravděpodobně postačí pro ochranu většiny každodenních rutinních obchodních dat. Ale v těch případech, kdy informace uložené na počítači mají vysokou hodnotu, nebo když chcete zabezpečení výrazně posílit, můžete BitLocker nastavit tak, aby používal ochránce klíčů spolupracující s TPM, které přidávají ještě druhou vrstvu ochrany. Vzhledem k tomu, že tyto dva typy ochránců klíčů spolupracují s TPM – a jen s TPM – říká se jim někdy také „TPM+“ nebo „TPM plus“ ochránci. BitLocker povoluje použít PIN nebo kryptografický klíč uložený na USB (tzv. „spouštěcí klíč“), který je poté nutný spolu s TPM k odblokování disku.

Ověřování nebo řízení přístupu

219

Takto je do fáze spouštění počítače přidán další krok a systém pak nelze spustit, dokud uživatel nezadá správný PIN či nezasune do slotu správný flash disk. Někteří uživatelé proti tomu protestují a stěžují si na nepohodlí. Jiní to naopak ocení a budou potěšeni očividným důkazem vylepšené ochrany jejich důvěrných dat. Bez TPM nebo spouštěcího klíče je vše potřebné k dešifrování obsahu uloženo přímo na disku, i když je to chráněno čipem TPM, a také TPM je na počítači zaručeně vždy přítomen. Když použijete PIN nebo spouštěcí klíč, můžete některé z povinných údajů fyzicky odnést pryč a znemožnit tak spuštění počítače. Jedná se o formu dvoufaktorového ověřování.

PIN Jestliže je nastaveno používání PINu, Správce spouštění systému Windows Vista přeruší zavádění systému a vyzve uživatele k zadání PINu, který může mít délku 4 až 20 číslic. Zadávání PINu probíhá mnohem dříve, než jsou inicializovány části grafického uživatelského rozhraní a shell, proto výzva vypadá asi takto:

PIN není heslo, které odemyká disk (nebo dešifruje VMK, a už vůbec ne FVEK) a pro jeho zpracování je nutná přítomnost TPM. (To znamená, že PIN není heslem pro obnovení.) Čip TPM obsahuje chráněné úložiště (secured storage area) pro uchovávání ověřovacích dat (někdy se zkracuje na „auth data“), a čísla PINů jsou samozřejmě jednou z hlavních věcí, která sem patří. Je-li PIN nastaven, je v ověřovacích datech uložena jedna jeho verze. Když je TPM požádán o rozpečetění klíče, porovná PIN zadaný uživatelem a informace uložené v chráněném úložišti.

220

Kapitola 5 – Bitlocker – řešení problémů se zabezpečením přenosných počítačů

Jestliže údaje nesouhlasí, nejsou klíče rozpečetěny a disk zůstává uzamčen. PIN není uložen na disku (ani v metadatech jednotky, ani v žádném souboru, který by byl řízen operačním systémem). Vzhledem k tomu, že systém s PINem je hardwarový, je velmi dobře chráněn. Specifikace TPM zahrnuje také obranu proti útokům hrubou silou. Jestliže se útočník pokusí uhodnout PIN opakovaným zadáváním náhodných nebo postupně generovaných čísel, TPM to odhalí a začne postupně prodlužovat interval, ve kterém je možné PIN zadávat.

Spouštěcí klíče Dáváte-li přednost fyzickému „klíči“, který musí být fyzicky přítomen u každého spouštění počítače, použijte spouštěcí klíč (startup key). Jde o kryptografické „tajemství“, uložení na USB flash disku („flešce“"). Důležitým faktem je to, že sám spouštěcí klíč nepostačuje k odemčení disku, TPM musí rozpečetit potřebné klíče. (Jestliže je BitLocker nastaven tak, aby pracoval na počítači bez TPM, chovají se spouštěcí klíče jinak. Tomuto druhu spouštěcího klíče se budeme věnovat o něco dále.) U konfigurace využívající spouštěcí klíče není čipem TMK zapečetěn a zabalen jen klíč VMK. Namísto toho BitLocker zašifruje VMK novým klíčem („intermediate key“ neboli IK) a zapíše zašifrovanou verzi do metadat jednotky. Intermediate key je poté rozdělen na dvě části. Jedna část je zapečetěna a zabalena čipem TPM. Druhá část je převedena na 256bitovou strukturu a zapsána ve formátu prostého textu na USB flash disk. Při spouštění počítače kód BitLockeru ve Správci spouštění systému zkontroluje, zda je přítomen potřebný spouštěcí klíč. Pokud ano, BitLocker spojí klíč z USB flash disku s informacemi o klíči, které rozpečetí VMK, a znovu vytvoří intermediate key, který je poté použit k dešifrování VMK. U prvního vydání Visty není možné použít současně PIN a spouštěcí klíč, tato kombinace však byla slíbena v prvním Service Packu. PIN lze použít jen v případě, kdy je počítač vybaven kompatibilním TPM (viz obrázek 5.5). Volba použití PINu nebo spouštěcího klíče má vliv na to, co budou vaši uživatelé potřebovat při spouštění počítače. U počítačů, které musí být schopny automatického restartu v případě nepřítomnosti uživatele, tyto prostředky používat nebudete… samozřejmě by šlo použít spouštěcí klíč na USB a ten nechat trvale zasunut v portu USB, ovšem to by jaksi znamenalo vyřazení celého zabezpečení, že? Je tu ještě pár očividných bezpečnostních důsledků (tedy, mně připadají jako očividné, koncový uživatel se na to bude dívat možná jinak): pokud máte vytvořen PIN, nikdy byste ho nikomu neměli říkat ani si ho zapisovat kamkoli na brašnu či samotný notebook. Jestliže používáte spouštěcí klíč USB, neměli byste flash disk s tímto klíčem dávat do brašny s notebookem, protože v případě ztráty notebooku bude klíč ztracen spolu s ním. Mnohem vhodnější je přidělat si flash disk k ostatním klíčům, které s sebou nosíte.

Ověřování nebo řízení přístupu

221

OBRÁZEK 5.5: Ochránci klíčů BitLocker TPM a TPM+ BitLocker default

BitLocker TPM+PIN

Pre-OS components validated

BitLocker TPM+USB Startup Key

Pre-OS components validated

and VMK Unsealed

PIN entered and validated

Blob with partial key unsealed

FVEK decrypted (with VMK)

VMK Unsealed

Intermediate key (IK) VMK decrypted recreated (with IK)

VMK

FVEK

USB with partial key present

Disk unlocked Sectors decrypted (with FVEK)

VMK

FVEK

VMK

FVEK decrypted (with VMK)

Disk unlocked Sectors decrypted (with FVEK)

FVEK

FVEK decrypted (with VMK)

Disk unlocked Sectors decrypted (with FVEK)

Ověřování zaváděcího procesu (kontrola integrity) Než ukončíme výklad spolupráce BitLockeru a TPM, je čas říci si něco více o tom, co je to vlastně „ověřování součástí spouštěných před operačním systémem“ (pre-OS component validation). BitLocker není jen o šifrování dat; ve skutečnosti je šifrování jen prostředkem k dosažení cíle. BitLocker se pokouší o zajištění důvěryhodnosti výpočetních operací, kdy si uživatel může být jist tím, že nebyl kompromitován. To je hlavní cil BitLockeru. Architektura TPM zahrnuje celkem 24 platformových řídicích registrů (PCR). Každý PCR obsahuje specifické naměřené hodnoty, vyjadřující stav součásti systému (neboli platformy). Většina hodnot uložených v PCR je po výpočtu uložena ve formě určitého hashe. V tabulce 5.1 vidíte, co vše každý PCR proměřuje.

222

Kapitola 5 – Bitlocker – řešení problémů se zabezpečením přenosných počítačů

TABULKA 5.1: Míry PCR PCR

Míra

PCR 0*

Core Root of Trust Measurement (CRTM), obsahující BIOS a všechna rozšíření platformy

PCR 1

Konfigurace a data platformy a základní desky

PCR 2*

Kód komponenty ROM

PCR 3

Konfigurace a data komponenty ROM

PCR 4*

Kód hlavního spouštěcího záznamu (MBR, Master Boot Record)

PCR 5

Tabulka oddílů hlavního spouštěcího záznamu

PCR 6

Události přechodu stavu a probuzení

PCR 7

Vyhrazeno pro výrobce počítače

PCR 8*

Zaváděcí sektor systému NTFS

PCR 9*

Zaváděcí blok systému NTFS

PCR 10*

Správce spouštění systému (Boot Manager)

PCR 11*

Řízení přístupu k nástroji BitLocker

PCR 12–23

Vyhrazeno pro další použití

PCR s hvězdičkou (*) používá BitLocker ve výchozí konfiguraci.

Když začne celý proces spouštění počítače, TPM nejdříve prověří všechny součástky a uloží naměřené hodnoty v příslušném PCR. V každém případě je součástka proměřena ještě předtím, než jí je předáno řízení. Součástka nemůže změnit dříve naměřené hodnoty PCR, proto když útočník vloží škodlivý kód do Správce spouštění systému (Boot Manager, PCR 10), bude se při následném měření hodnota uložená v PCR 10 lišit od nově naměřeného údaje, a zákeřný kód nemůže nijak změnit to, co bylo naměřeno po jeho instalaci ani před ní. Z toho vyplývá jeden velmi důležitý fakt: operační systém se nyní může spolehnout na to, že součásti nahrávané do paměti před ním nebyly změněny. Změna jedné takové součástky může být legitimní součástí inovace či údržby počítače, může však také znamenat pokus o útok vůči operačnímu systému, realizovaný prostřednictvím viru, spywaru nebo rootkitu.

První zapnutí BitLockeru

223

BitLocker se dá nastavit tak, aby byl při této kontrole přísnější či naopak méně přísný, a to prostou změnou sady PCR, kterou BitLocker zkoumá; to ale nemusí odpovídat vašim skutečným přáním. Proto můžete nastavit BitLocker například tak, aby zahrnoval PCR detekující zasunutí karty PCMCIA. Pro mnohé uživatele notebooků to bude příliš nepohodlné, ale vám to bude vyhovovat, protože chcete mít jistotu, že do notebooku nebyly přidány žádné nové karty PCMCIA.

První zapnutí BitLockeru Když už jste se dopracovali až sem, máte nyní moje oficiální požehnání zapnout BitLocker a zašifrovat svou jednotku OS Windows. Postup zapnutí BitLockeru je velmi jednoduchý, samozřejmě za předpokladu, že máte připraven pevný disk. Nejprve zkontrolujte, že máte: ■

Počítač splňující minimální hardwarové podmínky pro běh systému Windows Vista.

■

Mikročip TPM ve verzi 1.2. Někteří výrobci základních desek vyžadují, abyste tento čip zapnuli v BIOSu, většinou však ponechávají čip zapnutý a umožňují tak systému Windows, aby si ho samy našly a komunikovaly s ním prostřednictvím TPM Base Services.

■

BIOS splňující podmínky TCG (Trusted Computing Group).

■

Dva diskové oddíly NTFS; první bude určen pro aktivní oddíl („systémovou jednotku“, ze které počítač startuje) a druhý pro jednotku OS Windows (na něm bude nainstalován systém Vista). Aktivní oddíl musí mít velikost nejméně 1,5 GB.

■

V BIOSu musí být nastaveno zavádění systému z pevného disku s aktivním oddílem, ne z CD/DVD mechanik nebo USB slotů.

U nových notebooků se zabudovanou podporou Windows Vista se očekává, že jejich pevný disk je rozdělen na dva oddíly tak, aby byl kompatibilní s BitLockerem. Jestliže však systém inovujete z předchozích Windows XP nebo jste nainstalovali Vistu na pevný disk s jediným oddílem (jednotkou), musíte nejprve pevný disk na dva oddíly rozdělit. Provádíte-li „čistou“ instalaci, můžete disk rozdělit přímo v úvodních fázích instalace operačního systému Windows Vista. Upozorňuji na to, že při rozdělení disku bude smazáno vše, co je na pevném disku uloženo. Následující postup je převzat z článku „Windows BitLocker Drive Encryption Step-by-Step Guide“, který Microsoft zveřejnil na adrese http://www.microsoft.com/technet/ windowsvista/library/c61f2a12-8ae6-4957-b031-97b4d762cf31.mspx#BKMK_S1): 1. Spusťte počítač z instalačního DVD Windows Vista. 2. V úvodní obrazovce Instalace systému Windows vyberte jazyk, formát kalendářních dat a času a rozložení klávesnice. Poté klepněte na tlačítko Další. 3. V druhé instalační obrazovce klepněte na příkaz „Opravit tento počítač“, umístěné vlevo dole. 4. V dialogovém okně Možnosti obnovení systému klepněte na tlačítko Další.

224

Kapitola 5 – Bitlocker – řešení problémů se zabezpečením přenosných počítačů

5. V dalším dialogu Možnosti obnovení systému zkontrolujte, že není vybrán žádný operační systém (klepněte do prázdné oblasti seznamu Operační systém, pod poslední uvedenou položku). Klepněte na tlačítko Další. 6. V dalším dialogu Možnosti obnovení systému klepněte na položku Příkazový řádek. 7. Pro vytvoření potřebných oddílů použijete nástroj Diskpart. V příkazovém řádku zapište diskpart a stiskněte Enter. 8. Zapište select disk 0. 9. Dalším příkazem clean vymažte existující tabulku oddílů. 10. Zapište create partition primary size=1500. Tento příkaz nastaví první oddíl jako primární. 11. Příkazem assign letter=S přiřadíte tomuto oddílu písmeno S:. 12. Příkazem active nastavíte nový oddíl jako aktivní. 13. Příkazem create partition primary vytvoříte další primární oddíl. Do tohoto většího oddílu budete instalovat Windows. Protože v příkazu není zadána velikost, bude pro další oddíl využit veškerý zbývající prostor na disku. 14. Příkazem assign letter=C přiřaďte druhému oddílu písmeno C:. 15. Zapište list volume. Diskpart vypíše seznam všech jednotek na daném disku. V výpisu uvidíte čísla a přidělená písmena jednotek, jmenovky, souborové systémy, typy, velikosti, stav a informace. Zkontrolujte, zda máte dvě jednotky, zda mají přiřazen souborový systém NTFS a že si víte jejich jmenovky. 16. Příkazem exit ukončete aplikaci diskpart. 17. Příkazem format c: /y /q /fs:NTFS naformátujte řádně jednotku C:. 18. Příkazem format s: /y /q /fs:NTFS naformátujte řádně jednotku S:. 19. Příkazem exit opusťte příkazový řádek. 20. Okno Možnosti obnovení systému zavřete tlačítkem v pravém horním rohu (nebo stiskem ALT-F4) a poté se vrátíte do hlavní instalační obrazovky. (Neklepejte na Vypnout ani Restartovat.) 21. Klepněte na „Nainstalovat“ a postupujte podle dalšího návodu. Při instalaci Visty si vyberte jako cílový disk větší jednotku, ne aktivní oddíl. Pokud již máte Vistu nainstalovanou, ale na pevném disku je jen jedna jednotka, je postup u RC1 verze Visty velmi omezen. Oficiálně je podporováno jen rozdělení nového disku (nebo čistá instalace). Sehnat se dají různé aplikace pro změnu rozdělení disku, přímo v nástroji diskpart je příkaz shrink. Ovšem přemístění „živého“ systému z jedné na dvě jednotky s cílem umožnit nasazení BitLockeru není úloha pro začátečníky nebo bázlivé jedince. Až bude Vista dodávána na trh, měla by se podpora zlepšit. Vývojový tým BitLockeru ohlásil ve svém blogu během června 2006, že pracují na pomůcce, která by automaticky změnila rozdělení

První zapnutí BitLockeru

225

disku kvůli nasazení BitLockeru (viz http://blogs .technet.com/bitlocker/archive/2006/06/09/PartitionVistaB2.aspx). Hotový nástroj se jmenuje BitLocker Drive Preparation Tool a více se o něm dočtete na stránce http://support.microsoft.com/?id=930063, kde jsou také vypsány způsoby, jak se dá získat. Po úspěšném nainstalování systému Vista a správném nastavení diskových jednotek zapněte BitLocker podle následujících bodů: 1. V nabídce Start postupně klepněte na Ovládací panely  Zabezpečení  BitLocker Drive Encryption. 2. V dialogovém okně UAC zkontrolujte, zda navrhovaná akce je ta, kterou požadujete, a klepněte na tlačítko Pokračovat. 3. V obrazovce BitLocker Drive Encryption klepněte na příkaz Turn On BitLocker u jednotky OS Windows. Není-li váš TPM inicializován, objeví se průvodce Initialize TPM Security Hardware Wizard. Zapněte TPM podle návodu průvodce a restartujte počítač. Poté znovu klepněte na příkaz Turn On BitLocker u jednotky OS Windows. 4. V dialogu Save the recovery password budou nabídnuty následující možnosti: ■ Save the password on a USB drive. Uloží heslo na vyměnitelný disk. ■ Save the password in a folder. Uloží heslo na síťový disk nebo do jinému umístění. ■ Print the password. Vytiskne heslo. 5. Vyberte si nejméně jednu z těchto voleb. 6. V dialogu „Encrypt the selected disk volume“ zkontrolujte, že máte zapnutou volbu Run BitLocker System a klepněte na tlačítko Pokračovat. 7. Tlačítkem Restart Now potvrďte restart systému. Počítač restartuje, BitLocker si ověří kompatibilitu počítače a jeho připravenost k zašifrování disku. Není-li něco v pořádku, objeví se před začátkem šifrování chybové hlášení. 8. Jestliže je vše v pořádku, bude zobrazen stavový řádek Encryption in Progress. Postupný průběh šifrování jednotky můžete sledovat přes ikonu BitLocker Drive Encryption v panelu nástrojů u spodního okraje obrazovky, nad kterou stačí umístit kurzor myši (poté se objeví souhrn základních informací v okně rychlé nápovědy). POZNÁMKA:

Tyto kroky vycházejí z dokumentace Microsoftu, zveřejněné na adrese http://www.microsoft. com/technet/windowsvista/library/c61f2a12-8ae6-4957-b031-97b4d762cf31.mspx.

Vlastní šifrování disku potrvá určitou (delší) dobu, počítač však během převodu bude nadále použitelný. Skutečný čas se bude lišit v závislosti na velikosti volného místa na jednotce (protože volné místo lze obsloužit mnohem rychleji než obsazené sektory), předpokládejte asi 1 minutu na každý gigabajt, takže zašifrování 250 GB jednotky bude trvat něco mezi 2 a 3 hodinami.

226

Kapitola 5 – Bitlocker – řešení problémů se zabezpečením přenosných počítačů

Používáme BitLocker bez TPM V současné době je jen malá část počítačů vybavena čipem TPM verze 1.2 (a novějším) a BIOSem, který vyhovuje specifikacím Visty a TCG. Postupem doby se však tato hardwarová výbava objeví u většiny počítačů. Pokud se týká stávajících počítačů… hardwarové firmy vám sice normálně raději prodají nový počítač, než aby ztrácely čas a peníze na aktualizaci starších strojů, ale většina jich vydává aktualizace BIOSu pro poslední vyráběné řady počítačů. Pokud však váš počítač má starší čip TPM (například verzi 1.1), není možné ho inovovat. (Tyto čipy jsou hardwarové, nikoli softwarové zařízení, takže si novou verzi nestáhnete.) Počítač bez kompatibilního čipu TPM nemůže využívat prvky pro ověřování součástí nahrávaných před zaváděním OS, které provádí TPM a jeho PCR. Scházející čip TPM však nebrání tomu, abyste mohli využít šifrování disku se spouštěcím klíčem (uloženým na USB flash disku). Když se však pokusíte zapnout BitLocker na počítači bez čipu TPM, ve výchozí konfiguraci se vám to nepodaří. Uživatelské rozhraní BitLockeru bylo navrženo jako co nejjednodušší a přehledné pro typického uživatele a přitom umožnilo vcyužít všechny aspekty zabezpečení, vyplývající z přítomnosti čipu TPM. Abyste mohli zapnout ochránce klíčů (v kombinaci s TPM) nebo používat BitLocker bez čipu TPM, musíte BitLocker nastavit tak, aby používal rozšířené volby instalace. Tento režim se zapíná změnou jedné zásady skupiny (na úrovni domény či místního počítače). Postup pro změnu lokální zásady skupiny vypadá takto: 1. Klepněte na tlačítko Start a do pole Hledat zapište gpedit.msc. Stiskněte Enter. 2. V okně editoru objektů zásad skupiny postupně klepněte na Místní počítač – zásady  Konfigurace počítače  Šablony pro správu  Součásti systému Windows a poté poklepejte na Šifrování jednotky pomocí služby BitLocker. 3. Zde vyberte „Nastavení Ovládacích panelů: Povolit pokročilé možnosti spuštění. Uvidíte nastavení Setup Wizard Configure startup pro okno TPM computers. 4. Změňte nastavení této zásady na Povoleno a zapněte políčko „Povolit nástroj BitLocker bez kompatibilního čipu TPM“. Poté klepněte na tlačítko OK. POZNÁMKA:

Mezi body 1 a 2 se objeví výzva UAC, se kterou jste se během čtení této knihy již jistě stihli spřátelit. Můžete samozřejmě použít i jakýkoli jiný způsob, jak se dostat do okna editoru objektů lokálních zásad skupiny nebo objektu Zásady skupiny, platného pro daný počítač.

Je-li spouštěcí klíč použit bez čipu TPM, je značně jiný než klíč spolupracující s TPM, který je spolu s daty TPM zkombinován do jednoho ochránce klíče. Oproti tomu spouštěcí klíč používaný bez TPM je sám ochráncem klíče. Když zapnete BitLocker na počítači bez čipu TPM, bude vytvořen nový klíč pro obnovení a zapsán na USB disk. Z tohoto důvodu USB disk obsahuje binární klíč, který dokáže přímo dešifrovat klíč VMK. Spouštěcí klíč USB je tedy jedinou věcí, kterou uživatel potřebuje pro přístup k jednotce chráněné BitLockerem. Ve skutečnosti je USB spouštěcí klíč na počítači bez TPM přesně to samé, co „heslo pro obnovení uložené na disku USB“ na počítači vybaveném čipem TPM. Řečeno jinak: bez čipu TPM používáte klíč pro obnovení na disku USB při každém spuštění počítače. Celý proces je blíže vysvětlen na obrázku 5.6.

Používáme BitLocker bez TPM

227

OBRÁZEK 5.6: BitLocker na počítači bez TPM BitLocker without TPM or using USB for recovery USB Startup Key (Recovery key present)

VMK Decrypted (with key from USB) VMK

FVEK decrypted (with VMK) FVEK

Disk unlocked Sectors decrypted (with FVEK)

Souhrn ochránců klíčů V některých případech můžete mít ochránců klíčů tolik, že nad nimi začnete ztrácet přehled. Tabulka 5.2 vám pomůže se zorientovat. TABULKA 5.2 Ochránci klíčů Název

TPM Only (jen TPM)

Název

Může být

Vyžaduje

Uživatel

v příkazo-

počítač

TPM 1.2

musí

musí za-

vém řádku

spuštěn

vložit ob-

dat data

automatic-

jekt (USB

ky?

disk)

-tpm

Popis

TPM je použit pro šifrování, zapečetění a zabalení klíče VMK.

Poznámka

Implicitně vytvořen. TPM nerozpečetí VMK, dokud není úspěšně dokončena kontrola integrity.

Ano

228

Kapitola 5 – Bitlocker – řešení problémů se zabezpečením přenosných počítačů

Název

Může být

Vyžaduje

Uživatel

v příkazo-

Název

Popis

Poznámka

počítač

TPM 1.2

musí

musí za-

vém řádku

spuštěn

vložit ob-

dat data

automatic-

jekt (USB

ky?

disk)

Recovery Password (heslo pro obnovení)

-Recovery Password -rp

Číslo s 48 číslicemi, které musí uživatel zapsat při obnově systému.

Ne Implicitně je vytvořen klíč pro obnovení nebo heslo pro obnovení. Dá se snadno uložit do AD DS.

Ano (48 číslic)

Recovery Key (klíč pro obnovení)

-Recovery Key -rk

Binární klíč pro zašifrování VMK.

Ne[*] V průvodci nastavením je pro zjednodušení označen jako „heslo pro obnovení (recovery password). Implicitně je vytvořen klíč pro obnovení nebo heslo pro obnovení. Klíč pro obnovení je zapsán na USB disk tak, aby ho počítač dokázal přímo načíst.

Ano

Součásti WIC Název

Název

Popis

Poznámka

229

Může být

Vyžaduje

Uživatel

v příkazo-

počítač

TPM 1.2

musí

musí za-

vém řádku

spuštěn

vložit ob-

dat data

automatic-

jekt (USB

ky?

disk)

Ne[*]

Startup Key (spouštěcí klíč pro počítače bez TPM)

-Startup Key -sk

Binární klíč pro zašifrování VMK.

Uložen na USB disku a chová se stejně jako klíč pro obnovení. Nerozšifruje VM, pokud není USB disk přítomen.

TPM+PIN

-TPMAndPIN -tp

Používá TPM k zašifrování, zapečetění a zabalení klíče VMK, ověřovací data jsou však zadána v TPM

TPM nerozpečetí Ne VMK, dokud není úspěšně dokončena kontrola integrity a není zadán správný PIN.

Ano

Ano (4 až 20 číslic)

230

Kapitola 5 – Bitlocker – řešení problémů se zabezpečením přenosných počítačů

Název

TPM+USB Startup Key (spouštěcí klíč pro počítače s TPM)

Může být

Vyžaduje

Uživatel

v příkazo-

Název

počítač

TPM 1.2

musí

musí za-

vém řádku

spuštěn

vložit ob-

dat data

automatic-

jekt (USB

ky?

disk)

-TPMAnd Startup Key – tsk

Použijte Clear Key příkaz (BitLocdisable ker ve „vypnutém režimu“)

Popis

Poznámka

Používá TPM k zašifrování, zapečetění a zabalení části intermediate klíče, jehož druhou část uloží na USB disk. Klíč VMK je zašifrován intermediate klíčem.

TPM nerozpečetí Ne[*] část klíče, dokud není úspěšně dokončena kontrola integrity. Nevytvoří intermediate klíč ani nerozšifruje VMK, pokud není přítomen disk USB.

Ano

Zašifruje VMK novým klíčem, který poté zapíše ve formátu prostého textu do metadat jednotky.

Ano Použit při dočasném vypnutí BitLockeru, kdy není provedeno dešifrování dat. Nenabízí žádnou ochranu, BitLocker je zakázán (vypnut).

[*]Pokud není disk USB zapomenut v portu USB. Čtenáři této knihy jsou ovšem pozorní a dostatečně inteligentní, že by se nikdy podobné pitomosti nedopustili. A umí si vybrat kvalitní knihy.

Obnova

231

Obnova Už jste někdy ztratili klíče od zamčeného auta? U notebooků, na kterých jsou data chráněna BitLockerem, může dojít k několika situacím, kdy vy nebo váš uživatel nejste vpuštěni do systému. Může jít o tyto případy: ■

Zapomenutý PIN (v případě kombinace TPM + PIN)

■

Ztracený spouštěcí klíč (TPM + spouštěcí klíč USB nebo počítač bez TPM)

■

Chyba kontroly integrity (jen TPM, TPM + PIN nebo TPM + spouštění klíč USB)

Ve všech těchto případech BitLocker odmítne odemknout jednotku OS Windows a vy nedokážete systém na této jednotce spustit. I když spustíte jinou instalaci Windows Vista (nebo jiný operační systém) z jiného oddílu nebo disk zapojíte do jiného počítače, zůstanou data na něm nepřístupná. To je na jednu stranu výtečné, protože to úplně zkříží plány útočníka. Na straně druhé ovšem máte problém, protože se k datům nedostanete ani vy, a to jen kvůli vaší chybě nebo poškození kusu hardwaru. (To neplatí při plánované údržbě, kdy jste si – doufejme – dopředu BitLocker dezaktivovali pomocí clear klíče, někdy se však přihodí neplánované věci.) Kód BitLockeru (běžící ve Správci spouštění) namísto odemčení disku zobrazí tzv. „konzolu pro obnovu“ (recovery console), která vypadá asi takto:

Windows bitlocker Driver Encryption key needed. Insert key storage media. Press ESC to reboot after the media is in place.

Drive Label: VROUBEK-VISTABDE OS 10/1/2006 Key Filename: 4E65A3A7-35F3-4810-92AA-B6V833A78CD6.BEK ENTER=Recovery

ESC=Reboot

232

Kapitola 5 – Bitlocker – řešení problémů se zabezpečením přenosných počítačů

Jestliže se před vámi na obrazovce tato konzola pro obnovu objeví, máte na výběr z několika málo možností: 1. Můžete chybu opravit? Řečeno jinak, můžete vrátit zpět nějaký proces, který způsobil přechod BitLockeru do stavu obnovy? Třeba najít ztracený spouštěcí klíč? Můžete disk připojit zpět k původnímu počítači? Pokud ano, restartujte počítač a pokračujte normálním způsobem. Jestliže to není možné, pokračujte body 2 a 3. 2. Máte klíč pro obnovení? Připomeňme si, že klíčem pro obnovení je heslo pro obnovení uložené na USB disk během úvodní instalace BitLockeru nebo spouštěcí klíč USB, používaný na počítači bez čipu TPM. Jestliže žádný klíč pro obnovení neexistuje, pokračujte bodem číslo 3. 3. Máte heslo pro obnovení? Těch 48 číslic získává v tomto okamžiku nesmírnou důležitost. Heslo po obnovu může být uloženo na jednom z těchto míst: ■ V Active Directory ■ V textovém souboru, umístěném ve složce zadané v jednom z dialogů instalačního průvodce BitLockeru ■ Vytištěno na fyzickém listu papíru (k tisku došlo při úvodní instalaci BitLockeru) ■ Nosíte ho ve své peněžence, náprsní tašce nebo aktovce: toto platí, když dbáte o to, aby heslo bylo odděleno od počítače. Jestliže pracujete ve velké firmě, je dost pravděpodobné, že klíče nebo hesla pro obnovení jsou ukládány a centrálně spravovány oddělením technické podpory nebo podobnou organizací. U čtenáře této knihy se dá také předpokládat, že je jedním ze správců, zodpovědných za vytvoření a údržbu takového centrálního systému. Podívejme se nyní blíže na jednotlivé možné scénáře obnovy, se kterými se v praxi můžete setkat.

Ukázka obnovy č. 1: Selhání hardwaru (samostatný systém bez čipu TPM) Alice pracuje na volné noze a při práci se neobejde bez svého PC. Je to starší model, proto její základní deska neobsahuje čip TPM pro systém Vista. Alice si zakoupila Windows Vista ve verzi Ultimate Edition a protože na svém disku ukládá hodně důvěrných informací o svých klientech, zašifrovala si celý disk BitLockerem, v jehož konfiguraci zadala používání spouštěcího klíče USB. Jednoho odpoledne si Alice s překvapením všimla, že se její monitor začíná chovat divně. Večer už na něm nebylo vidět vůbec nic a stal se nepoužitelným. Alice se zadívala na počítač svého manžela, a rozhodla se, že se na ni určitě nebude zlobit, když svůj disk zasune do jeho počítače na dobu potřebnou k dokončení jedné spěšné nabídky. (Vzhledem k tomu, že si oba počítače koupili společně, šlo o identické modely – což náš příklad značně zjednodušuje.) Když spustila manželův počítač se svým připojeným diskem, objevila se obrazovka BitLockeru s výzvou ke vložení jejího média s klíčem. Alice vložila svůj spouštěcí klíč USB a restartovala počítač. BitLocker našel správný spouštěcí klíč pro disk, umístěný na jejím USB flash disku, a odemknul pevný disk. Alice dokončila nabídku a získala lukrativní zakázku.

Obnova

233

Ukázka obnovy č. 2: Selhání hardwaru na notebooku (s čipem TPM) Zakázka byla tak zisková, že se Alice s manželem rozhodli koupit si nové počítače, které by nahradily jejich již postarší mašinky. Robert si vybral špičkový notebook, vybavený čipem TPM 1.2 a BIOSem kompatibilním s normou TCG. Při instalaci systému si nastavil BitLocker do výchozího režimu „jen TPM“ a spoléhal se na kvalitně zvolené silné heslo, které bránilo nepovolaným v přístupu do systému . chybí poznámka

Robert pracoval na svém super notebooku jen několik týdnů; poté najednou počítač zkolaboval. Robert spěšně navštívil prodejnu, kde zjistili, že jde o závadu z výroby, která vyřadila jeho základní desku. Během krátké doby mu desku vyměnili a Robert si spokojeně odnesl opravený notebook domů … jenže tam se při spuštění počítače objevila následující výzva BitLockeru:

Windows BitLocker Drive Encryption key needed. Insert key storage media. Press ESC to reboot after the media is in place.

Drive Label: VROUBEK-VISTABDE OS 10/1/2006 Key Filename: 4E65A3A7-35F3-4810-92AA-B6V833A78CD6.BEK ENTER=Recovery

ESC=Reboot

Robert si uvědomil, že čip TPM byl trvale zabudován do staré základní desky, a proto není možné rozpečetit klíč VMK, který byl chráněn čipem TPM. Robert je posedlý zabezpečením více, než je zvykem, proto si při konfiguraci BitLockeru uložil heslo pro obnovení do souboru, vytisknul si kopii hesla a navíc ještě vytvořil klíč pro obnovení na USB disku, který uložil do zamykatelné kartotéky. Nyní proto vyndal klíč z kartotéky, vložil ho do portu USB na notebooku a restartoval počítač. Robert byl uchvácen tím, jak snadno obnova BitLockeru proběhla a vrátil klíč USB do kartotéky.

234

Kapitola 5 – Bitlocker – řešení problémů se zabezpečením přenosných počítačů

Druhého dne ráno byl ovšem Robert nepříjemně překvapen tím, že se výzva Bitlockeru objevila znovu. Při každém restartu počítače musel provést stejné kroky pro obnovení. Robert je bystrý a proto si rychle domyslel, že nový TPM nepečetí jeho klíče BitLockeru. Vzhledem k tomu, že se mu nechtělo dešifrovat a poté znovu zašifrovat celý pevný disk, vzpomenul si na jednu chytrou věc, kterou se naučil při čtení této kapitoly v části věnované práci v příkazovém řádku (je uvedena o něco dále). Proto spustil okno příkazového řádku s právy správce a v něm spustil příkazy: manage-bde.wsf -protectors -delete -type tpm c: manage-bde.wsf -protectors -add -tpm c:

Trvalo to jen sekundu a měl nového ochránce klíče. BitLocker poté spolehlivě odemkne jeho šifrovaný disk na základě výsledků kontroly integrity, kterou provede nový TPM.

Ukázka obnovy č. 3: Ztracený klíč USB (počítač s TPM) Robertova sestra Pavlína pracuje v mezinárodní korporaci vyrábějící tkaničky do bot. Pavlína má přidělen notebook připojený do domény, na kterém byl – kvůli špehům od konkurence Velcro, výrobců zipů a celého moderního hnutí sandálů – zapnut BitLocker v kombinaci s TPM a spouštěcím klíčem na USB. Po příjezdu do cíle své pracovní cesty zapne notebook, který ji pozdraví požadavkem na zasunutí média s uloženým klíčem:

Windows BitLocker Drive Encryption key needed. Insert key storage media. Press ESC to reboot after the media is in place.

Drive Label: VROUBEK-VISTABDE OS 10/1/2006 Key Filename: 4E65A3A7-35F3-4810-92AA-B6V833A78CD6.BEK ENTER=Recovery

ESC=Reboot

Obnova

235

USB flash disk musí být zasunut již v první fázi spouštění počítače; pokud ho zasunete až poté, co začne pracovat kód správce zavádění, je nutné celý počítač restartovat. Pavlína si náhle s hrůzou uvědomila, že počítač naposledy spouštěla (se zasunutým klíčem USB) během čekání na let v čekárně letištní haly. Před očima jí vyskočil jasný obraz flash disku, ležícího na sousední židli. Důkladná kontrola kapes a zavazadel potvrdila, že flash disk s klíčem skutečně zůstal na letišti. Vzhledem k tomu, že neexistuje žádný prakticky proveditelný způsob, jak v krátké době obnovit ztracený klíč USB, musí Pavlína spustit proces obnovy BitLockeru a stiskne klávesu Enter. Když byl její disk zašifrován, Pavlína si neuložila klíč pro obnovení na USB disk (přestože použila ochránce TPM + USB), proto se okamžitě objeví obrazovka pro zadání USB hesla pro obnovení. Tato obrazovka vypadá asi takto:

Windows Bitlocker Drive Encryption password Entry Enter the recovery password for this drive. ----- ----- ----- --------- ----- ----- ----Drive Label: VROUBEK-VISTABDE OS 10/1/2006 Password ID: 107241EE-A2F1-4553-978C-BC758F24D95 Use the function keys F1 – F9 for the digits 1 – 9. Use theF10 key for 0. Use the TAB, SHIFT-TAB, HOME, END and ARROW keys to move the cursor. The UP and DOWN ARROW keys may be used to modify already entered digits. Enter=Continue

ESC=Exit

Pavlína si vzpomněla, že si při zašifrování disku vytiskla stránku s tímto heslem, ale to bylo již dávno. Protože neví, co jiného by měla dělat, zavolá oddělení podpory své firmy. Příjemný mladý muž si nejdříve ověří její totožnost na základě posledního čísla jejího PSČ a data posledního očkování její kočky, a poté jí přečte do telefonu 48 číslic, které načetl z firemní databáze AD DS. Postupně ji vyzývá k zápisu jednotlivých bloků 6 číslic, tak jak jí je předčítá, aby si mohla zkontrolovat, zda někde neudělala překlep. POZNÁMKA:

Zajímaly vás někdy matematické algoritmy pro kontrolu typografických chyb, nebo jste někdy chtěli vědět, proč vstupní obrazovky dělí údaje do krátkých bloků? Dozvíte se to na stránce http://blogs.msdn. com/si_team/archive/2006/08/10/694692.aspx.

236

Kapitola 5 – Bitlocker – řešení problémů se zabezpečením přenosných počítačů

Poté, co Pavlína zapíše své heslo pro obnovení, už její počítač naběhne normálně. Aby to nemusela při příštím spouštění počítače opakovat, požádá hotelovou službu o zakoupení nového flash disku a po jeho donesení vytvoří nový spouštění klíč USB (volba Správa klíčů nástroje BitLocker v části Ovládacích panelů s názvem BitLocker (viz další obrázek). Poté pošle e-mail svému veterináři a objedná kočku na další očkování.

Heslo pro obnovení je možné uložit na několika dalších místech. Asi jste si všimnuli, že na obrazovce pro zadání hesla pro obnovení bylo zobrazeno GUID tohoto hesla (tzv. Password ID). Jestliže uložíte heslo pro obnovení do souboru na disku, je Password ID zapsáno do tohoto souboru a použito také jako jeho název.

Ukázka obnovy č. 4: „nalezený“ notebook Eva, úhlavní nepřítelka Pavlíny, se neustále motá kolem Pavlínina přítele Davida. David je zástupce ředitele oddělení výzkumu ve firmě, která je hlavním konkurentem společnosti, ve které pracuje Eva. Eva stopuje Davida a doufá, že se jí podaří ukrást nejnovější plány konkurence. Vidí, jak David vchází do baru, aby se trochu uvolnil po dlouhém dni, stráveném na firemní konferenci, a vchází za ním. Naváže konverzaci, koupí mu pár drinků a počká, až se David trochu uvolní. V momentu, kdy je zaujat něčím jiným, mu Eva potají vezme notebook a přesune ho do své tašky. O něco později (stejného večera) Eva otevře víko dlouho očekávané kořisti a chce si v něm číst různé informace. Ale po spuštění Davidova počítače se ukáže výzva k zadání PINu. Zkusí nejprve Davidovo datum narození a poté začátek jeho telefonu domů… po pár dalších náhodných pokusech rezignuje a hodlá celou noc postupně zkoušet kombinace 1111, 1112 atd. …brzy však pozná, že to nepůjde, protože čip TPM zobrazuje nové obrazovky pro zadání stále pomaleji a pomaleji.

Obnova

237

Nakonec se rozhodne rozdělat ukradený notebook a připojit Davidův pevný disk k jinému počítači. Ale ať zkouší jaký chce počítač nebo operační systém, vidí jen zašifrovaná data. Nakonec vrátí disk zpět do Davidova počítače a v úvodní obrazovce vybere obnovu systému. „Teď se ukáže“, myslí si a zavolá oddělení technické podpory Microsoftu, aby jí pomohli „obnovit“ její instalaci Visty. Velmi rychle je ovšem poučena o tom, že takto to nejde, a i kdyby se jí podařilo přesvědčit podporu Microsoftu, aby jí pomohli, neexistuje žádný způsob, jak by jí mohli sdělit klíč nebo říci, jak dešifrovat disk.

Souhrn obnovy Není možné vyjmenovat všechny možné situace, které se mohou v praxi vyskytnout. Doufám však, že z uvedených příkladů si další varianty dokážete odvodit. Pokud disk skončí odemčen klíčem pro obnovení uloženým na USB disku, je proces stejný jako v případě použití spouštěcího klíče bez TPM, který jste viděli na obrázku 5.6. Oproti tomu, pokud uživatel zadal číselné heslo pro obnovení (a bylo správné), je toto heslo přeloženo na kryptografické klíče, požadované podle obrázku 5.7. V tomto případě tu máme dva immediate klíče navíc a trochu „soli“ k tomu. (V kryptografii se pojmem „sůl“ označují dodatečně přidané údaje, které zvyšují složitost klíče, obvykle zvýšením jeho entropie.) OBRÁZEK 5.7: Použití hesla pro obnovení BitLocker using typed recovery password

Typed recovery password

Password encoded into intermediate key (A)

Intermediate key (B) recreated

VMK decrypted (with IK) VMK

FVEK decrypted (with VMK) FVEK

Disk unlocked Sectors decrypted (with FVEK)

“Salt” added for cryptographic strength

238

Kapitola 5 – Bitlocker – řešení problémů se zabezpečením přenosných počítačů

Obnova není těžká, za předpokladu přítomnosti USB klíče pro obnovení nebo číselného hesla pro obnovení. Pokud tyto údaje nemáte, neexistují žádná zadní vrátka nebo utajovaný způsob, jak by se data na disku dala dešifrovat. Jako správci systémů se proto musíte dopředu připravit na případnou katastrofu. Uvádím několik základních rad pro přípravu: ■

Máte-li doménu Active Directory (Windows Server 2003 SP1 nebo novější verze), uložte hesla pro obnovení do Active Directory. Neexistuje důvod, proč byste toto neměli udělat. Zajistíte si tak automatické řešení obnovy, probírané v příští části kapitoly.

■

Pokud doménu Active Directory nemáte, ale zodpovídáte z více jak jeden počítač, vytvořte si záložní kopie hesel pro obnovení pomocí služby WMI nebo nástroje příkazového řádku, protože takto se dají zálohy vytvářet i vzdáleně, nebo dokonce i v přihlašovacím skriptu.

■

Jestliže se staráte jen o vlastní počítač: vytvořte si více kopií klíče pro obnovení (heslo pro obnovení přesunuté instalačním průvodcem BitLockeru na USB disk). Počet kopií není nijak omezen, ale berte při jejich tvorbě ohled na dvě protichůdné věci – útočníci by se k těmto kopiím rozhodně neměli snadno dostat, ale vy se k nim dostat v případě potřeby musíte. Jednu kopii je vhodné uschovat v kanceláři v sejfu nebo v dobře zamčené zásuvce stolu; velcí cestovatelé si mohou nechat svou kopii v hotelovém pokoji, zatímco mají notebook s sebou v taxíku.

■

V konzole BitLockeru si vytvořte další klíče pro obnovení. Zkopírování textového souboru s heslem pro obnovení na USB disk nepostačuje pro vytvoření binárního souboru, nutného pro spuštění počítače. Nikdy nenechávejte klíč pro obnovení u počítače.

■

Vytvořte si také kopii hesla pro obnovení a uložte ji na dostupném místě, ale přímo u počítače. Pojem „uložit“ se dá vykládat různě: je například možné přečíst ho do heslem chráněné hlasové schránky. Také si ho můžete uložit ke svým kreditním kartám. Heslo pro obnovení lze uložit do záložního souboru na místním nebo síťovém disku. Ale opět platí pravidlo – heslo nemá být uloženo přímo u počítače, ke kterému patří.

Zásady obnovy počítačů je třeba v rámci firmy pořádně promyslet. Aby bylo jasno: BitLocker nikdy nepřejde do režimu obnovy jen tak z legrace, aby potrápil uživatele. Jestliže se tak stane, znamená to, že byl detekován nějaký problém se zabezpečením. Může se jednat o jednoduchý případ (někdo zapomněl svůj PIN), ale i o něco komplikovanějšího, například o útočníka pokoušejícího se instalovat do počítače rootkit. Někdy není správné se okamžitě pustit do obnovy a pokračovat, jako by se nic nestalo. Je vhodné promyslet zásady a postupy pro zjištění příčiny přechodu BitLockeru do režimu obnovy a navrhnout řádné a bezpečné způsoby obnovy, při kterých bude chráněn počítač, data na něm uložená i firemní síť.

BitLocker a Active Directory Ve středních a velkých firmách zabere správa počítačů a klíčů velké množství času. Pro 10 nebo 20 počítačů si správce dokáže hesla pro obnovení zapamatovat nebo mu postačí jejich evidence třeba v sešitu Excelu, ovšem u 100 až 500 počítačů je to mnohem těžší a zcela nemožné to je v případě, kdy máte pod palcem desítky tisíc PC.

BitLocker a Active Directory

239

V sítích Windows se většina správců při správě počítačů a uživatelů spoléhá na službu Active Directory (v novém Windows Serveru 2008 půjde o „Active Directory Domain Services“ čili „Doménové služby Active Directory“). BitLocker využívá službu Active Directory dvojím způsobem: zásady skupiny slouží pro správu předvoleb BitLockeru, přímo do Active Directory jsou ukládány informace nutné pro obnovení. (Konfigurace BitLockeru prostřednictvím zásad skupiny je probírána dále v této kapitole.) Logickým místem pro ukládání hesel pro obnovení BitLockerem chráněných počítačů ve velkých firmách je právě Active Directory. Pro každou jednotku se zapnutým BitLockerem je vytvořen objekt s názvem ms-FVE-RecoveryInformation, ve kterém je uloženo heslo pro obnovení a s ním svázané informace. Pro každý počítač používající BitLocker v kombinaci s TPM je vytvořen další objekt s názvem ms-TPM-OwnerInformation, ve kterém je uloženo heslo TPM (které za normálních situací většina uživatelů nepotřebuje). Tyto objekty jsou uloženy uvnitř objektu počítače. BitLocker tyto objekty automaticky vytvoří a využije doménové služby Active Directory pro ochranu informací potřebných pro obnovení (musíte ovšem AD DS správně nastavit, aby to šlo provést). Pro ukládání hesel pro obnovení do AD DS je nutné změnit nastavení Active Directory takto: 1. Na všech řadičích domény musí běžet Windows Server 2003 SP1 nebo novější verze. Tuto podmínku musí splňovat všechny řadiče domény, které klienti BitLockeru mohou použít. 2. Musíte mít přidělena patřičná oprávnění v doménách i doménové struktuře, abyste mohli dokončit následující kroky. 3. Rozšiřte schéma Active Directory o definice objektů a atributů BitLockeru. (Poznámka: pokud je řadičem domény počítač se systémem Windows Server 2008 Beta 3 nebo novější verze, je schéma již rozšířeno.) 4. Nastavte oprávnění objektů schématu tak, aby si do nich klienti mohli zálohovat své informace pro obnovení TPM. Microsoft pro tyto účely vytvořil skript, který tento bod řeší nejjednodušeji. 5. Upravte nastavení objektu zásady skupiny tak, aby bylo povoleno automatické zálohování údajů pro obnovení. (Možnosti zásad skupin pro BitLocker jsou probrány dále v této kapitole.) Existují dvě specifická nastavení: ■ Konfigurace počítače  Šablony pro správu  Součásti systému Windows  Šifrování jednotky pomocí služby BitLocker  Zapnout zálohování nástroje BitLocker do adresáře Active Directory Domain Services ■ Konfigurace počítače  Šablony pro správu  Systém  Služby TPM (Trusted Platform Module)  Zapnout zálohování čipu TPM službou AD DS Až bude Windows Vista na trhu, Microsoft zpřístupní podrobný návod na konfiguraci doménových služeb Active Directory. Součástí návodu budou pravděpodobně i všechny potřebné skripty a soubory pro rozšíření schémat.

240

Kapitola 5 – Bitlocker – řešení problémů se zabezpečením přenosných počítačů

Možnosti zásad skupiny Jak jsem již párkrát napsal, BitLocker a základní služby TPM (TPM Base Services) lze nastavit prostřednictvím zásad skupiny. V této souvislosti je třeba vědět o dvou uzlech zásady skupiny: ■

Nastavení BitLockeru najdete v uzlu Konfigurace počítače  Šablony pro správu  Součásti systému Windows  Šifrování jednotky pomocí služby BitLocker

■

Nastavení služeb TPM je v uzlu Konfigurace počítače  Šablony pro správu  Systém  Služby TPM (Trusted Platform Module)

Následující seznam obsahuje stručná vysvětlení jednotlivých možností pro BitLocker. Podrobnější informace najdete v nápovědě Windows nebo vysvětlivkách u jednotlivých zásad v jejich editoru. Zapnout zálohování nástroje BitLocker do adresáře Active Directory Domain Services Jak již bylo řečeno, toto nastavení povoluje BitLockeru zálohovat informace potřebné pro obnovení do doménových služeb Active Directory Domain Services. U tohoto nastavení je možné zapnout ještě dvě dodatečné volby. První z nich – „Požadovat zálohování nástroje BitLocker do adresáře AD DS“ – nastaví BitLocker tak, aby v případě neúspěšného pokusu o připojení k řadiči domény a zálohování informací pro obnovení do Active Directory nebyl BitLocker povolen. Z hlediska zajištění obnovitelnosti systému je to velmi užitečná volba, znamená ale zároveň, že při první aktivaci BitLocker musí být klientský počítač připojen k doméně (čili není možné BitLocker zapnout během letu na další konferenci). Druhá podřízená volba „Vyberte informace pro obnovení nástroje BitLocker, které chcete uložit“ stanoví, kolik informací pro obnovení bude uloženo. Pokud uložíte hesla obnovení a balíčky s klíči, bude kopie FVEK zašifrována klíčem vytvořeným z hesla pro obnovení a poté uložena do AD DS. Svou podstatou se to dost podobá vytvoření další kopie informací o klíčích, ukládaných do metadat jednotky. Při uložení balíčku s klíči do AD DS se trochu zvyšuje riziko prozrazení klíče, ale zase je kdykoli k dispozici pro případnou obnovu data z poškozeného disku. Jestliže je balíček s klíči uložen v AD DS, musíte na to brát ohled při návrhu procedur pro vyřazování starých počítačů. Konfigurovat šifrovací metodu V této volbě je možné vybrat použitý šifrovací algoritmus: ■

128bitové AES s difuzorem (výchozí)

■

256bitové AES s difuzorem

■

128bitové AES

■

256bitové AES

Konfigurovat profil ověření platformy čipu TPM V této volbě je možné přesně vybrat, které PCR budou zkoumány během ověřování součástí, aktivovaných před operačním systémem. Máte-li již zapnut BitLocker, musíte ho vypnout a poté znovu zapnout, jinak zde provedené změny nebudou platit. Před změnou této volby si proto navrhněte plán celého postupu při změně.

Možnosti zásad skupiny

241

Nastavení Ovládacích panelů: Povolit pokročilé možnosti spuštění Tady je možné určit, zda uživatel nastavující BitLocker v Ovládacích panelech Visty může měnit volby týkající se tvorby ochránců klíčů. K dispozici jsou tyto volby: Povolit nástroj BitLocker bez kompatibilního čipu TPM Nastavení pro počítače s čipem TPM: Možnost konfigurovat spouštěcí klíč čipu TPM: Umožnit uživateli vytvoření nebo přeskočení (výchozí hodnota) Vyžadovat spouštěcí klíč s čipem TPM Nepovolit spouštěcí klíč s čipem TPM Možnost konfigurovat spouštěcí kód PIN čipu TPM: Umožnit uživateli vytvoření nebo přeskočení (výchozí hodnota) Vyžadovat spouštěcí kód PIN čipu TPM Nepovolit spouštěcí kód PIN čipu TPM Uvědomte si, že nelze zároveň vyžadovat PIN a spouštěcí klíč, proto při nastavení jedné z posledních dvou voleb na „Vyžadovat“ bude druhá nastavena automaticky na „Nepovolit“. Nastavení Ovládacích panelů: Konfigurovat možnosti obnovení Zde je možné vybrat, jaké volby pro obnovení budou uživatelům dostupné v průvodci konfigurací BitLockeru. Nastavení Ovládacích panelů: Konfigurovat složku obnovení Slouží pro výběr výchozí složky pro uložení hesla obnovení. Za normálních podmínek se zadává jako úplná cesta (\\server\sdílená jednotka\cesta). Pozor, jedná se pouze o nastavení výchozí složky – uživatel si vždy bude moci vybrat jinou složku. Zakázat přepsání paměti při restartování Počítač je možné nastavit tak, aby při „teplém restartu“ nebyl přepsán obsah jeho operační paměti. To sice zkrátí čas potřebný pro restart, ale riskujete tak, že v paměti mohou zůstat tajemství BitLockeru. Ve výchozím nastavení je paměť přepisováním, aby byla odstraněna všechna tajemství BitLockeru. V dalších dvou odstavcích najdete stručné vysvětlení voleb pro služby TPM. Zapnout zálohování čipu TPM službou AD DS Zde je možné vybrat, zda je heslo vlastníka TPM zálohováno do AD DS a obdobně jako u ekvivalentní volby pro BitLocker učit, zda je zálohování povinné či ne. Jestliže zvolíte povinné zálohování, nemůžete změnit heslo vlastníka (jehož zadávání je obvykle součástí první aktivace BitLockeru) s výjimkou případů, kdy jste připojeni k síti a nové heslo je tedy možné zálohovat. Konfigurovat seznam blokovaných příkazů čipu TPM, Ignorovat výchozí seznam blokovaných příkazů čipu TPM, Ignorovat místní seznam blokovaných příkazů čipu TPM Tato tři nastavení slouží k povolování nebo zakazování funkcí čipu TPM. Pro BitLocker byste hodnoty těchto nastavení měnit neměli.

242

Kapitola 5 – Bitlocker – řešení problémů se zabezpečením přenosných počítačů

Správa čipů TPM a BitLockeru ve velkých firmách Zásada skupiny je pouze jedním z nástrojů pro řízení BitLockeru. Vzhledem k tomu, že BitLocker i základní služby TPM obsahují poskytovatele WMI, jsou jejich činnosti zpřístupněny přes službu WMI. Máte-li tedy konzolu pro správu WBEM, můžete správu BitLockeru zařadit do celkové strategie využívání WBEM. WMI však nabízí ještě několik jiných zajímavých vlastností. Tou první je vzdálená správa. Vše, co se dá provádět prostřednictvím WMI na místním počítači, se dá dělat také vzdáleně. To značně zpříjemňuje správu většího počtu počítačů. Vzdáleně však není možné BitLocker spravovat ve všech aspektech. Část specifikace TPM, týkající se přebírání vlastnictví nového čipu TPM, vyžaduje fyzickou přítomnost uživatele, aby nemohlo dojít k situaci, kdy vlastnictví přebere malware. Vliv fyzické přítomnosti uživatele rozebírá Xian Ke ve svém příspěvku na blogu vývojového týmu BitLockeru, dostupném na adrese http://blogs.technet. com/bitlocker/archive/2006/05/12/428173.aspx. Při změně vlastník čipu tedy někdo musí být přítomen u počítače, na kterém ke změně dochází. Druhá zajímavá součást WMI nám obyčejným smrtelníkům pomůže spíše. Vývojový tým BitLockeru vytvořil nástroj příkazového řádku pro komunikaci s WMI a poskytovateli BDE a TBS. Nástroj se jmenuje manage-bde.wsf a je součástí systému Vista. Dá se předpokládat, že Microsoft vystaví stáhnutelný dokument s podrobným popisem činnosti manage-bde, i když musím říci, že nápověda dodávaná přímo s ním je velmi podrobná. Na následujících obrazovkách vidíte ukázku různých příkazů, které jsou v nástroji manage-bde k dispozici.

Správa čipů TPM a BitLockeru ve velkých firmách

243

Všimněte si parametru –cn (nebo –computername), kterým lze nasměrovat manage-bde na vzdálené počítače. Uvádím několik příkladů využití manage-bde pro řešení reálných úloh. Dejme tomu, že chceme zjistit, zda je na nějakém vzdáleném počítači BitLocker zapnut nebo vypnut. (Vzdálený počítač se bude v následujících příkladech jmenovat vroubek-vistabde.) Manage-bde.wsf -cn vroubek-vistabde -status c:

Výpis příkazu bude vypadat asi takto:

Víme tedy, že na vzdáleném počítači je čip TPM aktivován, pravděpodobně tím pracovníkem IT, který na něm instaloval Vistu, a nyní je připraven k tomu, abyste na něm TPM zapnuli a převzali vlastnictví pomocí následujících příkazů: Manage-bde.wsf -cn vroubek-vistabde -tpm -TurnOn Manage-bde.wsf -cn vroubek-vistabde -tpm -TakeOwnership NoveHeslo

Výstupy těchto příkazů se budou lišit v závislosti na přesném stavu vašeho TPM. Dále chceme zapnout BitLocker, a to včetně povolení obnovy. Chceme si také ověřit, že šifrování disku skutečně začalo:

244

Kapitola 5 – Bitlocker – řešení problémů se zabezpečením přenosných počítačů

Manage-bde.wsf -cn vroubek-vistabde -on -skiphardwaretest -recoverypassword c:

Manage-bde.wsf -cn vroubek-vistabde -status c:

Pár poznámek: zadával jsem tu jméno počítače, přestože jsem pracoval přímo v jeho konzole. Nástroj manage-bde je tedy možné používat místně (s parametrem nebo bez parametru -cn) či

Údržba počítače chráněného nástrojem BitLocker

245

vzdáleně (vždy s parametrem –cn). Protože jsem pracoval přímo na něm, je to také důkaz o tom, že počítač zůstává plně dostupný i poté, co na něm začne šifrování dat. Protože obrázek ve své knize nepovažuji za „zabezpečené umístění“ (přestože je možné ho považovat za místo „mimo počítač“), změnil jsem si po jeho sejmutí své heslo obnovení.

Údržba počítače chráněného nástrojem BitLocker Počítač není statická věc, v průběhu času je na něm nutné aplikovat záplaty, aktualizovat aplikace (nebo dokonce i firmware). Jestliže si BitLocker ověřuje stav systému prostřednictvím čipu TPM, jaké změny hardwaru je možné provést? Jaká akce spustí obnovu? Připomeňme si předchozí pasáž o tom, jak VMK pomáhá udržet zabezpečení BitLockeru i v případech, kdy je potřebné BitLocker dočasně vypnout a přitom neprovádět zpětné dešifrování dat. Tato situace je v dokumentaci obvykle popisována jako „disabled mode“ (vypnuto), správnější by však bylo říkat „vypnutá ochrana“. Jestliže zakážete BitLocker, může dojít k opětovnému zapečetění klíčů čipem TPM. To znamená, že při provádění změn, které by jinak spustily proces obnovy, zůstane BitLocker vypnut a po jeho opětovném povolení budou nové klíče zapečetěny novými hodnotami PCR.

246

Kapitola 5 – Bitlocker – řešení problémů se zabezpečením přenosných počítačů

Jak je vidět na následujícím obrázku, v Ovládacích panelech je možné vybrat, zda jednotka bude či nebude dešifrována:

BitLocker je možné vypnout také z příkazového řádku, kde se dá rovněž provádět kontrola aktuálního stavu. (U dávkových souborů je také možné vracet stav ochrany jako hodnotu ERRORLEVEL. Chytré.)

Bezpečné vyřazování staré techniky

247

Vzhledem k tomu, že si čip TPM vytvoří hash pro BIOS a ten je následně sledován BitLockerem, vyvolá aktualizace BIOSu uzamčení jednotky a přechod do režimu obnovy. Proto byste v případě aktualizace BIOSu měli BitLocker vždy dočasně vypnout. Oproti tomu jsou aktualizace systému Vista, získávané prostřednictvím procesu Windows Update (včetně automatických aktualizací) digitálně podepsány a BitLocker o nich „ví“; u pravidelných aktualizací systému proto není nutné BitLocker vypínat. Ostatní aktualizace (softwarové záplaty aplikací a případně i aktualizace hardwarových součástí nebo ovladačů) se nacházejí někde mezi těmito dvěma případy – někdy je nutné BitLocker vypnout, jindy ne. Jestliže jde pouze o aplikaci na úrovni režimu uživatele (bez změny kódu na úrovni jádra), nemělo by být vypnutí BitLockeru podmínkou. Při aktualizaci ovladačů hardwarových zařízení nikdy neuškodí být obezřelý a buď BitLocker vypnout, nebo mít alespoň připraveno heslo obnovení po ruce (ideálně na USB flash disku).

Bezpečné vyřazování staré techniky Každý počítač je nakonec nutné vyřadit. Tato vyřazení může mít různou formu: u zapůjčených strojů je musíte vrátit majiteli, u vlastních počítačů je někdy předáte jinému oddělení, věnujete nějaké nevýdělečné organizaci, nebo vyhodíte. V každém případě je nutné při vyřazování odstranit ze všech úložišť veškerá citlivá data. Pro tyto účely byly vyvinuty nejrůznější nástroje i postupy. Na úrovni softwaru se běžně doporučuje přepsat obsah disku náhodnými nebo pevně danými čísly (přičemž zápis je třeba opakovat i několikasetkrát), je to však dost zdlouhavé a nákladné. Na úrovni hardwaru je více spolehlivých možností: pevný disk se dá rozdrtit, provrtat, roztavit nebo rozřezat. Je to sice také nákladná činnost, zabírající určitý čas, ale můžete se zde spolehnout na to, že hardware je skutečně zničen. S nástupem BitLockeru se objevila nová volba: už se nemusíte zatěžovat ničením disku nebo přemazáváním dat, stačí disk trvale znepřístupnit. Existují dva způsoby, jak se to dá udělat: první se dá popsat frází „ještě si nejsem jist“ a druhý „ano, to je moje poslední slovo“. V prvním případě vymažete z disku (z metadat jednotky) všechny ochránce klíčů s výjimkou klíčů pro obnovení a tak zajistíte, že systém přejde do režimu obnovy při každém spuštění. Přitom již neexistuje žádný další zdroj informací, který by povolil BitLockeru odemknout jednotku. Takto si zajistíte, že případný kupec počítače v bazaru ho nebude moci spustit a číst si historii lékařských předpisů vaší ženy (nebojte se, tady ji vypisovat nebudu), ale autorizovaný uživatel – vybavený heslem obnovení nebo USB klíčem pro obnovení – bude stále schopen získat data v případě potřeby zpět. Pokud jste si opravdu jisti, že už data nikdy potřebovat nebudete, můžete celý postup vylepšit: vymažte všechny informace pro obnovení ze služby Active Directory a vymažte všechny ochránce klíčů s metadat jednotky. I kdyby někdo měl stále k dispozici USB disk se spouštěcím klíčem, nebude mu to k ničemu – nedá se již použít. BitLocker však ve skutečnosti nedovolí, aby v metadatech jednotky nebyl žádný klíč, proto je třeba nahradit klíč pro obnovení náhodným klíčem, který si nikam nebudete ukládat. Pak odstraňte všechny ostatní klíče. Z pevného disku nyní máte ocelovou cihličku.

248

Kapitola 5 – Bitlocker – řešení problémů se zabezpečením přenosných počítačů

Další šikovnou pomůckou je formátovací nástroj Visty. Ve Vistě byl příkaz format přepracován tak, aby smazal všechny struktury klíčů BitLockeru, několikrát přepsal jejich prostor na disku a tak zabránil jejich obnově, a následně celý disk zformátoval, takže format i s přepínačem /Q (quick; rychlé formátování) postačuje pro rychlé a přitom bezpečné vyřazení disku z provozu. Je toto „bezpečné“ vyřazení pomocí BitLockeru dostatečně spolehlivé? No, není to samozřejmě tak spolehlivé jako tisícinásobné přepsání pevného disku náhodnými řetězci, po kterém disk provrtáte, rozdrtíte na prášek, zametete zlomky, roztavíte je a odlijete z nich medaili, kterou poté vypálíte do vesmíru jako pozdrav jiným civilizacím … ale zase to je o dost levnější. Každá situace je jedinečná. Pokud důvěřujete 256bitovému šifrování AES s přidaným algoritmem difuzoru – a tomu důvěřovat můžete – můžete se spolehnout na to, že váš počítač bude přiměřeným způsobem odstaven.

Příprava nasazení BitLockeru Nejsme si jisti, že nás redaktor nechá hovořit o tom, co musíte udělat nejdříve, až v poslední části kapitoly… ale když konečně víte, jak BitLocker funguje, víte dost na to, abyste mohli začít plánovat jeho nasazení a používání. Až začnete do svých firem nasazovat Vistu, měli byste si celý proces v každém případě pořádně rozmyslet. Určitě netoužíte po tom, aby vám ve dvě ráno volal šéf vašeho šéfa a chtěl vědět, jak je možné, že se hospodářské výsledky firmy prodávají na černém trhu; pravděpodobně netoužíte ani po tom, aby vám volal kvůli tomu, že si špatně zapsal PIN a nemůže se najednou dostat k oblíbené kolekci MP3 písní. Při plánování je vhodné brát ohled na tyto věci: ■

Hardwarové požadavky. V některých oborech je BitLocker považován za tak velký přínos, že neváhají hromadně nakoupit nové počítače s čipy TPM, zatímco jinde tento nákup trvá mnohem delší dobu. Počítače nemusejí být vybaveny čipem TPM, ale musí mít kompatibilní BIOS, aby bylo možné BitLocker používat v kombinaci se spouštěcím klíčem.

■

Prověřit stávající infrastrukturu a pracovní postupy. Jak jsou nastavovány nové počítače v současnosti? Chcete šifrování disků provést skriptem jako součást skriptované instalace Visty?

■

Logistika klíčů TPM. Nastavil výrobce počítače Endorsement Key? Kdo bude přebírat vlastnictví čipu TPM? Jak se vyrovnáte s požadavkem na fyzickou přítomnost uživatele? Je čip TPM zapnut a aktivován, nebo je dík nějakému záhadnému nastavení BIOSu „skryt“?

■

Promluvte si s dodavateli nebo výrobci hardwaru. Zjistěte si, jak oni navrhují řešit logistiku TPM. Sestaví vám počítače s vámi navrženými obrazy disků? Budou počítače splňovat požadavky na logo Windows Vista? Budou pevné disky rozděleny již ve výrobě tak, aby vyhovovaly požadavkům BitLockeru? Upraví vám ty počítače, které jste od nich koupili během posledního roku?

Souhrn

249

■

Definujte konfiguraci BitLockeru a ochránce klíčů. Jaké ochránce budete používat? Kde budete ukládat informace potřebné pro obnovení a jak se o ně budete starat? Které počítače, uživatelé nebo typy dat budou vyžadovat PIN nebo spouštěcí klíče?

■

Definujte zásady zabezpečení a obnovy. Co budete dělat, když se nějaký počítač dostane do režimu obnovy… na ústředí firmy? Během cesty? Jaký čas je potřebný na vydolování informací pro obnovení z doménových služeb Active Directory? Kdo bude mít přístup k informacím uloženým v AD DS? Jak zjistíte hlavní příčinu vstupu do procesu obnovy? Nezapomeňte si také naplánovat opětovné vytvoření nových klíčů a dalšího materiálu, pokud jste museli obnovu provádět někde mimo firmu nebo dát potřebné informace třetí straně.

■

Definujte zásady pro vyřazování počítačů. Jakou úroveň „asanace“ zvolíte? Budou se nainterní přesun počítačů vztahovat stejná pravidla jako na konečné odstavení?

■

Naplánujte a poté nastavte doménové služby Active Directory. U produkční instalace AD DS byste měli používat proces řízení změn. Kdo všechno potřebuje oprávnění pro čtení dat pro obnovení, aby mohl pomoci konkrétním uživatelům? Máte v podniku několik doménových struktur? (V tom případě máte i několik schémat – pozor na to.) Zjistěte, co vše je třeba změnit, pořiďte si potřebné skripty a pořádně je před jejich implementací otestujte.

■

Nastavte zásady skupiny. I zde je řízení změn váš přítel. Všechna měněná nastavení nejdříve otestujte, abyste se vyhnuli nepříjemným překvapením. Nezapomeňte na to, že změny předvoleb šifrování musí být provedeny ještě před spuštěním vlastního procesu zašifrování disků.

Souhrn BitLocker je skvělý. A může vás zachránit před pěkným průšvihem.

250

Kapitola 5 – Bitlocker – řešení problémů se zabezpečením přenosných počítačů

6 Ochrana po zavedení systému – integrita kódu, nová pravidla pro podepisování kódu a patchguard V předchozím průběhu knihy jste poznali, že Vista se chová lehce paranoidně, a to je dobře, protože zástupy počítačových kriminálníků neutěšeně rostou. Oproti všem předchozím verzím Windows nyní Windows Vista náhodně mění umístění základních systémových služeb, čímž značně ztěžuje práci pisatelům různých červů. Mezi další sadu anti-malwarové výbavy patří integrita kódu, kontrola digitálních podpisů souborů při zavádění systému a nová sada pravidel, určená jen pro 64bitové Windows. Podle těchto pravidel musí být digitálně podepsány všechny ovladače. Tato kapitola podrobně vysvětluje obě tyto ochrany. Ale to ještě nejsou všechny novinky 64bitové Visty: její jádro obsahuje tzv. „PatchGuard“ (novější pojem Kernel Patch Protection), který se pokouší inteligentním způsobem malware detekovat a zastavit.

Náhodné rozložení adresního prostoru První z post-boot ochran je sice jednoduchá, ale přesto velmi elegantní, a představuje silnou zbraň proti autorům různých červů. Oficiálně se jmenuje ASLR (Address Space Layout Randomization) a dělá přesně to, co prozrazuje její název: znáhodňuje Vistu. Tento pojem sice nemusí znít dobře, ale je dobrý. Když byste se totiž pořádně podívali do operační paměti RAM počítače s Windows XP, zjistili byste, že spousta míst paměti vypadá v různých počítačích jinak, ale některé části jsou vždy obsazeny stejně. Konkrétně jde o to, že stovky a možná tisíce drobných součástí Windows jsou do paměti nahrávány vždy ve stejném pořadí na všech počítačích – a platí to především pro všechny knihovny DLL, které systém používá. ASLR toto chování mění a při každém spouštění počítače nahrává knihovny DLL ve zcela náhodně generovaném pořadí. ASLR je navrženo tak, aby se knihovny daly nahrát celkem ve 256 různých variantách pořadí. To je velmi důležité, protože tvůrci červů využívajících techniku přetečení bufferu tak naráží na velké potíže. Přetečení bufferu je osvědčeným způsobem, jak se nabourat do kódu Windows, ale jakmile se do systému dostanete, kde se vlastně v paměti nacházíte? Dále, jakmile jste uvnitř, kde se nachází kód, který chcete změnit, abyste mohli převzít řízení nad systémem? Autoři červů využívajících přetečení bufferu opravdu mohou změnit libovolný kód, který je

252

Kapitola 6 – Ochrana po zavedení systému

zajímá – web server, hesla a další zajímavé věci – ale jen tak, že se jim podaří odhadnout relativní vzdálenost v RAM mezi místem, kde dojde k přetečení a místem cílového kódu. Náhodným rozmístěním systémových součástí můžeme plány těchto dobráků zásadně nebo úplně narušit. Předpokládám, že je možné teoreticky napsat chytřejší červy, ale bylo by to hodně náročné, pokud vůbec možné. Náhodný výběr adres není novinkou Windows, ve světě BSD Unixu ho už znají nějakou dobu. Je to vítaný přírůstek v arzenálu zabezpečení Windows.

Nové pancíře pro 64bitové systémy Prvním výpadem Microsoftu do světa 64bitových systémů byly Windows XP a Windows Server 2003. Přestože trh 64bitových systémů ještě není dostatečně rozvinut, stále více a více výrobců dodává 64bitové procesory. Během posledních dvou let se 64bitové procesory dost využívaly v serverech, ale jejich dramatický cenový pád v poslední době se odráží také na přechodu mnoha dalších lidí na 64bitové operační systémy i u pracovních stanic. Co je tak skvělé na 64bitových procesorech? Je to jen další kometa na obloze, která přesviští a zapadne, aniž by na ní záleželo? Ne. Ve skutečnosti 64bitové procesory značně zrychlují a zjednodušují práci s databázemi, digitálními filmy a velkými sadami dat. Kromě toho jsou 64bitové clustery mnohem spolehlivější než clustery 32bitové. Vista přináší ve své 64bitové architektuře dvě hlavní aktualizace (nová je pouze jedna z nich, ale o tom za chvíli): nová pravidla pro podepisování ovladačů a nástroj pro ochranu jádra proti injektáži kódu (kernel patching protection), označovaný kódovým jménem „PatchGuard“. Na ten se podíváme nejdříve.

PatchGuard Technologie Kernel Patch Protection, pro kterou se používá spíš pojem „PatchGuard“, není žádnou novinkou Windows Vista; najdete ji už v 64bitových verzích Windows XP Professional a Windows Server 2003 SP1. Tam však nezískala moc velkou pozornost, což mohlo být zaviněno právě nepříliš velkým zájmem o 64bitové systémy v této době. Nezávisle na tom se PatchGuard vrací na scénu v 64bitovém vydání Windows Vista, a zde se konečně dostává do obecného povědomí a spousta lidí o něm začíná mluvit, včetně výrobců různých softwarových řešení pro zabezpečení počítačů a výrobců antivirových programů. Než se pustíme do výkladu toho, zda je Kernel Patch Protection diskutabilní nebo prospěšná, musíme nejdříve probrat, co to je. Kernel Patch Protection chrání jádro systému – centrální část operačního systému, běžící na nejnižší úrovni – před sabotážemi. Jádro musí být chráněno, protože nad ním běží všechny aplikace a grafické uživatelské rozhraní Windows. Jádro je také prvním kusem kódu operačního systému, které je zavedeno do paměti při spouštění počítače. Je jasné, že pokud je jádro poškozeno, máte velký problém. V článcích Microsoft Knowledge Base č. 146419, 155892 a 327101 je podrobně popsáno, jak se dá systém obnovit po ztrátě nebo poškození souboru jádra, ale ve vší úctě, toto bychom dělat neměli. Jádro musí být chráněno. Většina problémů s jádrem je důsledkem selhání hardwaru, průniku malwaru nebo chyby při záplatování. Zatímco výpadkům hardwaru se Windows bránit nedokážou, mohou samy pomoci při obraně proti zápla-

Nové pancíře pro 64bitové systémy

253

tování jádra. Řízení uživatelských účtů Visty varuje uživatele před pokusy malwaru o instalaci do systému. Jestliže v dialogu UAC klepnete na tlačítko Pokračovat nebo poskytnete práva správce rootkitu jiným způsobem, bude vám brzy hodně horko. Opravdu? Podívejme se nyní na to, jak Vista Kernel Patch Protection zmirňuje účinky rootkitů a jiných útoků malwaru. Připomínám, že Kernel Patch Protection existuje jen u 64bitových vydání Windows Vista. Microsoft by byl velmi rád, aby nechvalně známé modré obrazovky smrti (BSoD) zůstaly ve Vistě jen vzpomínkou. BSoD se objeví v případě výskytu chyby jádra nebo chyby ovladače běžícího na úrovni jádra. Když ve Windows uvidíte BSoD, je nutné restartovat a doufat, že se to nebude opakovat. Microsoft vždy považoval záplatování jádra („kernel patching“ nebo také „kernel hooking“) za nepřípustné. Při záplatování jádra jsou používány nepodporované metody nahrazování části kódu jádra nebo jeho aktualizace (záplatování). Záplatované jádro je obvykle nestabilní a chová se neodhadnutelným způsobem. S modrými obrazovkami smrti se ve skutečnosti často setkáváme právě po aplikaci záplaty jádra. Většina lidí, kteří záplatují jádro, na něj ve skutečnosti útočí – tuto většinu tvoří tvůrci malwaru a virů. Existuje však jedna velká výjimka (která objasňuje, proč Kernel Patch Protection získala v poslední době tak velkou mediální pozornost): dodavatelé antivirových a anti-malwarových řešení často využívají záplatování jádra pro zachycení systémových volání kódu, který identifikovaly jako zákeřný. Tyto bezpečnostní aplikace běžící na úrovni jádra však mohou snížit stabilitu systému a jeho výkon. Po úspěšné aplikaci rootkitu zůstávají často všechny jeho procesy pro uživatele neviditelné. Když se podíváte na seznam spuštěných procesů ve Správci úloh (ve Vistě stiskněte Ctrl + Alt + Delete a poté klepněte na tlačítko Spustit správce úloh), neuvidíte v něm žádné procesy běžícího rootkitu. To znamená, že rootkit je neviditelný i z hlediska infrastruktury počítače. Podaří-li se rootkitu zapsat se do jádra systému, může proniknout do útrob operačního systému a instalovat tam další zákeřný kód, například keyloggery (aplikace sledující stisky kláves), schopné sbírat vaše hesla k počítači i třeba k bankovním účtům. Jak je 64bitová verze Visty vypořádá s touto noční můrou? POZNÁMKA:

Technologie Kernel Patch Protection není v současné době dostupná na 32bitové a ia64 architektuře.

Kernel Patch Protection aktivně sleduje jádro systému, aby dokázala zjistit každý pokus o neoprávněné záplatování jádra. Pokud Vista takový pokus odhalí, vypne počítač. Bylo by sice moc pěkné, kdyby Kernel Patch Protection byla universálním lékem nebo štítem proti veškerému škodlivému kódu a virům, je to ale příliš nereálná představa. Kernel Patch Protection není stoprocentní ochranou proti instalaci škodlivého kódu, ale proti útokům na systém využívajícím technologii záplatování jádra. Integrita jádra prostě musí být zachována, protože jde o fundamentální vrstvu operačního systému.

PatchGuard nepovolí mou aplikaci: co mám dělat? Nyní se dostáváme k diskutabilním aspektům Kernel Patch Protection – k místu, kde dochází k zákazům stávajících 64bitových aplikací. Máte-li ve Windows nainstalovánu nějakou antivirovou nebo anti-malware aplikaci, je vysoce pravděpodobné, že využívá technologii záplatování jádra pro

254

Kapitola 6 – Ochrana po zavedení systému

sledování škodlivých aktivit. 64bitové aplikace však nesmí měnit jádro ani jeho prostředky. Jen si představte, jak by se cítil uživatel, u kterého se vadná 64bitová aplikace opakovaně pokouší měnit jádro Visty… ten by se z neustálého vypínání počítače asi zbláznil. Co tedy výrobcům antivirových a jiných anti-aplikací zbývá? Kam se mají v 64bitovém světě obrátit? Naštěstí existuje několik alternativ k nadále nepoužitelnému záplatování jádra. ■

Jestliže jde o aplikaci, které využívá záplatování jádra pro průzkum obsahu síťových paketů (sem patří například firewally), může se obrátit na služby WFP (Windows Filtering Platform). Platforma WFP umožňuje hloubkovou analýzu paketů TCP/IP a celé cesty zpracování TCP/IP. WFP dovoluje antivirům a firewallům pakety zkoumat i měnit ještě přede jejich předáním k dalšímu zpracování. WFP je sada služeb a API, kterou však samu o sobě nelze implementovat jako službu. Brána Firewall systému Windows je na technologiích WFP založena.

■

Antivirové a anti-malwarové aplikace mohou používat „mini filter model“, který je součástí souborového systému Visty.

■

Aplikace vyžadující přístup k systémovému registru mohou používat registry notification hooks. Microsoft tyto háky zavedl již ve Windows XP.

Aplikace a ovladače, které se pokoušejí měnit jádro, musí být přepracovány tak, aby používaly jen podporovaná veřejná rozhraní. Jestliže je tato změna aplikace nebo ovladače nemožná, není možné požadované akce na 64bitové Vistě provádět bezpečně. Je pravda, že ve Vistě byla provedena spousta změn, které mají výrazný dopad na produkty jiných softwarových firem. V podstatě všechny změny byly provedeny kvůli tomu, aby se zlepšilo zabezpečení operačního systému. Vývojáři však budou muset stále sledovat požadavky na vývoj aplikací pro Vistu. Microsoft vyzval všechny vývojáře, kteří si nejsou něčím jisti nebo je doporučení a požadavky pro vývoj matou, aby na ně se obrátili kontaktním mailem msra@microsoft.com. Rovněž aplikace psané v samotném Microsoftu musí dodržovat pravidla Visty pro psaní programů a není na ně brán žádný zvláštní ohled. Žádný 64bitový kód samotné Visty nesmí měnit jádro operačního systému. Vista vyžaduje, aby všichni vývojáři Microsoftu i jiných firem dodržovali bezpečné postupy při vývoji aplikací a používali jen podporovaná rozhraní. Pravidla pro záplatování jádra Visty porušují aplikace, které provádějí následující činnosti: ■

Záplatují kernel.

■

Mění tabulku popisovačů přerušení.

■

Mění tabulku globálních popisovačů.

■

Mění tabulky systémových služeb.

■

Používají zásobníky jádra, které nebyly alokovány jádrem.

Microsoft dal rovněž jasně najevo, že v budoucnosti technologii Kernel Patch Protection dále rozšíří o ochranu dalších prostředků jádra, neuvedl však, o jaké prostředky se bude konkrétně jednat.

Chcete vypnout PatchGuard? Je mi líto, ale Kernel Patch Protection se na 64bitových systémech vypnout nedá. Neexistuje žádné veřejně dostupné uživatelské rozhraní, které by toto pravidlo měnilo. Je sice pravda, že vypnutím

Integrita kódu

255

tohoto nástroje by byl umožněn běh některých starších aplikací, ale zároveň bychom se tak vrátili do království nejistoty nahodilých ovladačů a aplikací, měnících jádro systému. Bohužel pojem „záplatování jádra“ neprozrazuje sám o sobě, že jde o nežádoucí činnost s negativními dopady. POZNÁMKA:

Ochrana Kernel Patch Protection je v jednom případě zakázána: když je k počítači připojen debugger jádra (samostatný počítač pro nízkoúrovňové odlaďování softwaru se spuštěnými programy, které umožňují nahlížet do paměti a registrů prvního počítače).

Integrita kódu Ve Vistě má premiéru také nová technologie, představující jednu z možností ochrany souborů a programů Windows před různými sabotážemi. Jde o tzv. integritu kódu (code integrity, CI). Kvůli jakým hrozbám tato technologie vznikla? Je-li nějaký životně důležitý systémový soubor změněn nebo přepsán trojským koněm nebo ničemným správcem, je systém zčistajasna zkompromitován. Musíme sice být realističtí a připustit, že každá osoba s fyzickým přístupem k počítači může být jeho „vlastníkem“, ve Vistě však existují komponenty, které pomáhají takové útoky omezit (a v některých případech jim úplně zabránit). Jednou z takových technologií je BitLocker Drive Encryption, kterou najdeme ve verzích Ultimate a Enterprise a které byla věnována předchozí kapitola. Šifrování celé jednotky OS Windows o síle až 512 bitů, kdy je klíč uložen buď v čipu TPM nebo na USB klíči v bezpečné vzdálenosti od počítače, je dostatečnou ochranou proti odcizení dat v případě krádeže nebo ztráty notebooku. Zajištění platnosti tisíce spustitelných souborů ve složce \Windows je základní součástí udržování integrity kódu, a jak jste se dočetli ve čtvrté kapitole, Microsoft upravil přístupová oprávnění ke složce \Windows a jejím podsložkám, což by se dalo označit jako „Windows Integrity Control Lite“ (zjednodušená verze řízení integrity – sám Microsoft to označuje jako Windows Resource Protection čili WRP). Ukazuje se ale, že WRP není příliš účinná ochrana, protože příkazem takeown lze jednoduše převzít vlastnictví složek Windows a následně mazat soubory. WRP dokonce velmi překvapivě neumí ani to, co WFP, protože pokud smažete soubor (například notepad.exe), není tento obnoven automaticky – musíte spustit příkaz sfc /scannow, aby si WRP všimnula, že byl smazán soubor! Integrita kódu funguje tak, že kontroluje vypočítané hodnoty hashů pro všechny soubory, které Windows při startu nahrávají do paměti. Hodnota hashe souboru je číslo, odvozené z textového řetězce, a slouží k ověření toho, že soubor nebyl změněn, přepsán nebo poškozen. Integrita kódu rovněž kontroluje soubory, které jsou nahrávány v chráněném procesu. Hashe souborů jsou uloženy buď v certifikátu X.509 přímo uvnitř souboru, nebo v systémovém katalogu operačního systému Vista. Vista dále kontroluje integritu jádra, vrstvy HAL (hardware abstraction layer) a ovladačů aktivovaných v prvních fázích spouštění počítače. Pokud některý soubor nebo obraz touto kontrolou integrity neprojde, Vista ho nenahraje do paměti. POZNÁMKA:

Integrita kódu Visty neověřuje integritu souborů a obrazů jiných výrobců.

256 TIP:

Kapitola 6 – Ochrana po zavedení systému

Příkazem sigverif lze zkontrolovat digitální podpisy libovolných souborů v libovolném čase.

Integrita kódu funguje také jako sada technologií, včetně těch, které budou probírány dále v této kapitole (například nová pravidla pro podepisování ovladačů na 64bitových systémech a PatchGuard.

Co se může pokazit? V případě selhání integrity kódu se můžete teoreticky setkat s několika možnými problémy, ale ty se vyskytují jen zřídka. Mezi tyto problémy patří například: ■

Windows nenastartují, protože během prvních fází zavádění selže kontrola integrity některého ovladače zaváděného v této době nebo kódu jádra.

■

Po spuštění Windows nebude správně fungovat některé hardwarové zařízení, protože selže kontrola integrity ovladače zaváděného v pozdější fázi spouštění.

■

Windows se budou chovat nenormálním způsobem kvůli tomu, že kontrolou integrity neprojde některá ze služeb.

■

Nelze provést určitou úlohu, protože kontrolou integrity neprošla některá součást Windows.

Je jasné, že v některých z těchto případů budete muset věnovat svůj čas podrobnějšímu zkoumání příčiny potíží. Uvádím proto několik tipů pro řešení problémů s integritou kódu.

Řešení potíží se službami Windows Při hledání příčin potíží se službami se zaměřte na dvě místa. Nejdříve spusťte modul snap-in Služby konzoly MMC (příkaz services.msc). Zde si ověřte, zda běží ty služby, které mají být spuštěny spolu se systémem. Poznamenejte si názvy všech služeb, které selhaly. Za druhé spusťte Prohlížeč událostí (eventvwr.msc)a prověřte auditovací protokol. Prohlédněte systémový protokol (uvnitř skupiny protokolů systému Windows a dále prohlédněte protokol aplikací a služeb. Vista obsahuje také auditovací protokol CodeIntegrity, umístěný ve větvi protokolu Protokoly aplikací a služeb/ Microsoft/Windows/CodeIntegrity. Jestliže najdete nějakou problémovou službu, můžete se pustit dál několika cestami. Jestliže jde o službu Windows, zkuste ji aktualizovat prostřednictvím Microsoft Update. Není-li žádná aktualizace dostupná, zkuste na webu vyhledat (Google) radu v článcích Knowledge Base nebo jiných podobných zdrojích. V některých případech je nutné službu nahradit její kopií, která nebyla zasažena škodlivým kódem nebo hrátkami hackera. Tento problém se dá řešit reinstalací služby a příslušných součástí přes legitimní kanál technické podpory (pro služby Windows například Microsoft Update).

Řešení potíží s ovladači Selhání ovladače zaváděného před OS nebo kódu jádra je nejtypičtějším případem selhání při kontrole integrity kódu. Pokud jedna z těchto kontrol integrity kódu selže, Windows se vůbec nespustí. V tom případě budete muset použít konzolu pro obnovu (Vista Recovery Console), do které se do-

Nová pravidla pro podepisování kódu

257

stanete po nastartování počítače z instalačního DVD Visty. V obrazovce Nainstalovat zvolte příkaz Opravit tento počítač, kterým se dostanete do dialogového okna Možnosti obnovení systému, ve kterém je nová a vcelku užitečná volba Oprava při spuštění. Pro obnovu ovladače, který je zaváděn až spolu s OS, není volba Oprava při spuštění nutná. Namísto ní spusťte Prohlížeč událostí a pole obsahu protokolů zjistěte, který ovladač nebyl správně nahrán. Vista nově obsahuje také protokol CodeIntegrity, umístěný ve větvi Prohlížeče událostí Protokoly aplikací a služeb/Microsoft/Windows/CodeIntegrity. Zařízení nefungující správně se dají najít také ve Správci zařízení. (Ve Vistě se do něj dostanete takto: po klepnutí na tlačítko Start klepněte pravým tlačítkem myši na Počítač a v místní nabídce vyberte Vlastnosti. V levém panelu klepněte na odkaz Správce zařízení. Ve Správci zařízení pak stačí najít veškerý hardware, který má vedle svého popisu otazník – tato zařízení nefungují správně, a to kvůli nějakému hardwarovému problému nebo scházejícímu či vadnému ovladači. Je-li ovladač špatný, sežeňte si novější verzi u výrobce nebo z instalačních médií vytáhněte originální verzi, která není nijak poškozena nebo jinak změněna.

Řešení potíží se součástmi Windows Nejlepší způsob řešení potíží se součástí Windows, které neprojdou testem integrity kódu, představuje důkladná pohlídka protokolů v Prohlížeči událostí. Vista nově obsahuje také protokol CodeIntegrity, umístěný ve větvi Prohlížeče událostí Protokoly aplikací a služeb/Microsoft/Windows/ CodeIntegrity. Výměna vadné součásti se provádí její aktualizací (služba Microsoft Update) nebo opravnou instalací, provedenou v konzole pro obnovu.

Nová pravidla pro podepisování kódu Vista obsahuje nová přísnější pravidla pro podepisování kódu, která vás s největší pravděpodobností nějakým způsobem ovlivní. Než se pustíme do specifických podrobností těchto pravidel, řekneme si, proč je digitální podepisování kódu vyžadováno.

Co si představit pod pojmem „podepisování kódu“ a proč na něm tak záleží? Proč není dobré spouštět nějaký nepodepsaný ovladač nebo aplikaci? Podstata podepisování kódu vychází z principu ověřování totožnosti vydavatele softwaru. Když vydavatel podepíše svou aplikaci, víme, že tato aplikace pochází skutečně od něj. Dále víme, že od okamžiku podepsání nikdo neprováděl žádné zásahy do kódu této aplikace. Aplikace s digitálně podepsaným kódem ještě nemusí být „dobrou“ aplikací. Soubor DobraAplikace.exe může být klidně podepsán firmou „Ďábel a syn“ a jejím účelem není nic jiného, než spolu se zdánlivě nevinným přehrávačem médií zatáhnout do systému i spyware zaznamenávající stisky kláves. Jste to vy coby správce, kdo musí vždy rozhodnout, která aplikace je „dobrá“ a která „zlá“, a rozhodnout o tom, které aplikace je povoleno v síti instalovat (prostřednictvím zásady pro instalaci nebo zapojením instalačních služeb). Vista sice obsahuje pár vestavěných

258

Kapitola 6 – Ochrana po zavedení systému

nástrojů, zabraňujících vzniku některých katastrof, ale pokud povolíte instalaci vadné aplikace, neexistuje žádná záruka, že váš systém zůstane nepřístupný. Jakmile jednou dáte neznámé nebo škodlivé aplikaci právo používat váš token plného přístupu správce, prohrál jste. V následujících částech je podrobně vysvětleno, které typy ovladačů a aplikací musí být ve Windows Vista podepsány.

Ovládací prvky ActiveX Jestliže si v Internet Exploreru stáhnete ovládací prvek ActiveX, Vista tento prvek nespustí, pokud není digitálně podepsán. Toto chování se dá změnit ve vlastnostech Internet Exploreru, umístění příslušné volby vidíte na obrázku 6.1. OBRÁZEK 6.1: Nastavení ActiveX v Internet Exploreru

Po zapnutí volby „Povolit spuštění nebo instalaci softwaru i v případě, že podpis není platný“ je možné v Internet Exploreru spustit a nainstalovat jak podepsaný, tak nepodepsaný software. Toto nastavení se mění také při úpravě voleb pro zóny zabezpečení. Výchozí nastavení zóny Internet ve Vistě je „Středně vysoké“, kdy je instalace nepodepsaných ovládacích prvků ActiveX blokována. Na obrázku 6.2 je snímek obrazovky s touto úrovní zabezpečení. Jestliže celou síťovou infrastrukturu řídíte prostřednictvím Active Directory, dá se rozsah povolených ovládacích prvků, které mohou standardní uživatelé (ne-správci) instalovat a aktualizovat, vymezit prostřednictvím služby ActiveX Installer Service . Služba ActiveX Installer Service určuje povolené ovládací prvky ActiveX na základě hostitelské adresy URL. Jedná se o volitelnou službu, proto je nutné ji na klientských počítačích nainstalovat. Opravdu skvělou vlastností této služby je to, že umožňuje správcům sledovat, jaké explicitně nepovolené ovládací prvky ActiveX se uživatelé pokoušejí nainstalovat. Když se uživatel o něco podobného pokusí (mezi zakázané ovládací prvky může patřit třeba přehrávač Adobe Flash), Vista spustí událost č. 4097. Ve vlastnostech této událos-

Nová pravidla pro podepisování kódu

259

ti najdete název dotyčného ovládacího prvku ActiveX. Správce pak na základě analýzy může určit, zda instalaci často požadovaných prvků povolí změnou příslušné zásady skupiny, nebo nechá dál platit aktuální zásadu. OBRÁZEK 6.2: Standardní nastavení úrovně bezpečnosti Internet Exploreru

Požadavky služby Protected Media Path Dále musí být podepsán veškerý software, který je spouštěn uvnitř tzv. Protected Media Path (PMP). PMP je technologie Visty, které v tomto systému prakticky implementuje Správu digitálních práv (digital rights management, DRM) pro nové generace multimediálních formátů (například HD-DVD). Stručně řečeno tento požadavek znamená, že obsah HD-DVD bude ve Vistě přehrán jen v případě, kdy je digitálně podepsán. Cesta PMP zahrnuje také ovladače zobrazovacích zařízení, které musí mít v sobě zabudován příslušný certifikát, jinak na Vistě fungovat nebudou.

Požadavky platformy x64 Všechny ovladače a aplikace běžící v režimu jádra, a také všechny ovladače zaváděné před vlastním OS musí být digitálně podepsány, jinak je není možné spustit. Ovladače a aplikace běžící v režimu jádra jsou spouštěny v chráněné oblasti jádra, a proto je požadavek na jejich podpis pochopitelný. Boot-start ovladač je takový ovladač, který zavaděč systému Vista nahrává během spouštění systému. Boot-start ovladače jsou vybaveny buď svým souborem INF, ve kterém je typ spouštění zapsán jako „Start=0“, nebo je ovladače označen jako „kernel driver“ či „file system driver“ a jeho StartMode má hodnotu „boot“. 64bitové aplikace běžící v režimu jádra musí být digitálně podepsány, a systém Vista nelze nijak nastavit tak, aby mohly být spouštěny i nepodepsané aplikace běžící v režimu jádra. Z toho vyplý-

260

Kapitola 6 – Ochrana po zavedení systému

vá, že 64bitová Vista prostě nepřekousne nepodepsaný ovladač a odmítne ho. Toto se nedá nijak obejít, jedině nainstalovat vlastní certifikační server a podepsat všechny aktuálně nepodepsané ovladače, které chcete použít. Tomuto postupu se budeme věnovat za chvíli. Boot-start ovladač musí mít podpis přímo v sobě a také zde se jedná o povinnou součást. Jestliže některý z vašich boot-start ovladačů nebude obsahovat vložený digitální podpis, nebude nikdy spuštěn. Zajištění integrity kódu však nemusí končit na úrovni ovladačů a součástí operačního systému. Jak si možná vzpomínáte, ve druhé kapitole byla řeč o tom, že služba Řízení uživatelských účtů umožňuje vyžadovat digitální podpisy také u běžných aplikací, pokud změníte nastavení zásady skupiny „Řízení uživatelských účtů: Zvýšit oprávnění pouze u podepsaných a ověřených spustitelných souborů“.

Jak podepsat aplikaci nebo ovladač Teď již víte, že aplikace pro systém Vista je nutné v mnoha (nebo všech) případech digitálně podepsat. Vlastní podpis se k aplikaci nebo ovladači dá přidat dvojím způsobem: 1. Softwarové firmy (vydavatelé) mohou podepsat kód aplikace nebo ovladače svým firemním certifikátem. 2. Správci systému mohou podepsat kód aplikace, která nebyla předtím podepsána jejím vydavatelem. POZNÁMKA:

Ovladače a aplikace běžící v režimu jádra musí být podepsány svým vydavatelem, který musí svůj podpis vložit také do boot-start ovladačů ještě před jejich vydáním. Neexistuje žádný způsob, kterým by správci systému mohli podepsat vydaný software běžící v režimu jádra nebo vložit certifikát dovnitř boot-start ovladačů.

Pokud se týká volby č. 2, je možné, že vydavatel softwaru nikdy svou původní aplikaci nepodepsal. V takovém případě kontaktujte přímo dodavatele a získejte od něj aktualizované ovladače a aplikace. Jestliže dodavatel zatím podepsanou verzi nenabízí, máte na výběr z dvou následujících voleb pro podepsání softwaru: 1. Použijte interní certifikační úřad (certification authority, CA). 2. Použijte komerční CA. Pozor na to, abyste podepsali jen aplikace od důvěryhodných dodavatelů. (Jinak si koledujete o velmi vážné problémy.) Informace o dodavatelích softwaru za vás může sesbírat i některá ze specializovaných externích firem.

Používáme interní certiﬁkační úřad Jedním z důvodů pro využití služeb interního certifikačního úřadu namísto jeho komerční obdoby jsou interní pravidla pro podepisování kódu. Interní CA musí být důvěryhodný – to je absolutní nutnost. Důvěryhodný CA ve vlastní síti vytvoříte pomocí zásady skupiny nebo automatické registrace (auto-enrollment), kterým přidáte kořenový certifikát interního CA do úložiště „Důvěryhodné kořenové certifikační úřady“. Interní CA se dá použít také pro zajištění vyšší míry kontroly nad aplikacemi, které jsou v rámci sítě považovány za důvěryhodné. Jestliže například povolíte použití

Nová pravidla pro podepisování kódu

261

vývojářského certifikátu, budou všechny aplikace tímto certifikátem podepsané automaticky považovány v rámci sítě za důvěryhodné. Tento případ není vhodný pro některá prostředí. Chcete-li mít větší míru kontroly nad tím, co je ve vaší sítí instalováno, zkuste zvážit použití interního CA pro podpis přesně vyhrazené sady vývojářských aplikací. Dávejte přitom ale dobrý pozor, protože opětovný podpis aplikací vyvinutých jinou firmou a jejich následná distribuce mimo rámec vlastní sítě může znamenat porušení některých licenčních ujednání a z toho vyplývající právní spory.

Používáme komerční CA Své aplikace, které distribuujete jen interně v rámci firmy, můžete podepsat také zakoupeným certifikátem od komerčního certifikačního úřadu. Velkou výhodou tohoto přístupu je fakt, že nemusíte vynakládat čas a peníze na instalaci a správu vlastního interního CA. Aplikace podepsané tímto typem certifikátu budou moci být důvěryhodné i mimo interní síť firmy. Proto je tato metoda vhodná například v situaci, kdy potřebujete sdílet svou interně vyvinutou aplikaci s lidmi, kteří ve vaší firmě nepracují. Proti komerčním CA lze postavit několik argumentů. Z hlediska vystavování nových certifikátů a aktualizací jste silně závislí na cizí firmě. Nákup certifikátu od komerční firmy může být také obtížný, drahý a časově náročný. Komerčnímu úřadu je nutné poskytnout větší množství informací, aby si mohl řádně ověřit identitu vaší organizace. Způsob podepisování, který si nakonec zvolíte, bude záviset na tom, k jakému cíli se chcete dopracovat. Potřebujete-li sdílet vaše aplikace s jinými firmami nebo lidmi, použijte certifikáty komerčního CA. Jestliže však již máte zřízen interní CA, můžete ušetřit čas i peníze a použít svůj úřad. POZNÁMKA:

Více informací o kladech a záporech jednotlivých metod přípravy na digitální podepisování aplikací najdete v dost rozsáhlém dokumentu Microsoftu, který se dá stáhnout na adrese http://www.download. microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fded599bac8184a/ 64bitDriverSigning.doc. Pokud tento odkaz nefunguje, obraťte se na Google a vyhledejte řetě-

zec „64bitdriversigning.doc“.

Nasazení aplikace nebo ovladače, podepsaného vydavatelem Systému Vista je třeba sdělit, že ten a ten vydavatel je v rámci vaší sítě důvěryhodný. To se dá zajistit různými způsoby: ■

Certifikát vydavatele pro podepisování kódu je vydán komerčním CA.

■

Důvěryhodnost certifikátu vydavatele pro podepisování kódu je dána tím, že ho přidáte do úložiště certifikátů Důvěryhodné kořenové certifikační úřady.

■

Certifikáty vydavatelů jsou ve vámi spravovaných počítačích uloženy v úložišti uživatele nebo počítače s názvem Důvěryhodný vydavatel.

POZNÁMKA:

Nezapomeňte na to, že bezpečnost vaší sítě bude záviset na zabezpečení privátních klíčů vydavatelů, pokud je umístíte do svého důvěryhodného úložiště.

262

Kapitola 6 – Ochrana po zavedení systému

Souhrn V této kapitole jsme se mrknuli na to, jak Vista chrání a ověřuje integritu softwaru, který běží na počítači, a také integritu základních souborů operačního systému. Přestože některá vylepšení v této oblasti jsou omezena jen na 64bitovou edici Visty, vedou tyto změny k větším omezením, kterými se vývojáři softwaru musí řídit. Tyto změny jsou však nutné, a to i přes to, že v počátku budou vývojáře hodně zatěžovat. Z dlouhodobého hlediska se zvýšené náklady softwarovým firmám vrátí prostřednictvím zvýšené bezpečnosti jak jejich aplikací a služeb, tak operačního systému Windows jako celé platformy.

7 Jak vista chrání služby Každý moderní operační systém, na který jsem narazil, byl schopný vytvářet a spouštět programy, které pracovaly nenápadně na pozadí a zajišťovaly různé údržbářské funkce. Na systémech Unix a Mac OS (což je ve skutečnosti také Unix, pouze s mnohem hezčím UI) se jim říká „démoni“; ve světě Windows hovoříme o „službách“. Postupem doby se – díky své podstatě – služby staly častým cílem počítačových kriminálních živlů, takže je bezpečnostní analytici začali pořádně zkoumat. Bohužel ve Windows nebylo možné u těchto služeb zvyšovat zabezpečení jednoduše, i když jsme věděli, jak jejich obranu proti útokům vylepšit. To platilo až do příchodu Visty. Myslím, že budete velmi příjemně překvapeni čtyřmi zásadními změnami, které Microsoft u služeb Visty zavedl – tři z nich budeme v této kapitole probírat podrobně, stručný přehled byl uveden již v kapitole minulé .

Stručné představení služeb Zkusme začít tím, co vlastně služby jsou, a jakým způsobem fungují z bezpečnostního hlediska. Služby jsou v podstatě klasické staré programy pro OS Windows, ale liší se od nich čtyřmi specifickými znaky. Za prvé, jsou spuštěny nepřetržitě. Jakmile je počítač spuštěn, jsou některé služby spuštěny spolu s operačním systémem a běží po celou dobu jeho činnosti. (Další služby lze spustit později – doba spuštění se dá řídit v nástrojích Visty pro konfiguraci služeb.) Služby provádějí různé úkoly běžící na pozadí, například postupné předávání tiskových úloh na tiskárnu (služba Zařazování tisku) nebo soustavné monitorování pohybu po službě WWW a případné upozornění uživatele na potencionální spyware (služba Windows Defender). Dalo by se uvést více příkladů. Za druhé, pro jejich spuštění není nutné, abyste se přihlásili k systému. Pokud byste na svém počítači s Vistou měli umístěn vlastní web – v beta verzích Visty byl pěkný, i když funkčně omezený web server; snad zůstane i ve finální verzi Visty – bude váš počítač reagovat na požadavky zobrazit vaše stránky přicházející zvenčí, aniž byste se museli přihlásit k systému a spustit na něm službu Internet Information Services (IIS). Z toho vyplývá, že na rozdíl od programů probíraných v kapitolách 2, 3 a 4 služby nedostávají kopii vašeho bezpečnostního tokenu a neběží tedy pod účtem uživatele. Ve většině případů jsou spuštěny pod jedním ze tří účtů, označovaných jako „účty služeb“: ■

LocalSystem Ve starších verzích Windows se tento účet jmenoval „System“. Na místním systému má téměř neomezené pravomoci a umí komunikovat s ostatními systémy na síti.

264

Kapitola 6 – Ochrana po zavedení systému

■

LocalService Účet s velmi omezenými privilegii, který není schopen komunikovat po síti.

■

NetworkService V podstatě jde o účet LocalService, doplněný o omezenou schopnost síťování.

Za třetí, i když se jedná v podstatě o běžné programy pro Windows, nejsou obvykle spouštěny stejným způsobem jako většina klasických programů, která jsou vyvolány názvem svého souboru EXE (když poklepete na ikonu Poznámkového bloku, říkáte tím Průzkumníkovi „Nahraj do paměti a spusť soubor notepad.exe“. Oproti tomu služby nebývají spuštěny přímo, ale běží uvnitř programu, označovaného jako „service host“ (hostitel služeb). Ve Windows je tímto programem svchost.exe. Kromě pojmu „service host“ se používá také pojem „wrapper“ (tím nemíním „white rappera“ se zlatými řetězy a silnou tendencí plivat do mikrofonu); úlohou tohoto programu je zjednodušit proces zabezpečení služeb. V praxi ale nejsou všechny služby umístěny uvnitř jedné kopie svchost.exe. Spuštěné instance svchost.exe lze najít ve Správci úloh, kde je třeba klepnout na záložku Procesy, zapnout volbu „Zobrazit procesy všech uživatelů“ a setřídit seznam procesů podle sloupce Název procesu. Když to uděláte, uvidíte asi to, co je na obrázku 7.1. Jak vidíte, na mém systému běželo celkem 13 instancí programu svchost.exe. Chcete-li vidět procesy uvnitř svchost, použijte Process Explorer (se kterým jsme se potkali ve čtvrté kapitole). Nezapomeňte ho spustit s právy správce (příkaz „Spustit jako správce“ v místní nabídce jeho ikony). Ve spuštěné aplikaci pak najděte svchost.exe a najeďte nad jeho název ukazatelem myši – objeví se rychlá nápověda (tooltip) s názvem služeb, běžících uvnitř daného procesu svchost. Druhou variantou je klepnutí pravým tlačítkem myši na názvu svchost, výběr položky Vlastnosti a poté zobrazení názvů služeb na stránce Services, kterou vidíte na obrázku 7.2. OBRÁZEK 7.1: Instance svchost na systému Vista

Stručné představení služeb

265

Princip práce procesu svchost tu probírám podrobněji schválně, abych zdůraznil důležitý bod: služby nedostávají žádný token – ten vlastní jednotlivé instance svchost.exe. Ani jedna z pěti služeb, které vidíte na obrázku 7.2, tedy nemá přidělen vlastní token s vlastním SID a privilegii; token s privilegii a jedním či více SID získá konkrétní instance souboru svchost.exe a služby běžící uvnitř hosta tento token jen sdílejí. Chcete-li vidět token, přepněte se na stránku Security, ve které uvidíte asi to, co je na obrázku 7.3. OBRÁZEK 7.2: Služby běžící v jednom procesu svchost

OBRÁZEK 7.3: Token procesu svchost v okně Process Exploreru

266

Kapitola 6 – Ochrana po zavedení systému

V tomto dialogu uvidíte, že daný svchost.exe běží pod účtem NetworkService namísto LocalSystem nebo LocalService. V horní polovině dialogu vypisuje Process Explorer seznam všech SIDů v tokenu a jak je zřejmé, je jich tu opravdu hodně, protože je nutné obsah seznamu posouvat, aby bylo možné prozkoumat všechny SIDy. Ve spodní části jsou vypsána oprávnění, která daná instance svchost vlastní. Ještě jednou zopakuji, že tyto identifikátory SID a oprávnění tokenu svchost jsou jedinými SIDy a privilegii, které těchto pět služeb získá, a neexistuje žádný způsob, jak některé ze služeb přidělit jiný SID nebo oprávnění bez toho, aby byly sdíleny s ostatními službami. Čtvrtým a posledním znakem služeb je to, že si s nimi všichni dělají starosti. Jen se zaposlouchejte do projevu libovolného specialisty na téma zabezpečení Windows (včetně mne) a vždy nakonec uslyšíte, že služby jsou vstupním bodem do systému pro různé hackery. Neříká se to kvůli tomu, že by služby byly nějak náchylnější na výskyt chyb ve srovnání s jinými druhy softwaru. Služby nás trápí proto, že běží nepřetržitě, že komunikují po síti a že mnohé z nich běží pod účtem LocalSystem. Dejme tomu, že by například Kalkulačka trpěla nějakou hroznou chybou, umožňující provést útok typu přetečení bufferu a následné ovládnutí počítače hackerem. Panika je v tomto případě v podstatě zbytečná, protože z praktického hlediska by tento útok vyžadoval, aby útočník seděl přímo u počítače (Kalkulačka totiž neumí komunikovat po síti) a Kalkulačka by musela běžet (chybu v programu lze zneužít jen v případě, kdy je program spuštěn). Pokud by ale touto závažnou chybou trpěla třeba služba BITS (Background Intelligent Transfer Service), nacházející se na každém počítači s Vistou, byl by to určitě důvod k obavám, protože BITS běží od počátku spuštění počítače a kvůli získávání aktualizací softwaru musí komunikovat po síti. BITS navíc běží pod účtem LocalSystem, což znamená, že pokud by útočník tuto službu ovládnul, mohl by v systému provést cokoli, co může provést účet LocalSystem (a to je v podstatě cokoli).

Správce služeb Po části věnované základní problematice služeb se nyní podíváme na program určený pro jejich správu, vhodně pojmenovaný jako Správce služeb (Service Control Manager, SCM) a jeho velmi užitečný nástroj pro konfiguraci služeb sc.exe. SCM je součástí Windows pro správu služeb již od dob Windows 95. O co se SCM stará především? ■

Spouští služby, ať již mají nastaveno automatické nebo ruční spuštění

■

Sleduje, které služby jsou aktuálně nainstalovány

■

Řídí komunikaci s právě spuštěnými službami, například požadavky na vypnutí

SCM vestavěný do systému Windows Vista zahrnuje několik velmi důležitých změn, které usnadňují změnu zabezpečení služeb. Modul snap-in konzoly MMC s názvem Služby (services.msc, určitě jste se s ním již setkali) je součástí SCM, stejně jako velmi užitečný nástroj příkazového řádku sc.exe, který existoval již pro předchozí verze Windows, ale byl dostupný jen v rámci Resource Kitu nebo Support Tools. Jeho přímé zařazení do Visty je vítaným krokem. SCM sám o sobě je program s názvem services.exe; Když se podíváte do Process Exploreru, uvidíte tam, že všechny instance svchost byly spuštěny právě programem services.exe. Nástroj sc.exe je nesmírně mocný příkaz, ale na několik věcí je v něm třeba dávat pozor. Základní syntaxe příkazu sc.exe vypadá takto:

Jak Vista „zpevňuje“ služby: přehled

267

sc [názevserveru] příkaz názevslužby [volby...]

Nástroj sc.exe lze použít pro řízení vzdálených systémů, jak napovídá argument názevserveru. Jako argument příkaz zadáváme jeden z několika desítek dostupných příkazů, přičemž

v této kapitole stihneme probrat jen několik málo příkazů. Argument názevslužby je v podstatě zkrácený název („key name“) služby, kterou chceme řídit. Například služba Klient zásad skupiny je v příkazu sc zadávána zkráceným názvem gpsvc. (Poznámka: „dlouhému“ názvu Klient zásad skupiny se správně říká zobrazovaný název, anglicky display name.) Anglický název „key name“ byl zvolen proto, že gpsvc je název klíče systémového registru, obsahujícího údaje o konfiguraci služby Klient zásad skupiny, umístěné ve větvi HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\gpsvc. Jen pro případ, že byste se neorientovali v registru, ještě uvádím, že tento zkrácený název se dá zjistit prostřednictvím nástroje sc.exe, pokud znáte alespoň zobrazovaný název. Stačí zavolat příkaz ve tvaru sc getkeyname "zobrazovaný název", jako například: C:\>sc getkeyname "group policy client" [SC] GetServiceKeyName SUCCESS Name = gpsvc

V této knize není prostor k probrání všech možných příkazů nástroje sc.exe, ale zkusme se podívat alespoň na ty základní a nejužitečnější. Příkazy stop, start, pause a continue zastaví, spustí, pozastaví a obnoví chod služby. Příkaz sc stop dnscache tedy zastaví službu Klient DNS. Opakem příkazu getkeyname je getdisplayname, který na základě známého zkráceného názvu vrátí zobrazovaný název služby. Příkaz config doplněný o některé přepínače umožňuje měnit nastavení služby z příkazového řádku a představuje tak zajímavou náhradu grafického modulu snapin Služby. Pokud byste například chtěli, aby služba Klient DNS (jejíž zkrácený název je dnscache) byla spouštěna ručně (je to jen ukázka, v praxi to nedělejte, není to dobrý nápad!), zapsali byste sc config dnscache start= demand

Všimněte si jedné z pastí syntaxe sc.exe: mezi "start=" a "demand" je nutné dát mezeru. Toto je nutné dodržet u všech voleb sc.exe.

Jak Vista „zpevňuje“ služby: přehled Víte již, proč bezpečnostní analytiky tolik trápí služby operačního systému: jsou to nepřetržitě spuštěné programy, často připojené k síti a často běžící pod účtem LocalSystem. Analytici z těchto důvodů obvykle doporučují provést určité úpravy výchozího nastavení: ■

Vypnout všechny služby, které nejsou skutečně potřebné. Vista sama toto provádí do značné míry, a postupem času – až si na Vistu zvykneme – se pravděpodobně objeví více a více rad na téma „co lze bezpečně vypnout“.

■

Namísto účtu LocalSystem používejte účet s nižším rozsahem privilegií. Jestliže pak dojde ke kompromitaci služby, bude mít útočník jen ta oprávnění, která vlastní daný účet a nebude tedy moci příliš škodit. Tento proces začal již ve Windows XP, kde byly zavedeny účty NetworkService a LocalService, jejichž oprávnění byla silně redukována. Na rozdíl od XP, kde

268

Kapitola 6 – Ochrana po zavedení systému

tyto účty byly používány jen u relativně malého procenta služeb a většina jich stále pracovala pod účtem LocalSystem, ve Vistě došlo k rozsáhlému přepsání mnoha služeb tak, aby implicitně pracovaly právě pod účty LocalService nebo NetworkService. ■

Zakažte vhodným nastavením oprávnění účtům LocalSystem, LocalService a NetworkService přístup k velmi cenným souborům, složkám apod. Když například v roce 2000 červ Code Red zasáhnul nezáplatované servery IIS po celém světě, musel jsem ostýchavě přiznat, že můj server IIS byl zasažen také, protože jsem na něj nenainstaloval potřebnou záplatu. Rozsah škod u mne však byl minimální, protože jsem již předtím zakázal účtu LocalSystem přistupovat k vlastnímu webovému obsahu. Když se Code Red pokusil smazat mou domovskou stránku, měl sice oprávnění účtu LocalSystem… ale byl odmítnut, protože neměl oprávnění NTFS ani ke čtení souboru. Najděte si proto čas a zakažte přístup účtům služeb k některým objektům (klíčům systémového registru, souborům, jiným službám, objektům AD apod.) – zabere to sice dost času, ale vyplatí se to.

Poslední dva body spolu tvoří základ toho, co je ve světě zabezpečení označováno pojmem „provozovat s co nejmenším možným oprávněním“. Jde asi o to, že v dokonalém světě by každá služba měla běžet pod účtem, který byl pro speciálně připraven, aby měla jen ta privilegia, která nezbytně potřebuje – a ani o jedno oprávnění víc. A ještě v lepším světě (ano, co může být lepší než dokonalé?) bychom pokročili ještě o jeden krok dál a explicitně zakázali těmto účtům s malým rozsahem oprávnění přístup ke všemu, co ke své práci nepotřebují. Je to sice nápad velmi dobrý, ale nepříliš praktický kvůli velké ztrátě času a jen zřídkavému přínosu. Vista však přináší některé změny, které cestu ke konečnému cíli spouštění služeb s co nejmenším možným oprávněním výrazně zkracují. Mezi tyto změny patří: Oddělení relací Vista z velké části nedovoluje službám přímou interakci s uživateli. Jak uvidíte později, Microsoft vytvořil něco, co připomíná úplně oddělenou relaci služby Terminal Services a do ní umístil všechny spuštěné služby. Pro tuto výhodu není nutné nic nastavovat, vše se děje automaticky. Zmenšení rozsahu oprávnění pro služby Ve Vistě může správce (nebo vývojář služby) sdělit Správci služeb, aby nadále spouštěl službu pod účtem LocalSystem, ale aby vyhodil z tokenu hostitele svchost všechny oprávnění účtu LocalSystem, která daná služba nepotřebuje. Díky tomu může SCM de facto převést nevídaně výkonný účet LocalSystem do „na míru šitého“ účtu služby s nejmenším možným oprávněním! Také tento postup vyžaduje rozsáhlejší přípravu ze strany správce nebo vývojáře, ale u mnoha služeb Visty se zdá, že tato práce již byla udělána za nás. (Omezení rozsahu oprávnění služeb je možné zobrazit příkazem sc qprivs a nová omezení se dají přidávat příkazem sc privs – obojí vám předvedu za chvíli.) Izolace služeb Jak jste právě četli, v dokonalém světě by každá služba mohla přistupovat jen k těm souborům, které pro svou práci potřebuje. U Visty je možné podobné izolace služeb dosáhnout několika malými úpravami jejich nastavení, které provedete vy nebo vývojář služby. (Prakticky si příslušný příkaz sc sidtype ukážeme opět o něco později.) Síťová omezení Vývojář může službu napsat tak, aby jí Brána Firewall Windows povolila komunikovat jen přes určitý port.

Jak Vista „zpevňuje“ služby: přehled

269

Oddělení relací Pojem relace (sessions) se ve světě Windows (přinejmenším Windows NT) používá nejméně od doby, kdy Microsoft zakoupil od firmy Citrix technologii MetaFrame a přidal ji do Windows NT 4.0 Terminal Server Edition. Relace je v podstatě sada aplikací a (obvykle) pracovní plocha připojená k uživateli. Mezi případy, kde jste se již s relacemi nejspíše setkali, patří: Relace Terminálových služeb Mnoho lidí se může připojit k jedinému Windows Serveru prostřednictvím relací Terminálových služeb. Tyto relace jsou navzájem pevně odděleny prostřednictvím relací, takže nemůže dojít k „průsaku“ dat z jedné relace do jiné. Různí uživatelé mohou mít různé pracovní plochy a aplikace, i když jsou spuštěny na stejném počítači, a jejich relace o sobě navzájem nemají tušení. Vzdálená plocha a Vzdálená pomoc Jedná se o implementace Terminálových služeb na systémech XP a Vista, které vytvářejí různé relace, jejich funkčnost je ovšem výrazně omezena ve srovnání s tím, co nabízí Terminálové služby na systému Windows Server. Rychlé přepínání uživatelů Systémy XP a Vista mohou sledovat několik současně přihlášených uživatelů prostřednictvím tzv. Rychlého přepínání uživatelů. Každý přihlášený uživatel má v této službě svou vlastní relaci. Relace jsou číslovány od nuly, před nástupem Visty byla relace 0 označována jako „konzolová“. Rychlé přepínání uživatelů ve Vistě má toto číslování změněno, první přihlášený uživatel dostane přidělenu relaci č. 1, druhý uživatel relaci č. 2 atd. (Pochopitelně tu předpokládáme, že se nikdo z uživatelů neodhlásí; Pokud se někdo přihlásí a odhlásí, a poté se přihlásí další uživatel, budou oba mít relaci č. 1, ale přitom samozřejmě nebudou sdílet stejnou pracovní plochu.) Ve Vistě Microsoft přesunul všechny služby do relace č. 0 a přidal pár nových pravidel týkajících se „života“ v relaci č. 0. Za prvé platí, že relace 0 nemá žádný typ uživatelského rozhraní. Nemůže komunikovat s žádným video hardwarem. Nemůže zasílat zprávy uživatelům v jiných relacích. Jediný povolený způsob komunikace s ostatními relacemi představuje protokol RPC (Remote Procedure Call), bezpečná metoda pro vzájemnou komunikaci aplikací. Zařazení všech služeb do relace č. 0, ke které uživatelé nemají přístup, má ještě jeden příznivý důsledek: běžný přístup ke zvýšení privilegií je vyloučen. Hackeři vytvořili během posledních let množství nástrojů, jejichž cílem je umožnit někomu s omezenými privilegii – standardního uživateli nebo dokonce hostovi (účet guest) – povýšit svoje oprávnění až na úroveň účtu tak, že převezme řízení nad některou špatně napsanou službou. Jedním z nejčastěji používaných postupů bylo například využití plánovače úloh (at.exe) ke spuštění příkazového řádku, který díky tomuto způsobu spuštění běžel pod účtem LocalSystem. To už se ve Vistě nedá použít. A jak to tak často v případě zvýšené bezpečnosti bývá, ránu dostává zpětná kompatibilita. Některé druhy ovladačů – především ovladače tiskáren – jsou nahrány službou (u tiskáren jde o službu Zařazování tisku) a proto žijí v relaci č. 0. To znamená, že když se ovladač tiskárny pokusí otevřít nějaký svůj dialog, nejspíše kvůli oznámení chyby nebo požadavku na zadání údajů během instalace, tento pokus skončí neúspěchem. Tyto problémy je možné vyřešit díky dočasné (platí jen pro Vistu, v příštích verzích Windows již nebude přítomna) službě „Zjišťování interaktivních

270

Kapitola 6 – Ochrana po zavedení systému

služeb“. Na svém systému můžete tuto službu spustit v příkazovém řádku s právy správce příkazem net start ui0detect (ve zkráceném názvu služby je nula, nikoli velké „O“). V případě potřeby můžete systému přikázat, aby službu Zjišťování interaktivních služeb spouštěl automaticky: sc config ui0detect start= auto

Opět připomínám, že mezi „start=“ a „auto“ musí být mezera – je to jedna z pastiček syntaxe sc.exe.

Zmenšení rozsahu oprávnění pro služby Jak jsem již napsal, dobře zabezpečená služba by běžela pod účtem služby, který by měl jen ta oprávnění, která potřebuje, a ani o jedno navíc. Z toho však vyplývá, že by Microsoft musel vytvořit pro každou službu samostatný účet. Nápad je to sice hezký, ale správa takových účtů by byla dost obtížná, proto lidé v Microsoftu využili něco zajímavého : POZNÁMKA:

Není podstatné to, jaká privilegia má účet, pod kterým služba běží. Záleží na tom, jaká oprávnění jsou definována v tokenu připojenému k hostitelskému programu svchost.exe za běhu služby

V předchozích verzích Windows by to byl jeden z těch „rozdílů, který žádným rozdílem není“; tam totiž účet služby, pod kterým běží svchost, dostane veškerá svá oprávnění. Ale jak jste viděli již ve druhé kapitole, Vista dostala do vínku zajímavé schopnosti filtrování tokenů, proto je Microsoft využil také u služeb.

Vývojáři mohou omezit oprávnění služeb Jste zvědavi, jak to funguje? Když vývojář píše službu pro Windows Vista, může do ní volitelně přidat určité instrukce pro Správce služeb (SCM), kterými vyjadřuje to, že služba potřebuje jen určitá, přesně vyjmenovaná oprávnění. Když poté SCM službu ve Vistě spouští, vytvoří pro ni token (to platí i ve starších verzích Windows). Ve Vistě však SCM neprovádí prosté kopírování tokenu účtu služby do instance svchost.exe, která je hostitelem dané služby; namísto toho dostane svchost.exe je ta oprávnění, která potřebuje. Pokud to není jasné, představte si, že máte službu s názvem SuperServis, která potřebuje – dejme tomu – jen oprávnění „vynechat postupnou kontrolu při průchodu adresáři“ (SeChangeNotifyPrivilege), ale je spuštěna uvnitř svchost.exe, který běží pod všemocným účtem služby LocalSystem. Když je služba spuštěna, sdělí Správci služeb toto: „nazdar, potřebuji jen oprávnění vynechat postupnou kontrolu při průchodu adresáři“, a SCM se proto podívá na SID účtu služby, pod kterým SuperServis běží (je to účet LocalSystem). Jak si jistě vzpomínáte, tento účet je vybaven celkem asi 4 731 privilegii. Správce služeb proto zareaguje větou „Svatá prostoto, tolik oprávnění tedy určitě nepotřebuješ“ a přidělí službě token odvozený z tokenu účtu LocalSystem… ze kterého jsou ale vyříznuta všechna privilegia s výjimkou požadovaného vynechání kontroly při průchodu adresáři.

Zmenšení rozsahu oprávnění pro služby

271

Správci mohou také omezit privilegia služeb Co si ale počít v případě, kdy vaši službu napsal nějaký lenoch a neobtěžoval se vymezit, jaká oprávnění stačí službě SuperServis k životu? V tomto případě to můžete Správci služeb sdělit sami, a to pomocí nástroje sc.exe, universální aplikaci pro řízení služeb. Příkaz bude mít v tomto případě tvar SC <server> privs názevslužby opravneni1/opravneni2...

Seznam potřebných oprávnění pro službu je v tomto příkazu zadáván v jednom řádku, navzájem jsou odděleny lomítkem. Názvy oprávnění jsou zadávány ve tvaru „SEněco“. Pokud by například naše ukázková služba SuperServis potřebovala oprávnění SeShutdownPrivilege a SeChangeNotifyPrivilege, sdělili bychom to systému Vista příkazem sc privs SuperServis seshutdownprivilege/sechangenotifyprivilege

(Příkaz je nutné zapsat jako jeden dlouhý řádek; na tištěné stránce této knihy může být zalomen, ale na konci tištěného řádku nemačkejte klávesu Enter.) Po předání tohoto příkazu Správci služeb nejsou uvedené informace smazány, ale jsou uloženy v položce systémového registru typu REG_MULTI_SZ s názvem RequiredPrivileges, nacházející se v klíči pro službu SuperServis, a přežijí tedy restart systému. Jak zjistit, zda už služba nemá přiděleny tyto údaje, vymezující potřebná privilegia? Jednoduše – zeptáte se Správce služeb: sc qprivs názevslužby

Jestliže tento příkaz spustím například pro službu Zjišťování interaktivních služeb, bude výpis vypadat takto: C:\>sc qprivs ui0detect [SC] QueryServiceConfig2 SUCCESS SERVICE_NAME: ui0detect PRIVILEGES : SeTcbPrivilege : SeAssignPrimaryTokenPrivilege : SeIncreaseQuotaPrivilege : SeDebugPrivilege

A dovolím si tvrdit, že z tohoto výpisu poznám, proč Microsoft nechal službu ui0detect implicitně vypnutou. Jen se koukněte na ta oprávnění, která potřebuje: „jednat jako část operačního systému“ a „ladit jiné procesy“ – to jsou přece dvě oprávnění z Notoricky Známé Devítky. TIP:

Jak je již ve Windows pravidlem, všechny operace, které mění obsah tokenu, se projeví až poté, co se daný účet – v tomto případě účet služby – odhlásí a poté opět přihlásí, proto chcete-li vidět účinek provedené změny, restartujte svchost.

Rád bych zdůraznil, že vestavěné informace o potřebných oprávněních jsou zapsány jen v některých službách. Zkuste například příkazem sc vypsat oprávnění služby lanmanserver čili služby souborového a tiskového serveru: tam nic nezjistíte. Neznamená to, že by služba Server neměla přidělena žádná oprávnění, ale jen to, že Microsoft v tomto případě nepověřil svou novou technologii, aby držela tuto službu na uzdě.

272

Kapitola 6 – Ochrana po zavedení systému

POZNÁMKA:

Podle mne je to ostuda. Na jedné straně plno článků a oslavných řečí o vylepšeném zabezpečení Visty, ale stačí stručně prozkoumat několik vestavěných služeb Visty a ukáže se, že u nich žádná změna konfigurace omezující počet parametr neproběhla. Ale správci systémů snad dokážou po určité době sami odhadnout, jaká oprávnění můžeme těmto službám odebrat.

V případě, že služba nemá v registru zapsánu položku RequiredPrivileges, chová se SCM ke službě tak, jak se chová již od dob NT 3.1: přidělí jí token s úplnými privilegii účtu, pod kterým běží.

Speciální případ: více služeb vyžaduje různá oprávnění Čili bez položky registru RequiredPrivileges není token hostitele svchost.exe nijak omezen; pokud má služba v registru tuto položku zapsánu, dostane svchost.exe jen omezený token… je to tak? V podstatě ano, ovšem vynechal jsem ještě jeden detail. Co se stane, pokud uvnitř svchost. exe běží více jak jedna služba, a všechny tyto služby mají v systémovém registru zapsánu položku RequiredPrivileges?

Dejme tomu, že máme svchost.exe, běžící pod účtem LocalSystem. V tomto svchost.exe běží Služba1, vyžadující oprávnění SeDebugPrivilege, a Služba2, která vyžaduje oprávnění SeShutdownPrivilege. Přestože se v jednom procesu svchost.exe nachází více běžících služeb, existuje pouze jediný token pro tyto služby, protože jediným procesem s přiděleným tokenem je proces svchost.exe – Služba1 a Služba2 proto nemohou mít rozdílné tokeny, žijí-li ve stejném svchost. exe. Co je tedy zapsáno v tomto tokenu? Sjednocení hodnot klíčů RequiredPrivileges. SCM tedy pro svchost.exe sestaví token obsahující privilegia SeDebugPrivilege i SeShutdownPrivilege, a to znamená, že Služba1 má k dispozici obě oprávnění, stejně jako Služba2. Ponaučení z celého příkladu spočívá v tom, že když nastavíte službě nové oprávnění, je jí implicitně přidělen vlastní svchost.exe. Nemáte-li opravdu dobrý důvod toto chování měnit, neměňte ho, protože jinak skončíte zavaleni ručním laděním minimálních potřebných oprávnění pro hromadu různých služeb, a ty stejně nakonec budou mít přiděleny tolik oprávnění, že se tato práce prostě nevyplatí.

Souhrn výkladu o omezených privilegiích Vista mění problematiku přidělování oprávnění službám v tom, že služby nyní mohou přesně vyjmenovat potřebná oprávnění samy a správci mohou tyto seznamy potřebných parametrů měnit příkazem sc privs. Z toho plyne, že: ■

V případě, kdy svchost.exe hostuje jen jednu službu a ta nemá zapsány žádné údaje o vyžadovaných privilegiích, získá svchost.exe (a tedy i služba) token s plnými privilegii daného účtu služby.

■

V případě, kdy svchost.exe hostuje jen jednu službu a ta má deklarována potřebná oprávnění, přidělí SCM procesu svchost.exe token obsahující jen ta oprávnění, která služba

Izolace služeb

273

uvádí jako nutná. (Jestliže však služba požaduje oprávnění, které nemá účet služby procesu svchost.exe přiděleno, nemůže SCM do tokenu toto oprávnění zapsat.) ■

V případě, kdy svchost.exe hostuje více jak jednu službu, které mají deklarovány potřebná oprávnění, vypočítá SCM sjednocení všech potřebných oprávnění pro všechny služby a zapíše je do tokenu, který přidělí procesu svchost.exe.

■

V případě, kdy svchost.exe hostuje více služeb, přičemž některé z nich deklarují potřebná oprávnění a jiné ne, SCM prostě zkopíruje token účtu služby a přidělí ho procesu svchost.exe.

VAROVÁNÍ:

A pokud to někomu nedošlo přímo z výkladu, dodávám ještě: budete-li ve službě deklarovat potřebná oprávnění, do kterých nezahrnete všechna privilegia, která služba skutečně potřebuje, musí služba zákonitě selhat. Například účet NetworkService nabízí pouze pár jednoduchých oprávnění, mezi které nepatří SeDebugPrivilege. Jestliže spustíte službu v hostiteli svchost.exe pod účtem NetworkService a určíte, že tato služba potřebuje oprávnění SeDebugPrivilege, vyvolá tato služba chybu při každém pokusu o použití daného oprávnění.

Izolace služeb Kromě separace relací a omezení sady přidělených oprávnění jde Vista v oblasti omezování služeb ještě o krůček dále a umožňuje správcům služby „izolovat“. Izolace služeb vychází z představy úplného zákazu pro služby měnit cokoli v systému s výjimkou malého počtu přesně definovaných objektů. Pokud v tomto případě dojde k ovládnutí služby útočníkem, může tato (nyní „zlá“) služba napáchat v systému jen velmi omezené škody, protože jste jí zúžili okruh působnosti. Když se například nějaká služba stane kořistí útočníka, který využije její chybu a pošle jí vstupní data vyvolávající přetečení bufferu, může tento útočník dostat do systému červa, který se pokusí chybu zneužít například pro instalaci rootkitu. Jenže instalace rootkitu vyžaduje kopírování souborů a zápis do systémového registru … a pokud je služba izolována, je jí z podstaty celé věci zakázáno měnit většinu částí systému. Služba tedy téměř určitě nebude schopná zapisovat nic do těch částí systémového registru a souborového systému, které rootkit potřebuje… červ tedy žádnou podstatnou škodu nenapáchá.

Podstata činnosti izolace služeb Microsoft musel provést několik strukturálních změn v systému, aby byla izolace služeb možná. Stručně řečeno, Vista se liší tím, že v ní nově: ■

Každá služba dostane svůj SID, označovaný – nijak překvapivě – jako „service SID“ (SID služby), který slouží jako identifikátor služby v oprávnění k souborům, registru nebo v jiném typu oprávnění.

■

Každá služba může být nepovinně omezena tak, by mohla do objektu zapisovat jen v případě, kdy tento objekt obsahuje položku řízení přístupu, výslovně udělující danému SID služby

274

Kapitola 6 – Ochrana po zavedení systému

právo zápisu do objektu; SID účtu služby nemá pro izolovanou službu význam, ten jí právo zápisu neuděluje. ■

Toto omezení může do služby buď natrvalo vložit její vývojář, nebo ho může správce systému vytvořit dodatečně v nástroji sc.exe (ukázka bude následovat).

Klíčem k pochopení izolace služeb je to, že služby obvykle potřebují někam zapisovat nějaké údaje – ať již do souboru, složky, databáze, klíče registru, objektu Active Directory nebo něčeho jiného… to je jejich účel, jinak by byly k ničemu. Jak jste se dočetli ve čtvrté kapitole, všechny v minulé větě vyjmenované typy objektů jsou „chranitelné“, proto služba potřebuje položku řízení přístupu (ACE) s právem zápisu do tohoto chranitelného objektu, jejíž SID odpovídá SIDu tokenu služby. Před příchodem Visty získávaly služby svůj SID od svých účtů služby a malého počtu skupin, do kterých tyto účty patřily. Toto byly jediné SIDy, které mohly služby použít k vlastní identifikaci vůči objektu, když doufaly, že tento objekt obsahuje ACE s právem zápisu pro odpovídající SID. Ve Vistě mohou služby získat nejen SID účtu služby, ale nepovinně i svůj vlastní SID. Pomocí tohoto velmi úzce zaměřeného SIDu služby vám SCM dovoluje velmi přesně vymezit, co si daná služba může a co nemůže dovolit. Microsoft například přepracoval službu Systém událostí COM+ (řídící protokoly událostí) tak, že tato služba nyní může zapisovat jen do těch souborů, které tvoří vlastní obsah protokolů, neboli do souborů ve složce \windows\system32\winevt, které mají příponu .EVT. Toto si Microsoft mohl dovolit právě díky novince Visty s názvem „izolace služeb“. Pojďme se podívat na to, jak se to v praxi provede….

Jak omezit SID služby Chcete-li pochopit izolaci služby, je nejdříve nutné chápat, co je omezený SID. V systému Vista může vývojář nebo správce přikázat Správci služeb (SCM), aby změnil způsob vytváření tokenu pro svchost.exe. Správně poučený SCM poté sestaví tento token tak, aby obdržel SID účtu služby (jako vždy), ale přidal k němu poznámku „tento SID neplatí po všechny operace zápisu“. Služba běžící uvnitř svchost.exe s tímto SID tedy může číst vše, co může číst použitý účet služby, ale jakmile se jedná o zápis čehokoli, nepovolí Vista službě použít SID jejího účtu služby. Tomuto se říká „přidělit službě omezený token“. SID služby se dá omezit následujícím příkazem: sc sidtype názevslužby restricted

Dejme tomu, že chceme jako ukázku omezit naši známou službu SuperServis, se kterou jsme se již setkali v předchozích částech kapitoly, a chceme jí povolit zápis jen do jediného souboru c:\pokusy\superlog.txt. (Budeme předpokládat, že služba SuperServis běží uvnitř instance svchost.exe pod účtem LocalSystem.) První krok při izolaci služby SuperServis zahrnuje omezení jejího SID, které v následujícím řádku provedeme v okně příkazového řádku s právy správce: C:\>sc sidtype SuperServis restricted [SC] ChangeServiceConfig2 úspěch

Izolace služeb

275

(Není nadšení nástroje sc.exe z toho, že se mu povede něco úspěšně provést, silně nakažlivé?) TIP:

Opět tu měníme obsah tokenu, je tedy nutné zastavit a znovu spustit svchost.exe, aby se provedená změna uplatnila. A ano, mám na mysli skutečně svchost.exe – pokud tento svchost.exe sdílejí ještě další služby, je nutné je všechny vypnout, zabít svchost.exe ve Správci úloh, a poté všechny služby restartovat (nebo prostě restartovat celý systém).

Jak udělit oprávnění zápisu pro SID služby Naše služba SuperServis je nyní službou omezenou a nemůže použít SID účtu LocalSystem pro zápis libovolných údajů… proto je momentálně jaksi… nepoužitelná. Pokud bych se v jejím kódu nyní pokusil o zápis do souboru c:\pokusy\superlog.txt, zeptal by se souborový systém NTFS služby před povolením zápisu na její pověřovací údaje (credentials). SuperServis by je předala ke kontrole a NTFS by na to reagovalo přibližně takto: „jo, vidím SID účtu LocalSystem, to je fajn… ale koukám, že se nedá použít pro zápis. Tak to sorry, bejby." Služba potřebuje pomoci, jinak do souboru c:\pokusy\superlog.txt nikdy nic nezapíše. Abychom to dokázali, připomínám, že SCM ve Vistě vytváří SID služby po každou službu zvlášť. To se dá snadno dokázat na obrázku 7.3, kde vidíte, že každý konkrétní běžící svchost.exe je členem několika skupin, o kterých jste nikdy předtím neslyšeli: KtmRm, NlaSvc, TermService a dalších. Názvy by vám měly připadat známé: jsou to názvy služeb, běžících uvnitř daného svchost.exe. Tyto SIDy však nejsou „úplné“ SIDy, protož se nejedná o samostatné účty; jsou to jen jmenovky, něco jako mandatory label úrovně integrity, jejichž SIDy mají tvar Mandatory Label\Medium Level Label – stejně jako neexistuje doména s názvem „Mandatory Label“, tak neexistuje žádný uživatelský účet ani skupina s názvem NlaSvc. Ale těmto SIDům mohou být – věřte nevěřte – přiřazován oprávnění NTFS, oprávnění k systémovému registru a dalším věcem. Nyní mohu klepnout pravým tlačítkem myši na soubor c:\pokusy\superlog.txt a otevřít dialogové okno jeho vlastností, kde na stránce „Oprávnění pro…“ klepnu na tlačítko „Přidat“, abych vytvořil nové oprávnění. V dialogu mě systém žádá, abych zvolil účet, skupinu nebo něco jiného, ale já chci v tomto případě udělit oprávnění službě SuperServis, zkráceně supserv. Na obrázku 7.4 vidíte, jak to udělám. V tomto dialogu vidíte, že chci přidělit oprávnění k souboru (jeho název se v tomto dialogu nikde neobjevuje) účtu, jehož název domény je „NT Service“ a vlastní název služby „supserv“. Po klepnutí na tlačítko OK bude Vista chvíli hledat, ale nakonec zjistí, že skutečně má někde zapsán SID pro něco, co se jmenuje NT Service\supserv, a dovolí mi vytvořit oprávnění, které službě SuperServis povolí zápis do souboru.

276

Kapitola 6 – Ochrana po zavedení systému

OBRÁZEK 7.4: Jak zadat název služby pro přidělení oprávnění

POZNÁMKA:

Nezapomínejte, prosím, že toto je jen vymyšlený příklad. Na vašem systému není žádná služba SuperServis dostupná, proto nebudete schopni zopakovat přesně to, co uvádím v této knize – j to jen ukázka postupu, jak udělit službě oprávnění něco změnit.

Vytvořením SID pro jednotlivou službu tedy Vista umožňuje vytvořit oprávnění v rámci jednotky NTFS, registru a jiných objektů, a uvést v něm název konkrétní služby, která potom může do daného objektu zapisovat i v případě, kdy oprávnění zápisu nemá žádný jiný proces. Nyní může služba SuperServis změnit obsah souboru c:\pokusy\superlog.txt, ale nic jiného.

Příkazy nástroje sc.exe pro práci s omezenými SID Po výkladu principů izolace služeb a jejího zprovoznění se ještě podíváme na to, jakým způsobem se dají SID služeb ovládat prostřednictvím nástroje sc.exe. Jak jste již viděli, SIDy služeb se dají řídit novým příkazem nástroje sc.exe s názvem „sidtype“. Jeho úplná syntaxe vypadá takto: sc [názevserveru] sidtype názevslužby none|unrestricted|restricted

Co dělá volba restricted, jsme již viděli, nebo alespoň část z toho, co dělá. Ve skutečnosti má volba restricted dva důsledky. Za prvé, svchost.exe bude používat SID účtu služby pro všechny operace s výjimkou zápisu (to již víte). Druhým důsledkem volby restricted je to, že SCM vloží SID služby SuperServis do tokenu svchost.exe. Pokud je mi známo, nelze operačnímu systému Vista přikázat, aby nevytvářel SID pro službu SuperServis, lze mu však říci, zda má nebo nemá zahrnout tento SID do tokenu svchhost.exe. Jestliže SCM nemá vkládat SID služby do tokenu svchost.exe, použijete volbu none: sc sidtype SuperServis none

Tento příkaz zároveň zruší omezení tokenu služby SuperServis. Alternativně je možné namísto none uvést unrestricted. V tomto případě bude v tokenu svchost.exe zahrnut SID služby, ale ten nebude nijak omezen a svchost.tedy bude moci plně využít svůj vlastní SID účtu LocalSystem, NetworkService nebo LocalService. Aktuální stav SIDu služby (tedy zda je jeho aktuální hodnotou none, restricted nebo unrestricted) se zjistí příkazem sc qsidtype názevslužby

277 Chcete-li zobrazit skutečný SID služby, spusťte příkaz sc showsid názevslužby

Nezapomeňte spouštět tyto příkazy v okně příkazového řádku s právy správce. Zopakujme si, co jsme tu probírali: ■

Služba vždy používá SID svého hostitele.

■

Služba může také získat svůj vlastní SID.

■

Správce (nebo vývojář služby) může službě odebrat schopnost používat SID svého hostitele pro všechny operace zápisu – k tomuto účelu slouží nastavení „restricted“.

■

Jestliže službu omezíte, je absolutně nezbytné přidělit SIDu dané služby oprávnění zapisovat do všech objektů, kam služba musí kvůli své činnosti zapisovat.

■

Restartujte celého hostitele svchost.exe, aby se mohly uplatnit provedené změny.

A co případ, kdy v daném hostiteli běží více jak jedna služba? Pokud mají všechny nastaven sidtype na hodnotu none nebo unrestricted, nebude to mít na jejich činnost žádný vliv. Pokud jsou ale některé služby omezené a jiné ne, nebudou ty omezené spuštěny. Omezené služby je možné používat jen v případě, kdy jedna a právě jedna služba v daném hostiteli bude omezena, zatímco všechny ostatní služby omezené nebudou.

Omezení síťových portů pro službu Poslední omezení, které se ve Vistě dá uplatnit na nějakou službu, je omezení rozsahu jejích povolených síťových portů, o které se postará Brána Firewall. Tato ochrana zajistí, aby na kompromitovaném systému nemohlo být spuštěno skenování portů. Zní to sice velmi slibně, ale v době, kdy píšu tyto stránky (říjen 2006), je tento prostředek zmíněn jen jako velmi stručná poznámka v dokumentu Microsoftu s názvem „Vista Services“. Dokument najdete na webu Microsoftu, zmínka o omezení povolených portů je na stránkách 9 a 10.

Souhrn V dřívějších dobách připomínalo zabezpečení systému proti následkům zneužití služeb spíše magii, nyní je to jen lehčí kouzlo. Jsme-li vyzbrojeni nástrojem sc.exe a známe-li názvy služeb, můžeme omezit oprávnění služeb a izolovat služby prostřednictvím jejich omezených SIDů. Pokud se omezených parametr týká, dá se velmi rychle zjistit, že Microsoft sám příliš mnoho služeb neizoloval. To znamená, že se můžete pustit do vlastních experimentů a zpřísnit zabezpečení služeb sami … ale zkoušejte to vždy na testovacím systému! Jsme na konci knihy; děkuji vám za to, že jste se mnou a mými spoluautory vydrželi tak dlouho. Upřímně doufám, že se nyní dokážete orientovat v některých „velkých novinkách“ zabezpečení Visty… aby vás nepřekvapily v nesprávný čas. Díky za přečtení, a pokud můžete, napište mi pár řádků se svými názory na tuto útlou knížečku!

Mark Minasi, Byron Hynes

WINDOWS VISTA BEZPEČNOST Podrobně o bezpečnosti Windows Vista pro systémové administrátory Podrobně o bezpečnosti Windows Vista pro systémové administrátory Tato kniha přináší vše, co potřebuje systémový operátor vědět o bezpečnosti a technologii systému Windows Vista. Autorem knihy je Mark Minasi, známý odborník na Windows. V knize se věnuje především největším změnám týkajícím se bezpečnosti a tomu, jakým způsobem tyto novinky ovlivní práci těch, kteří zodpovídají za integraci a poskytují technickou podporu pro systémy Windows, zejména Windows Vista. V knize najdete instrukce, tipy, pracovní postupy a mnoho praktických rad.

ZONER software, s.r.o. významný producent software v oblasti digitální fotogra¿e, poþítaþové gra¿ky a multimédií, poskytovatel internetových služeb, souvisejících s prezentací na internetu a e-komercí, a nakladatelství odborné literatury.

Z obsahu a témat je možné uvést: – vysvětlení a použití řady novinek Windows Vista jako přihlašování a spouštění úloh jako administrátor – virtualizace – jak funguje a ve kterých případech ne – práce se soubory v System32 jako administrátor – seznámení se s novými vlastnostmi post-boot bezpečnosti jako Patch Guard – ochrana laptopů s inovativním BitLocker – problematika ochrany proti virům a jinému nebezpečí – jak funguje mechanizmus integrity Windows – upravený Event Viewer, poskytování událostí a nové nástroje pro řešení problémů Mark Minasi, MCSE, je jedním z nejlepších světových odborníků na Windows. Vede školení v 15 zemích světa, je nejvyhledávanějším přednášejícím na konferencích a hlavním řečníkem, který představuje zásadní témata. Jeho společnost, MR&D, proškolila desítky tisíc zájemců o navrhování a práci v prostředí sítí na bázi Windows. Mark napsal pro vydavatelství Sybex více než 15 publikací, včetně bestsellerů Mastering Windows Server 2003 a The Comlete PC Upgrade and Maintenance Guide. Byron Hynes pracuje ve skupině Windows Server User Assistance v Microsoftu. Dříve se zabýval internetovými komunikacemi (spravoval regionální páteřní síť internetu), systémy pro řešení problémů client-server, webovými aplikacemi, navrhoval síťové infrastruktury a bezpečnostní modely. Je spoluautorem knihy Hands-On Microsoft Windows Server 2003 Active Directory.

Z O N E R

www.zoner.cz

P R E S S

Pod tímto logem vycházejí publikace určené pro každého vážného zájemce o práci s počítačem. Od ryze praktických příruček a průvodců až po komplexní publikace o všem, co potřebuje grafik, webdesignér, vývojář či programátor při každodenní práci. Na slevy, které můžete získat, a vydavatelský plán, v němž vedle knih domácích odborníků najdete celou řadu titulů světově uznávaných autorů, se informujte na adrese vydavatelství.

E N C Y K L O P E D I E

DOPORUČENÁ CENA: 259 Kč KATALOGOVÉ ČÍSLO: ZR946

Zoner Press tel.: 532 190 883 e-mail: knihy@zoner.cz www.zonerpress.cz ZONER software, a.s., Nové sady 18, 602 00 Brno

ISBN 978-80-7413-024-3

9 7 8 8 0 7 4 1 3 0 2 4 3