Kontrola konta użytkownika Windows 7 od środka

Autor: Mark Russinovich

Opublikowano: 29 lipca 2009

Zawartość strony

	Technologie UAC
	Podnoszenie uprawnień i zabezpieczenia przed złośliwym oprogramowaniem
	Co nowego jest w systemie Windows 7
	Automatyczne podnoszenie uprawnień
	Cele automatycznego podnoszenia uprawnień i kontroli konta użytkownika
	Podsumowanie

Standardowe konta użytkownika zapewniają większe bezpieczeństwo i niższy koszt własności zarówno w środowisku domowym, jak i w korporacyjnym. Kiedy użytkownicy działają ze standardowymi prawami użytkownika zamiast praw administracyjnych, chroniona jest konfiguracja zabezpieczeń systemu, obejmująca program antywirusowy i zaporę sieciową. To daje użytkownikom bezpieczny obszar, który może chronić ich konto i resztę systemu. Dla wdrożeń w przedsiębiorstwach zasady ustawione przez menedżerów IT dla komputerów osobistych nie mogą być zastępowane, a na wspólnie używanym komputerze rodzinnym różne konta użytkownika są chronione przed zmianami dokonywanymi przez inne konta.

Jednak system Windows ma długą historię użytkowników działających z prawami administracyjnymi. W rezultacie, oprogramowanie było często tworzone tak, aby było uruchamianie z kont administracyjnych i często mimowolnie przyjmowało prawa administracyjne dla kont zależnych. Aby udostępnić więcej oprogramowania działającego ze standardowymi prawami użytkownika, jak i pomóc programistom w pisaniu aplikacji prawidłowo działających ze standardowymi prawami użytkownika, w Windows Vista została wprowadzona Kontrola konta użytkownika (User Account Control, UAC). UAC jest zbiorem technologii, obejmujących wirtualizację systemu plików i rejestru, konto Protected Administrator (PA), zgłoszenia podniesienia uprawnień UAC oraz poziomy Windows Integrity, które wspierają te cele. Mówiłem o tym na moich prezentacjach w czasie konferencji oraz w artykule TechNet Magazine,UAC internals.

Cele UAC z podstawowymi technologiami zostały przeniesione do Windows 7 w stosunkowo niezmienionej postaci. Wprowadzono jednak nowe dwa tryby, w których może działać konto PA UAC z mechanizmem automatycznego podnoszenia uprawnień dla niektórych wbudowanych komponentów Windows. W tym tekście omawiam motywację stojącą za technologiami UAC, ponownie spojrzę na relację pomiędzy UAC i bezpieczeństwem, opiszę dwa nowe tryby i wyjaśnię, jak dokładnie działa automatyczne podnoszenie uprawnień. Trzeba zwrócić uwagę, że informacje tutaj zawarte odzwierciedlają działanie wersji RC (Release Candidate) Windows 7, który różni się na kilka sposobów od wersji beta.

Technologie UAC

Najbardziej podstawowym elementem i bezpośrednią korzyścią z technologii UAC jest to, że system Windows jest bardziej przyjazny dla standardowego użytkownika. Modelowym przykładem jest różnica między wymaganiami dotyczącymi przywileju ustawiania strefy czasowej w Windows XP oraz Windows Vista. W Windows XP zmiana strefy czasowej – a faktycznie nawet jej podgląd w aplecie sterowania czasem/datą – wymaga praw administracyjnych.

Jest tak dlatego, że Windows XP nie rozróżnia zmiany czasu, który jest operacją systemową wrażliwą z punktu widzenia bezpieczeństwa, od zmiany strefy czasowej, która rzadko ma wpływ na wyświetlany czas. W Windows Vista (i Windows 7) zmiana strefy czasowej nie jest operacją administracyjną, a w aplecie panelu sterowania czasem/datą operacje administracyjne są oddzielone od standardowych operacji użytkownika. Sama ta zmiana umożliwia wielu przedsiębiorstwom konfigurowanie podróżujących użytkowników ze standardowymi kontami, ponieważ użytkownicy mogą dostosować strefę czasu, aby odzwierciedlić swoje aktualne położenie. W systemie Windows 7 zmiany poszły dalej, poprzez utworzenie czegoś podobnego do odświeżania adresu IP systemu przy użyciu Windows Update do instalowania opcjonalnych aktualizacji i sterowników, zmiany DPI ekranu i przeglądania aktualnych ustawień zapory sieciowej, dostępnych dla standardowych użytkowników.

