User Account Control: Kontrola dostępu użytkownika w Windows 7

Autor: Mark Russinovich

Opublikowano: 20 listopada 2009

Zawartość strony

	Techniki UAC
	Podnoszenie uprawnień i złośliwe oprogramowanie
	Co zmieniło się w Windows 7
	Automatyczne podnoszenie uprawnień
	Automatyczne podnoszenie uprawnień a cele UAC
	Wnioski

Standardowe konta użytkowników zapewniają większe bezpieczeństwo i mniejszy koszt utrzymania zarówno dla domowych, jak i firmowych środowisk. Gdy użytkownicy pracują przy użyciu praw standardowych zamiast administracyjnych, konfiguracja zabezpieczeń systemu, w tym ustawień antywirusowych i zapory, jest chroniona. Zapewnia to użytkownikom bezpieczną przestrzeń, która chroni ich konta i resztę systemu. We wdrożeniach korporacyjnych zasady ustanawiane przez menedżerów IT nie mogą być zastąpione, zaś na współużytkowanym komputerze rodzinnym różne konta użytkowników są chronione przed zmianami wykonanymi przez inne konta.

System Windows ma jednak długą historię użytkowników pracujących na prawach administratorów. W rezultacie oprogramowanie często było projektowane tak, by było uruchamiane przez administratorów i w bywało uzależnione, choć często nieintencjonalnie, od dostępu do praw administracyjnych. Aby pozwolić na uruchamianie większej liczby programów na prawach standardowego użytkownika, a zarazem ułatwić projektantom pisanie aplikacji, które będą poprawnie działały w takich warunkach, w systemie Windows Vista pojawił się składnik Kontrola dostępu użytkownika (User Account Control – UAC). UAC stanowi zespół technik, obejmujących wirtualizację systemu plików i rejestru, konto Protected Administrator (PA), monity podniesienia uprawnień UAC oraz poziomy Windows Integrity wspierające wspomniane cele. Przedstawiłem je szczegółowo w mojej prezentacji oraz w artykule na temat szczegółów UAC opublikowanym w TechNet Magazine.

Windows 7 przesuwa dalej cele UAC, przy czym leżące u podstaw techniki zasadniczo się nie zmieniły. Jednak pojawiły się dwa nowe tryby, w których może działać konto PA oraz mechanizm automatycznego podnoszenia uprawnień dla niektórych wbudowanych komponentów Windows. W tym artykule postaram się przedstawić umotywowanie poszczególnych technik UAC, ponownie przejrzeć powiązania pomiędzy UAC a bezpieczeństwem, opisać dwa nowe tryby i wyjaśnić, jak działa automatyczne podnoszenie uprawnień. Warto też zauważyć, że informacje w tym artykule dotyczą działania wersji RC (release candidate) systemu Windows 7, które pod wieloma względami różni się od znanego z wersji beta.

Techniki UAC

Najbardziej podstawowym elementem i bezpośrednią korzyścią wynikającą z zastosowania UAC jest fakt, że system Windows jest bardziej przyjazny dla standardowego użytkownika. Klasycznym przykładem jest różnica pomiędzy wymaganiami uprawnień dla ustawania strefy czasowej w systemie Windows XP i Windows Vista. W Windows XP zmiana strefy czasowej – a w rzeczywistości samo zajrzenie do jej ustawień w aplecie panelu sterowania – wymaga praw administracyjnych.

Wynika to z faktu, że Windows XP nie odróżnia operacji zmiany czasu, co jest ważną z punktu widzenia zabezpieczeń operacją systemową, od zmiany strefy czasowej, co jedynie zmienia sposób wyświetlania tego czasu. W Windows Vista (i Windows 7) zmiana strefy czasowej nie jest operacją administracyjną, zaś aplet sterujący ustawieniami czasu i daty oddziela operacje administracyjne (ustawianie zegara) od operacji, które może wykonać standardowy użytkownik. Ta jedna zmiana pozwala wielu przedsiębiorstwom skonfigurować dla swoich podróżujących pracowników standardowe konta użytkowników, gdyż mogą oni dopasować strefę czasową do miejsca, w którym się znajdują. Windows 7 idzie jeszcze dalej, pozwalając standardowym użytkownikom na wykonywanie takich czynności jak odświeżanie systemowego adresu IP, instalowanie opcjonalnych aktualizacji i sterowników przy uzyciu Windows Update, zmienianie rozdzielczości ekranu lub przeglądanie bieżących ustawień zapory.

