Во время предыдущего обсуждения акцент делался на том, что в нормальном режиме методы объекта выполняются с использованием маркера доступа процесса объекта. Однако не обсуждался вопрос о том, как проконтролировать, какой принципал защиты должен использоваться для создания начального маркера серверного процесса. Когда SCM запускает серверный процесс, то он присваивает новому серверному процессу маркер, основанный на конфигурации именованной величины RunAs из AppID. Если же в AppID нет величины RunAs, то считается, что сервер неправильно сконфигурирован для работы в режиме распределенного доступа. Для того чтобы этот тип серверного процесса не внедрял указанные «дыры» в защите в систему, SCM запускает такие процессы с использованием того принципала защиты, который произвел запрос на активацию. Такой тип активации часто называют активацией «как активизатор» («As Activator»), так как серверный процесс выполняет тот же принципал защиты, что и запускающий пользователь. Активация типа «как активизатор» предназначена для поддержки удаленной активации старых серверов и содержит несколько ловушек. Во-первых, чтобы придерживаться семантики типа «как активизатор», COM запустит отдельный серверный процесс для каждой активационной учетной записи пользователя, независимо от того, используется ли REGCLS_MULTIPLEUSE в CoRegisterClassObject. Это вступает в серьезный конфликт с принципом расширяемости и вдобавок делает невозможным сохранение всех экземпляров класса в одном и том же процессе. Во-вторых, каждый серверный процесс запускается с маркером, ограниченным уровнем RPC_C_IMP_LEVEL_IMPERSONATE, из чего следует, что серверные процессы не имеют доступа ни к каким удаленным ресурсам или объектам[1].
В идеале серверные процессы конфигурируются для запуска как отдельные принципалы защиты. Управлять этим можно, помещая именованную величину RunAs в имя учетной записи в AppID:
[HKCR\AppID\{27EE6A4D-DF65-11d0-8C5F-0080C73925BA}]
RunAs="DomainX\UserY"
Если эта именованная величина присутствует, SCM будет использовать указанное имя учетной записи для создания нового регистрационного маркера (login token) и присвоит этот маркер серверному процессу. Для правильной работы этой схемы требуются два условия. Во-первых, соответствующий пароль должен быть записан в определенном месте реестра в качестве ключа локальных средств защиты (LSA – Local Security Authority). Во-вторых, указанная учетная запись пользователя должна иметь полномочия «Вход в систему как пакетное задание» («Logon as a batch job»). При установке значения RunAs утилита DCOMCNFG.EXE обеспечивает выполнение обоих этих условий[2].
Для предотвращения спуфинга (spoofing, получение доступа путем обмана) классов злонамеренными программами CoRegisterClassObject проверяет, зарегистрирован ли AppID данного класса. Если AppID имеет установку RunAs, то COM гарантирует, что принципал вызывающей программы совпадает с именем принципала, записанным в реестре. Если же вызывающая программа не имеет указанной учетной записи RunAs для AppID класса, то вызов метода CoRegisterСlassObject будет отклонен и возвратится известный HRESULT CO_E_WRONG_SERVER_IDENTITY. Поскольку конфигурационные установки COM записаны в защищенной части реестра, только привилегированные пользователи могут изменять список соответствия классов и пользователей.
Важно отметить, что когда в AppID имеется явная учетная запись пользователя RunAs, то SCM всегда будет запускать серверный процесс в его собственной отдельной window-станции (window station)[3]. Это означает, что серверный процесс не может с легкостью ни создавать окна, видимые для интерактивного пользователя на данной машине, ни принимать информацию с клавиатуры, от мыши или из буфера (clipboard). Вообще говоря, такая защита полезна, поскольку не дает простым (naive) серверам COM влиять на деятельность пользователя, работающего на машине[4]. К сожалению, иногда серверному процессу бывает необходимо связаться с авторизовавшимся (logged on) в данный момент пользователем. Одним из способов достижения этого является использование для управления window-станциями и рабочими столами (desktop) явных API-функций COM, что дает потоку возможность временно выполняться на интерактивном рабочем столе. При выполнении на интерактивном рабочем столе любые окна, которые создает поток, будут видимы интерактивному пользователю, и, кроме того, поток может получать аппаратные сообщения (hardware messages) от клавиатуры и мыши. Если же все, что нужно, – это получить от пользователя ответ типа да/нет, то на этот случай в API-функции Win32 MessageBox имеется флаг MB_SERVICE_NOTIFICATION, при выставлении которого, без какого-либо добавочного кода, на интерактивном рабочем столе появится окно сообщения.
Если требуется расширенное взаимодействие с интерактивным пользователем, то использование Win32 API window-станции может стать весьма громоздким. Лучшим подходом могло бы стать выделение компонентов пользовательского интерфейса во второй внепроцессный сервер, который сможет работать на window-станции, отличной от той, на который запущена основная иерархия объектов. Чтобы заставить серверный процесс, содержащий компоненты пользовательского интерфейса, работать при интерактивной пользовательской window-станции, COM распознает характерное значение RunAs «Interactive User» («Интерактивный пользователь»):
[HKCR\AppID\{27EE6A4D-DF65-11d0-8C5F-0080C73925BA}]
RunAs="Interactive User"
При использовании этого значения COM запускает новый серверный процесс в window-станции, соответствующей подсоединенному в текущий момент пользователю. Для запроса полномочий для нового серверного процесса COM при создании этого нового серверного процесса просто копирует маркер текущего интерактивного сеанса. Это означает, что в реестр не требуется записывать никаких паролей. К сожалению, и этот режим активации не обходится без ловушек. Во-первых, если активационный запрос поступает в момент, когда на хост-машине не зарегистрировано ни одного пользователя, то активационный запрос даст сбой с результатом E_ACCESSDENIED. Кроме того, если интерактивный пользователь выйдет из сети в тот момент, когда у серверного процесса еще есть подключенные клиенты, то серверный процесс будет преждевременно прерван, что приведет к грубому отсоединению всех существующих в тот момент заместителей. И наконец, часто невозможно предсказать, какой пользователь будет подсоединен во время активации, что усложняет обеспечение достаточных прав и привилегий доступа ко всем необходимым ресурсам для данного объекта. Эти ограничения сводят применимость такого режима активации к простым компонентам пользовательского интерфейса[5].