Wirtualizacja systemu plików i rejestru działają w tle, aby pomóc w prawidłowym działaniu wielu aplikacji, które niezamierzenie korzystają z praw administracyjnych, bez tych praw. Najbardziej powszechnym, niepotrzebnym użyciem praw administracyjnych jest przechowywanie ustawień aplikacji lub danych użytkownika w obszarach rejestru lub systemu plików, które są używane przez system. Niektóre starsze aplikacje przechowują swoje ustawienia na przykład w części rejestru dotyczącej całego systemu (HKEY_LOCAL_MACHINE\Software), zamiast w części związanej z użytkownikiem (HKEY_CURRENT_USER\Software), a wirtualizacja rejestru kieruje próby zapisu w lokalizacji systemowej do HKEY_CURRENT_USER (HKCU), zachowując jednocześnie kompatybilność aplikacji.

Konto PA zostało zaprojektowane w celu zachęcenia programistów do takiego pisania swoich aplikacji, aby wymagały tylko standardowych praw użytkownika, umożliwiając jednocześnie dalszą pracę wielu aplikacji, które dzielą stan między komponentami administracyjnymi a komponentami standardowego użytkownika. Domyślnie pierwszym kontem w systemie Windows Vista lub Windows 7, którym w poprzednich wersjach systemu było konto pełnego administratora, jest konto PA. Wszelkie programy wykonywane przez PA działają ze standardowymi prawami użytkownika, dopóki użytkownik jawnie nie podniesie uprawnień aplikacji, który gwarantuje administracyjne prawa aplikacji. Zgłoszenia podnoszenia uprawnień są wywoływane przez działania użytkownika, takie jak instalowanie aplikacji i zmienianie ustawień systemu. Te zgłoszenia są najbardziej widoczną technologią UAC, w postaci przełącznika do ekranu z oknem dialogowym zezwolenia/anulowania oraz wygaszonym zrzutem pulpitu w tle.

Konta utworzone po instalacji są domyślnie standardowymi kontami użytkownika, które zapewniają możliwość podnoszenia uprawnień „mimochodem”, przez zgłoszenie pytające o poświadczenia konta administracyjnego, które będzie użyte do przyznania praw administracyjnych. Dzięki tej możliwości członkowie rodziny mogą współużytkować komputer domowy lub użytkownik bardziej świadomy kwestii bezpieczeństwa, korzystający ze standardowego konta użytkownika, może – przy założeniu, że zna hasło do konta administracyjnego – uruchamiać aplikacje z prawami administracyjnymi bez konieczności ręcznego przełączania do innej sesji logowania użytkownika. Typowe przykłady takich aplikacji obejmują instalatory i konfiguracje kontroli rodzicielskiej.

Kiedy kontrola konta użytkownika (UAC) jest włączona, wszystkie konta użytkowników – łącznie z kontami administracyjnymi – działają ze standardowymi prawami użytkownika. Oznacza to, że projektanci aplikacji muszą brać pod uwagę fakt, że ich oprogramowanie nie ma domyślnie praw administracyjnych. To powinno im przypominać o projektowaniu swoich aplikacji ze standardowymi prawami użytkownika. Jeśli aplikacja lub części jej funkcjonalności wymagają praw administracyjnych, można wykorzystać mechanizm podnoszenia uprawnień, aby umożliwić użytkownikowi odblokowanie tej możliwości. Zasadniczo programiści aplikacji muszą dokonywać tylko drobnych zmian w swoich aplikacjach, aby dobrze pracowały ze standardowym użytkownikiem. Jak pokazuje post na temat UAC na blogu E7, UAC z powodzeniem zmienia sposób, w jaki programiści tworzą oprogramowanie.

Zgłoszenia podnoszenia uprawnień dają także taką korzyść, że „zawiadamiają" użytkownika, gdy oprogramowanie chce dokonać zmian w systemie, co daje mu możliwość zapobiegnięcia temu. Na przykład, jeśli pakiet oprogramowania, któremu użytkownik nie ufa lub nie chce dopuścić do modyfikacji przez niego systemu, pyta o prawa administracyjne, można odrzucić zgłoszenie.

 Do początku strony

Podnoszenie uprawnień i zabezpieczenia przed złośliwym oprogramowaniem

