Файл: Руссинович М., Маргозис А. Утилиты Sysinternals. Справочник администратора 2012.pdf

32  Часть 

I   

Приступая к работе

Server Edition, они не поддерживались клиентскими версиями Windows до 
Windows XP. Функции, которые они поддерживают, включают быструю сме-
ну пользователей (Fast User Switching), удаленный рабочий стол (Remote 
Desktop), удаленный помощник (Remote Assistance), удаленные локально 
интегрированные приложения (RAIL или RemoteApps)  и функции инте-
грации виртуальной машины. Важным ограничением клиентских версий 
Windows (Windows XP, Windows Vista, и Windows 7) является поддержка 
единственного активного интерактивного сеанса одновременно. Другими 
словами, только один сеанс может обновлять изображение на дисплее и при-
нимать ввод от клавиатуры и мыши, в то время как разные процессы могут 
продолжать работу в разных независимых сеансах. Следующее ограничение 
заключается в том, что подключенный к домену компьютер с Windows XP 
поддерживает не более одного интерактивного сеанса. Например, если поль-
зователь вошел в систему с консоли, вы можете войти в систему через уда-
ленный рабочий стол, используя ту же учетную запись, и продолжить этот 
сеанс, однако вы не можете войти под другой учетной записью до тех пор, 
пока первый пользователь не выйдет из системы.

Сеансы служб терминалов идентифицируются порядковыми числовы-

ми идентификаторами, начиная с сеанса 0. Windows определяет глобальное 
пространство имен в диспетчере объектов и «локальное» сеансовое про-
странство имен для каждого сеанса с номером 1 и выше для изоляции сеан-
сов. Глобальное пространство имен служит в качестве локального для про-
цессов сеанса 0 (WinObj дает графическое изображение пространства имен 
диспетчера объектов, см. главу 14).

Системные процессы и службы Windows всегда работают в сеансе служб 

терминалов 0. В Windows XP и Windows Server 2003 первый интерактивный 
пользователь, входящий в систему, также использует сеанс служб термина-
лов 0 и, следовательно, использует то же локальное пространство имен, что и 
службы. Windows XP и Windows Server 2003 создают сеансы 1 и далее толь-
ко по мере необходимости. Если первый пользователь выходит из системы 
до того, как в нее войдет второй, то второй пользователь также использует 
сеанс 0. Таким образом, для Windows XP, подсоединенной к домену, сеанс 0 
всегда является единственным сеансом.

В Windows Vista и более поздних версиях службы работают в сеансе 0, 

однако, в целях безопасности, все интерактивные пользовательские сеансы 
работают в сеансах 1 и выше. Это строгое разделение процессов конечных 
пользователей и системных процессов называется изоляцией сеанса 0.

 Примечание  Термин «консольный сеанс» иногда ошибочно считается синонимом 

сеанса 0. Консольный сеанс — это сеанс служб терминалов, связанный с локально 
подсоединенными клавиатурой, видео и мышью. Если все активные сеансы системы 
представляют собой сеансы удаленного рабочего стола, то консольный сеанс оста-
ется подключенным и отображает экран входа в систему. Он может являться или не 
являться сеансом 0 в Windows XP/Windows 2003, однако никогда не является таковым 
в Windows Vista и более поздних версиях.

SIN_ch_02.indd   32

27.12.2011   14:12:08

Основные понятия Windows  

Глава 2  33 

Оконные станции

Каждый сеанс служб терминалов содержит одну или несколько имено-
ванных оконных станций. Оконная станция — это защищаемый объект, 
содержащий буфер обмена, атомарную таблицу, а также не менее одного 
рабочего стола. Каждый процесс связан с одной оконной станцией. В сеан-
се терминальных служб только оконная станция с именем WinSta0 может 
отображать пользовательский интерфейс и принимать ввод от пользовате-
ля. В сеансах терминальных служб с номерами 1 и выше Windows создает 
только оконную станцию WinSta0. (см. рис. 2-8). В сеансе 0 Windows соз-
дает, помимо WinSta0, отдельную оконную станцию для каждого сеанса 
LSA, связанного со службой. Такие сеансы имеют локально уникальный 
идентификатор (LUID), который добавляется к имени оконной стан-
ции. Например, процессы системных служб работают в оконной станции 
Service-0x0-3e7$, в то время как процессы сетевых служб работают в окон-
ной станции Service-0x0-3e4$. Эти оконные станции не могут отображать 
пользовательский интерфейс.