Wirtualizacja systemu plików i rejestru, działająca w tle, pomaga w poprawnym działaniu wielu aplikacji, które niepotrzebnie wymagały praw administracyjnych. Typowym nieuzasadnionym wykorzystaniem praw administracyjnych jest przechowywanie ustawień aplikacji lub danych użytkownika w tych obszarach rejestru lub systemu plików, które są zarezerwowane do wykorzystania przez system. Niektóre starsze aplikacje przechowują swoje ustawienia w ogólnosystemowej części rejestru (HKEY_LOCAL_MACHINE\Software) zamiast w części poszczególnych użytkowników (HKEY_CURRENT_USER\Software). Wirtualizacja rejestru przetwarza próby zapisu w lokalizacji systemowej na zapis w jednej z gałęzi HKEY_CURRENT_USER (HKCU), zachowując kompatybilność aplikacji.

Konto PA zostało zaprojektowane, aby zachęcić projektantów do pisania aplikacji w taki sposób, by wymagały jedynie praw standardowego użytkownika i zarazem umożliwić działanie możliwie wielu aplikacji, które wymagają praw administracyjnych dla części swoich komponentów. Domyślnie pierwsze konto w systemie Windows Vista lub Windows 7, które we wcześniejszych wersjach było pełnym kontem administratora, jest kontem PA. Każdy program uruchamiany przez użytkownika PA działa przy użyciu uprawnień standardowych, o ile użytkownik jawnie nie podniesie uprawnień, co daje aplikacji prawa administracyjne. Monit o podniesienie uprawnień jest wyzwalany przy takich działaniach użytkownika, jak instalowanie aplikacji lub zmienianie ustawień systemu. Jest to najbardziej widoczna część technik UAC, manifestowana poprzez wyświetlenie ekranu zawierającego okno dialogowe z opcjami zezwól/anuluj i wyszarzonym pulpitem jako tłem.

Konta tworzone po instalacji są domyślnie standardowymi kontami użytkownika, dające możliwość podniesienia uprawnień poprzez monit pytający o poświadczenia konta administracyjnego, które ma zostać użyte do nadania praw. Funkcjonalność ta pozwala członkowi rodziny używającemu wspólnego komputera albo bardziej doświadczonemu użytkownikowi o uprawnieniach standardowych na uruchomienie programu z prawami administracyjnymi, o ile zna on hasło do konta administratora, bez konieczności ręcznego przełączania się na inną sesję logowania. Typowymi przykładami takich programów są instalatory aplikacji lub konfigurowanie kontroli rodzicielskiej.

Jeśli UAC jest włączone, wszystkie konta użytkowników – łącznie z administracyjnymi – używają praw standardowych użytkowników. Oznacza to, że projektanci aplikacji muszą uwzględnić fakt, że ich program nie będzie miał domyślnie dostępu administracyjnego. Powinno to również przypominać, że należy projektować programy tak, aby działały przy standardowych uprawnieniach. Jeśli aplikacja lub część jej funkcjonalności wymaga praw administracyjnych, użytkownicy mogą wykorzystać mechanizm podnoszenia uprawnień, by umożliwić odblokowanie tej funkcjonalności. Najczęściej projektanci aplikacji muszą dokonać w nich tylko nieznacznych zmian, aby działały dobrze przy prawach standardowych. Jak można przeczytać we wpisie E7 na blogu UAC, UAC znacząco zmienił sposób, w jaki programiści piszą swoje programy.

Monity podniesienia uprawnień mają również tę zaletę, że „powiadamiają” użytkownika, gdy oprogramowanie próbuje dokonać zmian w systemie i dają możliwość zablokowania takiego działania. Jeśli na przykład pakiet oprogramowania, któremu użytkownik nie ufa i nie chce pozwolić na modyfikowanie systemu, żąda praw administracyjnych, użytkownik może odrzucić monit.

 Do początku strony

Podnoszenie uprawnień i złośliwe oprogramowanie