Głównym celem UAC jest umożliwienie większej liczbie użytkowników działania ze standardowymi prawami użytkownika. Jedna z technologii UAC wygląda jednak całkiem jak funkcja zabezpieczeń: to zgłoszenie zgody. Wiele osób wierzy, że fakt, iż oprogramowanie musi prosić użytkownika o przydzielenie praw administracyjnych, oznacza, że chroni to przed uzyskaniem praw administracyjnych przez złośliwe oprogramowanie. Obok wizualnej konsekwencji, że zgłoszenie jest bramą do praw administracyjnych tylko dla operacji, którą opisuje, przełączenie do innego pulpitu dla okna dialogowego podnoszenia uprawnień i użycie mechanizmu Windows Integrity wraz z UIPI (User Interface Privilege Isolation) wydaje się wzmacniać to przekonanie.

Jak stwierdziliśmy wcześniej, przed wprowadzeniem na rynek Windows Vista, głównym celem podnoszenia uprawnień nie było bezpieczeństwo, lecz wygoda: jeśli użytkownik musiał przełączyć konta, aby wykonać operacje administracyjne, albo poprzez logowanie do konta administracyjnego, albo przełączanie za pomocą Fast User Switching, większość użytkowników przełączała się raz i nie wracała do poprzedniego konta. Nie było wtedy żadnego postępu w zmianie środowiska, dla którego programiści projektują tę aplikację. Do czego więc służą bezpieczny pulpit oraz mechanizm Windows Integrity?

Głównym powodem przełączania się na inny pulpit dla zgłoszenia jest to, że standardowy użytkownik nie może „sfałszować" zgłoszenia podnoszenia uprawnień, na przykład rysując na górze nazwę wydawcy w oknie dialogowym, aby oszukać użytkownika, że to Microsoft lub inny dostawca oprogramowania generuje zgłoszenie zamiast nich. Pulpit alternatywny jest nazywany „bezpiecznym pulpitem”, ponieważ jego właścicielem jest system, a nie użytkownik, podobnie jak w przypadku pulpitu, na którym system wyświetla okno dialogowe logowania Windows.

Użycie innego pulpitu ma także ważny cel zgodności aplikacji: podczas gdy wbudowane oprogramowanie dostępności, takie jak On Screen Keyboard, działa dobrze na pulpicie z uruchomionymi aplikacjami, których właścicielami są różne osoby, istnieje oprogramowanie innych firm, które na nim nie działa. To oprogramowanie nie będzie prawidłowo działać, gdy okno dialogowe podnoszenia uprawnień, należące do lokalnego konta systemu, jest wyświetlane na pulpicie należącym do użytkownika.

Mechanizm kontroli integralności Windows (Windows Integrity Mechanism) oraz UIPI zostały zaprojektowane w celu utworzenia bariery ochronnej wokół aplikacji z podniesionymi uprawnieniami. Jednym z pierwotnych celów było zapobieganie używaniu przez projektantów oprogramowania skrótów klawiszowych oraz wykorzystaniu aplikacji z już podniesionymi uprawnieniami do wykonywania zadań administracyjnych. Aplikacja uruchomiona ze standardowymi prawami użytkownika nie może wysyłać danych ze sztucznej myszy lub klawiatury do aplikacji z podniesionymi uprawnieniami, aby spowodować wykonanie przez nią kodu wywołanego lub wprowadzonego, do wykonania operacji administracyjnych.

Mechanizm kontroli integralności Windows oraz UIPI były stosowane w Windows Vista, w trybie chronionym Internet Explorer, co bardzo utrudniało złośliwemu oprogramowaniu, które zainfekowało uruchomioną instancję IE, modyfikację ustawień konta użytkownika – na przykład takie skonfigurowanie samego siebie, aby uruchamiać się przy każdym logowaniu użytkownika. Chociaż wczesnym celem projektu Windows Vista było użycie podnoszenia uprawnień z bezpiecznym pulpitem, mechanizmu kontroli integralności Windows oraz UIPI do utworzenia nieprzepuszczalnej bariery – nazywanej granicą bezpieczeństwa – pomiędzy oprogramowaniem działającym ze standardowymi prawami użytkownika oraz z prawami administracyjnymi, dwa powody uniemożliwiły jego osiągnięcie i spowodowały jego późniejsze porzucenie: użyteczność oraz kompatybilność aplikacji.

Rysunek 1: Pokazanie nazwy pliku wykonywalnego.

