Kategoria: security

UAC vs RunAs

w UAC dla w7 wprowadzono kilka zmian, które powodują, że na prawdę jest bardziej przyjazny [czyt. mniej wqrzający] – wyświetla dużo mniej komunikatów, dzięki czemu da się z nim lepiej żyć. osobiście, na swoim systemie i tak nie przekonałem się do tego mechanizmu, ale wynika to ze specyfiki tego, co na nim robię. na komputerze domowym, na którym pracuje end-user [ (; ] UAC jest włączony [Vista] i przy “normalnej” pracy fatycznie nie jest zbyt częstym gościem na ekranie.

UAC vs Run As

od zarania dziejów mam sporo pretensji do Microsoft o kilka decyzji – imho kluczowych, dotyczących kilku mechanizmów, które mogły być wprowadzone wraz wersją w2k – kiedy wprowadzane były tak drastyczne zmiany w całej koncepcji systemu. jedną z takich decyzji jest to, iż pierwszy zakładany użytkownik standardowo dodawany jest do grupy administratorów. pomimo wielkiego halo wokół bezpieczeństwa, zmiany myślenia przez emes i tak dalej… nie zmieniło się to w Vista [gdzie znów była szansa to zmienić] ani nie zmieni się to w w7. drogi były [co najmniej] dwie:

• pierwszy użytkownik jest zwykłym userem, interfejs powinien być zmodyfikowany tak, aby tak gdzie dziś pojawia się “run as administrator” był faktycznie tym, co znaczy – linkiem do ‘run as’ z parametrem aplikacji. dzięki temu każdy użytkownik byłby standardowo wyizolowany, a niezbędne aplikacje uruchamiałyby się we własnym środowisku z maksymalnymi uprawnieniami dla komputera lokalnego
• drugim scenariuszem jest wprowadzenie User Account Control. pokrótce czym jest UAC: mechanizm ten dodaje w całym systemie dodatkowy poziom bezpieczeństwa tzw. “integrity level” – zarówno dla plików, kluczy rejestrów czy procesów. dzięki temu dodawany jest dodatkowy poziom zabezpieczenia – poza autoryzacją niezbędny jest odpowiedni poziom integralności. pomimo, że poziomów takich jest więcej, wykorzystywane są 3 podstawowe – low,midim,high. System – pliki i procesy działają w “high”, użytkownik w “mid” a część aplikacji [np. przeglądarka w trybie IESC] w “low”. dzięki prostej zasadzie “nie masz praw do kogoś nadrzędnego” użytkownik – pomimo, że ma odpowiednie uprawnienia bo należy do grupy administratorów [a co za tym idzie – aplikacje z których korzysta], nie ma możliwości interakcji bezpośrednio z procesami/plikami systemowymi. jeśli proces próbuje się do nich dostać – pojawia się komunikat UAC z prośbą o autoryzację.

to tak w dużym skrócie, bo artów na temat UAC jest całkiem sporo – chociaż jeszcze kilka kwestii technicznych będę próbował poruszyć. pozostaje pytanie – które rozwiązanie jest lepsze, i dla czego emes zdecydował się na UAC?

Zalety i Wady RunAs

podstawową zaletą jest to, że nie wymagałoby to ingerencji w architekturę systemu – wykorzystanie tego mechanizmu sprowadzałoby się do dobrego zaprojektowania interfejsu [np. dodania możliwości zapamiętywania hasła, wygodnego zarządzania które aplikacje można tak uruchomić etc]. drugą zaletą – bardzo istotną ze względu na ogólne bezpieczeństwo jest fakt, że użytkownicy byliby realnie zmuszeni do wpisania jakiegoś hasła. z jednej strony mało wygodne, z drugiej strony dzięki temu każdy realnie by odczuł, że nie powinien czegoś robić, i musi wpisać jakieś hasło, a więc jest to faktycznie “coś niebezpiecznego”.

Wadą takiego rozwiązania jest trochę skomplikowania życia użytkownikowi – np. podczas instalacji systemu jest proszony o wprowadzenie hasła, a potem o założenie jeszcze jednego użytkownika. to jednak kwestia edukacji, odpowiedniej informacji i propagandy – która imho w przypadq UAC jest dużo trudniejsza i jak się okazuje – stała się jednym z bardziej znaczących gwoździ w trumnie dogorywającej “vista”.
jak się jednak okazuje poważniejszym problemem były same aplikacje. niestety liczna rzesza developerów nie dba o to dla kogo pisze aplikacje i nie jest świadoma faktu, iż od dawien dawna z komputera korzysta wielu userów, czy że system wprowadza pewne ograniczenia ze względu na bezpieczeństwo samego siebie – jak np. zakaz zapisywania w katalogu systemowym czy w program files. wiele aplikacji po prostu nie chce działać “na drugim” koncie. problemem w przeważającej mierze jest konieczność powtórnego uwierzytelnienia, działanie na innym tokenie, a w przypadq aplikacji np. wymagającej uprawnień w domenie, powstaje problem przekazania tokena zalogowanego usera. w końcu ‘run as’ to uruchomienie równoległej sesji, de facto zalogowanie się na innego użytkownika z innymi uprawnieniami – w tym przypadq, administratora lokalnego. tego aplikacje przeważnie nie przeżywają. żeby dobić ten pomysł pozostaje jeszcze fakt, iż podczas wykonywania ‘run as’ nie jest to dokładnie to samo, co zalogowanie się obok – nie jest ładowany/generowany pełny profil użytkownika, w kontekście którego uruchomiona zostanie aplikacja, i tego również część aplikacji nie przeżywa.

Zalety i Wady UAC

podstawową wadą UAC jest jego mała skuteczność – UAC wyświetla krótkie pytanie tak/nie i w zasadzie obserwując userów i rozmawiając z nimi – większość kieruje się zasadą “pozbądź się tego przerażającego okienka z pytaniem jak najszybciej” – co ono oznacza, o co pytało, o czym informowało? mało kogo obchodzi. użytkownicy i tak będą zatwierdzać “byle szybciej zniknęło”. jaki to daje poziom bezpieczeństwa?

pozostawiając jednak dylematy psychologiczne osobom, które się tym zajmują i prowadzą na pewno jakieś statystyki [których niestety nie znam – mogę tylko oceniać to, co sam obserwuję], warto się zastanowić nad potęgą jaką od strony technicznej, czyli przynajmniej teoretycznie, daje UAC.
podstawową działania mechanizmu jest przyznanie użytkownikowi dwóch tokenów – jego własnego, oraz administracyjnego. oczywiście dzieje się tak jeśli:

• użytkownik należy do grupy administratorów
• jest włączony UAC

dzięki temu user może pracować w poziomie integracyjnym “mid”, gdzie wszystko spokojnie działa i nie może nic popsuć w systemie, który “jest piętro wyżej”. jeśli natomiast uruchamia się coś, co w system musi zaingerować – np. źle napisana aplikacja, która próbuje coś pisać w katalogu systemowym, rejestruje jakieś biblioteki etc – wyświetla się okno z prośbą o świadome potwierdzenie, że aplikacja ta ma do tego prawo. po wyrażeniu zgody, przekazywany jest aplikacji token administracyjny, dzięki któremu może uruchomić się na wyższym poziomie integracyjnym. dzięki temu obchodzi się problem podwójnego uwierzytelnienia, ponieważ aplikacja de facto będzie mieć uprawnienia użytkownika ORAZ uprawnienia administratora lokalnego. do tego nie będzie generowany dodatkowy profil, nie będzie dodatkowego logowania w systemie.

aby zabezpieczyć się przed takimi aplikacjami, mechanizm wprowadza dodatkowe zabezpieczenie, które jest częścią UAC – wirtualizacja kluczy rejestru oraz aplikacji. jeśli aplikacja uruchamia się z podwyższonymi uprawnieniami, nie oznacza to, że może robić niedozwolone rzeczy, do których należy pisanie po kluczach HKLM, katalogu “program files” czy systemowym “windows”. dla tego system automatycznie przekierowuje takie żądania do wirtualnych odpowiedników – aplikacja myśli, że zapisała tam, gdzie chciała, dane są przechowywane obok – “wilk syty i owca cała”:

• dla rejestru jest to klucz “HKEY_USERS< User SID >_ClassesVirtualStore”
• dla systemu jest to katalog "$env:USERPROFILEappdataLocalVirtualStore”

uwaga! trzeba pamiętać, że po wyłączeniu
UAC aplikacje znów będą pisać/czytać z realnych katalogów i kluczy – może się więc okazać, że skonfigurowana i działająca aplikacja po włączeniu/wyłączeniu nagle jest ‘zresestowana’. należy wtedy ręcznie przenieść konfigurację ze/do wskazanych miejsc.

Dodatkowo “konto administratora” jest traktowane inaczej niż “konto z uprawnieniami administratora” – dzięki czemu po zalogowaniu się na administratora, ekrany UAC nie zatruwają pracy. zachowanie mechanizmu UAC można skonfigurować za pomocą GPO.

Płaszczyzna działania

ponieważ UAC był pod bardzo mocnym ostrzałem warto zastanowić się, jaki jest realny target tego mechanizmu, czyli “dla kogo ten pomysł”:

• dotyczy to kont z uprawnieniami administratora a więc standardowo stacji domowych, nie należących do domeny
• mechanizm ten jest łatwo wyłączyć jeśli przeszkadza – na prawdę nie rozumiem czemu duża część ludzi tak agresywnie reagowała. nie pasuje – wyłącz.
• w kontekście sieci korporacyjnej jego zastosowanie jest dość niszowe – w końcu jeśli jakaś aplikacja bussiness-critical nie chce działać, wtedy można dodać usera do grupy administratorów lokalnych. czy to dobrze, że w ogóle można pozostaje kwestią sporną – z punktu widzenia bezpieczeństwa i wszelkich best-practices, to developer/firma powinna w swoim dobrym interesie aplikację poprawić. rzeczywistość jednak zmusza do kompromisów.

o co więc ten raban? cóż… nowości bolą, no i fajnie jest kopnąć giganta w kostkę q:

whoami

poziom integralności w jakim się działa, można sprawdzić wykorzystując polecenie “whoami /groups”. przy wyłączonym UAC lub po uruchomieniu konsoli ‘as administrator’ na liście pojawi się:

Mandatory LabelHigh Mandatory Level Label    S-1-16-12288

jeśli zaloguje się jako zwykły user, lub należący do grupy administracyjnej z włączonym UAC:

Mandatory LabelMedium Mandatory Level    S-1-16-8192

jeśli użytkownik zaloguje się jako “power user”:

<brak nazwy> S-1-16-8448

to właśnie jest różnica pomiędzy tokenami. jakie prawa systemowe ma user można sprawdzić przy pomocy “whoami /priv”.

ps. w Vista doszła jeszcze jedna zmiana – każda usługa ma własny SID dzięki czemu jest identyfikowalna w systemie. żeby sprawdzić SID usługi należy wykonać polecenie “sc showsid <service_name>”. bardzo ciekawie polecenie zachowuje się, kiedy poda się złą/nieistniejącą nazwę…

n.