Podstawowym celem UAC jest umożliwienie pracy większej liczby użytkowników na prawach standardowych. Jednak jeden z komponentów UAC robi wrażenie funkcji zabezpieczeń: monit o akceptację. Wiele osób wierzy, że fakt, że oprogramowanie musi zapytać użytkownika o zgodę na przyznanie praw administracyjnych oznacza, że pozwala to powstrzymać złośliwe programy przed uzyskaniem takich praw. Niezależnie od oczywistego faktu, że monit jest bramą do praw administracyjnych jedynie dla tych operacji, które opisuje, przełączenie na inny pulpit w celu wyświetlenia monitu i wykorzystanie Windows Integrity Mechanism, a w tym User Interface Privilege Isolation (UIPI), wydaje się umacniać to przekonanie.

Jeszcze przed opublikowaniem Windows Vista stwierdziliśmy, że podstawowym celem podnoszenia uprawnień nie jest jednak bezpieczeństwo, tylko wygoda: gdyby użytkownik musiał zmieniać konta w celu wykonania działań administracyjnych, czy to poprzez wylogowanie i ponowne zalogowanie się, czy przy użyciu szybkiego przełączania użytkowników do konta administracyjnego, większość użytkowników przełączyłaby się tylko raz – ale nie z powrotem. Nie byłoby więc postępu i zmian środowiska, dla którego projektanci tworzą swoje aplikacji. Do czego zatem służą bezpieczny pulpit i składnik Windows Integrity Mechanism?

Podstawowym powodem przełączania na inny pulpit w celu wyświetlenia monitu jest chęć, by oprogramowanie uruchomione przez użytkownika nie mogło „sfałszować” monitu, na przykład zamazując w nim nazwę wydawcy i zastępując ją nazwą Microsoft czy innego zaufanego dostawcy oprogramowania i tym samym oszukać użytkownika. Alternatywny pulpit nazywany jest „bezpiecznym”, gdyż jest on własnością nie użytkownika, lecz systemu, podobnie jak pulpit, na którym system wyświetla okno dialogowe logowania.

Wykorzystanie innego pulpitu ma jeszcze jeden ważny powód: kompatybilność aplikacji. Podczas gdy wbudowane programy zwiększania dostępności, takie jak On Screen Keyboard, działają dobrze na pulpicie, gdy uruchomiona aplikacja jest własnością innego użytkownika, istnieją jednak inne programy tego typu, które tego nie potrafią. Takie programy nie działałyby poprawnie, gdyby monit o podniesienie uprawnień, którego właścicielem jest lokalne konto systemowe, został wyświetlony na pulpicie, będącym własnością użytkownika.

Windows Integrity Mechanism oraz UIPI zostały zaprojektowane w celu utworzenia ochronnej bariery wokół aplikacji o podniesionych uprawnieniach. Jednym z oryginalnych celów było powstrzymanie projektantów od „pójścia na skróty” i wykorzystania aplikacji o już podniesionych uprawnieniach do realizacji zadań administracyjnych. Aplikacja działająca z prawami standardowego użytkownika nie może przesłać syntetycznych danych wejściowych (ruchów myszy czy naciśnięć klawiszy) do aplikacji o podniesionych uprawnieniach, aby zrealizować swoje cele.

Windows Integrity Mechanism oraz UIPI zostały użyte w systemie Windows Vista do stworzenia trybu chronionego przeglądarki Internet Explorer, co utrudnia złośliwym programom, które zainfekowały działającą instancję IE, modyfikowanie ustawień konta użytkownika, na przykład skonfigurowania siebie samych jako uruchamianych podczas logowania. Wprawdzie początkowym celem projektowym Windows Vista było stosowanie podniesień uprawnień na bezpiecznym pulpicie z wykorzystaniem Windows Integrity Mechanism i UIPI do stworzenia nieprzenikalnej bariery – zwanej granicą bezpieczeństwa – pomiędzy oprogramowaniem uruchamianym na standardowych prawach i administracyjnym, jednak dwie przyczyny spowodowały, że celu tego nie udało się osiągnąć i w konsekwencji został on porzucony: wygoda użytkowania i kompatybilność aplikacji.

Rysunek 1: Ukazywanie nazwy pliku wykonywalnego.

