Windows Portal

A User Account Control működése

• 2007-05-15 12:40

Bár a Windows Vista teljes kódjának mindössze egy elhanyagolható töredékét teszi ki - mondhatni egy apró kiegészítésről van szó - a felhasználói fiókok felügyelete egyértelműen a legnagyobb sajtóvisszhangot váltotta ki az új operációs rendszer megjelenésekor, sőt még azelőtt is. Van, aki gyűlöli, van aki elfogadja, de vajon tudjuk-e pontosan hogyan működik, milyen szempontok alapján dönti el, mikor kell közbelépnie?


Miért van rá szükség?

Ahhoz, hogy megértsük a User Account Control (továbbiakban UAC) tervezésének és bevezetésének fő szempontjait, tekintsünk kicsit vissza a múltba, ahogy tették ezt a fejlesztők is. Az emberek többsége azt gondolná, a nagyvállalatoknál annak rendje és módja szerint a dolgozók többsége korlátozott felhasználói fiókon keresztül tevékenykedik, mely karbantartott csoportházirenddel megfelelő jogosultsági szinteket ad nekik. A Microsoft felmérései szerint a valóság meglepő módon épp az ellenkezője, a vállalatok mintegy 90%-ánál (!) az alkalmazottak adminisztrátori jogkörben dolgoznak nap mint nap, ezzel potenciális veszélyforrást jelentve a cég teljes infrastruktúrájára. Érdekességként megjegyzendő, volt olyan hely, ahol szándékosan kaptak rendszergazda jogosultságot a felhasználók, mert például az utazó ügynökök hordozható gépeiken másképp nem tudták volna megváltoztatni az időzóna-beállításokat.

Az otthoni felhasználók esetében, noha hasonló arányokról beszélhetünk, a rendszergazdaként való számítógéphasználatnak történelmi gyökerei vannak. Az öt-tíz évvel ezelőtti Windows rendszereken egyetlen felhasználói fiók volt, és mivel azokban az időkben nem is nagyon volt szükség jogosultság-korlátozásokra, ez az egyetlen felhasználó természetesen rendszergazda is volt, mindent elért az adott számítógépen. Az NT-vonallal történő egyesülés után sem változott sokat a helyzet, a Windows XP a telepítéskor mindig automatikusan létrehozott egy rendszergazda felhasználót, melyet aztán a későbbiekben nem is változtatott meg a felhasználó - minek is, kényelmes volt, szintén mindent el tudott végezni fennakadások nélkül. A probléma gyökere pedig pontosan itt található - mivel a felhasználó rendszergazda, minden általa indított folyamat, minden az internetről általa letöltött állomány, minden általa megnyitott e-mail melléklet örökölte jogosultságait, így szintén bármit megtehetett a rendszerben. A végeredményt mindannyian ismerjük: tömegesen zombivá váló gépek, lassú, instabil operációs rendszerek, ideges és elégedetlen felhasználók, rémálomba illő újratelepítés.

A Microsoftnál ezért úgy döntöttek, véget kell vetni az efféle megpróbáltatásoknak, nem szabad hagyni, hogy a felhasználók ilyen kiszolgáltatottá váljanak, a munkát gördülékenyebbé és megbízhatóvá kell tenni számukra. Mindez egyben azt is jelenti, hogy "a felhasználókat meg kell védeni saját maguktól".


A megoldás

A probléma megoldása adta magát: korlátozni kell a felhasználók jogosultsági körét. Az elsőre egyszerűnek tűnő feladat azonban számos problémát vetett fel már az elméleti fázisban is. Először is a Windows alkalmazások jó részét úgy tervezték, hogy a programozó feltételezi, hogy a felhasználó rendszergazdaként dolgozik, így hozzáférhet a rendszer bármely részéhez. Sokszor bizony még a Microsoft programjai esetén sem mindig volt elsőszámú szempont a standard felhasználóként való felhasználhatóság, a kényelem gyakran a biztonság rovására ment. 2004 augusztusában aztán minden megváltozott, a Windows XP Service Pack 2 megjelenésével egyidőben a redmondi cég áttért az úgynevezett "Secure by Design" azaz biztonságosnak tervezve alapelvre, mely minden szoftver írásakor elsőszámú szempontként állította fel a biztonságos integrálódást a rendszerbe. A felhasználók ekkor találkozhattak először az olyan új biztonsági szolgáltatásokkal, mint az Internet Explorer felugró ablakainak szűrője, az ActiveX vezérlők és fájlok automatikus letöltődésére figyelmeztető biztonsági sáv, valamint a tűzfal, az antivírus és a kémprogram-elhárító alkalmazások naprakész állapotát felügyelő Biztonsági központ.

