2016-01-27 27 views
11

Niektóre interfejsy API systemu Windows zwracają token podstawowy, a niektóre zwracają token personifikacji. Niektóre interfejsy API wymagają tokena podstawowego, a inne wymagają tokena personifikacji.Jaka jest różnica między tokenem podstawowym a tokenem podszywania się?

Na przykład LogonUser zwykle zwraca podstawowy znak, z wyjątkiem przypadku korzystania LOGON32_LOGON_NETWORK jako typ logowania (dwLogonType):

W większości przypadków zwracane Uchwyt jest podstawowym tokenu, którego można użyć w wywołań funkcja CreateProcessAsUser. Jeśli jednak podasz flagę LOGON32_LOGON_NETWORK, LogonUser zwróci token personifikacji, którego nie możesz użyć w CreateProcessAsUser, chyba że wywołasz DuplicateTokenEx w celu przekonwertowania go na token podstawowy.

SetThreadToken wymaga tokenu personifikacji while ImpersonateLoggedOnUser które wydaje się zrobić całkiem dużo samo trwa jedn.

CreateProcessAsUser i CreateProcessWithTokenW oba wymagają podstawowej żeton i oba pamiętać podstawowym żeton można nabyć z tokenem personifikacji wywołując DuplicateTokenEx, ale czego typy tokenów oznaczać?

Słowniczek mówi co następuje:

access token

tokenu dostępu zawiera informacje o zabezpieczeniach dla sesji logowania. System tworzy token dostępu, gdy użytkownik loguje się, a każdy proces wykonywany w imieniu użytkownika ma kopię tokena. Token identyfikuje użytkownika, grupy użytkowników i uprawnienia użytkownika. System wykorzystuje token do kontrolowania dostępu do zabezpieczanych obiektów i kontrolowania zdolności użytkownika do wykonywania różnych operacji związanych z systemem na komputerze lokalnym. Istnieją dwa rodzaje tokenu dostępu, podstawowe i podszywanie się.

primary token

tokenu dostępu, które są zwykle tworzone wyłącznie przez jądro systemu Windows. Może być przypisany do procesu reprezentującego domyślne informacje bezpieczeństwa dla tego procesu.

impersonation token

tokenu dostępu, który został stworzony w celu przechwytywania informacji o zabezpieczeniach procesu klienta, co pozwala serwerowi „podszywać” procesu klienta w operacjach zabezpieczeń.

Ale to nie jest całkiem przydatne. Wygląda na to, że ktoś chciał użyć słów big boya, takich jak "jądro", ale służy to tylko do zadawania więcej pytań, na przykład, co jeszcze (oprócz przypisania do procesu) może być użyty token podstawowy i kto oprócz jądra może utworzyć dostęp tokeny?

(Czy mają na myśli sens Microsoftu, w którym jądro jest tylko częścią tego, co działa w trybie jądra, jest też Executive itd. Czy to znaczy, że kod trybu użytkownika może również tworzyć tokeny? Bez względu na to, nawet jeśli kod trybu użytkownika może tworzyć tokeny, będzie musiał to zrobić poprzez wywołanie systemowe, tak jak w każdym obiekcie Object Manager, tak więc token będzie faktycznie tworzony w trybie jądra.)

W każdym razie to nie robi t odpowiedź na podstawowe pytanie: Jaka jest różnica między typami żetonów?Nie jakie mogą być używane dla lub jak są one tworzone zwykle.

Odpowiedz

12

Znajomy odesłał mnie pod numer Programming Windows Security Keitha Browna, który dokładnie odpowiada na to pytanie.

Żetony główne mogą i powinny być nazywane tokenami procesowymi, a żetony podszywania się mogą i powinny być nazywane tokenami wątku. Żetony podstawowe można dołączać tylko do procesu, a tokeny personifikacji można dołączać tylko do wątków. To wszystko. W rzeczywistości można je dowolnie konwertować za pomocą DuplicateTokenEx (zakładając, że masz niezbędne prawa dostępu do uchwytu, który chcesz konwertować, oczywiście).

Od strony 115 w książce:

