O>>В смысле через политики? SeCreateTokenPriviledge до висты был у всех системных процессов, после висты — лишь у lsass.exe. А нужна она для NtCreateToken всегда была.
JR>Я имел в виду, что это право назначается конкретной учётке, а по умолчанию есть только у системной (на XP). Но через политики (с помощью оснастки MMC, например) его можно назначить любой учётке. На висте, как я понимаю, либо для lsass стали использовать специальную учётку, либо для запуска остальных служб использовать ограниченный маркер, так?
Я не копался как они этот токен делают. Но думаю не обязательно CreateRestrictedToken (aka NtFilterToken). Скорее всего создают готовый токен в NtCreateToken, там привилегии указываются. А учетками, оснастками etc занимается сам lsass, — все это лишь абстракции над NtCreateToken. С помощью NtCreateToken мона нафантазировать абсолютно любой токен — с любыми группами, привилегиями etc причем совершенно независимо от того, че там наконфигурено в настройках юзеров.

JR>>>А спионэрить токен у lsass и имперсонироваться тоже не получится?
O>>Получится. Я так делал. Но не думаю что микрософт так делает.
JR>MS может заначить нужный маркер, например. Или даже обратиться за помощью к lsass.
Врядли.

Здравствуйте, ononim, Вы писали:

O>Я не копался как они этот токен делают. Но думаю не обязательно CreateRestrictedToken (aka NtFilterToken). Скорее всего создают готовый токен в NtCreateToken, там привилегии указываются. А учетками, оснастками etc занимается сам lsass, — все это лишь абстракции над NtCreateToken. С помощью NtCreateToken мона нафантазировать абсолютно любой токен — с любыми группами, привилегиями etc причем совершенно независимо от того, че там наконфигурено в настройках юзеров.

Согласен, я под ограниченным и не имел в виду фильтрованный, неудачно выразился. Просто специальный маркер с неполным набором прав.

Если SeCreateTokenPriviledge осталась в висте доступна через политики, то в принципе можно при инсталляции создать специальную учётку с нужными настройками, в том числе и SeCreateToken, и назначить запуск службы от неё. Другой вопрос, поможет ли это топикстартеру. Я вот как-то никогда не интересовался возможностью подмены Logon Sid, а сейчас попробовал поискать в сети — что-то глухо

JR>>MS может заначить нужный маркер, например. Или даже обратиться за помощью к lsass.
O>Врядли.

Да, я тоже сомневаюсь, откровенно говоря.

JR>Согласен, я под ограниченным и не имел в виду фильтрованный, неудачно выразился. Просто специальный маркер с неполным набором прав.
В том то и дело что полный или не полный это лишь слова. На самом деле токен мона создать совершенно левый — к примеру на юзера гость и принадлежащему группе админов с полным набором привилегий — вот "полный" он будет или нет? . Или возможно даже с левыми SID'ами несуществущих групп и юзера.

JR>Если SeCreateTokenPriviledge осталась в висте доступна через политики, то в принципе можно при инсталляции создать специальную учётку с нужными настройками, в том числе и SeCreateToken, и назначить запуск службы от неё.
Всякими там политиками занимается lsass, LogonUser на самом деле просто RPC колл в lsass, lsass в ответ вычитывает юзера, проводит авторизацию etc, вычисляет какие группы и привилегии принадлежат тому кого мы логиним согласно политикам и.. вызывает NtCreateToken со всеми этими параметрами.
wininit и services запускаются до него. Потому токены для wininit и services сочиняются ядром без помощи lsass и без участия каких либо политик.

JR> Другой вопрос, поможет ли это топикстартеру. Я вот как-то никогда не интересовался возможностью подмены Logon Sid, а сейчас попробовал поискать в сети — что-то глухо
На самом деле вопрос стоит лишь за 10..30 мин в windbg

Здравствуйте, ononim, Вы писали:

O>Всякими там политиками занимается lsass, LogonUser на самом деле просто RPC колл в lsass, lsass в ответ вычитывает юзера, проводит авторизацию etc, вычисляет какие группы и привилегии принадлежат тому кого мы логиним согласно политикам и.. вызывает NtCreateToken со всеми этими параметрами.
O>wininit и services запускаются до него. Потому токены для wininit и services сочиняются ядром без помощи lsass и без участия каких либо политик.

Это понятно, но ведь это не отменяет возможности топикстартеру воспользоваться политикой и вызвать NtCreateToken в третьем кольце, верно?

JR>> Другой вопрос, поможет ли это топикстартеру. Я вот как-то никогда не интересовался возможностью подмены Logon Sid, а сейчас попробовал поискать в сети — что-то глухо
O>На самом деле вопрос стоит лишь за 10..30 мин в windbg

И желания или необходимости этим заниматься

Здравствуйте, Jolly Roger, Вы писали:

JR>Если SeCreateTokenPriviledge осталась в висте доступна через политики, то в принципе можно при инсталляции создать специальную учётку с нужными настройками, в том числе и SeCreateToken, и назначить запуск службы от неё. Другой вопрос, поможет ли это топикстартеру. Я вот как-то никогда не интересовался возможностью подмены Logon Sid, а сейчас попробовал поискать в сети — что-то глухо

Да, SeCreateTokenPriviledge осталась доступна. Так что можно создать собственного юзера с привелегией SeCreateToken. В принципе, это может помочь.
Но есть один важный нюанс (о нем ниже).

Я нашел в сети исходники программы на тему "RunAs" от некого Zhefu Zhang (http://www.codeproject.com/KB/system/RunUser.aspx). Исходники основаны на коде Jeffrey Richter, примеров от Gary Nebbett с собственной доработкой автором.
Одним из вариантов запуска этой программой дочернего процесса — путем запуска ZwCreateToken с дальнейшим использованием CreateProcessAsUser. Так вот, в Windows XP подобный вариант запуска проходит на ура (в полиси пользователя установлены все необходимые привелегии). А в Windows Vista при попытке выполнить аналогичную операцию — программа вылетает с ексцепшеном (привелегия у пользователя есть). Пока еще не разбирался, но предполагаю, что ексцепшен вызван тем, что изменился список параметров/способ использования некоторых функций Native API. Так что это палка в двух концах, как говориться )).

Кстати, пробовал запускать SetTokenInformation с классом TokenOrigin. Этот класс читает/устанавливает logon session, который означает: "Logon session процесса, создавшего данный токен", что-то в этом роде. Кстати, параметр этот документирован только для Windows 2003 /2008. На практике работает и в Win Vista.

Использование SetTokenInformation совместно с классом TokenLogonSid вызывает возврат ошибки, что соответствует поведению согласно документации.