A Windows XP-be már nem került beépítésre (talán a Service Pack 3 majd hoz valami hasonló megoldást), a Windows Vista azonban a Beta 2 óta alapértelmezésként bekapcsolva tartalmazza a cikkünk tárgyát képező új biztonsági szolgáltatást. Az eleinte mindenkit őrületbe kergető új eszköz az idők során rengeteget változott. A bétatesztelők visszajelzéseinek megfelelően egyre kevesebbszer bukkant fel és kezelése is sokat javult a Beta 2-ben debütáló kezdetleges verzió óta. A Vista végleges kiadásában a felhasználói visszajelzés már csak opcionálisan bekapcsolható lett, ha a hibajelentéseknél engedélyezzük az adatgyűjtést, a Windows minden nem várt UAC prompt felbukkanása esetén elküldi az információt a Microsoft fejlesztőinek, hogy megvizsgálhassák a konkrét esetet és tovább csiszolhassanak a szoftveren.

Fontos megérteni, hogy az UAC nem a felhasználók korlátozására jött létre. Sokszor, sok helyen hallani, az ismerős "rendszergazda vagyok, mégsem tudok néhány műveletet elvégezni" mondatot. Ez bizonyos szinten igaz is, meg nem is. Igaz abból a szempontból, hogy a kritikus rendszerfájlokat immár az adminisztrátor sem tudja módosítani, ez azonban nem kifejezetten az UAC hatása, inkább az integritási szintek hatása. Hamis viszont az a nézet, miszerint a rendszer úgymond "hülyének nézi" a felhasználót és mindenre kétszer kérdez vissza. Az UAC adja igazán a felhasználó kezébe az irányítást, hiszen így soha nem történhet semmi kritikus művelet a gépet kezelő háta mögött és annak tudta nélkül. Bekapcsolt UAC-vel továbbra is bármilyen műveletet el tudunk végezni, mindössze egy a rendszer által küldött megerősítést kell jóváhagynunk. Tény és való, hogy a frissen telepített rendszer első időkben történő konfigurálása közben számos alkalommal belebotlunk az engedélykérő ablakba, de amint rendeződtek a körülmények és rendes napi használatra fogjuk a gépet (hacsak nem végzünk állandó jelleggel adminisztratív feladatokat), szinte alig fogunk találkozni vele.

Lássuk pontosan, mikor is bukkanhat fel az UAC prompt:

• Alkalmazások telepítése és eltávolítása
• Eszközmeghajtó programok telepítése és eltávolítása
• ActiveX vezérlők telepítése
• Windows frissítések telepítése
• A Windows Update beállításainak módosítása
• A Windows tűzfal beállításainak módosítása
• A Felhasználói fiókok felügyelete (UAC) beállításainak módosítása
• Felhasználói fiókok létrehozása és törlése
• Felhasználói fiókok típusának megváltoztatása
• A Szülői felügyelet konfigurálása
• A Feladatütemező megnyitása
• Rendszerfájlok biztonsági mentésből történő visszaállítása
• Más felhasználó mappájának megnyitása vagy megváltoztatása

Láthatjuk, hogy csupa olyan műveletről van szó, amit a rendszeres napi felhasználás során igen ritkán érintünk. Miért kapunk néha mégis figyelmeztetést? A Windows Vista két csoportra osztja az alkalmazásokat. Vannak a hagyományos, úgynevezett "Legacy" alkalmazások, melyek még a régi időkből maradtak ránk, ezek készítője általában nem fordított elegendő figyelmet arra, hogy többfelhasználós, korlátozott jogosultságú környezetben is alkalmassá tegye programját a futásra. A másik kategóriába tartoznak a "Vista-aware" programok, melyek képesek érzékelni, hogy az új operációs rendszeren futnak, így ismerik az UAC-t, annak működését, "tudják mit szabad és mit nem".

