Форма входа
0/0
Сущность технологии СОМ. Библиотека программиста - Дональд Бокс
- Дата:20.06.2024
- Категория: Компьютеры и Интернет / Программирование
- Название: Сущность технологии СОМ. Библиотека программиста
- Автор: Дональд Бокс
- Просмотров:3
- Комментариев:0
Уважаемые читатели!
Тут можно читать бесплатно Сущность технологии СОМ. Библиотека программиста - Дональд Бокс. Жанр: Программирование. Так же Вы можете читать полную версию (весь текст) онлайн книги без регистрации и SMS на сайте Knigi-online.info (книги онлайн) или прочесть краткое содержание, описание, предисловие (аннотацию) от автора и ознакомиться с отзывами (комментариями) о произведении.
Описание онлайн-книги Сущность технологии СОМ. Библиотека программиста - Дональд Бокс:
В этой книге СОМ исследуется с точки зрения разработчика C++. Написанная ведущим специалистом по модели компонентных объектов СОМ, она раскрывает сущность СОМ, помогая разработчикам правильно понять не только методы модели программирования СОМ, но и ее основу. Понимание мотивов создания СОМ и ее аспектов, касающихся распределенных систем, чрезвычайно важно для тех разработчиков, которые желают пойти дальше простейших приложений СОМ и стать по-настоящему эффективными СОМ-программистами. Показывая, почему СОМ для распределенных систем (Distributed СОМ) работает именно так, а не иначе, Дон Бокс дает вам возможность применять эту модель творчески и эффективно для ежедневных задач программирования.
Читем онлайн Сущность технологии СОМ. Библиотека программиста - Дональд Бокс
Шрифт:
-
+
Интервал:
-
+
Закладка:
Сделать
При использовании уровня аутентификации RPC_AUTHN_LEVEL_CONNECT никакого дополнительного обмена информацией, касающейся защиты, после проверки начальных полномочий не осуществляется. Это означает, что программы-злоумышленники могут перехватывать сообщения в сети и воспроизводить RPC-запросы путем простого изменения порядковых номеров DCE (среды распределенных вычислений) в заголовках пакетов. Для дополнительной защиты от воспроизведения вызова следовало бы использовать уровень аутентификации RPC_C_AUTHN_LEVEL_CALL. Он информирует библиотеки SSP DLL о необходимости защиты RPC-заголовка первого пакета каждого запроса или отклика RPC путем привязывания к передаваемому пакету однонаправленного хэш-ключа (на базе случайных чисел). Поскольку запрос или отклик RPC может быть помещен частями в более чем один сетевой пакет, то RPC API поддерживает также уровень аутентификации RPC_C_AUTHN_LEVEL_PKT. Этот уровень защищает от воспроизведения на уровне сетевых пакетов, что является большей защитой, чем уровень RPC_C_AUTHN_LEVEL_CALL, поскольку RPC-сообщение может занимать два пакета или более.
До уровня аутентификации RPC_C_AUTHN_LEVEL_PKT включительно SSP DLL в большей или меньшей мере игнорирует фактическую полезную нагрузку RPC-пакетов и защищает только целостность RPC-заголовков. Для того чтобы убедиться, что состояние маршалированного параметра не изменено вражеским агентом в сети, в RPC предусмотрен уровень аутентификации RPC_C_AUTHN_LEVEL_PKT_INTEGRITY. Этот уровень предписывает SSP DLL вычислять контрольную сумму состояния маршалированного параметра и проверять, что содержимое пакета не было изменено в процессе передачи. Поскольку при этом уровне аутентификации каждый передаваемый байт должен обрабатываться с помощью SSP DLL, она проходит значительно медленнее, чем при уровне RPC_C_AUTHN_LEVEL_PKT, и его следует использовать только в ситуациях, требующих особой защиты.
До уровня аутентификации RPC_C_AUTHN_LEVEL_PKT_INTEGRITY включительно фактическое содержание RPC-пакетов пересылается как открытый текст (например, незашифрованный). Для обеспечения невидимости состояния маршалированного параметра для вражеских агентов сети в RPC предусмотрен уровень аутентификации RPC_C_AUTHN_LEVEL_PKT_PRIVACY. Данный уровень аутентификации предписывает SSP DLL зашифровывать состояние маршалированного параметра до передачи. Подобно всем прочим уровням аутентификации уровень RPC_C_AUTHN_LEVEL_PKT_PRIVACY включает в себя защиту всех уровней ниже себя. Как и в случае RPC_C_AUTHN_LEVEL_PKT_INTEGRITY, каждый передаваемый байт должен обрабатываться SSP DLL, поэтому во избежание излишних издержек этот уровень аутентификации следует использовать только в особых с точки зрения безопасности ситуациях.
Наиболее важной API-функцией в службе безопасности COM является CoInitializeSecurity. Каждый процесс, использующий COM, вызывает CoInitializeSecurity ровно один раз, явно или неявно. Функция CoInitializeSecurity вводит автоматические установки по защите. Эти установки применяются ко всем импортируемым и экспортируемым ссылкам на объекты, за исключением явно переопределенных с использованием дополнительных вызовов API-функций. Чтобы использовать один или нескольких модулей защиты, CoInitializeSecurity конфигурирует используемый исполняемый слой RPC, а также устанавливает уровень аутентификации, принимаемый по умолчанию для процесса. Кроме того, CoInitializeSecurity позволяет вызывающей программе указать, каким пользователям разрешено делать ORPC-запросы на объекты, экспортируемые из текущего процесса. CoInitia1izeSecurity имеет довольно большое число параметров:
HRESULT CoInitializeSecurity(
[in] PSECURITY_DESCRIPTOR pSecDesc, // access control
// контроль за доступом
[in] LONG cAuthSvc, // # of sec pkgs (-1 == use defaults)
// количество модулей защиты (-1 == используем по умолчанию)
[in] SOLE_AUTHENTICATION_SERVICE *rgsAuthSvc, // SSP array
// массив SSP
[in] void *pReserved1, // reserved MBZ
// зарезервировано, должен быть О
[in] DWORD dwAuthnLevel, // auto, AUTHN_LEVEL
// аутентификация AUTHN_LEVEL
[in] DWORD dwImpLevel, // auto. IMP_LEVEL
// аутентификация IMP_LEVEL
[in] void *pReserved2, // reserved MBZ
// зарезервировано, должен быть О
[in] DWORD dwCapabilities, // misc flags
// различные флаги
[in] void *pReserved3 // reserved MBZ
// зарезервировано, должен быть О
);
Некоторые из этих параметров применяются только в тех случаях, когда процесс выступает как экспортер/сервер. Другие – только если процесс действует как импортер/клиент. Остальные применяются в обоих случаях.
Первый параметр функции CoInitializeSecurity, pSecDesc, применим только в случае, когда процесс выступает как экспортер. Этот параметр используется для контроля того, каким принципалам – пользователям или процессам, имеющим учетную запись (principals) – разрешен доступ к объектам, экспортируемым из данного процесса. В деталях этот параметр будет обсужден позже в данной главе. Второй и третий параметры функции CoInitializeSecurity, соответственно cAuthSvc и rgsAuthSvc, используются при работе процесса в качестве экспортера для регистрации одного или нескольких модулей защиты с помощью библиотеки COM. Эти два параметра ссылаются на массив описаний модулей защиты:
typedef struct tagSOLE_AUTHENTICATION_SERVICE {
DWORD dwAuthnSvc; // which authentication package?
// какой модуль защиты?
DWORD dwAuthzSvc; // which authorization service?
// какая служба авторизации?
OLECHAR *pPrincipalName; // server principal name?
// имя серверного принципала?
HRESULT hr; // result of registration
// результат регистрации
} SOLE_AUTHENTICATION_SERVICE;
В Windows NT 4.0 единственной установленной службой аутентификации является RPC_C_AUTHN_WINNT (NTLM). При использовании аутентификации NTLM служба авторизации (authorization service – сервис контроля доступа, определяющий права клиента) должна быть указана как RPC_C_AUTHZ_NONE, а имя серверного принципала не используется и должно быть нулевым[1]. Для тех процессов, которые просто хотят использовать пакет (пакеты) защиты по умолчанию на отдельной машине, следует использовать значения: cAuthSvc, равное -1, и rgsAuthSvc, равное нулю.
Пятый параметр функции CoInitializeSecurity, dwAuthnLevel, применим как к экспортируемым, так и к импортируемым объектным ссылкам. Величина, заданная для этого параметра, устанавливает предельно низкий уровень аутентификации для объектных ссылок, экспортируемых из этого процесса. Это означает, что поступающие ORPC-запросы должны иметь по крайней мере такой уровень аутентификации; в противном случае этот вызов будет отклонен. Эта величина определяет также минимальный уровень аутентификации, используемый новыми интерфейсными заместителями, которые возвращаются API-функциями или методами COM. Создавая новый интерфейсный заместитель во время демаршалинга, COM рассматривает число, обозначающее нижний уровень аутентификации, заданный экспортером, как часть разрешения OXID. Затем COM устанавливает уровень аутентификации нового заместителя равным или нижнему уровню экспортера, или нижнему уровню текущего процесса – в зависимости от того, какой из них выше. Если процесс, импортирующий объектную ссылку, имеет уровень аутентификации ниже, чем экспортирующий процесс, то для установки уровня аутентификации используется нижний уровень экспортера. Такой способ гарантирует, что любые ORPC-запросы, посылаемые интерфейсным заместителем, пройдут через нижний уровень экспортера. Далее в этой главе будет рассмотрено, как с целью более детального контроля можно явным образом изменить уровень аутентификации для отдельного интерфейсного заместителя[2].
Шестой параметр функции CoInitializeSecurity, dwImpLevel применяется для импортируемых объектных ссылок. Величина, определенная для этого параметра, устанавливает уровень заимствования прав (impersonation level), используемый для всех объектных ссылок, которые возвращаются функцией CoUnmarshalInterface. Уровень заимствования прав позволяет одному процессу заимствовать атрибуты защиты у другого процесса и отражает степень доверия, которое клиент испытывает к серверу. Этот параметр должен принимать одно из следующих четырех значений, характеризующих уровень заимствования прав:
enum {
// hide credentials of caller from object
// скрываем от объекта полномочия вызывающей программы
RPC_C_IMP_LEVEL_ANONYMOUS = 1,
// allow object to query credentials of caller
// разрешаем объекту запрашивать полномочия вызывающей программы
RPC_C_IMP_LEVEL_IDENTIFY = 2,
// allow use of caller's credentials up to one-hop away
// разрешаем использовать полномочия вызывающей
// программы не далее одной сетевой передачи
RPC_C_IMP_LEVEL_IMPERSONATE = 3,
// allow use of caller's credentials across multiple hops
// разрешаем использовать полномочия вызывающей
// программы в течение нескольких сетевых передач
RPC_C_IMP_LEVEL_DELEGATE = 4
};
Уровень RPC_C_IMP_LEVEL_ANONYMOUS не позволяет реализации объекта обнаружить идентификатор безопасности вызывающей программы[3]. Уровень доверия RPC_C_IMP_LEVEL_IDENTIFY указывает, что реализация объекта может программно определить идентификатор защиты вызывающей программы. Уровень доверия RPC_C_IMP_LEVEL_IMPERSONATE указывает, что сервер может не только определить идентификатор защиты вызывающей программы, но также выполнить операции на уровне операционной системы с использованием полномочий вызывающей программы. На этом уровне доверия объекты могут использовать полномочия вызывающей программы, но имеют доступ только к локальным ресурсам[4]. В противоположность этому, уровень доверия RPC_C_IMP_LEVEL_DELEGATE разрешает серверу доступ как к локальным, так и к удаленным ресурсам с использованием полномочий вызывающей программы. Этот уровень доверия не поддерживается протоколом аутентификации NTLM, но поддерживается протоколом аутентификации Kerberos.
На этой странице вы можете бесплатно читать книгу Сущность технологии СОМ. Библиотека программиста - Дональд Бокс бесплатно.
Похожие на Сущность технологии СОМ. Библиотека программиста - Дональд Бокс книги
- Аквариум. (Новое издание, исправленное и переработанное) - Виктор Суворов (Резун) - Шпионский детектив
- Права на результаты интеллектуальной деятельности и средства индивидуализации: Комментарий к части четвертой Гражданского кодекса Российской Федерации - Вадим Погуляев - Юриспруденция
- У меня есть идея! Что дальше? - Михаил Соболев - О бизнесе популярно
- Ориентирование - К. М. Станич - Современные любовные романы
- Проект 365 - Константин Рочев - Поэзия
