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 >_Classes\VirtualStore\”
- dla systemu jest to katalog "$env:USERPROFILE\appdata\Local\VirtualStore”
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 Label\High 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 Label\Medium 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.
Na pewno warto widzieć obie strony medalu. Do google nic nie mam - korzystam i zachwalam - także jak coś gromadzą to z pożytkiem dla wszystkich - ale jak mi EU zaczyna przebąkiwać o jakimś analizowaniu/filtrowaniu sieci do już nie zdzierżę…
Widzę, że pijesz m.in. do mojego komentarza a propos Google DNS.
Od strachu do paranoi jest dość daleko, IMHO. Więc pominę paranoję, bo wydaje mi się to przesadzone, ale skupię się na wspomnianym przez Ciebie strachu. Czy faktycznie musimy się bać?
Bo jak można się bać tego, że nasze dane zostaną wykorzystane do niecnych celów? Czy podobnie się boimy jeżdżąc samochodem (strach przed wypadkami), mieszkając w kapitalistycznym kraju (strach przed krachem giełdowym), chodząc codziennie do pracy (strach przed byciem zwolnionym), używaniem komórek (strach przed efektami promieniowania radiowego)? Nie. Mamy świadomość zagrożeń i odpowiednio dostosowujemy nasze życie, by te zagrożenia minimalizować (pasy, poduszki powietrzne, finansowe instrumenty kontrolne, etc).
Dlatego, wracając do Google DNS, wiedząc do czego (potencjalnie) Google może wykorzystywać dane i mając pod uwagę minimalny zysk z używania ich serwerów, ja oceniam ich propozycję jako nie wartą świeczki.
Dlaczego to właśnie Google może te dane tak wykorzystać, a nie np. mój ISP czy administrator mojej firmy? Bo na tym właśnie polega biznes Google by dać użytkownikowi to, czego on dokładnie potrzebuje. Jeszcze żaden ISP czy administrator nie dał mi niczego czego *dokładnie* potrzebuję i nie będzie analizował ruchu w szczegółach, bo ich na to nie stać.
@mike: i to JEST zdroworozsadkowe - co powiedziales. natomiast zostalem zbombardowany podnymi tresciami w tak krotkim okresie czasu, ze zaczalem sie zastanawiac o co c’mon! a od strachu do paranoi jest bardzo niedluga droga - jesli owe strachy, ktore wspomniales, zaczna zaprzatac ci glowe - jestes skonczony. moje pytanie - kiedy sie bac a kiedy olac? w sumie zdaje sobie sprawe, ze dosc retoryczne… bo nie ma to jednej odpowiedzi, ale qrde… grrrr
Mike dokladnie o to mi tez chodzi, tylko ze ja akurat pojawiam sie tu w kwestii Facebooka, chociaz w pelni sie zgadzam z Toba w temacie o ktorym piszesz ;)
temat FB jest poruszony od ‘dupy strony’
mi chodzi o czysto miedzy ludzkie sprawy w temacie fotek, a nie jakies bezduszne IT. Nie mam ochoty zeby cala rzesza ludzi znala moje zycie intymne a do tego zaliczam wypady ze znajomymi. Nie znosze jak ktos mi robi zdjecie na imprezie i potem zamieszcza je w sieci i jeszcze zapina mnie spinaczem. Moj wizerunek jest moja prywatnoscia i ja chce nim zarzadzac.
kolejna rzecz to zamieszczanie fotek ktorych sie nie zrobilo, nie jest sie na nich, nie bylo sie w trakcie ich tworzenia - normalnie paragraf za publikacje nie swojej tresci ;) hehe
przeciez moze ktos nie chce byc upubliczniony w tej konkretnej sytuacji! a zamieszczanie fotek na forach jest czyms takim
Ty sie czujesz w skorze exhibicjonisty ja wole obnazac sie kameralnie.
Jest jeszcze pare aspektow na ktore tu nie ma miejsca i pogadamy o nich jeszcze wiele razy :)
Pozostaje myśleć… ja się zgadzam z nexorem … ulubiona lista zakupów, albo kalendarz na google, to po prostu wygoda … widomo, że nie wpiszę tam “delikatnych” danych …. a że inni to robią … soory… tak po prostu to działa, są ludzie żyjący jak lumpy mieszkając w pałacach i są ludzie żyjący jak królowie, mieszkając w kawalerkach … to twoja decyzja ile siebie pokazujesz na zewnątrz…. pewne dane muszą i są publiczne …nr dokumentów, nazwiska, adresy … nie ma w tym nic złego .. prosta identyfikacja … inne być nie muszą … paranoja zawsze jest zła … widziałem gościa, który kłócił się, że chcą przetwarzać jego nazwisko i nr tel w serwisie sprzętu … argument obsługi był jedyny słuszny … a jak inaczej mamy pana powiadomić, że sprzęt jest do odbioru!!! … a jak ktoś umieści twoje zdjęcia na blogu bez twojej wiedzy, to faktycznie jest przegięcie, ale i przy okazji przestępstwo, więc trzeba też dobierać sobie znajomych i szanować się na imprezach ;p
Jak ktoś będzie potrzebował, to każde dane wygrzebie — jakoś kiedyś ludzie sobie radzili z tym bez internetu. Teraz można ewentualnie zaszumiać swoje dane — bo na pewno się ich z Sieci nie wytnie. Ja już się przestałem przejmować — część danych upubliczniam, bo i tak są w sieci; a te ważniejsze mam w głowie.
A fotki — jak ktoś wrzuca Ciebie do sieci, to go poproś, żeby tego nie robił. A jak nie poskutkuje, to jest na to paragraf. No, chyba, że jesteś na focie „częścią większej całości” — wtedy jedynie możesz się odtagować. :)