Na początek rozważmy sam monit o podniesienie uprawnień. Wyświetla on nazwę i wydawcę podstawowego pliku wykonywalnego, dla którego mają być przyznane prawa administracyjne. Nieszczęśliwie, choć coraz większa liczba wydawców podpisuje swój kod cyfrowo, nadal są tacy, którzy tego nie robią, a ponadto jest wiele starszych aplikacji, które nie są podpisane. W takiej sytuacji monit ukazuje tylko nazwę pliku wykonywalnego. Sprawia to, że złośliwy program (już uruchomiony przy użyciu konta użytkownika) mógłby oczekiwać na pojawienie się monitu o podniesienie uprawnień dla niepodpisanego instalatora Setup.exe i zastąpić go własnym programem po zmianie nazwy na Setup.exe – bez możliwości odróżnienia tego przez użytkownika (patrz Rysunek 1).

Po drugie, okno dialogowe nie informuje, jakie biblioteki DLL załaduje program, gdy już się uruchomi. Jeśli program ten znajduje się w katalogu, który jest pod kontrolą użytkownika, złośliwy program używający praw standardowego użytkownika może podmienić dowolne biblioteki w tej lokalizacji na własne. Alternatywnie złośliwy program mógłby użyć funkcjonalności równoległej, aby spowodować załadowanie spreparowanych wersji bibliotek aplikacji lub wersji systemowych. I nawet jeśli użytkownik kliknie przycisk wyświetlający szczegóły i przejrzy ścieżki plików wylistowanych w monicie, złośliwy program może skopiować kod wykonywalny do podobnie wyglądającej lokalizacji, na przykład \ProgramFiles\Vendor\Application.exe (zwróćmy uwagę na brakującą spację – powinno być „Program Files”), skąd mógłby kontrolować, które biblioteki będzie ładowała aplikacja. Na Rysunku 2 pokazany jest monit wyświetlony, gdy skopiowałem jeden ze składników Microsoft Network Monitor do utworzonego przeze mnie katalogu C:\ProgramFiles, do którego moje konto użytkownika miało pełne prawa, po czym go uruchomiłem.

Rysunek 2: Uruchomienie kopii programu ze sfałszowanej lokalizacji.

Wreszcie ze względu na kompatybilność aplikacji programy o podniesionych uprawnieniach współużytkują znaczącą część środowiska z otoczeniem standardowego użytkownika, co złośliwe aplikacje mogą wykorzystać do wpływu na działanie takich programów. Najoczywistszym przykładem jest część rejestru należąca do użytkownika HKEY_CURRENT_USER (HKCU). Jest ona współdzielona, gdyż oczekuje się, że ustawienia i rozszerzenia zarejestrowane przez użytkowników w trybie standardowym będą nadal działać po podniesieniu uprawnień. Złośliwe oprogramowanie może więc wykorzystać rozszerzenia powłoki zarejestrowane w HKCU do załadowania swojego kodu do aplikacji o podniesionych uprawnieniach używającej któregoś z okien przeglądania folderów, takich jak otwieranie czy zapisywanie pliku. Współdzielone są też inne elementy stanu , z których najważniejsza jest przestrzeń nazw Base Named Object, gdzie aplikacje tworzą obiekty synchronizacji i współużytkowanej pamięci. Złośliwe oprogramowanie może skorzystać z tego w celu przechwycenia współużytkowanego obiektu pamięci, aby skompromitować aplikację o podniesionych uprawnieniach i – w konsekwencji – sam system.

Podobnie jak w przypadku Windows Integrity Mechanism skuteczność UIPI jako bariery jest ograniczona problemami podobnymi do przedstawionych wyżej, ale dodatkowo ma on jeszcze ograniczenia wynikające z kompatybilności aplikacji. Po pierwsze, UIPI nie powstrzyma standardowych aplikacji przed zmienianiem wyglądu pulpitu, co może zostać wykorzystane do skłonienia użytkownika do takich działań z aplikacją o podniesionych uprawnieniach, które dałyby złośliwemu oprogramowaniu prawa administracyjne. Windows Integrity Mechanism nie może również oddziaływać poprzez sieć. Aplikacja standardowego użytkownika korzystającego z konta PA będzie miała dostęp do zasobów systemowych na systemie zdalnym, na którym to konto PA ma prawa administracyjne. Rozwiązanie tych ograniczeń ma znaczący wpływ na kompatybilność aplikacji. Tak więc, cały czas szukamy sposobów poprawy bezpieczeństwa systemu, na przykład ulepszając tryb chroniony w przeglądarce IE, jednocześnie starając się rozwiązać problemy ze zgodnością aplikacji i pracując możliwie ściśle z projektantami oprogramowania.