Miért fontos, hogy az alkalmazás tudjon róla, hogy Vistán fut? Tulajdonképpen nem fontos, de illendő, mert ezáltal nem próbálja "teleszemetelni" a rendszert. Az UAC-nek az eleváló prompton kívül egy másik rendkívül fontos feladata is van, ez pedig nem más, mint a fájlrendszer és a registry virtualizálása. Ez a virtualizáció nem tévesztendő össze a hagyományos értelemben vett hardverkörnyezet-izolációval, mégis ahhoz hasonló eredményt érünk el vele. Az UAC vigyáz a rendszer stabilitására, így minden olyan folyamatot, mely a Windows rendszerkönyvtáraiba, illetve a registry számítógépszintű kulcsaiba próbál írni egyszerűen átirányítja egy virtuális "homokozóba", így az érintett helyek is tiszták maradnak és az alkalmazás is gond nélkül tovább fut, abban a boldog tudatban, hogy sikerült - például a beállításokat tároló - INI fájlját elhelyeznie a Windows mappában. Ugyanez a virtualizáció vonatkozik az Internet Explorer-re is, tehát minden olyan fájlletöltés, illetve szkriptfuttatás, mely a böngészőn belülről indult az Explorer saját homokozójában történik, nincs kihatással a rendszer épségére. Szintén az UAC feladata az egyfelhasználós környezetet feltételező telepítőprogramok által a Start menübe helyezett parancsikonok közzététele az összes felhasználó számára.

A Microsoft az UAC fejlesztésekor többezer alkalmazást tesztelt le, hogy azok mennyire képesek korrekt módon beépülni a rendszerbe anélkül, hogy megpróbáljanak belepiszkálni a Windows saját állományaiba. A tesztelt alkalmazásoknak körülbelül a fele azonnal megbukott és itt csak arról a viszonylag korlátozott körről beszélünk, melyeket a fejlesztők górcső alá vettek. Ezt figyelembe véve beláthatjuk, milyen nagy szükség is van az UAC-re.


A kivitelezés

Most, hogy egy kicsit már belelátunk az UAC feladatkörébe és működésének irányelveibe, tekintsük át, hogyan is működik a gyakorlatban egy alkalmazás magasabb jogkört megkövetelő tulajdonságának detektálása és maga a szintemelés. Példánkban egy telepítőprogram indítását fogjuk modellezni, először Windows XP rendszeren.



Mint látjuk, a művelet rendkívül egyszerű. A felhasználói keretalkalmazásként (Shell) működő Explorer.exe az adott fájlra mutatva meghívja a "ShellExecuteEx" függvényt, mely továbbítja a kérést a "CreateProcess" függvényhez, ami aztán létrehozza az alkalmazás kezdő szálát, lefoglalja számára a szükséges memóriacímeket és egyéb erőforrásokat, majd útjára indítja a folyamatot. Mivel a "CreateProcess" funkció mindig az őt meghívó folyamat jogosultsági szintjét örökli, amennyiben a felhasználó rendszergazdaként használja a számítógépet, az így indított alkalmazás is adminisztrátor lesz a rendszerben.

A Windows Vista esetében a programok indítása pontosan ugyanilyen módon történik, már amennyiben az elvégzendő műveletekhez elegendőek a felhasználó (még rendszergazdaként is) csökkentett hozzáférési jogai. Ha nem, akkor jön az UAC és figyelmeztet: egy program adminisztrátori jogosultságot kér, megengedjük vagy sem? De honnan tudja az UAC, hogy a programnak valóban szüksége van-e erre?

A Vista "CreateProcess" függvénye nem hajtja végre szó nélkül az Explorer-től kapott parancsot, helyette három különböző vizsgálatnak veti alá a futtatandó állományt. Az első ezek közül "AppCompat" névre hallgat. Az itt fennakadó alkalmazások specifikusan "adminisztrátor-alkalmazásoknak" minősülnek egy a Microsoft által összeállított igen hosszú lista alapján. Ezekről a programokról előre tudni, hogy futásukhoz emelt jogosultsági szint kell majd, így az UAC azonnal léphet az ügy érdekében. Az AppCompat vizsgálat alatt ezen kívül egy további heurisztikus detektálási folyamat is lezajlik, mely a fájlnévből és a fájlstruktúrából próbálja "kitalálni", hogy szükséges-e a szintemelés. Sokat segít például, ha a fájlnév tartalmazza a "setup", "install" és hasonló szavakat, ez a művelet azonban a nagyobb fájlok (>100 MB) esetén több másodperces, vagy akár fél perces késleltetést is okozhat.