Najpierw rozważmy samo okno dialogowe podnoszenia uprawnień. Jest w nim wyświetlona nazwa i wydawca głównego pliku wykonywalnego, który będzie miał przydzielone prawa administracyjne. Niestety, chociaż wielu wydawców oprogramowania podpisuje cyfrowo swój kod, są tacy, którzy tego nie robią; jest też wiele starszych, niepodpisanych aplikacji. Dla oprogramowania, które nie jest podpisane, okno dialogowe podnoszenia uprawnień pokazuje po prostu nazwę pliku wykonywalnego, co umożliwia złośliwemu oprogramowaniu, które już działa na koncie użytkownika i które obserwuje podnoszenie uprawnień niepodpisanej aplikacji instalatora Setup.exe, na przykład zastąpienie pliku wykonywalnego złośliwym Setup.exe, czego użytkownik nie jest w stanie rozpoznać (patrz rysunek 1).

Po drugie, okno dialogowe nie informuje użytkownika, jakie biblioteki DLL załaduje plik wykonywalny po uruchomieniu. Jeśli plik wykonywalny jest umieszczony w katalogu będącym pod kontrolą użytkownika, złośliwe oprogramowanie uruchomione ze standardowymi prawami użytkownika mogą zastąpić wszelkie powiązane biblioteki w lokalizacji, która będzie użyta przez oprogramowanie. Alternatywnie, złośliwe oprogramowanie może użyć równoległej funkcjonalności, aby spowodować załadowanie przez plik wykonywalny złośliwej wersji aplikacji lub systemowych bibliotek DLL. Jeśli użytkownik nie kliknie czujnie przycisku szczegółów i nie popatrzy uważnie na ścieżkę pliku wymienioną dla pliku wykonywalnego podnoszącego uprawnienia, złośliwe oprogramowanie może skopiować plik wykonywalny do podobnie nazwanej lokalizacji, na przykład, \ProgramFiles\Vendor\Application.exe (zwróćmy uwagę na brakującą spację w „Program Files”), gdzie mógłby kontrolować, jakie biblioteki DLL są ładowane przez aplikację. Na rysunku 2 skopiowałem komponent Microsoft Network Monitor do utworzonego przez użytkownika katalogu C:\ProgramFiles, który może być przez niego kontrolowany, i uruchomiłem go.

Rysunek 2: Uruchomiona kopia komponentu Microsoft Network Monitor.

Wreszcie dla kompatybilności aplikacji, aplikacje z podniesionymi uprawnieniami współdzielą faktyczny stan ze środowiskiem standardowego użytkownika, którego złośliwa aplikacja może użyć do wpływania na zachowanie aplikacji z podniesionymi uprawnieniami. Najbardziej wyraźnym tego przykładem jest profil rejestru użytkownika, HKEY_CURRENT_USER (HKCU). Jest on współdzielony, ponieważ użytkownicy oczekują ustawień i rozszerzeń, które zarejestrowali jako standardowy użytkownik do pracy z aplikacjami z podniesionymi uprawnieniami. Złośliwe oprogramowanie może użyć rozszerzeń powłoki zarejestrowanych w HKCU, aby załadować je do aplikacji z uprawnieniami, które korzystają z wszelkich okien dialogowych przeglądania powłoki, takich jak File Open (Otwórz plik) oraz File Save (Zapisz plik). Inne rodzaje stanu są także współdzielone, najbardziej zauważalnie w obszarze nazw Base Named Object, gdzie aplikacje tworzą obiekty synchronizacji i współdzielonej pamięci. Złośliwe oprogramowanie może korzystać z tego współdzielenia, aby przywłaszczyć obiekt współdzielonej pamięci użyty przez aplikację z podniesionymi uprawnieniami i na przykład zagrozić aplikacji, a następnie systemowi.

Jeśli chodzi o Windows Integrity Mechanism, jego skuteczność jako bariery jest ograniczona przez wspomniane przeze mnie kwestie podnoszenia uprawnień, lecz to także ma ograniczenia ze względu na kompatybilność aplikacji. Po pierwsze, UIPI nie chroni aplikacji użytkownika standardowego przed narysowaniem na pulpicie czegoś, co mogłoby być użyte do oszukania użytkownika w celu interakcji z aplikacjami z podniesionymi uprawnieniami, które powodują przydzielenie praw administracyjnych złośliwemu oprogramowaniu. Nie ma także przepływu mechanizm kontroli integralności w całej sieci. Aplikacja standardowego użytkownika uruchomiona w koncie PA będzie miała dostęp do zasobów systemu w systemie zdalnym, na którym konto PA ma prawa administracyjne. Reakcja na te ograniczenia ma istotne konsekwencje dla zgodności aplikacji. Stwierdziwszy to, nadal szukamy sposobów poprawy bezpieczeństwa systemu, ulepszając na przykład tryb chroniony (Protected Mode) IE, a w tym samym czasie zajmujemy się kwestiami zgodności aplikacji i współpracujemy ściśle z projektantami aplikacji.

