Какая разница между основным токеном и маркером олицетворения

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

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

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

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

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

В глоссарии говорится следующее:

токен доступа

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

первичный токен

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

токен олицетворения

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

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

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

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

Ответы

Ответ 1

Друг передал меня Программирование безопасности Windows от Keith Brown, который точно отвечает на этот вопрос.

Первичные жетоны можно и нужно называть токенами процесса, а токены олицетворения могут и должны называться токеновыми маркерами. Первичные жетоны могут быть прикреплены только к процессу, а токены олицетворения могут быть прикреплены только к потокам. Все это. Они действительно могут быть свободно преобразованы с использованием 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-интерфейсы разрешают привилегии на время вызова, в то время как другие требуют, чтобы вызывающие абоненты сами включали эти привилегии.
  • LogonUser (и LsaLogonUser), вероятно, возвращают токены олицетворения для сетевых входов из-за предположения о том, кто обычно выполняет сетевые входы в систему (например, стр. 83).
  • Вы можете создавать токены из пользовательского режима, используя недокументированную функцию NTDLL ZwCreateToken, для которой требуются довольно необычные привилегии (в частности, уникальный SE_CREATE_TOKEN_NAME). Вы, вероятно, не должны...