A következő lépés a "Fusion", mely a korábban említett "Vista-aware" alkalmazások észlelését hivatott ellátni. Ha az alkalmazás rendelkezik Fusion-leíróval, a rendszer biztos lehet benne, hogy azt a Windows Vistával való kompatibilitás jegyében és az UAC-t figyelembe véve készítették. Ezesetben például kikapcsolható a fájlrendszer-virtualizáció, mely némileg gyorsabbá teszi az alkalmazás futását. (A Fusion egyébként a programozóknak már ismerős lehet, a különböző verziójú DLL-ek és egyéb közös vezérlők kiválasztásakor használt "side-by-side" módszerként. Az UAC ugyanezt az eljárást alkalmazza, de a side-by-side séma kiterjesztésével.)

Az utolsó vizsgálat az úgynevezett "Installer Heuristics", melynek során az UAC a legelterjedtebb és legismertebb hagyományos telepítőprogramok és önkicsomagoló alkalmazások listájához hasonlítja a kapott mintát.

Ha a három vizsgálat közül egyik sem generál hibát, az alkalmazás a szokásos módon, minden további nélkül elindul. Ellenkező esetben a CreateProcess az "ERROR_ELEVATION_REQUIRED" (jogosultsági szint emelése szükséges) hibaüzenettel visszaadja a vezérlést a ShellExcecuteEx függvénynek. Erre azért van szükség, mert a "CreateProcess" alacsony szintű API, mely nincs felkészítve ablak megjelenítésére (valójában képes sem lenne rá, mert nem kommunikál az ablakkezelővel), pedig az UAC esetében a prompt megjelenítése egy kritikus momentum.


Ha bekövetkezik a fent vázolt esemény, az UAC átadja a teljes felügyeletet a rendszer számára, innentől az "AppInfo.dll" veszi át az irányítást. Az AppInfo "Application Information Service" néven üzemel a rendszerben, feladata pedig a neki átpasszolt alkalmazások jogosultsági szintemelésének kezdeményezése. Bár az AppInfo eleve azért kapja meg a vezérlést, mert szükség van szintemelésre, a biztonság kedvéért mégis újrafuttatja a korábbi három tesztet. Ebben a pillanatban következik a sokak által csak "elsötétítésként" emlegetett Secure Desktop (biztonsági asztal) indítása.





Secure Desktop

Itt álljunk meg egy pillanatra és nézzük meg, mi is valójában a "Secure Desktop". A Windowsban hierarchikus sorrendben megkülönböztetünk úgynevezett munkafolyamatokat (Session), ablakkezelőket (Window Station), valamint asztalokat (Desktop). Mint arról már korábbi cikkeinkben többször is szót ejtettünk, a Windows Vista rendszerben a szolgáltatásoknak fenntartott nulladik munkafolyamat (Session) nem interaktív, tehát a felhasználó nem is találkozhat vele. A felhasználói bejelentkezésekkor sorra létrejövő 1-es, 2-es, stb. munkafolyamatok egymástól elszeparáltan, a hitelesített felhasználó előtt jelennek meg, egymás területére nem tudnak átnyúlni. Az egyes munkafolyamatok alatt futnak az egyes ablakkezelők (Window Station), melyek speciális kernel-objektumok és a programok egymástól független működését teszik lehetővé (külön ablakokban). Az ablakkezelő végül "saját maga alatt" hozza létre az asztalt (Desktop), melyet a felhasználó a képernyőn megjelenő felhasználói felületként ismer.




A Secure Desktop a felhasználó munkafolyamatában, de elszeparált asztalként jön létre, ráadásul csak a rendszer által írható, így a biztonsági asztalt semmilyen külső, a felhasználó asztalán futó folyamattal nem lehet befolyásolni. Ez szinte tökéletesen megbízhatóvá teszi a Secure Desktop-on megjelenített ablakokat, vagyis biztosak lehetünk benne, hogy maga a rendszer és nem pedig egy vírus küldte a megtévesztő üzenetet. A Secure Desktop jelölése: "Winsta0\Winlogon", ahol a "Winsta0" a Window Station 0-t jelöli, a "Winlogon" pedig az asztal neve. (A felhasználó saját asztalának jele: "Winsta0\Default".)