Jak dużą ochronę przed złośliwym oprogramowaniem zyskamy zatem, gdy uruchomimy konta PA w Windows Vista PA z włączoną kontrolą konta użytkownika? Po pierwsze, pamiętajmy, że kwestie te są problemem tylko wtedy, gdy złośliwe oprogramowanie dostanie się do systemu i zacznie działać. Windows ma wiele funkcji głębokiej obrony, łącznie z DEP (Data Execution Prevention – zapobieganie wykonywaniu danych), ASLR (Address Space Load Randomization – losowe przydzielanie przestrzeni adresowej), Protected Mode IE – tryb chroniony IE, filtr IE 8 SmartScreen oraz Windows Defender, które pomagają w ochronie przed dostaniem się do systemu złośliwego oprogramowania i jego działaniem.

W przypadku gdy złośliwemu oprogramowaniu jakoś uda się dostać do systemu, ponieważ jego autorzy (jak uprawnieni programiści) założyli, że użytkownicy działają z prawami administracyjnymi, większość złośliwego oprogramowania nie będzie prawidłowo działać. Samo to można uważać za korzyść dla bezpieczeństwa. Jednak złośliwe oprogramowanie, jakie dostało się do systemu i jest zaprojektowane do wykorzystywania okazji, może być w stanie uzyskać prawa administracyjne, gdy użytkownik po raz pierwszy podniesie uprawnienia – lecz złośliwe oprogramowanie nawet nie musi czekać na „prawdziwe” podniesienie uprawnień, ponieważ może doprowadzić do oszukania nawet najbardziej wrażliwych na bezpieczeństwo użytkowników. W moich prezentacjach UAC Internals oraz Windows Security Boundaries (demo w 1:03 minucie w rozmowach o granicach zabezpieczeń) pokazałem publicznie, jak złośliwe oprogramowanie może przejąć kontrolę nad procesem podnoszenia uprawnień. Trzeba jednak pamiętać, że, jeśli złośliwe oprogramowanie rzeczywiście zostanie uruchomione, może dokonać większości rzeczy, które chce zrobić, z samymi standardowymi prawami użytkownika, łącznie z taką samokonfiguracją, aby było uruchamiane przy każdym logowaniu użytkownika, kradnąc lub usuwając wszystkie jego dane, a nawet stając się częścią botnetu.

 Do początku strony

Co nowego jest w systemie Windows 7

Wspomniałem niektóre z działań w Windows 7, które mogą być teraz wykonywane przez standardowych użytkowników, lecz jak to wyjaśniono w blogu E7, we wpisie na temat UAC, uznaliśmy także, że można ułatwić obsługę z Windows nie poświęcając celów UAC. Wielu użytkowników narzeka na fakt, że sam Windows Vista często pyta o prawa administracyjne podczas wykonywania typowych operacji zarządzania systemem. Jest to w naszym najlepszym interesie, ponieważ jest to w interesie naszych klientów, aby Windows działał dobrze w środowiskach użytkownika standardowego. Jednak zgłoszenia podniesienia uprawnień nie uczą ani nie zachęcają nas do robienia tego, lecz tak naprawdę zmuszają użytkowników do klikania po raz drugi w okno dialogowe, którego ogromna ich większość nie czyta. Dlatego celem w Windows 7 stała się minimalizacja tych zgłoszeń przy domyślnej obsłudze Windows i umożliwienie użytkownikom, którzy działają jako administratorzy, kontrolę obsługi zgłoszeń.