Tak więc, jak dużą ochronę przed złośliwym oprogramowaniem uzyskamy, pracując na koncie PA w systemie Windows Vista PA z włączonym mechanizmem UAC? Po pierwsze należy pamiętać, że złośliwy program musi najpierw dostać się do systemu i zostać uruchomiony. System Windows dysponuje wieloma funkcjami obronnymi, takimi jak Data Execution Prevention (DEP), Address Space Load Randomization (ASLR), Protected Mode IE, IE 8 SmartScreen Filter oraz Windows Defender, które pomagają powstrzymać takie programy przed załadowaniem się do systemu i uruchomieniem.

W przypadku, gdy nawet złośliwe programy jakoś zdołają dostać się do systemu, to ponieważ ich autorzy (podobnie jak „normalni” programiści) założyli, że użytkownicy pracują na uprawnieniach administracyjnych, większość takich programów nie będzie działać poprawnie. Już samo to można uznać za wyraźną korzyść. Jednak złośliwy program, który dostał się do systemu i w którym przewidziano wykorzystanie jakiejś luki, może być w stanie uzyskać prawa administracyjne za pierwszym razem, gdy użytkownik użyje podniesienia uprawnień – ale nawet nie musi czekać na „rzeczywistą” okazję, gdyż sam może wygenerować taką, która oszuka nawet najbardziej doświadczonego użytkownika. Zademonstrowałem publicznie, jak złośliwy program może przechwycić proces podnoszenia uprawnień w prezentacjach UAC Internals oraz Windows Security Boundaries (demonstracja zaczyna się od 1:03 w wykładzie o granicach zabezpieczeń). Trzeba jednak pamiętać, że jeśli taki program w ogóle zostanie uruchomiony, może osiągnąć większość rzeczy, których chciał jego twórca, używając tylko praw standardowego użytkownika, łącznie ze skonfigurowaniem siebie samego do automatycznego uruchamiania, przechwytując lub usuwając dane użytkownika albo wręcz stając się częścią botnetu.

 Do początku strony

Co zmieniło się w Windows 7

Wspomniałem o kilku działaniach, które obecnie w Windows 7 mogą być realizowane przez standardowych użytkowników, jednak jak wyjaśnił E7 w blogu UAC, zorientowaliśmy się również, że możemy poprawić działanie Windows bez poświęcania celów UAC. Wielu użytkowników skarżyło się na fakt, że system Windows Vista sam z siebie często pyta o prawa administracyjne podczas wykonywania typowych działań konserwacyjnych. W naszym najlepszym interesie, jako że jest to interes naszych klientów, jest zapewnienie dobrego działania Windows w środowisku standardowego użytkownika. Jednak monity o podniesienie uprawnień nie uczą, ale skłaniają użytkowników do bezmyślnego klikania potwierdzenia w oknie dialogowym, którego większość z nich w ogóle nie czyta. Z tego względu w Windows 7 zminimalizowano liczbę tych monitów w domyślnym ustawieniu, a ponadto pozwolono, aby użytkownicy pracujący jako administratorzy mieli kontrolę nad zachowaniem się monitów.

W tym celu dokonaliśmy dalszej przebudowy systemu, aby ktoś z uprawnieniami standardowego użytkownika mógł wykonać więcej zadań, a także zmniejszyliśmy liczbę monitów w scenariuszach, które dotąd powodowały wiele zapytań o podniesieni uprawnień (na przykład przy instalowaniu kontrolki ActiveX w IE). W Windows 7 wprowadzono również dwa nowe tryby pracy UAC, które można wybrać w nowym oknie dialogowym konfiguracji UAC (patrz Rysunek 3). Okno to można wyświetlić, otwierając Control Panel, klikając User Accounts, następnie User Accounts i na koniec Change User Account Control Settings (to samo okno można również wyświetlić, klikając łącze Change When Notifications Appear w monicie o podniesienie uprawnień).