Visszatérve tehát az eredeti témához, az "AppInfo" létrehozza a Secure Desktop-ot, majd ott elindítja a "Consent.exe" programot, mely a "CredUI.dll"-en keresztül megjeleníti a figyelmeztető ablakot. Az UAC többféle formában tűnhet fel, az egyes ablakelrendezések jelentéseit már szintén tárgyaltuk korábbi cikkünkben, emlékeztetőül azonban lássuk újra az ábrát.



Mint láthatjuk, megbízhatósági sorrendben egyre feltűnőbb külsővel és egyre vészjóslóbb megfogalmazásban kapjuk a figyelmeztetéseket. A színeken kívül is több változat is létezik ezekből az ablakokból. Ha rendszergazdaként tevékenykedünk, alapértelmezésként egy jóváhagyó/elutasító promptot kapunk, ha standard felhasználók vagyunk, alapértelmezésként egy név/jelszó páros megadására lesz lehetőségünk. Azért hangsúlyozom ki, hogy alapértelmezésként, mert az ablakok megjelenési módját a rendszergazdák a csoportházirendből szabályozhatják.




Az UAC működése itt befejeződik, ha a felhasználó megadja az engedélyt, vagy a rendszergazda begépeli a hitelesítési adatokat, a "Consent.exe" egy új adminisztrátori folyamatot hoz létre, és a "ShellExecuteEx"-t újra meghívva elindítja a programot. Elsőre talán túl bonyolultnak tűnik az egész művelet, de tulajdonképpen - mint a bevezetőben is említettem - viszonylag kis kódrészről, egy-két plusz DLL-ről van csak szó, és a teljes ellenőrzési folyamat a legtöbb gépen körülbelül egy másodpercen belül lefut. Mindazonáltal láthatjuk, hogy az UAC sokkal többről szól, mint egy egyszerű figyelmeztető ablakról.




Amit még érdemes tudni

Az UAC beépítését több ezer program tesztelése előzte meg, a heurisztikus ellenőrzést megpróbálták minél intelligensebbre faragni. Ez azt jelenti, hogy egy frissítéseket kereső folyamat, mely például a "check for updates" szöveget tartalmazza, az "update" szócska miatt ne kérjen rögtön szintemelést, csak akkor, ha már a tényleges frissítési művelet is elindul.

Az "Installer Heuristics" fázisban ellenőrzött telepítők, frissítők és egyéb programok belső szerkezete több nyelven is letapogatásra kerül, így biztosítva, hogy minél több alkalmazás sikeresen vegye az UAC által felállított "akadályt".

Ha egy program futása közben szükségtelenül generál szintemelést kérő párbeszédablakot, a Microsoft "alkalmazáshibaként" tekint az esetre, tehát úgy kezelik a problémát, mintha a program egyáltalán nem működne. Ezzel magas prioritást kapnak az efféle problémák, tehát a fejlesztők is hamarabb reagálhatnak rá.

Az UAC tervezésekor felállított programozási irányelvek kimondják, hogy a felhasználónak mindig előre tudnia kell róla, ha a művelet jogosultsági szintemelést követel. Ezt a gombokon és hivatkozások mellett elhelyezett kis pajzsok jelzik, egyértelművé téve, mely műveletekhez szükséges rendszergazda hozzáférés.




Az UAC fejlesztése nem fejeződött be. A Microsoft programozói a jövőben a felhasználói visszajelzéseknek megfelelően folyamatosan alakítják majd a kódot, így reményei(n)k szerint elkerülhetők lesznek az olyan esetek, amikor például egy rendszermappából történő csoportos fájtörléshez összesen négy prompton kell átverekedie magát a felhasználóknak.

Bár a Secure Desktop felhasználói asztaltól való elszigeteltsége biztonságossá teszi az UAC-t, mindez egyben akadályokat is jelent az alternatív beviteli szoftverek (például beszédfelismerők) és a különböző képernyő-felolvasó programok számára. A fejlesztők ígéretük szerint dolgoznak a problémán, az UAC jövőbeni verziója valamilyen úton-módon vezérelhető lesz a hagyományostól eltérő módszerekkel is.