Aby to osiągnąć, dokonaliśmy refaktoringu systemu, tak aby osoba ze standardowymi prawami użytkownika mogła wykonywać więcej zadań, i zredukowaliśmy liczbę zgłoszeń w kilku scenariuszach z wieloma zgłoszeniami (na przykład instalując kontrolę ActiveX w IE). Windows 7 wprowadza także dwa nowe tryby działania UAC, które można wybrać w nowym oknie dialogowym UAC (patrz rysunek 3). To okno dialogowe można otworzyć, przechodząc do Control Panel (Panel sterowania), klikając User Accounts (Konta użytkowników), jeszcze raz klikając User Accounts, a następnie klikając Change User Account Control Settings (Zmień ustawienia kontroli konta użytkownika). (Można także to uzyskać klikając łącze Change When Notifications Appear (Zmień, gdy pojawi się powiadomienie) w zgłoszeniu podniesienia uprawnień lub przechodząc przez Action Center – Centrum akcji).

Rysunek 3: Dwa nowe tryby działania UAC, które można wybrać w nowym oknie dialogowym konfiguracji UAC.

Domyślne ustawienie, pokazane na rysunku 3, jest jednym z nowych poziomów. Inaczej niż Always Notify (Zawsze powiadamiaj), które jest wyborem na górze suwaka i jest identyczne z domyślnym wyborem w Windows Vista, Windows 7 wyświetla domyślnie zgłoszenie użytkownikowi tylko wtedy, gdy plik wykonywalny spoza Windows prosi o podniesienie uprawnień; postępowanie dla podnoszenia uprawnień dla plików spoza Windows jest takie samo jak w Windows Vista.

Następna pozycja w dół suwaka to drugie nowe ustawienie, które ma taką samą etykietę, z wyjątkiem dodania „(don’t dim my desktop – nie wygaszaj mojego pulpitu)". Jedyna różnica między tym trybem a trybem domyślnym jest taka, że zgłoszenia pojawiają się na pulpicie użytkownika, a nie na bezpiecznym pulpicie. Ma to tę zaletę, że użytkownik może komunikować się z pulpitem, gdy zgłoszenie jest aktywne, lecz jak wspomniałem wcześniej, istnieje ryzyko, że dostępne oprogramowanie innej firmy nie będzie działać prawidłowo w oknie dialogowym zgłoszenia.

Wreszcie, dolne położenie suwaka całkowicie wyłącza technologie UAC, więc całe oprogramowanie działające w koncie PA jest uruchamiane z pełnymi prawami administracyjnymi, wirtualizacja systemu plików i rejestru jest wyłączona, a tryb chroniony IE nie jest aktywny. Ponieważ w tym trybie nie ma zgłoszeń, brak chronionego trybu IE jest poważną wadą tego trybu.

 Do początku strony

Automatyczne podnoszenie uprawnień

Powodem tego, że podnoszenie uprawnień (większości) plików wykonywanych Windows w dwóch środkowych ustawieniach nie ma wpływu na zgłoszenie, jest fakt, że system „automatycznie podnosi uprawnienia" wykonywalnych plików Windows. Po pierwsze, co w tym kontekście jest określone jako plik wykonywalny Windows? Odpowiedź zależy od kilku czynników, lecz dwie rzeczy muszą być utrzymane: musi być cyfrowo podpisany przez wydawcę Windows, co jest certyfikatem stosowanym do podpisywania całego kodu dołączonego do Windows (nie wystarczy podpisanie przez Microsoft, więc oprogramowanie Microsoft, które nie jest dostarczane z systemem Windows, nie jest włączone); oraz musi być umieszczone w jednym z niewielu „bezpiecznych” katalogów. Bezpieczny katalog to taki, który nie może być modyfikowany przez standardowych użytkowników i obejmuje %SystemRoot%\System32 (np. \Windows\System32) i większość z jego podkatalogów, %SystemRoot%\Ehome, a także kilka katalogów pod %ProgramFiles%, wśród nich Windows Defender i Windows Journal.

Również, zależnie od tego, czy plik wykonywany jest normalnym obiektem .exe, Mmc.exe lub COM, automatyczne podnoszenie uprawnień ma dodatkowe reguły. Pliki wykonywalne Windows (jak już zdefiniowano) z rozmaitych .exe podnoszą automatycznie uprawnienia, jeśli mają określoną właściwość autoElevate w swoim manifeście, w którym także aplikacje informują UAC, że chcą praw administracyjnych. Na rysunku 4 widać program użytkowy Sysinternals Sigcheckzrzucający manifest dla Menedżera zadań (Task Manager, Taskmgr.exe) za pomocą polecenia "sigcheck –m %systemroot%\system32\taskmgr.exe", które pokazuje, że Menedżer zadań został wybrany do automatycznego podniesienia uprawnień.

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