BOOL DuplicateTokenEx( HANDLE ExistingToken, // in DWORD DesiredAccess, // in LPSECURITY_ATTRIBUTES Attributes, // in, optional SECURITY_IMPERSONATION_LEVEL ImpLevel, // in TOKEN_TYPE Type, // in PHANDLE NewToken); // out

...

Parametr Type jest historyczny artefakt. Jeśli spojrzysz na definicję wyliczenia TOKEN_TYPE, zauważysz, że tokeny zostały taksonomicznie podzielone na dwie kategorie: podszywanie się w stosunku do tokenów podstawowych. Nie powiesić się na tej nomenklaturze; znaczenie jest znacznie prostsze niż się wydaje. Żetony personifikacji można dołączać tylko do wątków, a tokeny podstawowe można dołączać tylko do procesów. To wszystko znaczy. Token procesu uzyskany wcześniej przez OpenProcessToken był zatem tokenem podstawowym.

W bardzo wczesnych wersjach systemu Windows NT (3.x) istniały o wiele surowsze ograniczenia co do tego, co można zrobić za pomocą tokena, w zależności od tego, skąd pierwotnie je otrzymano, a zatem typ tokena został wprowadzony do śledzenia zamierzone użycie tokena. Ponieważ w tym tekście założono, że używasz systemu Windows NT 4.0 lub nowszego, pomyśl o tokenie personifikacji jako "tokenie wątku" i tokenie podstawowym jako "tokenie procesu", a następnie użyj DuplicateTokenEx, aby przekonwertować między nimi, kiedy tylko zajdzie taka potrzeba. Windows NT 4.0 oddzielił granice między nimi, wprowadzając DuplicateTokenEx; wersja Windows NT 3.x tej funkcji, DuplicateToken, została zakodowana na stałe tylko w celu generowania tokenów podszywania się. W rzeczywistości, teraz powinieneś być w stanie zobaczyć głupi błąd, który powoduje niepowodzenie pierwszego połączenia z SetThreadToken: kod próbuje podłączyć token podstawowy (ten, który uzyskano z procesu) do wątku (który wymaga tokena podszywania się) . To nie jest nie. Aby rozwiązać zarówno problem logiczny i głupie historie problemu, oto poprawiony kod:

Inne rzeczy, które nie są ściśle odpowiedź na pytanie, ale zostały wymienione w pytaniu:

  • Widocznie ImpersonateLoggedOnUser dokłada wszelkich starań i zamienia żetony podstawowe na żetony podszywania się, podczas gdy SetThreadToken nie przejmuje się. Czemu? kto wie? Prawdopodobnie z tego samego powodu niektóre interfejsy API zezwalają na przywileje na czas trwania połączenia, podczas gdy inne wymagają od rozmówców samodzielnego włączenia uprawnień.
  • (i) prawdopodobnie zwracają tokenów personifikacji dla logowania do sieci z powodu założenia, kto zwykle wykonuje loginy sieciowe (na przykład od 83).
  • Możesz tworzyć tokeny z trybu użytkownika, używając nieudokumentowanej funkcji NTDLL ZwCreateToken, która wymaga całkiem nietypowych uprawnień (szczególnie unikalnego SE_CREATE_TOKEN_NAME). Prawdopodobnie nie powinieneś ...
+0

Możesz również tworzyć tokeny z trybu użytkownika z udokumentowanymi funkcjami CreateToken i CreateTokenEx, ale potrzebujesz dużej ilości infrastruktury, aby to zrobić, ponieważ te funkcje mogą być wywoływane tylko z SSP/AP ("dostawca/autoryzacja bezpieczeństwa" pakiet"). –

+0

Dobra uwaga. Zauważ, że nie tylko wymagają one implementacji całego interfejsu SSP/AP (funkcje "SpLsaModeInitialize" powinny powrócić w tabeli funkcji itp.), W przeciwieństwie do "zwykłych" SSP, SSP/AP działają jako część LSASS, więc działa pod kontem 'NT AUTHORITY \ SYSTEM' i ma w dalszym ciągu' SeCreateTokenPrivilege', 'SeTcbPrivilege' itd. Tak więc pod względem bezpieczeństwa mają te same wymagania (możesz nawet powiedzieć, że "ZwCreateToken" jest mniej wymagający), chociaż masz rację, zauważając, że są one udokumentowane, co jest plusem. – conio

+0

Co stanie się z wątkiem po usunięciu żetonów podszywania się? – Dolev

Powiązane problemy