2016-01-27 3 views
11

Некоторые API Windows возвращают первичный токен, а некоторые возвращают маркер олицетворения. Для некоторых API требуется первичный токен, в то время как другим требуется токен олицетворения.В чем разница между основным токеном и токеном олицетворения

Например, LogonUser обычно возвращает основной маркер, за исключением при использовании LOGON32_LOGON_NETWORK как тип входа (dwLogonType):

В большинстве случаев, возвращенный дескриптор является основным маркером, который можно использовать в вызовах функция CreateProcessAsUser. Однако, если вы укажете флаг LOGON32_LOGON_NETWORK, LogonUser вернет маркер олицетворения, который нельзя использовать в CreateProcessAsUser, если вы не вызываете DuplicateTokenEx, чтобы преобразовать его в первичный токен.

SetThreadToken требуется маркер олицетворения то время как ImpersonateLoggedOnUser, который, кажется, чтобы сделать почти то же самое происходит ни один.

CreateProcessAsUser и CreateProcessWithTokenW оба требуют первичных маркеров и как отметить первичный маркер может быть получен из маркеров олицетворения путем вызова DuplicateTokenEx, но что типы маркеров означают?

Словарь говорит следующее:

access token

Маркер доступа содержит информацию о безопасности для сеанса входа в систему. Система создает маркер доступа, когда пользователь входит в систему, и каждый процесс, выполняемый от имени пользователя, имеет копию токена. Токен идентифицирует пользователя, группы пользователей и привилегии пользователя. Система использует токен для управления доступом к защищаемым объектам и для управления способностью пользователя выполнять различные системные операции на локальном компьютере. Существует два типа токена доступа, первичный и олицетворяющий.

primary token

маркер доступа, который, как правило, создается только в ядре Windows. Он может быть назначен процессу для представления информации безопасности по умолчанию для этого процесса.

impersonation token

маркер доступа, который был создан для сбора информации о безопасности процесса клиента, что позволяет серверу «выдавать себя» процесс клиента в операциях по обеспечению безопасности.

Но это не совсем полезно. Похоже, что кто-то хотел использовать большие слова мальчика, такие как «ядро», но это только помогает поднимать больше вопросов, таких как то, что еще (кроме того, что назначено процессу) может использоваться первичный токен и кто еще, кроме ядра, может создавать доступ жетоны?

(Являются ли они пониманием Microsoft, когда ядро ​​является частью того, что работает в режиме ядра, а также есть исполнительный и т. Д., Или они означают, что код в режиме пользователя также может создавать токены? если код пользовательского режима может создавать токены, он должен будет сделать это с помощью системного вызова, как и с любым объектом Object Manager, поэтому в любом случае токен будет фактически создан в режиме ядра.)

В любом случае, Ответ на основной вопрос: Какая разница между типами токенов?Не что они могут быть использованы или как они обычно создано.

ответ

12

Друг передал меня Programming Windows Security Китом Брауном, который точно отвечает на этот вопрос.

Первичные токены можно и нужно называть процессуальными жетонами, а маркеры олицетворения могут и должны называться токенами токенов. Первичные жетоны могут быть прикреплены только к процессу, а токены олицетворения могут быть прикреплены только к потокам. Это все. Они действительно могут быть свободно преобразованы с использованием DuplicateTokenEx (при условии, что у вас есть необходимые права доступа к дескриптору, который вы хотите преобразовать, очевидно).

От странице 115 в книге:

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

...

Параметр Type исторический артефакт. Если вы посмотрите на определение перечисления TOKEN_TYPE, вы обнаружите, что токены были таксономизированы на две категории: олицетворение против первичных токенов. Не подвешивайте эту номенклатуру; смысл на самом деле намного проще, чем кажется. Листы олицетворения могут быть прикреплены только к потокам, а первичные маркеры могут присоединяться только к процессам. Это все это значит. Таким образом, токен процесса, полученный ранее через OpenProcessToken, был основным маркером.

В очень ранних версиях Windows NT (3.x) было гораздо более жесткое ограничение на то, что вы могли бы сделать с токеном, в зависимости от того, откуда вы его взяли, и, следовательно, тип маркера был введен для отслеживания предполагаемое использование токена. Поскольку в этом тексте предполагается, что вы используете Windows NT 4.0 или выше, просто подумайте о токенах олицетворения как «токен токена» и первичный токен как «токен процесса» и используйте DuplicateTokenEx для преобразования между ними, когда это необходимо. Windows NT 4.0 разорвала границы между ними, представив DuplicateTokenEx; версия Windows NT 3.x этой функции, DuplicateToken, была жестко запрограммирована только для создания жетонов олицетворения. Фактически, теперь вы должны иметь возможность увидеть глупую ошибку, которая вызывает первый вызов SetThreadToken, чтобы сбой: код пытается привязать первичный токен (тот, который получен от процесса) к потоку (для которого требуется токен олицетворения) , Это не-нет. Для того, чтобы исправить как логическую задачу и глупую историческую проблему, вот исправленный код:

Другие вещи, которые не являются строго ответ на этот вопрос, но были упомянуты в вопросе:

  • Видимо ImpersonateLoggedOnUser идет лишняя миля и преобразует основные токены в токены олицетворения, в то время как SetThreadToken не беспокоит. Зачем? кто знает? Вероятно, по той же причине некоторые API-интерфейсы разрешают привилегии на время вызова, в то время как другие требуют звонящих, чтобы самостоятельно предоставлять привилегии.
  • LogonUserLsaLogonUser), вероятно, возвращают маркеры олицетворения для сетевых подключений из-за предположения о том, кто обычно выполняет сетевые подключения (например, стр. 83).
  • Вы можете создавать токены из пользовательского режима, используя недокументированную функцию NTDLL ZwCreateToken, которая требует довольно необычных привилегий (в частности, уникальных SE_CREATE_TOKEN_NAME). Вы, вероятно, не должны ...
+0

Вы также можете создавать маркеры из пользовательского режима с задокументированными функциями CreateToken и CreateTokenEx, но для этого требуется много инфраструктуры, поскольку эти функции можно вызывать только из SSP/AP («поставщик/пакет "). –

+0

Хорошая точка. Обратите внимание, что не только они требуют, чтобы вы реализовали весь интерфейс SSP/AP (функции «SpLsaModeInitialize» должны возвращаться в таблице функций и т. Д.), В отличие от «простых» SSP, SSP/AP запускаются как часть LSASS, поэтому они запускаться под учетной записью '' AUTHORITY \ SYSTEM' '' NT и в любом случае иметь 'SeCreateTokenPrivilege',' SeTcbPrivilege' и т. д. Таким образом, по безопасности они имеют одинаковые требования (вы даже можете сказать, что «ZwCreateToken» менее требовательна), хотя вы правильно заметили, что они документированы, что является плюсом. – conio

+0

Что произойдет с нитью после того, как будут выведены маркеры олицетворения? – Dolev

 Смежные вопросы

  • Нет связанных вопросов^_^