Prostą metodą znalezienia plików wykonywalnych z automatycznym podnoszeniem uprawnień w drzewie katalogów jest użycie programu użytkowego Sysinternals Strings, za pomocą poniższego polecenia:

strings –s *.exe | findstr /i autoelevate

Istnieje także zakodowana na stałe lista plików wykonywalnych Windows, które są traktowane jako pliki z automatycznym podnoszeniem uprawnień. Te wykonywalne pliki Windows są dostarczane do Windows 7 z zewnątrz i musi być możliwość uruchomienia ich w systemach niskiego poziomu, gdzie obecność właściwości autoexecute mogłaby spowodować błąd. Lista obejmuje Migwiz.exe, kreator migracji, Pkgmgr.exe, menedżer pakietów oraz Spinstall.exe czyli instalator Service Pack.

Konsola zarządzania (Microsoft Management Console, Mmc.exe) jest traktowana specjalnie, ponieważ udostępnia wiele przystawek zarządzania systemem, które są implementowane jako biblioteki DLL. Mmc.exe jest uruchamiana z wiersza poleceń, w którym jest podany plik .MSC z przystawką MMC do załadowania. Kiedy system Windows widzi Mmc.exe, pyta o prawa administracyjne, gdy to polecenie jest uruchamiane z konta PA, sprawdza, czy Mmc.exe jest plikiem wykonywalnym Windows, a następnie sprawdza plik .MSC. Aby spełnić warunki automatycznego podnoszenia uprawnień, plik .MSC musi spełniać kryteria plików wykonywalnych (podpisane przez Windows w bezpiecznej lokalizacji) i musi być wymieniony na wewnętrznej liście plików .MSC do podnoszenia uprawnień. Ta lista obejmuje praktycznie wszystkie pliki .MSC dostarczane z Windows.

Ostatecznie potrzebę posiadania praw administracyjnych przez obiekty COM można określić za pomocą wartości rejestru w ich kluczu rejestru, poprzez utworzenie podklucza o nazwie Elevation z wartością Enabled ustawioną na 1. Na rysunku 5pokazano klucz rejestru dla obiektu powłoki Copy/Move/Rename/Delete/Link Object, który jest stosowany przez Explorer, gdy użytkownik wykonuje operację w systemie plików w lokalizacji, do której jego konto nie ma uprawnień.

Rysunek 5: Klucz rejestru powłoki.

Aby obiekt COM miał automatycznie podnoszone uprawnienia, musi również być plikiem wykonywalnym Windows i jego egzemplarz musi być utworzony przez plik wykonywalny Windows. (Jednak plik wykonywalny tworzący egzemplarz nie musi być zaznaczony do automatycznego podnoszenia uprawnień). Kiedy na przykład użyjemy Eksploratora do utworzenia katalogu w %ProgramFiles% z konta PA, operacja będzie miała automatycznie podniesione uprawnienia, ponieważ obiekt COM wymaga podniesienia uprawnień, zaś DLL obiektu oraz Eksplorator są wykonywalnymi plikami Windows.

 Do początku strony

Cele automatycznego podnoszenia uprawnień i kontroli konta użytkownika

Co więc kryje się za wszystkimi specjalnymi regułami automatycznego podnoszenia uprawnień? Wskazówką dokonywania wyboru, co ma mieć automatycznie podnoszone uprawnienia, a co nie, jest pytanie: „Czy projektantowi aplikacji może przez nieuwagę lub wprost zależeć na prawach administracyjnych poprzez wykorzystanie automatycznego podnoszenia uprawnień?". Ponieważ Cmd.exe może być użyte do wykonywania skryptów wsadowych za pośrednictwem argumentów wiersza polecenia, a przeciętni użytkownicy nie mają potrzeby uruchamiania wiersza poleceń z podniesionymi uprawnieniami (większość nie wie, co to jest wiesz poleceń), nie został przedstawiony do automatycznego podniesienia uprawnień. Podobnie Rundll32.exe, plik wykonywalny, który udostępnia wtyczki panelu sterowania, nie ma automatycznie podnoszonych uprawnień w ostatniej wersji Windows 7, ponieważ to podniesienie nie jest wymagane dla żadnego z typowych zadań administracyjnych. Gdyby Rundll32.exe miał automatycznie podnoszone uprawnienia, jego zdolność do udostępniania dowolnych bibliotek DLL za pośrednictwem wiersza poleceń mogłaby spowodować, że projektant potrzebowałby praw administratora nie zdając sobie z tego sprawy.