Рис. 2-8.  WinObj отображает интерактивную оконную станцию в закрытом пространстве 
имен сеанса 2

Команда PsExec -s cmd.exe запускает командную строку в оконной стан-

ции Service-0x0-3e7$ и перенаправляет ввод-вывод своей консоли в PsExec 
(см. главу 6). Параметр -i программы PsExec позволяет задавать сеанс тер-
минальных служб, а также запускает целевой процесс в своей оконной стан-
ции WinSta0.

Для службы, настроенной для работы под системной учетной записью, 

можно также включить параметр Разрешить взаимодействие с рабочим 
столом (Allow Service To Interact With Desktop). При такой настройке 
служба работает в оконной станции WinSta0  сеанса 0 вместо Service-0x0-
3e7$.  Когда интерактивный пользователь также находился в сеансе 0, это 
позволяло службе отображать пользовательский интерфейс конечному 
пользователю. Оглядываясь назад, следует отметить, что это была не луч-
шая идея, поэтому компания Microsoft не рекомендует использовать данный 
метод. Теперь он вовсе не работает из-за изоляции сеанса 0. (Служба обна-

SIN_ch_02.indd   33

27.12.2011   14:12:08

34  Часть 

I   

Приступая к работе

ружения интерактивных служб, UIODetect, частично смягчает негативные 
последствия этого обстоятельства.)

Рабочие столы

Каждая оконная станция имеет один или более рабочих столов. Рабочий 
стол — это защищаемый объект с логическим экраном, на котором приложе-
ния могут создавать пользовательский интерфейс в виде окон.

 Примечание  Рабочие столы, описываемые здесь, не имеют отношения к абстрак-

ции Рабочий стол (Desktop) наверху пространства имен командной оболочки Прово-
дника (Explorer).

Пользовательский интерфейс содержат многие рабочие столы, но только 

один из них может отображаться в данный момент. В интерактивной окон-
ной станции обычно содержатся три рабочих стола: Default, Screen-saver и 
Winlogon. Default — это рабочий стол, где пользовательские приложения за-
пускаются по умолчанию. Утилита Sysinternals Desktops создает до трех до-
полнительных рабочих столов для запуска приложений (об этом написано 
в главе 10). Screen-saver — это рабочий стол, на котором Windows запускает 
экранную заставку, если включена защита паролем. Winlogon, который так-
же называют защищенным рабочим столом, — это рабочий стол, которому 
Windows передает управление при нажатии Ctrl+Alt+Del, а также по умол-
чанию место отображения диалоговых окон повышения привилегий UAC. 
Разрешения на рабочем столе Winlogon ограничивают доступ только к про-
граммам, работающим под системной учетной записью, что обеспечивает 
безопасность операций, связанных с вводом пароля.

Рис. 2-9.  Процесс в сеансе 0 с открытыми описателями объектов рабочего стола 
и оконной станции

SIN_ch_02.indd   34

27.12.2011   14:12:08

Основные понятия Windows  

Глава 2  35 

Поскольку процесс связан с оконной станцией, каждый из его потоков 

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

Некоторые утилиты Sysinternals, в том числе, Process Explorer (описанный 

в главе 3) и Process Monitor (см. главу 4), опознают идентификатор сеанса 
службы терминала, к которому принадлежит процесс. Хотя ни одна утилита 
не может надежно идентифицировать оконную станцию или рабочие столы, 
с которыми связан процесс, функция Handle View (Просмотр описателей) 
утилиты Process Explorer может дать информацию об этом в виде открытых 
описателей оконных станций или объектов рабочих столов. Например, на 
рис. 2-9 Process Explorer отображает процесс, работающий в качестве систе-
мы в сеансе 0 с открытыми описателями рабочего стола \Default и оконной 
станции \Windows\WindowStations\Service-0x0-3e7$.

Оконные сообщения