Rysunek 3: Dwa nowe tryby robocze UAC, które można wybrać w oknie konfiguracji.

Ustawienie domyślne, pokazane na Rysunku 3, jest jednym z nowych poziomów. W odróżnieniu do Always Notify (Zawsze monitu), które odpowiada najwyższemu położeniu suwaka i jest identyczne z domyślnym trybem w Windows Vista, system Windows 7 domyślnie pyta użytkownika jedynie wówczas, gdy program wykonywalny niebędący częścią Windows żąda podniesienia uprawnień; w tym wypadku zachowanie jest takie same jak w Windows Vista.

Kolejna pozycja jest drugą nową opcją i ma tę samą etykietę z dodatkowym warunkiem „do not dim my desktop” (nie wyszarzaj pulpitu). Jedyna różnica między tym trybem a trybem domyślnym polega na tym, że monit pojawia się na pulpicie użytkownika, nie na pulpicie bezpiecznym. Korzyść z tego jest taka, że użytkownik może coś zrobić na pulpicie przy aktywnym monicie, ale jak wspomniałem wcześniej, wiąże się to z ryzykiem, że oprogramowanie ułatwienia dostępu innych firm nie będzie działało właściwie z oknem dialogowym.

Wreszcie ostatnia, dolna pozycja suwaka całkowicie wyłącza technikę UAC, tak więc wszystkie programy uruchamiane przez konto PA działają z pełnymi prawami administracyjnymi, wirtualizacja systemu plików i rejestru zostaje wyłączona, jak również tryb chroniony przeglądarki IE. Wprawdzie w tym wypadku nie będzie żadnych monitów, jednak utrata trybu chronionego IE jest znaczącą wadą tego trybu.

 Do początku strony

Automatyczne podnoszenie uprawnień

Powodem, dla którego podniesienie uprawnień dla (większości) plików wykonywalnych Windows przy dwóch środkowych ustawieniach nie powoduje wyświetlenia monitu jest to, że system „automatycznie” podnosi uprawnienia dla plików Windows. Najpierw jednak ustalmy, co system Windows definiuje w tym kontekście jako „plik wykonywalny Windows”? Odpowiedź zależy od wielu czynników, ale dwie rzeczy muszą być spełnione: plik musi być podpisany cyfrowo przez wydawcę Windows, którym to certyfikatem podpisywany jest cały kod dołączony do Windows (nie wystarczy podpisanie przez firmę Microsoft – tak więc oprogramowanie Microsoft niedołączone do systemu Windows, nie jest uwzględnione); musi być zlokalizowany w jednym z kilku „bezpiecznych” katalogów. Bezpieczny katalog to taki, którego użytkownik standardowy nie może modyfikować. Należą do nich %SystemRoot%\System32 (czyli \Windows\System32) i większość jego podkatalogów, %SystemRoot%\Ehome, a także kilka katalogów wewnątrz %ProgramFiles%, w tym te zawierające Windows Defender i Windows Journal.

Ponadto w zależności od tego, czy plik wykonywalny to zwykły .exe, Mmc.exe, czy też obiekt COM, automatyczne podnoszenie uprawnień ma dodatkowe reguły. Pliki wykonywalne Windows (zgodnie z wcześniejszą definicją) typu .exe podlegają automatycznemu podniesieniu uprawnień, jeśli mają określony atrybut autoElevate w swoim manifeście, znajdujący się również tym miejscem, w którym aplikacje informują UAC, że potrzebują praw administracyjnych. Rysunek 4 ukazuje zrzut manifestu programu Task Manager (Taskmgr.exe) z opcją "sigcheck –m %systemroot%\system32\taskmgr.exe" wykonany przez narzędzie Sysinternals Sigcheck, w którym widać, że Task Manager żąda automatycznego podniesienia uprawnień.

Rysunek 4: Właściwość autoElevate.

Łatwą metodą znalezienia takich programów w drzewie katalogów jest użycie narzędzia Sysinternals Strings:

strings –s *.exe | findstr /i autoelevate

Istnieje też stała lista plików wykonywalnych Windows, które podlegają automatycznemu podnoszeniu uprawnień. Programy te są publikowane jako zewnętrzne w stosunku do Windows 7, a poza tym muszą być w stanie działać w systemach wcześniejszych wersji, gdzie obecność właściwości autoElevate spowodowałaby błąd. Lista ta obejmuje kreator migracji Migwiz.exe, menedżer pakietów Pkgmgr.exe oraz instalator pakietów serwisowych Spinstall.exe.

