Zrozumieć User Account Control

Windows Vista różni się, w zasadniczym stopniu, od poprzednich wersji systemów z tej rodziny, w dziedzinie obsługi kont użytkowników. Co może sprawiać problemy zarówno użytkownikom, jak i programistom. Wprowadzony mechanizm User Account Control jest czymś, co trzeba pojąć, by móc tworzyć poprawnie działające aplikacje pod Windows Vista czy Windows Server 2008.

     1 Czasy zamierzchłe
          1.1 NTFS a konta użytkowników
          1.2 Rejestr a konta użytkowników
     2 Co nowego w Windows Vista w dziedzinie kont użytkowników?
          2.3 Podniesienie uprawnień i trzy typy kont
          2.4 Consent UI i Credential UI
          2.5 Zalety mechanizmu UAC
          2.6 UAC i inne rozwiązania
          2.7 Bezpieczny pulpit
     3 Czy UAC będzie miał wpływ na twoją aplikację?
          3.8 Wirtualizacja Rejestru i folderów systemowych
     4 Współpraca z UAC
          4.9 Działaj!
          4.10 Stwórz oddzielne elementy interfejsu dla użytkowników standardowych i administratorów
          4.11 Pozwól użytkownikom podnieść uprawnienia w razie odmowy dostępu
          4.12 Aplikacje tylko dla administratorów mogą być uruchamiane od razu z żądaniem podniesienia uprawnień
     5 Współpraca z UAC od strony programisty
          5.13 Tworzenie manifestu
          5.14 Dodawanie manifestu do aplikacji C/C++ w Visual Studio 2005 krok po kroku
               5.14.1 Dodawanie manifestu do programów w kodzie zarządzanym (np. C#)
     6 Podsumowanie
     7 Dodatkowe źródła informacji

Czasy zamierzchłe

Dotychczas w systemie Windows domyślnie tworzone konta użytkowników po procesie instalacji (na przykład w Windows XP dzięki usłudze OOBE - Out Of Box Experience) posiadały uprawnienia administratora systemu. Tak samo praktycznie działało to w Windows z linii 9x, gdzie nie istniał podział na konta administracyjne i ograniczone. Dygresja: nazwa ograniczone sugeruje pewne upośledzenie, dlatego ja będę stosował nazwę "konto zwykłego użytkownika" lub "konto standardowe".

Konto zwykłego użytkownika, w odróżnieniu od konta administracyjnego, nie posiada praw do wielu operacji (oczywiście prawa dostępne dla różnych kont czy grup można zmieniać korzystając z odpowiedniej przystawki MMC), takich jak na przykład zmiana adresu IP karty sieciowej, zmiana strefy czasowej, czy - rzecz jasna - zatrzymywania i uruchamiania usług.

NTFS a konta użytkowników

W systemach z rodziny Windows NT dostępny jest także system plików NTFS - i jako nowocześniejszy od FAT32 jest zalecany przez producenta (który zmusza do niego różnorodnymi "sztuczkami"), który jednak posiada pewną niezbędną do zrozumienia własność, jaką są listy kontroli dostępu (ACL), kontrolujące czy dany użytkownik lub grupa użytkowników może posiadać prawa dostępu do różnorodnych zasobów na dysku. I połączenie list ACL w systemie plików NTFS z kontami użytkowników jest największą bolączką aplikacji niekompatybilnych z systemem Windows Vista.

Dotychczas, jako użytkownik o prawach administratora, gdyż takie uprawnienia były nadawane użytkownikom w procesie instalacji systemu, użytkownik miał możliwość dostępu - a raczej: zarówno odczytu, jak i zapisu - do wszystkich katalogów na wszystkich dyskach twardych. Jednak użytkownik standardowy takiego zestawu możliwości już nie posiada - na przykład nie może zapisać czegokolwiek do podkatalogów systemowego folderu \Program Files czy katalogu samego systemu operacyjnego (%SYSTEMROOT% - zwykle C:\Windows). Co daje to użytkownikowi? Dzięki temu żaden proces nie uruchamiany na koncie użytkownika z prawami administracyjnymi nie będzie mógł nam zmodyfikować systemowych plików (na przykład choćby pliku hosts, by spowodować działania mające na celu pozyskanie danych użytkownika - tzw. phishing).

Rejestr a konta użytkowników

Systemowy Rejestr także posiada mechanizmy list kontroli dostępu. Przykładowo klucz HKEY_LOCAL_MACHINE ma uprawnienia zapisu tylko dla użytkowników o prawach administratora. To ma wielki wpływ na nasze aplikacje, gdy nie pracują one na koncie z takimi uprawnieniami.

Co nowego w Windows Vista w dziedzinie kont użytkowników?

Tutaj została wprowadzona pewna istotna zmiana - obecnie nawet posiadając uprawnienia administratora, użytkownik domyślnie pracuje z uprawnieniami niższymi, a elewacja (podwyższenie) uprawnień jest przeprowadzana na wyraźne żądanie, do czego służy właśnie mechanizm User Account Control, czyli UAC.

Wprowadzono także drugą zmianę, która jest bardzo istotna - standardowo nie podaje się przy instalacji hasła konta wbudowanego o nazwie "Administrator", a konto to jest wyłączone, czym zamknięto często stosowaną metodę ataków.

Podniesienie uprawnień i trzy typy kont

W gruncie rzeczy zatem dysponujemy trzema rodzajami kont użytkowników: kontami standardowymi, zwykłego użytkownika, kontami administracyjnymi na standardowych prawach oraz kontami administracyjnymi z podniesionymi uprawnieniami. (warto dodać, że wbudowane konto "Administrator" nie wymaga podnoszenia uprawnień).

Użytkownicy standardowi sami nie mogą oczywiście podnieść swoich uprawnień, ale mogą o to "poprosić" administratora, korzystając z mechanizmu Credential UI.

Consent UI i Credential UI

Mechanizm UAC posiada dwa swoje okna dialogowe, do których dokumentacja MSDN odwołuje się jako do Consent UI i Credential UI, wspomniane w poprzednim akapicie.

Consent UI to okno dla kont administracyjnych, które pozwala na podniesienie uprawnień:

Z kolei Credential UI pozwala zwykłemu użytkownikowi uwierzytelnić się by skorzystać z uprawnień administracyjnych:

Zalety mechanizmu UAC

* zmniejszenie potencjalnego wachlarza ataków złośliwego oprogramowania * lepsza kontrola nad tym, co jest instalowane w systemie * możliwość podniesienia uprawnień jednorazowo i tylko w razie potrzeby

UAC i inne rozwiązania

Dotychczas rzeczywiście istniało pewne rozwiązanie, które może UAC niejako zastąpić - runas.exe pozwalał uruchamiać w Windows NT dany proces jako inny użytkownik. Wady tego rozwiązania są jednak oczywiste - UAC pozwala nam wykonać tylko konkretną akcję jako użytkownik, do tego działa "automatycznie".

W systemach uniksowych z kolei istnieje już od długiego czasu mechanizm sudo, który działa w podobny sposób, ale umożliwia nieco bardziej elastyczną konfigurację, jednak nie dysponuje inną możliwością UAC, o której powiem zaraz - tzw. bezpiecznego pulpitu.

Bezpieczny pulpit

Aplet UAC, tak, jak i na przykład aplikacja Windows CardSpace, w momencie uruchamiania przyciemnia cały ekran. Wizualnie wygląda to tak, jakby system chciał użytkownikowi "zwrócić uwagę" na okno dialogowe. Różnica ujawnia się wtedy, gdy spróbujemy kliknąć cokolwiek poza oknem - nie jest to możliwe. Pulpit cały został zablokowany. Oczywiście działa to w obydwie strony - żadna zewnętrzna aplikacja nie może przejąć uchwytu okna Consent UI i "kliknąć" "Kontynuuj" zamiast użytkownika.

Czy UAC będzie miał wpływ na twoją aplikację?

Aplikacje, które działają dobrze pod kontem zwykłego użytkownika pod Windows XP, tak samo będą sobie radzić pod jego następcą.

Aplikacje działające dobrze nie powinny od użytkownika wymagać uprawnień administracyjnych, gdy nic takiego nie potrzebują. Do problematycznych aplikacji zalicza się te, które na przykład:

• dokonują zmian w kluczach rejestru HKEY_LOCAL_MACHINE czy HKEY_CLASSES_ROOT
• modyfikują pliki systemowe
• modyfikują pliki w swoim własnym katalogu w folderze \Program Files
• instalują nowe usługi czy kontrolki ActiveX
• zmieniają ustawienia odnoszące się do całości systemu

Do sprawdzenia czy aplikacja będzie działać na koncie użytkownika można - oprócz wykonania ręcznego audytu - użyć narzędzia "Standard User Analyzer" z pakietu Microsoft Application Compatibility Toolkit 5.0.

Wirtualizacja Rejestru i folderów systemowych

Jako, iż wiele aplikacji jest dostosowanych do zachowań, które w Windows Vista nie są dopuszczalne, powstał mechanizm wirtualizacji Rejestru oraz niektórych folderów systemowych.

W momencie gdy używamy UAC oraz konta o uprawnieniach administracyjnych lub standardowych, aplikacja może zapisywać do Rejestru czy niektórych folderów w rodzaju \Program Files czy %SYSTEMROOT%, jednak w rzeczywistości dane te są przechowywane w specjalnym folderze w %LOCALAPPDATA%\VirtualStore (w przypadku rejestru: HKEY_CURRENT_USER\Classes\VirtualStore) i system automatycznie dostosowuje tak wywołania funkcji API, ze dla programu uruchamianego Rejestr czy wspomniane foldery wyglądają, jakby faktycznie były przezeń zmodyfikowane. Dla innych aplikacji oczywiście nie są.

Wirtualizacja dostępna jest tylko dla 32-bitowych aplikacji (z wyjątkami takimi jak aplikacje nieinteraktywne) i pozwala zapisywać do lokalizacji, do których normalnie brak dostępu. Tworząc jednak aplikacje kompatybilne z systemem Windows Vista należy ustawić odpowiedni requestedExecutionLevel w manifeście (patrz dalej) i odpowiednio oprogramować aplikację.

Współpraca z UAC

Microsoft opracował szereg zaleceń, które powinny spełniać aplikacje zgodne z systemem Windows Vista, niektóre z nich odnoszą się do współpracy z UAC.

Działaj!

Aplikacje powinny działać na kontach zwykłych użytkowników - nie jest pożądana sytuacja, gdy pojawia się komunikat o braku odpowiednich uprawnień. Przykładowo tak było to w Windows XP przy próbie obejrzenia ustawień strefy czasowej.

Stwórz oddzielne elementy interfejsu dla użytkowników standardowych i administratorów

Informacje tylko do odczytu powinny być widoczne dla każdego użytkownika, jednak te operacje, które wymagają uprawnień większych, powinny być dokładnie oznaczone specjalną ikoną czterokolorowej tarczy na przycisku.

Przykład:

Pozwól użytkownikom podnieść uprawnienia w razie odmowy dostępu

Jeżeli użytkownicy mogą wykonać pewne operacje bez podniesienia uprawnień - pozwól im, a w razie ewentualnej porażki możesz pokazać odpowiednie okno dialogowe.

Przykład:

Aplikacje tylko dla administratorów mogą być uruchamiane od razu z żądaniem podniesienia uprawnień

To tyczy się np. programów administracyjnych (do zarządzania serwerem) czy programów instalacyjnych. Programy tego typu zostaną oznaczone specjalną ikoną, a dialog UAC pojawi się przy próbie ich uruchomienia.

Uwaga: Windows Vista domyślnie wielu programom instalacyjnym (opierając się na ich nazwie, np. install.exe czy setup.exe) przypisuje takie możliwości.

Współpraca z UAC od strony programisty

Uwaga: W przyszłych wersjach systemu Windows jedyną możliwością uruchamiania aplikacji z podwyższonymi uprawnieniami będzie fakt posiadania przez aplikację odpowiedniego (podpisanego!) manifestu określającego potrzebne uprawnienia.

Manifesty aplikacji nie są niczym nowym w Windows Vista - dotychczas używano już ich w Windows XP. W Windows Vista dodano jednak nowy element, dzięki któremu można określić wymagany poziom uprawnień dla aplikacji.

Wygląda on przykładowo tak:

<requestedExecutionLevel level="requireAdministrator" uiAccess="false" />

Dostępne wartości dla atrybutu level to:

• requireAdministrator - aplikacja jest uruchamiana od razu w stanie podwyższonych uprawnień
• highestAvaliable - aplikacja jest uruchamiana z maksymalnymi prawami dostępnymi dla danego użytkownika
• asInvoker - aplikacja działa z takimi uprawnieniami, z jakimi została uruchomiona

Atrybut uiAccess odpowiada za pewne zachowania dotyczące aplikacji - wartość false powinna być stosowana najczęściej, wartość true pozwala aplikacji wysyłać zdarzenia do okien aplikacji o wyższych uprawnieniach. Aby uruchomić aplikację z uiAccess ustawionym na true, musi być ta aplikacja podpisana cyfrowo z użyciem mechanizmu Authenticode.

Tworzenie manifestu

Aby określić wymagany poziom uprawnień w aplikacji, należy najpierw stworzyć odpowiedni plik manifestu - powinien on mieć taką nazwę jak plik wykonywalny, z rozszerzeniem .manifest.

Na przykład może on wyglądać tak:

<!-- Aplikacja: IsUserAdmin.exe 
Manifest: IsUserAdmin.exe.manifest -->
<?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="IsUserAdmin"
     type="win32"/> 
  <description>Opis aplikacji</description> 
  <!-- Wymagania odpowiedzialne za bezpieczeństwo. -->
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
    <security>
      <requestedPrivileges>
        <requestedExecutionLevel
          level="requireAdministrator"
          uiAccess="false"/>
        </requestedPrivileges>
       </security>
  </trustInfo>
</assembly>

Taki plik manifestu należy dołączyć do zasobów aplikacji. W pliku .rc powinny się znaleźć przykładowo takie linie:

#define MANIFEST_RESOURCE_ID 1
MANIFEST_RESOURCE_ID RT_MANIFEST "IsUserAdmin.exe.manifest"

Jednak dotyczy to tylko i wyłącznie aplikacji tylko dla Windows Vista. Aplikacje, które mają pracować także w Windows XP, niestety należy nieco zmodyfikować manifest. Jest to spowodowane, że aplikacja dodająca manifesty, mt.exe z pakietu Visual Studio 2005, posiada błąd uniemożliwiający użycie drugiej przestrzeni nazw w pliku XML. Można to obejść stosując taką konstrukcję pliku:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
   <ms_asmv2:trustInfo xmlns:ms_asmv2="urn:schemas-microsoft- 
     com:asm.v2">
      <ms_asmv2:security>
         <ms_asmv2:requestedPrivileges>
            <ms_asmv2:requestedExecutionLevel level="asInvoker">
            </ms_asmv2:requestedExecutionLevel>
         </ms_asmv2:requestedPrivileges>
      </ms_asmv2:security>
   </ms_asmv2:trustInfo>
</assembly>

Dodawanie manifestu do aplikacji C/C++ w Visual Studio 2005 krok po kroku

1. Stwórz plik manifestu (np. w edytorze tekstowym) 2. Otwórz projekt 3. W menu Project wybierz Properties 4. W Properties, wybierz Manifest Tool, a następnie Input and Output. 5. Dodaj nazwę twojego pliku manifestu do sekcji Additional manifest files. 6. Przebuduj aplikację

Dodawanie manifestu do programów w kodzie zarządzanym (np. C#)

Visual Studio 2005 nie dysponuje taką opcją i należy użyć programu mt.exe.

Przykładowa składnia:
mt.exe –manifest <plik manifestu> –outputresource:<nazwa pliku wykonywalnego aplikacji>;#1.

Podsumowanie

User Account Control jest zupełnie nowym - i całe szczęście znacznie lepszym - podejściem do polityki kont użytkowników w systemach Windows NT. Niestety nowe technologie mogą sprawiać problemy programistom - oraz użytkownikom - przyzwyczajonym do dotychczasowej konwencji (zwłaszcza tej z epoki Windows 98: każdy jest administratorem), jednak z drugiej strony mogą znacznie ograniczyć ataki złośliwego oprogramowania oraz raz na zawsze pogrzebać mit Windows jako niebezpiecznego systemu "z założenia".

Niestety, wielu użytkowników, zdenerwowanych niekompatybilnością UAC i aplikacji oraz zbytnim - zdaniem większości - ograniczeniem (zbyt wiele operacji wymagających podwyższenia uprawnień) kieruje się ku wyłączeniu tej opcji, co nie rokuje zbyt dobrze na przyszłość.

Dodatkowe źródła informacji

* Windows Vista Application Development Requirements for User Account Control Compatibility * Dostosowanie interfejsu użytkownika do UAC * Tworzenie i włączanie pliku manifestu * Designing UAC Applications for Windows Vista * Windows Vista Application Development Requirements for User Account Control (UAC)

<font size="1">Przedstawione zrzuty ekranu pochodzą z Windows Server 2008 beta 3.</span>