Omijanie UIPI

Dawno nie pisalem o wnetrznosciach systemu, wiec pora to nadrobic i zejsc kawalek pod powierzchnie pulpitu.

Zacznijmy od podstaw. System Windows jak sama nazwa wskazuje ma cos wspólnego z oknami. Typowy "klikacz" pare z nich widzi nawet na ekranie, choc w wielu przypadkach nie ma swiadomosci, ze niektóre rzeczy sa oknami. Poza oknami widocznymi istnieja okna niewidoczne, przy czym niewidoczne moga byc z kilku powodów: albo sa poza obszarem ekranu albo sa ukryte, albo sa w innej sesji itp. Tych ukrytych potrafi byc naprawde duzo i póki nie ma sie wobec nich zadnych specjalnych zamiarów – ich ukrycie naprawde powinno byc traktowane jako sposób umilenia pracy. Pewnych rzeczy lepiej nie widziec, bo zazwyczaj nie ma takiej potrzeby.

Moze niektórych to zaskoczy, ale okna ze soba rozmawiaja. Widoczne i niewidoczne. Rozmawiaja przy pomocy komunikatów. Praktycznie kazde okno moze wyslac komunikat i kazde inne okno moze taki komunikat otrzymac. Okno na komunikat zazwyczaj reaguje. Na przyklad dowolnemu oknu mozna poslac komunikat WM_CLOSE (nazwa WM_costam to dosc pewny znak, ze mamy do czynienia z komunikatem) i okno takie odbierze to polecenie i zareaguje. Zazwyczaj reakcja bedzie zamkniecie okna, ale to od okna tak naprawde zalezy co zrobi. Równie dobrze, okno w tej sytuacji moze nakrzyczec na uzytkownika, ze sobie nie zyczy, zeby mu posylac takie rzeczy i powiekszy sie na caly ekran. Oczywiscie, wszystkim zyje sie latwiej, gdy okna robia to co powinny.

Poniewaz jedno okno moze wplywac na inne – wprowadzono pojecie sesji. Oczywiscie zrobiono to nie tylko z powodu komunikatów. W kazdym razie, sesji w systemie moze byc wiele, ale w normalnych warunkach, komunikaty przesylane sa tylko w obrebie kazdej z nich. Dzieki temu mozna odseparowac okna tak, zeby okno z sesji X nie moglo "rozmawiac" z oknem z sesji Y. Czasem warto...

Bardzo szybko okazalo sie jednak, ze nawet w ramach jednej sesji, na jednym ekranie u jednego uzytkownika, dobrze byloby jednak zakazac oknom pewnych form komunikacji. W sumie to zaden problem, do okna wiersza polecen poslac serie komunikatów odpowiadajacych nacisnieciu i puszczeniu (to dwa oddzielne komunikaty!) klawiszy F, O, R, M, A, T, VK_RETURN. Zazwyczaj komunikacja jest bardzo wskazana, ale czasem moze jednak nie powinno byc to mozliwe. Na przyklad niekoniecznie "zwykle" aplikacje powinny wysylac cos do okien utworzonych przez procesy uruchomione na prawach administratora. Jak rozróznic takie okna? Windows Vista i nowsze ma do tego bardzo dobry mechanizm: Integrity Levels. To naprawde dziala i w przypadku okien daje sie swietnie zastosowac. Dzieki temu, okna procesów na róznych poziomach zaufania sa od siebie odseparowane a mechanizm ten nazywa sie UIPI czyli User Interface Privilege Isolation. Siegajac glebiej, stwierdzic mozna, ze niektóre komunikaty sa przepuszczane, ale wszedzie tam, gdzie mowa o separacji ze wzgledu na poziom zabezpieczen – mechanizm sprawdza sie bardzo dobrze.

UIPI jest swietnym pomyslem, ale okazuje sie, ze mozna izolacje taka ominac. Wymagania nie sa takie proste do spelnienia, zwlaszcza w przypadku zlosliwego kodu. Jezeli aplikacja ma ominac UIPI, to musi spelnic nastepujace warunki:

  • Manifest aplikacji musi zawierac flage uiAccess=true
  • Aplikacja musi byc uruchmiona z "zaufanego" miejsca na dysku, takiego jak (%ProgramFiles%) C:\Program Files lub %windir% (C:\Windows)
  • Aplikacja musi byc podpisana cyfrowo przez kogos zaufanego

Jak widac, nie jest tak prosto, ale sie da... UIPI mozna ominac. Poza wykorzystaniem opisanych powyzej mechanizmów, pozostaje zawsze ChangeWindowMessageFilter. Funkcja ta pozwala na celowe tworzenie kanalów dla komunikatów, dzieki którym komunikat dotrze do okna na wyzszym poziomie integralnosci. Z Internet Explorer moze sie to nie udac (i bardzo dobrze!), ale inne aplikacje daja sie latwo "uprzywilejowac".

Podsumowujac, zauwazyc mozna, ze caly ten mechanizm okien i komunikatów, korzeniami siega do Windows 1.0 i po prostu brakuje w nim mechanizmów ACL. Kiedys ich nie bylo i nie ma dalej, mimo ze systemy sie rozwinely. Troche to archaiczna architektura, ale polatana przy pomocy Integrity Levels i izolacji sesji sprawdza sie na razie zupelnie dobrze. Nie chcialbym wrózyc przyszlosci w zadnym obszarze IT, ale mozna chyba zgadywac, ze kiedys, w dalekiej przyszlosci, ACL dla okien i komunikatów zaczna sie pojawiac. Pytanie co na to programisci, bo skoro na razie nie wszyscy sa w stanie zrozumiec, ze istnieja uzytkownicy bez praw administratora, to gdzie im do tak powaznych zmian.

Autor: Grzegorz Tworek [MVP]