Program Microsoft Management Console, Mmc.exe, jest traktowany specjalnie, gdyż jest on hostem dla wielu przystawek zarządzania systemem, implementowanych jako biblioteki DLL. Mmc.exe uruchamiany jest poleceniem wskazującym plik .MSC, który zawiera listę przystawek do załadowania. Gdy system Windows zauważy żądanie Mmc.exe o prawa administracyjne, co nastąpi, gdy zostanie uruchomiony z konta PA, sprawdza najpierw, ze Mmc.exe jest plikiem wykonywalnym Windows, po czym sprawdza .MSC. Aby mieć możliwość automatycznego podniesienia uprawnień, plik .MSC musi spełnić kryteria wymagane od plików wykonywalnych Windows (być podpisany przez wydawcę Windows i umieszczony w bezpiecznej lokalizacji) i musi być wymieniony na wewnętrznej liście dopuszczonych .MSCs. Lista ta zawiera niemal wszystkie pliki .MSC oryginalnie dołączone do systemu Windows.

Wreszcie obiekty COM mogą określić potrzebę praw administracyjnych poprzez rejestr, tworząc w swoim kluczu podklucz o nazwie Elevation z wartością o nazwie Enabled ustawioną na 1. Rysunek 5 pokazuje taki klucz dla obiektu powłoki Copy/Move/Rename/Delete/Link, używanego przez Windows Explorer przy wykonywaniu operacji w systemie plików w takiej lokalizacji, do której bieżące konto nie ma uprawnień.

Rysunek 5: Klucz rejestru powłoki.

Oprócz tego, aby obiekt COM mógł podlegać automatycznemu podnoszeniu uprawnień, sam musi być plikiem wykonywalnym Windows i być zainicjowany przez plik wykonywalny Windows (ten ostatni jednak nie musi być oznakowany do automatycznego podnoszenia uprawnień). Jeśli użyjemy Windows Explorer do utworzenia podkatalogu w %ProgramFiles% z konta PA, operacja ulegnie automatycznemu podniesieniu uprawnień, gdyż obiekt COM tego zażąda, DLL obiektu jest plikiem wykonywalnym Windows, podobnie jak sam Windows Explorer.

 Do początku strony

Automatyczne podnoszenie uprawnień a cele UAC

Co zatem kryje się poza tymi specjalnymi regułami automatycznego podnoszenia uprawnień? Przy określaniu, co powinno, a co nie powinno dysponować tą możliwością, musieliśmy odpowiedzieć na pytanie „Czy uzależnienie działania aplikacji od dostępu do uprawnień administracyjnych (i rozwiązywanie tego problemu via automatyczne podnoszenie uprawnień) jest wynikiem przeoczenia, czy też głupoty projektanta aplikacji?” Na przykład Cmd.exe może (i jest) zostać użyty do wykonywania skryptów wsadowych, ale przeciętni użytkownicy nie mają żadnej potrzeby, aby uruchamiać go z podniesionymi uprawnieniami (większość nie wie nawet, że coś takiego jak wiersz polecenia w ogóle istnieje), i właśnie dlatego jego manifest nie zawiera właściwości autoElevation). Analogicznie Rundll32.exe, plik wykonywalny, który obsługuje wtyczki panelu sterowania, również nie podlega automatycznemu podnoszeniu uprawnień w finalnej wersji Windows 7, gdyż nie jest to potrzebne dla większości zadań zarządzania systemem, a przede wszystkim jego zdolność do wykonania dowolnej biblioteki DLL z wiersza polecenia mogłaby doprowadzić do tego, że programiści żądaliby dla swoich bibliotek praw administracyjnych, uzyskiwali je – i w ogóle nie zdawaliby sobie z tego sprawy. W istocie program ten jest jednym z najpotężniejszych (i tym samym potencjalnie najgroźniejszych) komponentów Windows.