Użytkownicy często prosili o zapewnienie w systemie Windows możliwości dodania dowolnych aplikacji do listy automatycznego podnoszenia uprawnień, począwszy od wersji beta Windows Vista. Powszechnie przytaczanym powodem było to, że niektóre aplikacje innych firm, często przez nich używane, zmuszają ich do ciągłego klikania zgłoszenia podniesienia uprawnień w ramach ich codziennych obowiązków. Windows 7, tak jak Windows Vista, nie daje takiej możliwości. Rozumiemy zdenerwowanie i być może istnieje uzasadniony powód, dla którego te aplikacje nie mogą być uruchamiane bez praw administracyjnych, lecz ryzyko jest zbyt wysokie, aby programiści pominęli ustawienie swojego kodu z prawami standardowego użytkownika. Nawet gdy lista aplikacji z automatycznym podnoszeniem uprawnień jest dostępna tylko dla administratorów, programiści mogą po prostu zmienić program instalacyjny swojej aplikacji, który wymaga jednorazowego podniesienia uprawnień, aby dodać swoje aplikacje do listy. Zamiast tego wybraliśmy inwestowanie w edukację i ścisłą współpracę z programistami aplikacji, aby zapewnić, że ich programy będą prawidłowo działać jako użytkownik standardowy.

Kilka osób zauważyło, że oprogramowanie innych firm uruchomione w koncie PA z prawami użytkownika standardowego może korzystać z automatycznego podniesienia uprawnień, aby uzyskać prawa administracyjne. Na przykład oprogramowanie może użyć API WriteProcessMemory, aby wprowadzić kod do Eksploratora, oraz API CreateRemoteThread, aby wykonać ten kod, co jest nazywane techniką wstrzykiwania DLL. Ponieważ kod jest wykonywany w Eksploratorze, który jest plikiem wykonywalnym Windows, może wykorzystać obiekty COM z automatycznym podnoszeniem uprawnień, takie jak Copy/Move/Rename/Delete/Link Object, do modyfikacji kluczy lub katalogów rejestru systemowego i nadać oprogramowaniu prawa administracyjne. Chociaż to prawda, te kroki wymagają umyślnego zamiaru, nie są trywialne, i dlatego nie są czymś, co według nas wybiorą uprawnieni programiści zamiast ustawić swoje oprogramowanie do uruchamiania z prawami standardowego użytkownika. W rzeczywistości nie zalecamy, aby jakikolwiek projektant aplikacji uzależniał zachowanie w systemie od podnoszenia uprawnień oraz zalecamy, aby projektanci testujący swoje oprogramowanie uruchamiali je w trybie standardowego użytkownika.

Dalsza obserwacja mówi, że złośliwe oprogramowanie może uzyskać prawa administracyjne za pomocą tej samej techniki. Tutaj także jest to prawda, ale jak wskazałem wcześniej, złośliwe oprogramowanie może także zagrozić systemowi poprzez zgłaszane podnoszenie uprawnień. Z perspektywy złośliwego oprogramowania, domyślny tryb Windows 7 nie jest bardziej ani mniej bezpieczny niż tryb Always Notify („tryb Vista”), a złośliwe oprogramowanie, które przejmuje prawa administracyjne będzie je nadal łamać, gdy będzie uruchomione w domyślnym trybie Windows 7.

 Do początku strony

Podsumowanie

Reasumując, UAC jest zestawem technologii, które mają jeden ogólny cel: umożliwić użytkownikom działanie w trybie standardowego użytkownika. Cała kombinacja zmian w Windows, które pozwalają standardowym użytkownikom wykonywać więcej operacji wymagających wcześniej praw administracyjnych, wirtualizacja pliku i rejestru oraz zgłoszenia, działają wspólnie, aby osiągnąć ten cel. Ostateczny wynik jest taki, że w domyślnym trybie UAC w Windows 7 UAC obsługa użytkownika PA jest prostsza dzięki zmniejszeniu liczby zgłoszeń, pozwala im na kontrolowanie, jakie legalne oprogramowanie może zmieniać ich system, a przy tym nadal osiąga cele UAC, pozwalające uruchamiać oprogramowanie bez uprawnień administracyjnych i dalsze przesunięcie ekosystemu oprogramowania w kierunku pisania programów ze standardowymi prawami użytkownika.

O autorze

Mark Russinovich zajmuje się kwestiami technicznymi w dziale platform i usług firmy Microsoft.

 Do początku strony