Можно ли в токене (primary) изменить Logon SID ?
1. Например, с помощью SetTokenInformation, указавши в качестве TokenInformationClass тип TokenLogonSid ?
2. С помощью изменения/добавления списка групп, т.е с помощью SetTokenInformation, указавши в качестве TokenInformationClass тип TokenGroups ?
Подозреваю, что нельзя. Естественно, это можно проверить, попробовавши, что, если будет необходимость, и сделаю.
Но если кто-то знает/пробовал, просьба отписаться. MSDN четкого ответа не дала.
Интересует в первую очередь для Windows Vista, ну и для остальных версий ОС тоже.
Здравствуйте, Jolly Roger, Вы писали:
JR>Здравствуйте, KolyanV, Вы писали:
JR>В MSDN перечислены валидные для SetTokenInformation значения TOKEN_INFORMATION_CLASS, TokenLogonSid среди них нет А Вам для чего?
. В результате пришел к выводу, что создаваемый процесс не будет под Windows Vista (в XP нормально работает) нормально работать, если LogonSID токена, с помощью которого создается процесс, не соответсвует LogonSID процесса explorer.exe в сессии, в которой запускается процесс. И никакие примочки в виде изменения DACL для WindowStation, Desktop, \\Sessions\\(номер сессии)\\BaseNamedObjects для создаваемого процесса, если его Logon SID не равен експлореровскому, не помагают.
Поэтому я предположил два возможных выхода:
1. Создать токен с помощью LogonUser, изменить его Logon SID на тот же что и у explorer.exe — как и предполагал, с помощью SetTokenInformation — сделать этого нельзя. (А, возможно, можно его установить с помощью изменения/добавления списка групп (TokenGroups) ? )
2. Дуплицировать токен explorer.exe, заменить его TokenUser и TokenGroups требуемого пользователя.
Я провел эксперемент: Запустил процесс с помощью RunAs от имени другого пользователя. С помощью SysInternals ProcessExplorer проверил — explorer.exe и запущенный процесс имеют одинаковый Logon SID, не смотря на то, что запущены от имени разных пользователей. При этом утилита SysInternal logonsessions.exe показывает, что explorer.exe и запущенный процесс запущены в разных Logon Sessions. Теперь мое ИМХО: т.е для запуска процесса утилита RunAs создает токен с помощью LogonUser, а потом каким-то образом его модифицирует.
Здравствуйте, Jolly Roger, Вы писали:
JR>Здравствуйте, KolyanV, Вы писали: JR>В MSDN перечислены валидные для SetTokenInformation значения TOKEN_INFORMATION_CLASS, TokenLogonSid среди них нет А Вам для чего?
Искал, искал, так и не нашел в ON-Line MSDN информацию о валидных значениях TOKEN_INFORMATION_CLASS при передаче этого параметра в функцию SetTokenInformation. Может подскажите ссылку ?
Зато нашел это: Описание Phyton функции win32security.SetTokenInformation
Т.е судя по всему в SetTokenInformation можно передавать только такие виды TOKEN_INFORMATION_CLASS:
TokenOwner PySID to be used as owner of created objects
TokenPrimaryGroup PySID
TokenDefaultDacl PyACL — Default permissions for created objects
TokenSessionId Int — Terminal services session id
TokenVirtualizationEnabled Boolean
TokenVirtualizationAllowed Boolean
TokenIntegrityLevel PySID_AND_ATTRIBUTES containing an integrity SID and SE_GROUP_INTEGRITY flag
TokenMandatoryPolicy
Вывод из этого — нельзя в токене менять Logon SID, также как и менять состав групп и User SID. (Включение/выключение групп присутствующих в токене не в счет).
Теперь слегка дублирую свое предыдущее сообщение: >Я провел эксперемент: Запустил процесс с помощью runas.exe от имени другого пользователя. С помощью SysInternals ProcessExplorer проверил — explorer.exe и запущенный процесс имеют одинаковый Logon SID, не смотря на то, что запущены от имени разных пользователей. При этом утилита SysInternal logonsessions.exe показывает, что explorer.exe и запущенный процесс запущены в разных Logon Sessions (Session ID, т.е сессия, естественно, одинаковые).
Отсюда следует вопрос: КАК ОС запускает процесс с правами другого пользователя, при этом, в свойствах токена запущенного процесса LogonSID равен LognSID системного процесса explorer.exe ?
KV>Теперь слегка дублирую свое предыдущее сообщение: >>Я провел эксперемент: Запустил процесс с помощью runas.exe от имени другого пользователя. С помощью SysInternals ProcessExplorer проверил — explorer.exe и запущенный процесс имеют одинаковый Logon SID, не смотря на то, что запущены от имени разных пользователей. При этом утилита SysInternal logonsessions.exe показывает, что explorer.exe и запущенный процесс запущены в разных Logon Sessions (Session ID, т.е сессия, естественно, одинаковые).
KV>Отсюда следует вопрос: КАК ОС запускает процесс с правами другого пользователя, при этом, в свойствах токена запущенного процесса LogonSID равен LognSID системного процесса explorer.exe ?
Блииииииин ... А как все было просто. Посмотрел в исходниках Win2000, запуск осуществляет банально — с помощью CreateProcessWithLogon...
KV>>Отсюда следует вопрос: КАК ОС запускает процесс с правами другого пользователя, при этом, в свойствах токена запущенного процесса LogonSID равен LognSID системного процесса explorer.exe ? KV>Блииииииин ... А как все было просто. Посмотрел в исходниках Win2000, запуск осуществляет банально — с помощью CreateProcessWithLogon...
CreateProcessWithLogon всего лишь делает запрос в сервис (внутри одного из svchost'ов) который и делает LogonUser и CreateProcessAsUser.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ononim, Вы писали:
KV>>>Отсюда следует вопрос: КАК ОС запускает процесс с правами другого пользователя, при этом, в свойствах токена запущенного процесса LogonSID равен LognSID системного процесса explorer.exe ? KV>>Блииииииин ... А как все было просто. Посмотрел в исходниках Win2000, запуск осуществляет банально — с помощью CreateProcessWithLogon... O>CreateProcessWithLogon всего лишь делает запрос в сервис (внутри одного из svchost'ов) который и делает LogonUser и CreateProcessAsUser.
Даааа.... Вот еще-бы посмотреть что этот сервис там мухлюет. Подозреваю, что использует Kernel API и недокументированные функции ...
Здравствуйте, KolyanV, Вы писали:
KV>Искал, искал, так и не нашел в ON-Line MSDN информацию о валидных значениях TOKEN_INFORMATION_CLASS при передаче этого параметра в функцию SetTokenInformation. Может подскажите ссылку ?
В ON-Line версии осталась только фраза
The valid values from TOKEN_INFORMATION_CLASS are described in the TokenInformation parameter.
и далее в описании TokenInformation — пусто
В локальной версии за 2002-й — TokenOwner, TokenPrimaryGroup, TokenDefaultDacl и TokenSessionId. В версии за 2005-й к ним добавился TokenOrigin. Попробуйте поиграть этим последним, мало-ли. Ну а полный список, похоже, можно получить только пробой или дизассемблированием.
И Вы упоминали про модификацию DACL оконной станции и стола, а ACE для LogonSid Вы туда пробовали добавить?
"Нормальные герои всегда идут в обход!"
Re[5]: Работа с токенами (tokens) в Windows
От:
Аноним
Дата:
15.07.10 20:16
Оценка:
Здравствуйте, Jolly Roger, Вы писали:
JR>Здравствуйте, Jolly Roger, Вы писали:
JR>И Вы упоминали про модификацию DACL оконной станции и стола, а ACE для LogonSid Вы туда пробовали добавить?
Да, добавляю туда ACE моего Logon SID с всеми разрешающими. В Windows XP — работает на ура. В Windows Vista — на первый взгляд, тоже.
Но после тщательной проверки выявляются "спецэффекты". Например такой, что при использовании GetSaveFileName, — енумерация списка файлов и каталогов жестко тормозит систему с почти 100% ее загрузкой самим процессом и процессом lsass.exe.
А>Но после тщательной проверки выявляются "спецэффекты". Например такой, что при использовании GetSaveFileName, — енумерация списка файлов и каталогов жестко тормозит систему с почти 100% ее загрузкой самим процессом и процессом lsass.exe.
в event log системный и секурный загляните, любопытно, мож там есть чо
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ononim, Вы писали:
А>>Но после тщательной проверки выявляются "спецэффекты". Например такой, что при использовании GetSaveFileName, — енумерация списка файлов и каталогов жестко тормозит систему с почти 100% ее загрузкой самим процессом и процессом lsass.exe. O>в event log системный и секурный загляните, любопытно, мож там есть чо
Да, вот, ничего необычного и нет в этих журналах (((
JR>В локальной версии за 2002-й — TokenOwner, TokenPrimaryGroup, TokenDefaultDacl и TokenSessionId. В версии за 2005-й к ним добавился TokenOrigin. Попробуйте поиграть этим последним, мало-ли. Ну а полный список, похоже, можно получить только пробой или дизассемблированием.
Неа, TokenOwner -Только в Win2003 и в Win2008. В клиентских ОС не поддерживается. (((
Здравствуйте, KolyanV, Вы писали:
KV>Даааа.... Вот еще-бы посмотреть что этот сервис там мухлюет. Подозреваю, что использует Kernel API и недокументированные функции ...
Возможно, это NtCreateToken, она вроде как позволяет собрать маркер с любым набором групп. Следовательно, и Logon SID можно назначить.
KV>>Даааа.... Вот еще-бы посмотреть что этот сервис там мухлюет. Подозреваю, что использует Kernel API и недокументированные функции ... JR>Возможно, это NtCreateToken, она вроде как позволяет собрать маркер с любым набором групп. Следовательно, и Logon SID можно назначить.
нет. Начиная с висты привилегией SeCreateToken обладает лишь lsass.exe. А без нее NtCreateToken не работает.
Как много веселых ребят, и все делают велосипед...
O>>нет. Начиная с висты привилегией SeCreateToken обладает лишь lsass.exe. А без нее NtCreateToken не работает. JR>То есть начиная с висты она через политики недоступна?
В смысле через политики? SeCreateTokenPriviledge до висты был у всех системных процессов, после висты — лишь у lsass.exe. А нужна она для NtCreateToken всегда была.
JR>А спионэрить токен у lsass и имперсонироваться тоже не получится?
Получится. Я так делал. Но не думаю что микрософт так делает.
Кстати SetTokenInformation принимает больше классов информации чем говорит об этом мсдн. Так что имеет смысл попробовать вызвать ее с TokenLogonSid.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ononim, Вы писали:
O>В смысле через политики? SeCreateTokenPriviledge до висты был у всех системных процессов, после висты — лишь у lsass.exe. А нужна она для NtCreateToken всегда была.
Я имел в виду, что это право назначается конкретной учётке, а по умолчанию есть только у системной (на XP). Но через политики (с помощью оснастки MMC, например) его можно назначить любой учётке. На висте, как я понимаю, либо для lsass стали использовать специальную учётку, либо для запуска остальных служб использовать ограниченный маркер, так?
JR>>А спионэрить токен у lsass и имперсонироваться тоже не получится? O>Получится. Я так делал. Но не думаю что микрософт так делает.
MS может заначить нужный маркер, например. Или даже обратиться за помощью к lsass.
O>Кстати SetTokenInformation принимает больше классов информации чем говорит об этом мсдн. Так что имеет смысл попробовать вызвать ее с TokenLogonSid.