§ 7.1.Технологиибезопасности,реализованныев Windows
Ранее указывалось, что ОС Windows линейки 9x является незащищенной, в отли-
чие от Windows линейки NT, системой. Поэтому рассмотренный далее материал будет в
основном посвящен средствам защиты, реализованным в NT. Но следует отметить, что
некоторые элементы безопасности в Windows 98 все же были добавлены [4]:
• поддержка защищенных каналов;
• поддержка интеллектуальных карточек (smart cards);
• встроенная поддержка API-функций, предназначенных для выполнения операций
шифрования;
• встроенная поддержка алгоритма Authenticode;
• встроенная поддержка программы Microsoft Wallet (бумажник Microsoft).
Поддержка защищенных каналов осуществляется с помощью протокола РРТР
(Point to Point Tunneling Protocol), который позволяет устанавливать безопасное соеди-
нение с удаленной сетью даже посредством незащищенной сети. Такая связь устанавли-
вается с помощью зашифрованных инкапсулированных пакетов и обеспечивает возмож-
ность вложения одного протокола в другой. Например, таким образом пользователь
может подключиться к Internet с помощью протоколов TCP/IP и установить защищенное
IPX-соединение со своей офисной сетью. Обеспечивается поддержка SSL 3.0, новой
версии протокола SSL (Secured Sockets Layer), что повышает степень безопасности при
обмене данными по сетям Internet и intranet.
Поддержка операций с интеллектуальными карточками реализована в виде двух-
уровневой модели, включающей драйверы устройств считывания карточек, а также на-
бор API-функций, предназначенных для аутентификации, записи и чтения данных. Ин-
теллектуальные карточки выполняют, по крайней мере, три важные функции:
аутентификацию пользователей при входе в систему (вместо паролей или в сочетании с
ними); проведение финансовых операций по Internet и другим сетям;
хранение информации о человеке, например индивидуальные противопоказания к ле-
карствам или история болезни.
Поддержка API криптографии, технологии Authenticode и программы Microsoft
Wallet реализована в виде модулей, которые инсталлируются при установке Internet Ex-
plorer.
В табл. 7.1 перечислены возможности подсистем безопасности, реализованные в
Windows 95, Windows 98 и Windows NT.
Таблица 7.1
Технология
Windows 95
Windows 98 Windows 2000
Authenticode
PPTP-клиент
Надстройка (IE4) Есть
Надстройка (IE4) Есть
Есть
Есть
PPTP-сервер
Нет
Есть
Есть
Интеллектуальные карточки
API криптографии
Microsoft Wallet
Надстройка (IE4) Есть
Надстройка (IE4) Есть
Надстройка (IE4) Есть
Есть
Есть
Есть
Безопасность на уровне групп
Частично
Частично
Есть
Безопасность на уровне файлов Нет
Нет
Есть
Права и привилегии доступа для
отдельных объектов
Нет
Нет
Есть
Как показано в табл. 7.1, Windows NT и Windows 98 имеют много общих техноло-
гий безопасности, в частности технологии, связанные с Internet. Однако в Windows NT
они реализованы на более высоком уровне.
Хорошим примером различия между уровнями безопасности Windows NT и Win-
dows 98 является доступ к файлам. В Windows 98 (и Windows 95) защита обеспечивается
только на уровне доступа к диску и к папке. В указанных системах нельзя установить
индивидуальные права доступа к отдельным файлам. Отчасти это обусловлено тем, что
в среде Windows 98 существует много различных способов доступа к файлу: посредст-
вом DOS-прерываний, функций BIOS, функций Windows API, а также средств различ-
ных языков программирования (Pascal, C++ и т.д.). Из-за такого изобилия возможностей
доступа к файлам возникает множество "лазеек" в системе защиты, которые очень слож-
но предусмотреть и устранить, не прерывая работу текущих приложений [1, 7].
Технологии безопасности реализуются с помощью специального набора API-
функций, который называется API безопасности. Хотя этот набор входит в состав под-
системы Win32 API, он полностью реализован только в Windows NT. С точки зрения
программистов, это означает, что полная безопасность может быть обеспечена лишь в
этой системе. Такой вывод никого не удивит, ведь всем известно, что основное преиму-
щество Windows NT перед Windows 98 - это встроенная разветвленная система безопас-
ности.
В настоящее время в операционной системе Windows NT имеется около 80 API-
функций, предназначенных для обеспечения безопасности (исключая API-функции для
шифрования данных). Тем не менее API-функции, хотя бы частично способные работать
в среде Windows 98, можно пересчитать по пальцам. Как правило, со всеми API-
функциями безопасности системы Windows NT связаны функции-заглушки, которые
расположены в соответствующих DLL-файлах. Поэтому приложение, разработанное для
Windows NT, загружается в среде Windows 98 без ошибок компоновки. Следовательно,
разрабатывая приложение для Windows NT, вы самостоятельно должны определить, ка-
кие из его возможностей должны использоваться при работе в среде Windows 98 (если
приложение вообще сможет работать в этой среде).
Для каких приложений действительно необходимо обеспечить безопасность уров-
ня системы Windows NT? Первоочередными кандидатами являются программы, выпол-
няемые на сервере. Кроме того, безопасность на уровне Windows NT необходима при-
ложениям, имеющим доступ к собственным защищенным объектам (совместно
используемая память, файлы, семафоры, системный реестр и т.д.), а также большинству
приложений, применяемых в качестве сервисов.
Для предотвращения операции несанкционированного доступа к определенным
возможностям приложения или к определенным разделам базы данных, программисту
необходимо самостоятельно организовывать специальную проверку безопасности про-
граммы в следующей последовательности [1].
• Подготовка списка всех информационных объектов и/или операций, доступ к кото-
рым нельзя предоставлять без проверки полномочий пользователей.
• Разработка логической схемы специальных прав и привилегий доступа, которые
можно предоставлять различным пользователям и/или группам пользователей, экс-
плуатирующим вашу программу.
• Задание в своей программе проверки безопасности везде, где осуществляется доступ
к защищенным объектам или операциям.
• Ограничение доступа к защищенным объектам извне (например, с помощью стан-
дартных функций доступа к файлам). Обычно это достигается путем установки атри-
бута доступа к объекту "Только для администратора" и запуска приложения с приви-
легиями администратора, чтобы оно имело доступ к собственному объекту.
Система безопасности в Windows NT основана на модели безопасности длякаж-
догопользователя. При выполнении всех операций, которые активизируются пользова-
телем после входа в систему (запуск приложений, доступ к принтерам и дискам, откры-
тие и закрытие файлов), производится проверка того, обладает ли пользователь
соответствующими правами и привилегиями [1, 7].
API-функции безопасности в Windows NT предоставляют возможность регистри-
ровать события на системном уровне и на уровне приложений. Это позволяет опреде-
лить, кто и когда имел доступ к различным компонентам системы. После того как поль-
зователь вошел на защищенный сервер, ему автоматически присваивается маркер
доступа. Этот маркер закреплен за пользователем все время, пока он находится в сети
Windows NT. С другой стороны, каждому системному объекту соответствует дескрип-
торбезопасности (security descriptor - SD), который содержит различную информацию,
связанную с безопасностью данного объекта. С помощью маркера доступа и дескрипто-
ра безопасности система защиты Windows NT проверяет при обращении к объекту, име-
ет ли пользователь право работать с данным объектом.
В Windows NT встроенные средства безопасности реализованы только для объек-
тов ядра операционной системы (подсистема Kernel). Поэтому, создавая такие объекты,
как растровые рисунки, указатели мыши, перья, кисти, значки, метафайлы или дескрип-
торы окон, вы не должны принимать меры по обеспечению их защиты (с помощью API-
функций безопасности). Но при создании или обращении к объектам ядра (файлы, пап-
ки, устройства хранения информации, каналы, почтовые слоты, последовательные пор-
ты, разделы реестра, консольные устройства и принтеры) необходимо предоставлять, по
крайней мере, дескриптор безопасности (или указывать вместо соответствующего пара-
метра значение NULL).
В среде Win32 постоянно приходится сталкиваться с API-функциями, предназна-
ченными для манипулирования объектами ядра. Эти функции в качестве аргумента все-
гда принимают указатель на структуру SECURITY_ATTRIBUTES. Подобные функции
мы уже рассматривали ранее, например при создании потоков и процессов, например
CreateThread().
HANDLE CreateThread (
LPSECURITY_ATTRIBUTES lpThreadAttributes,// привилегии доступа
DWORD dwStackSize,
// по умолчанию равен 0
LPTHREAD_START_ROUTINE lpStartAddress, // указатель на стартовую
// функцию
LPVOID lpParameter,
DWORD dwCreationFlags,
LPDWORD lpThreadId);
// значение, передаваемое
// функции
// активное состояние или
//состояние ожидания
// здесь система возвращает
// идентификатор потока
Чаще всего программист применяет данную функцию, просто задав значение
NULL в качестве аргумента lpSecurityAttributes. Такой подход является удачным при
реализации большинства стандартных операций доступа. Это связано с тем, что при за-
дании значения NULL используется набор параметров структуры SECURI-
TY_ATTRIBUTES, который задан по умолчанию.
Если необходимо нечто большее, чем атрибуты, заданные по умолчанию посредст-
вом значения NULL для структуры SECURITY_ATTRIBUTES, нужно вручную сформи-
ровать эту структуру.
§ 7.2.Созданиеструктуры SECURITY_ATTRIBUTES
На первый взгляд, в структуре SECURITY_ATTRIBUTES нет ничего сложного:
typedef struct _SECURITY_ATTRIBUTES
{
}
DWORD nLength;
LPVOID lpSecurityDescriptor;
BOOL bInheritHandle;
// размер структуры SECURITY_ATTRIBUTES;
// дескриптор безопасности
// будет ли дескриптор наследоваться
// дочерним процессом.
SECURITY_ATTRIBUTES; *LPSECURITY_ATTRIBUTES;
Заполнить поле nLength очень просто (и очень важно!) [1]. Установить флаг bInhe-
ritHandle также несложно: он имеет значение типа Boolean. А вот второе поле, которое
представляет собой указатель структуры SECURITY_DESCRIPTOR, мы рассмотрим бо-
лее подробно. Если вы не хотите использовать механизмы безопасности,
lpSecurltyDescriptor можно присвоить значение NULL. Если вы намерены защитить объ-
ект от несанкционированного доступа, необходимо создать структуру SECURI-
TY_DESCRIPTOR, соответствующую этому объекту, и внести указатель на нее в струк-
туру SECURITY_ATTRIBUTES.
Структура SECURITY_DESCRIPTOR (SD) хранит в себе информацию, связанную
с защитой некоторого объекта от несанкционированного доступа. В этой структуре со-
держится информация о том, какие пользователи обладают правом доступа к объекту и
какие действия эти пользователи могут выполнить в отношении этого объекта. Следует
отметить, что внутреннее строение структуры SECURITY_DESCRIPTOR не документи-
ровано. Указатель на структуру SECURITY_DESCRIPTOR в составе структуры SECU-
RITY_ATTRIBUTES является указателем на тип void. Предполагается, что если вы знае-
те о строении структуры SECURITY_DESCRIPTOR, значит, теоретически вы можете
обойти систему безопасности.
Дескриптор безопасности объекта хранит в себе следующую информацию:
• SID (Security ID) владельца объекта;
• SID основной группы владельца объекта;
• дискреционный список управления доступом (Discretionary Access Control List,
DACL);
• системный список управления доступом (System Access Control List, SACL);
• управляющая информация (например, сведения о том, как списки ACL передают
информацию дочерним дескрипторам безопасности).
Идентификатор безопасности (SID) представляет собой структуру переменной
длины, которая однозначно идентифицирует пользователя или группу пользователей.
Внутри идентификатора безопасности (среди прочей информации) содержится 48-
разрядный уникальный код аутентифицированного лица (пользователя или группы), со-
стоящий из значения уровня доступа, кода основного лица и кода вторичного лица.
Список DACL определяет, кто обладает (и кто не обладает) правом доступа к объ-
екту. Список SACL определяет, информация о каких действиях вносится в файл журна-
ла.
Но как можно создать дескриптор безопасности, если вы не знаете его структуры?
Для этой цели следует использовать системный вызов InitializeSecurityDescriptor. Этой
функции следует передать указатель на дескриптор безопасности SECURI-
TY_DESCRIPTOR и значение DWORD, которое содержит номер ревизии структуры
SECURITY_DESCRIPTOR. В качестве второго аргумента следует использовать значе-
ние SECURITY_DESCRIPTOR_REVISION.
Функция InitializeSecurityDescriptor инициализирует указанный вами дескриптор
таким образом, что в нем отсутствует DAСL, SACL, владелец и основная группа вла-
дельца, а все управляющие флаги установлены в значение FALSE. При этом дескриптор
имеет абсолютный формат. Что это значит? Дескриптор в абсолютном (absolute) форма-
те содержит лишь указатели на информацию, связанную с защитой объекта. В отличие
от этого дескриптор в относительном (self-relative) формате включает в себя всю необ-
ходимую информацию, которая располагается в памяти последовательно поле за полем.
Таким образом, абсолютный дескриптор нельзя записать на диск (так как при после-
дующем чтении его с диска все указатели потеряют смысл), а относительный дескрип-
тор - можно.
Windows позволяет преобразовывать абсолютный дескриптор в относительную
форму и обратно. Обычно это требуется лишь в случае, если вы записываете дескриптор
на диск и считываете дескриптор с диска. Системные вызовы, требующие передачи ука-
зателя на дескриптор безопасности, работают только с дескрипторами в абсолютном
формате.
Преобразование осуществляется при помощи функций MakeSelfRelativeSD и Ma-
keAbsoluteSD. Преобразовать абсолютную форму в относительную несложно. Однако
обратное преобразование (из относительной в абсолютную) обычно выполняется в не-
сколько этапов. Дело в том, что при этом необходимо подготовить несколько буферов в
памяти и передать указатели на них в функцию MakeAbsoluteSD.
Для работы с идентификаторами SID используются две основные функции: Looku-
pAccountName и LookupAccountSid. Эти функции позволяют преобразовать идентифи-
катор SID в имя учетной записи, и наоборот, имя учетной записи в идентификатор SID.
Если программа работает в сетевой среде, она может обратиться к этим функциям
с удаленного компьютера. Эта возможность может пригодиться, например, при разра-
ботке сервера, который обслуживает удаленных клиентов. При обращении к любой из
этих функций в качестве имени компьютера можно указать NULL, и тогда вы сможете
получить интересующие вас сведения относительно локальных пользователей.
Помимо имени или идентификатора SID каждая из этих функций также сообщает
значение перечисляемого типа, указывающее, какому классу объектов соответствует
этот SID (табл. 7.2). Переменная типа SID_NAME_USE содержит класс идентификатора
SID, с которым вы имеете дело.
Таблица 7.2
Имя
SidTypeUser
SidTypeGroup
SidTypeDomain
SidTypeAlias
Обычный пользователь
Обычная группа
Доменное имя
Псевдоним
Описание
SidTypeWellKnownGroup Хорошо известная группа
SidTypeDeletedAccount
SidTypeUnknown
Старая учетная запись
Неизвестный объект
Чтобы получить имя текущего пользователя, следует использовать функцию GetU-
serName. Получив имя, вы можете определить соответствующий SID при помощи функ-
ции LookupAccountSid.
Не всем идентификаторам SID соответствуют имена. Например, в процессе под-
ключения к системе пользователю присваивается произвольный SID, идентифицирую-
щий текущий рабочий сеанс. Этот SID не обладает соответствующим ему именем. К
функциям, которые могут оказаться полезными при работе с SID, можно отнести: Ano-
cateAndInitializeSid, InitializeSid, FreeSid, CopySid, IsValidSid, GetLengthSid и EqualSid.
Элемент управления доступом (Access Control Element, АСЕ) - это запись, которая
указывает на то, что некоторый пользователь (или группа) обладает определенным пра-
вом. Записи АСЕ бывают трех основных разновидностей; ACCESS_ AL-
LOWED_ACE_TYPE, ACCESS_DENIED_ACE_TYPE и SYSTEM_AUDIT_ACE_TYPE.
Запись АСЕ первого типа наделяет пользователя (или группу) некоторым правом. За-
пись второго типа отменяет это право в отношении пользователя (или группы). Запись
третьего типа обозначает необходимость осуществления аудита при пользовании пра-
вом.
Список управления доступом (Access Control List, ACL) - это набор записей АСЕ.
Дискреционный список DACL содержит записи типа ACCESS_ALLOWED_ACE_TYPE
и ACCESS_DENIED_ACE_TYPE, а системный список SACL содержит записи типа
SYSTEM AUDIT_ACE_TYPE.
Каждая запись АСЕ, определяющая уровень доступа к объекту, обладает 32-
битной маской ACCESS_MASK. Эта маска является набором бит, которые определяют,
какие права предоставляет или отменяет данная запись АСЕ. Значение каждого бита оп-
ределяется объектом, по отношению к которому применяется данная АСЕ. Например,
набор прав, которые можно назначить в отношении семафора, отличается от набора
прав, которые можно назначить в отношении файла. Все же существуют четыре права,
которые можно назначить в отношении абсолютно любого защищаемого объекта, это:
GENERIC_READ (обобщенное чтение), GENERIC_WRITE (обобщенная запись), GE-
NERIC_EXECUTE (обобщенное исполнение) и GENERIC_ALL (все права). Этим четы-
рем правам всегда соответствуют одни и те же биты в маске ACCESS_MASK любой за-
писи АСЕ.
Каждый системный объект или файл обладает индивидуальным списком ACL.
Чтобы обеспечить защиту данных, о существовании которых система не имеет пред-
ставления, необходимо самостоятельно сформировать собственный список ACL и со-
хранить его специальным образом.
Система безопасности может использоваться для защиты объектов нескольких
разных типов. Для доступа к дескриптору безопасности каждого из этих объектов следу-
ет использовать разные функции (табл. 7.3).
Таблица 7.3
Тип объекта
Файлы (Files)
Пользователь (User)
Ядро ОС (Kernel)
Реестр (Registry)
Примеры
Файлы NTFS, именованные
каналы
Окна, меню
Дескрипторы процессов и
потоков, объекты отобра-
жения в память, и т.д.
КлючиRegGetKeySecurity,
Функции
GetSecurity, SetSecurity
GetUserObjectSecurity,
SetUserObjectSecurity
GetKernelObjectSecurity,
SetKernelObjectSecurity
RegSetKeySecurity
Службы (Services)
Любая службаQueryServiceObjectSecurity,
SetServiceObjectSecurity
Частный (Private)
Определяемые пользовате-
лем объекты
CreatePrivateObjectSecurity,
GetPrivateObjectSecurity,
SetPrivateObjectSecurity,
DestroyPrivateObjectSecurity
Чаще всего, когда говорят о защите данных, имеют в виду файлы. На самом деле в
некоторых ситуациях может потребоваться ограничить доступ к объектам других типов.
В некоторых ситуациях может возникнуть необходимость в создании ваших собствен-
ных объектов, доступ к которым необходимо контролировать. Windows может не знать о
существовании этих объектов, однако это не значит, что хранящаяся в них информация
не нуждается в защите.
Представьте, например, что вы разрабатываете базу данных, содержащую инфор-
мацию о заработках сотрудников. Для защиты этой информации можно использовать
ваши собственные списки ACL; содержащие сведения о том, кто имеет доступ к данным
о зарплате. Если база данных получает запрос от неавторизированного источника, сис-
тема может внести сообщение об этом в журнал аудита, полностью запретить доступ к
базе данных или передать обратившемуся клиенту все запрашиваемые им данные за ис-
ключением секретной информации, вместо которой будет передан символ звездочки.
Рассмотрим принцип построения списков ACL [1]. Список ACL - это область па-
мяти, содержащая заголовок ACL и некоторое количество (или ни одной) записей АСЕ.
В свою очередь, запись АСЕ включает в себя ACE_HEADER и одну из структур:
ACCESS_ALLOWED_ACE
(соответствует
разрешающей
записи)
или
ACCESS_DENIED_ACE (соответствует запрещающей записи). При заполнении списков
АСЕ в Windows NT 4.0 (и в более ранних версиях) следовало следить за тем, чтобы за-
писи типа ACCESS_DENIED_ACE располагались в списке раньше, чем все остальные
записи. Дело в том, что запрещающие записи имеют больший вес, чем разрешающие за-
писи. Если в списке ACL одна запись разрешает некоторому пользователю доступ к
объекту, а другая запись запрещает этому же пользователю доступ к этому же объекту,
то в силу вступает именно запрещающая запись. В этом случае разрешающая запись иг-
норируется, и пользователь теряет право на доступ к объекту. В Windows NT 4.0 это ус-
ловие выполнялось только в случае, если запрещающие записи располагались в начале
списка ACL.
Одной из проблем, возникающих при работе с ACL, является то обстоятельство,
что для того, чтобы сформировать список ACL, вы должны вычислить его точный раз-
мер. Список ACL должен обладать размером, достаточным для того, чтобы вместить в
себя все АСЕ. Однако разные записи АСЕ могут включать в себя разное количество
байт. Таким образом, задача вычисления размера ACL может оказаться непростой.
Размер записи АСЕ зависит от ее типа и длины SID, который в ней содержится.
Для записей АСЕ, разрешающих доступ, длина записи составляет:
L= sizeof(ACCESS_ALLOWED_ACE) - sizeof(ACCESS_ALLOWED_ACE.SidStart) +
GetLengthSid((PSID)ace.SidStart);
Как видно, к длине заголовка (за вычетом длины первой части SID) добавляется
длина SID.
Таким образом, размер ACL равняется размеру структуры ACL плюс сумма разме-
ров всех АСЕ, входящих в список. Зачастую возникает соблазн не тратить время на рас-
четы, а просто зарезервировать достаточно большой буфер в памяти и предположить,
что выделенного места должно хватить для размещения всего списка. В общем случае
такой подход не запрещается - ACL может обладать размером, большим, чем размер,
достаточный для хранения всех его записей.
Когда вы получили достаточно объемный буфер, вы должны инициализировать
ACL при помощи вызова InitializeAcl. После этого можно добавлять в список записи
АСЕ. Для этого служат функции AddAccessDeniedAce и AddAccessAllowedAce. Каждая
из этих функций принимает в качестве аргументов указатель на буфер ACL, константу
ACL_REVISION, права, которые вы намерены предоставить или отменить, а также ука-
затель на SID. Этот SID идентифицирует пользователя или группу, которым соответст-
вует АСЕ. Получить SID можно при помощи вызова LookupAccountName.
Помните, что записи АСЕ, запрещающие доступ, следует добавлять в список в
первую очередь, в противном случае Windows NT 4.0 и более ранние версии NT будут
некорректно обрабатывать взаимоисключающие АСЕ. Чтобы пояснить ситуацию, рас-
смотрим следующий простой пример. Допустим, я являюсь членом группы ТЕСН, а
также членом группы USERS. Допустим, в списке ACL содержится запись, запрещаю-
щая для группы USERS доступ к файлу. Другая запись разрешает доступ к файлу для
группы ТЕСН. В этой ситуации я не должен иметь возможности прочитать файл, так как
я принадлежу к группе, для которой доступ к файлу явно запрещен. Если вы не размес-
тите все АСЕ, запрещающие доступ, в самом начале списка ACL, в некоторых, версиях
NT такая комбинация взаимоисключающих АСЕ будет обработана некорректно.
Когда ACL сформирован, его необходимо установить в рамках структуры SECU-
RITY_DESCRIPTOR. Для этого служит вызов SetSecurityDescriptorDacl. Затем указатели
на дескриптор безопасности, содержащий ACL, необходимо разместить в структуре SE-
CURITY_ATTRIBUTES, которую, в свою очередь, можно передать любой API функции,
элементом которой является данная структура.
§ 7.3. API-функциидляобеспечениябезопасности Windows
В таблицах 7.4-7.15 приведено описание API-функций безопасности. В таблицах
функции разделены на следующие категории [4]:
• Таблица 7.4 - функции для операций с маркерами доступа;
• Таблица 7.5 - функции, используемые в процессе передачи полномочий клиента;
• Таблица 7.6 - функции для операций с дескрипторами безопасности;
• Таблица 7.7 - функции для операций с идентификаторами безопасности;
• Таблица 7.8 - функции для операций с записями в списках управления доступом;
• Таблица 7.9 - функции для операций со списками управления доступом;
• Таблица 7.10 - функции для проверки прав доступа;
• Таблица 7.11 - функции для операций с привилегиями;
• Таблица 7.12 - функции для операций с окнами-станциями;
• Таблица 7.13 - функции для операций с Local Service Authority;
• Таблица 7.14 - функции для получения информации, связанной с безопасностью;
• Таблица 7.15 - функции аудита.
Таблица 7.4
Функция
AdjustTokenGroups
AdjustTokenPrivileg-
es
DuplicateToken
DuplicateTokenEx
Описание
Изменяет группу, которой принадлежит маркер доступа
Изменяет привилегии для маркера доступа
Создает новый маркер доступа, идентичный заданному
Аналогична предыдущей, но может создавать первичный маркер
доступа, используемый в функции GreateProcessAsUser
GetTokenInformation Возвращает данные о пользователе, группе, привилегиях, а также
другую информацию, содержащуюся в маркере доступа
SetThreadToken
Присваивает заданному потоку маркер передачи полномочий
SetTokenInformation Изменяет данные о пользователе, группе, привилегиях, а также
другую информацию, содержащуюся в маркере доступа
OpenProcessToken
OpenThreadToken
Функция
Читает маркер доступа для заданного процесса
Читает маркер доступа для заданного потока
Описание
Таблица 7.5
CreateProcessAsUser
DdeImpersonateClient
Идентична функции CreateProcess, но создает процесс с
заданным маркером доступа
Позволяет DDE-серверу принять полномочия DDE-
Поделиться:
Поиск по сайту
Все права принадлежать их авторам. Данный сайт не претендует на авторства, а предоставляет бесплатное использование.
Дата создания страницы: 2016-04-02
Нарушение авторских прав и Нарушение персональных данных