Терминальные Сеансы Служб

Терминальные службы поддерживают многократные интерактивные пользовательские сеансы на единственном компьютере. Представленный в Windows NT 4.0 Выпуска Терминального сервера, они не были включены в клиентское семейство операционной системы Windows до Windows XP. Функции, которые они поддерживают, включают Быстрого Пользователя, Переключающегося, Удаленный рабочий стол, Отдаляют Помощь, Отдаляют Приложения, Интегрированные Локально (ЖЕЛЕЗНАЯ ДОРОГА, a.k.a. RemoteApps), и функции интеграции виртуальной машины. Важное ограничение клиентов Windows (Windows XP, Windows Vista, и Windows 7) - то, что только один ­интерактивный сеанс может быть активным за один раз. Таким образом, в то время как процессы могут продолжать работать в многократных разъединенных сеансах одновременно, только один сеанс может обновить дисплей и получить ввод мыши и клавиатура. Дальнейшее ограничение - то, что присоединенный доменом компьютер Windows XP поддерживает в большинстве только один интерактивный сеанс. Например, если пользователь зарегистрирован в консоли, можно войти в систему к компьютеру через Удаленный рабочий стол, используя ту же самую учетную запись и продолжать тот сеанс, но невозможно войти в систему с различной учетной записью пользователя, если первый пользователь не выходится из системы.

 

Терминальные сеансы служб идентифицируются постепенно увеличивающимся числовым ID сеанса, запускающимся с сеанса 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, но это никогда не сеанс 0 на Windows Vista или более новый.

Станции окна.

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

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

PsExec-s cmd.exe выполняет командную строку в станции окна $ Service-0x0-3e7 и перенаправляет ее консольный ввод-вывод к PsExec. -i опция PsExec позволяет Вам определять терминальный сеанс служб и выполняет целевой процесс в его станции окна WinSta0. PsExec описывается в Главе 6.

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

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

Каждая станция окна содержит один или более рабочих столов. Рабочий стол - объект securable с логической поверхностью отображения, на которой приложения могут представить UI в форме окон.

Примечание. Рабочие столы, описанные здесь, не связаны с Настольной абстракцией наверху пространства имен оболочки Windows Explorer.

Многократные рабочие столы могут содержать UI, но только один может быть выведен на экран за один раз. В интерактивной станции окна обычно есть три рабочих стола: Значение по умолчанию, Экранная заставка, и Winlogon.

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

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

Несколько утилит Sysinternals, включая Проводник Процесса (обсужденный в Главе 3) и Монитор Процесса (охваченный в Главе 4), идентифицируют ID сеанса TS, которому принадлежит процесс. Хотя ни одна из утилит достоверно не идентифицирует станцию окна или рабочие столы, с которыми связывается процесс, Представление Дескриптора Проводника Процесса может предложить подсказки в форме открытых дескрипторов к станциям окна или объектам рабочего стола. 

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

Сообщения окна.

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

 

Обмен сообщениями окна устанавливается администратором полноэкранного режима. Сообщения могут быть отправлены любому окну от любого потока, работающего на том же самом рабочем столе — администратор полноэкранного режима не позволяет программе отправлять сообщение окна окну на различном рабочем столе. Обработайте / Монитора, Оконечные и/WaitForldle команды должны быть вызваны от того же самого рабочего стола, на котором работает целевой экземпляр Procmon, потому что они используют окно, обменивающееся сообщениями, чтобы сказать ­существующему экземпляру завершать работу себя и решать, что целевой экземпляр готов обработать команды в форме сообщений окна.

Сообщения окна могут использоваться, чтобы моделировать действие клавиатуры или мышь. RegJump и Переход К функции в Мониторе Процесса и Автовыполнениях делают точно это, чтобы переместиться к ключу в Regedit. Из-за уровней абстракции между физическим нажатием клавиши и получающимися сообщениями окна, полученными программой GUI, для целевой ­программы эффективно невозможно ­знать с абсолютной уверенностью, была ли клавиша нажата на клавиатуре или другой программе, моделируемой нажатие клавиши, отправляя это сообщения окна. (Это верно для всех систем работы с окнами, не только Windows.)

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

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

До Windows Vista любой процесс, работающий, поскольку, определенный пользователь мог взять полный контроль над любым другим процессом, работающим как тот же самый пользователь. С Обязательным Управлением Целостностью (MIC) процессы присваиваются и выполняются на уровне целостности (IL), числовое значение, которое указывает на относительную степень доверия процесса. Поднятые приложения, выполненные в Высоких, нормальных пользовательских приложениях, выполненных в Носителе, и процессах низких прав, таких как Internet Explorer Защищенного режима, выполненный в Низко. (Проводник процесса, описанный в Главе 3, может показать IL каждого процесса.)

 

С UIPI, когда администратор полноэкранного режима добивается сообщения окна, которое может изменить состояние цели (такое как сообщение нажатия кнопки), администратор полноэкранного режима сравнивает IL процесса, отправляющего сообщение IL процесса, которому принадлежит окно, получающее сообщение. Если IL отправителя ниже чем тот из получателя, сообщение блокируется. Это - причина, что RegJump и подобный Переход К функциям должны выполниться в IL, по крайней мере, столь же высоко как тот из Regedit.

Для получения дополнительной информации о MIC и UIPI, см. Технический справочник Механизма Целостности Windows Vista в http://msdn.microsoft.com/en-us/library/bb625964.aspx.