Użytkownicy często pytają o możliwość dodania arbitralnie wybranych aplikacji do listy programów o automatycznie podnoszonych uprawnieniach – i to już od czasów wersji beta systemu Windows Vista. Typowym uzasadnieniem jest to, że pewna często używana aplikacja zmusza ich do ciągłego klikania w monitach o podniesienie uprawnień – nieraz kilka razy w ciągu godziny. Windows 7, podobnie jak Windows Vista, nie udostępnia takiej funkcjonalności. Rozumiemy zdenerwowanie użytkowników, a także przyznajemy, że może istnieć uzasadniony powód, dla którego dana aplikacja nie może działać bez praw administracyjnych, jednak zbyt wysokie jest ryzyko, że w takim przypadku programiści nie będą próbowali poprawiać swojego kodu, by działał w kontekście standardowego użytkownika. Nawet gdyby lista takich aplikacji była dostępna tylko dla administratorów, projektant mógłby po prostu zmienić program instalacyjny swojej aplikacji (który i tak zwykle wymaga podniesienia uprawnień – ale tylko jednorazowego), by dopisał tę aplikację do listy. Zamiast tego zdecydowaliśmy się zainwestować w edukowanie i bliższą współpracę z projektantami aplikacji, aby zagwarantować, że ich programy po prostu nie będą potrzebowały podnoszenia uprawnień.

Kilka osób zauważyło, ze oprogramowanie innej firmy (a ściślej: nie-Windows) uruchomione przez konto PA z uprawnieniami standardowego użytkownika może skorzystać z automatycznego podnoszenia uprawnień w celu uzyskania praw administracyjnych. By podać przykład, program taki może wykorzystać API WriteProcessMemory w celu wprowadzenia własnego kodu do programu Explorer, a następnie API CreateRemoteThread do wykonania tego kodu –jest to technika zwana iniekcją DLL. Ponieważ wstrzyknięty fragment wykonywany jest wewnątrz programu Explorer, który jest plikiem wykonywalnym Windows, może posłużyć się obiektami COM podlegającymi automatycznemu podnoszeniu uprawnień, takimi jak Copy/Move/Rename/Delete/Link, do zmodyfikowania systemowych kluczy rejestru lub katalogów i przyznania programowi praw administracyjnych. To prawda, jednak takie działanie wymaga świadomego działania i nie jest trywialne, a tym samym nie jest czymś, za czym (w naszym przekonaniu) mogliby optować twórcy uprawnionego oprogramowania, zamiast po prostu poprawić programy tak, by działały z uprawnieniami standardowymi. W istocie zalecamy programistom, aby nie uzależniali działania swoich programów od zachowania mechanizmu podnoszenia uprawnień i wykonywali wszystkie testy w trybie standardowego użytkownika.

Wnioskiem z powyższego spostrzeżenia jest fakt, że złośliwe oprogramowanie również może uzyskać tą samą techniką prawa administracyjne. Ponownie jest to prawda, ale jak już wskazałem wcześniej, programy takie mogą skompromitować system również przy użyciu jawnego monitu o podniesienie uprawnień. Z tej perspektywy domyślny tryb działania Windows 7 nie jest ani bardziej, ani mniej „bezpieczny” niż tryb Always Notify („tryb Vista”), zaś złośliwe programy, które zostały napisane przy założeniu, że działają z prawami administracyjnymi, nadal nie będą w stanie działać w domyślnym trybie Windows 7.

 Do początku strony

Wnioski

Podsumowując, UAC stanowi zbiór technik, które mają jeden cel ogólny: umożliwić ludziom pracę na prawach standardowych użytkowników. Są to: zmiany w systemie Windows, pozwalające standardowym użytkownikom na wykonywanie operacji, które wcześniej wymagały praw administracyjnych; wirtualizacja systemu plików i rejestru; monity o podniesienie uprawnień. Wszystkie te elementy współpracują ze sobą, by zrealizować ten cel. Jednak domyślny tryb UAC w systemie Windows 7 sprawia, że praca użytkownika PA staje się płynniejsza dzięki redukcji liczby monitów, ale nadal pozwala osiągać cele UAC – umożliwić działanie większej liczby programów bez praw administracyjnych oraz skłaniać całe środowisko programistów do pisania takich programów, które tych praw nie potrzebują.

O autorze

Mark Russinovich jest doradcą technicznym w firmie Microsoft w dziale platform i usług.

 Do początku strony