В отличие от консольных приложений, GUI-приложения Windows являют-
ся событийно-управляемыми. Каждый поток, создающий оконные объекты, 
имеет очередь, в которую отправляются сообщения. Потоки графического 
пользовательского интерфейса ожидают, а затем обрабатывают входящие 
оконные сообщения. Эти сообщения информируют окно о том, что следует 
сделать или что произошло. Например, сообщения могут передавать окну 
следующие команды: «обновиться», «переместиться в точку экрана с коор-
динатами (х, у)», «закрыться», «была нажата клавиша Enter», «был сделан 
щелчок правой кнопкой мыши в координатах (х, у)» или «пользователь вы-
ходит из системы».

Оконные сообщения отправляются при помощи диспетчера окон. 

Сообщения могут отправляться любому окну из любого потока, работаю-
щего на том же рабочем столе. Диспетчер окон не позволяет программе от-
правлять оконное сообщение окну с другого рабочего стола. Команды про-
граммы Process Monitor /Terminate и /WaitForldle должны отправляться с 
того же рабочего стола, на котором работает адресат Procmon, поскольку они 
используют оконные сообщения для передачи существующему адресату ко-
манды закрытия, а также определять, готов ли адресат обрабатывать коман-
ды в виде оконных сообщений.

Оконные сообщения могут использоваться для имитации действий мыши 

или клавиатуры. Именно этим занимаются программа RegJump и функция 
Jump To в Process Monitor и Autoruns, чтобы перейти к разделу в Regedit. 
Из-за уровней абстракции между физическим нажатием клавиши и появ-
ляющимися оконными сообщениями, принимаемыми GUI-программой, 
конечной программе практически невозможно отличить с абсолютной точ-
ностью, нажата ли клавиша на клавиатуре или это другая программа сыми-
тировала нажатие клавиши, отправив оконное сообщение. Это справедливо 
не только для Windows, но и для других «оконных» систем.

SIN_ch_02.indd   35

27.12.2011   14:12:08

36  Часть 

I   

Приступая к работе

Данная архитектура оконных сообщений (за исключением внедрения 

многопоточной поддержки 32-разрядных версий Windows), восходит к 
Windows 1.0, и имеет множество унаследованных свойств. В частности, 
оконные объекты не имеют дескрипторов защиты и списков управления 
доступом. Именно поэтому разрешить службам отображение окон на поль-
зовательском рабочем столе было плохой идеей, так как пользовательские 
программы могли отправлять ошибочные или злонамеренные сообщения 
окнам системных процессов и, при успешном использовании дыр в защите, 
управлять этими процессами (это т.н. shatter-атака). Если пользователь не 
был администратором, повышение привилегий очень простым было делом. 
Именно в этом заключается главная причина, по которой интерактивные 
пользователи больше не входят в систему в сеансе 0.

При работе с пользовательскими правами (это режим по умолчанию в 

Vista и более поздних версиях Windows), а также при повышении приви-
легий UAC (оно нужно для работы приложений, требующих администра-
торских прав, на одном рабочем столе с процессами, обладающими пользо-
вательскими правами), требовалась дополнительная защита от shatter-атак 
окон процессов с повышенными привилегиями. Результатом стала изоля-
ция привилегий пользовательского интерфейса (UIPI).

До Windows Vista любой процесс, работающий под пользовательской 

учетной записью, имел полный доступ к управлению любыми другими про-
цессами, работающими под той же записью. При выключенном обязательном 
контроле целостности (Mandatory Integrity Control, MIC) процессы созда-
ются и работают на определенном уровне целостности (Integrity Level, IL). 
IL представляет некоторое значение, связанное с относительным уровнем 
доверия к процессу. Приложения с повышенными привилегиями работают 
на высоком IL, стандартные пользовательские приложения — на среднем, а 
процессы с низким уровнем прав (например, Internet Explorer в безопасном 
режиме) — на низком IL. (Программа Process Explorer, описанная в главе 3, 
может отображать IL для каждого процесса).

Когда передается оконное сообщение, которое может изменить состоя-

ние окна-адресата (например, сообщение о щелчке кнопкой мыши), при 
активной UIPI диспетчер окон сравнивает IL процесса, отправляющего со-
общение, с IL процесса, владеющего окном-адресатом. Если IL отправителя 
ниже, чем у получателя, сообщение блокируется. По этой причине RegJump 
и аналогичные функции Jump To должны выполняться с IL не ниже уровня 
Regedit. Подробнее о MIC и UIPI см. по адресу: http://msdn.microsoft.com/
en-us/library/bb625964.aspx

SIN_ch_02.indd   36

27.12.2011   14:12:08