Марапулец Ю.В. Основы программирования в Win32API

Подождите немного. Документ загружается.

80 API-функций, предназначенных для обеспечения безопасности (исключая

API-функции для шифрования данных). Тем не менее API-функции, способ-

ные хотя бы частично работать в среде Windows 98, можно пересчитать по

пальцам. Как правило, со всеми API-функциями безопасности системы Win-

dows NT связаны функции-заглушки, которые расположены в соответствую-

щих DLL-файлах. Поэтому приложение, разработанное для Windows NT, за-

гружается в среде Windows 98 без ошибок компоновки. Следовательно,

разрабатывая приложение для Windows NT, вы самостоятельно должны опре-

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

Windows 98 (если приложение вообще сможет работать в этой среде).

Для каких приложений действительно необходимо обеспечить безопас-

ность уровня системы Windows NT? Первоочередными кандидатами являются

программы, выполняемые на сервере. Кроме того, безопасность на уровне

Windows NT необходима приложениям, имеющим доступ к собственным за-

щищенным объектам (совместно используемая память, файлы, семафоры, сис-

темный реестр и т. д.), а также большинству приложений, применяемых в ка-

честве сервисов.

Для предотвращения операции несанкционированного доступа к опреде-

ленным возможностям приложения или к определенным разделам базы данных

программисту необходимо самостоятельно организовывать специальную про-

верку безопасности программы в следующей последовательности:

1. Подготовка списка всех информационных объектов и/или операций,

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

лей.

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

па, которые можно предоставлять различным пользователям и/или группам

пользователей, эксплуатирующим вашу программу.

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

осуществляется доступ к защищенным объектам или операциям.

4. Ограничение доступа к защищенным объектам извне (например, с по-

мощью стандартных функций доступа к файлам). Обычно это достигается пу-

тем установки атрибута доступа к объекту «Только для администратора» и за-

пуска приложения с привилегиями администратора, чтобы оно имело доступ к

собственному объекту.

Система безопасности в Windows NT основана на модели безопасности для

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

пользователем после входа в систему (запуск приложений, доступ к принтерам и

дискам, открытие и закрытие файлов), производится проверка того, обладает ли

пользователь соответствующими правами и привилегиями [3, 4].

API-функции безопасности в Windows NT предоставляют возможность

регистрировать события на системном уровне и на уровне приложений. Это

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

темы.

На рис. 7.1. представлена упрощенная схема механизма, с помощью кото-

рого система безопасности Windows NT отслеживает взаимодействие пользо-

вателей с объетами [4]. После того как пользователь вошел в защищенный сер-

вер, ему автоматически присваевается маркер доступа. Этот маркер закреплен

за пользователем все время, пока он находится в сети Windows NT. С другой

стороны, каждому системному объекту соотвтствует дискриптор безопасно-

сти (security descriptor – SD), который содержит различную информацию, свя-

занную с безопасностью данного объекта. С помощью маркера доступа и дискрип-

тора безопасности система защиты Windows NT проверяет при обращении к

объекту, имеет ли пользователь право работать с данным объектом.

Рис. 7.1. Упрощенная схема механизма безопасности Windows NT

В Windows NT встроенные средства безопасности реализованы только для

объектов ядра операционной системы (подсистема Kernel). Поэтому, создавая

такие объекты, как растровые рисунки, указатели мыши, перья, кисти, значки,

метафайлы или дескрипторы окон, вы не должны принимать меры по обеспе-

чению их защиты (с помощью API-функций безопасности). Но при создании

или обращении к объектам ядра (файлы, папки, устройства хранения инфор-

мации, каналы, почтовые слоты, последовательные порты, разделы реестра,

консольные устройства и принтеры) необходимо предоставлять по крайней

мере дескриптор безопасности (или указывать вместо соответствующего пара-

метра значение NULL).

В среде Win32 постоянно приходится сталкиваться с API-функциями,

предназначенными для манипулирования объектами ядра. Эти функции в

качестве аргумента всегда принимают указатель на структуру SECURI-

TY_ATTRIBUTES.

Подобные функции мы уже рассматривали ранее – при

создании потоков и процессов, например CreateThread():

HANDLE CreateThread

(LPSECURITY_ATTRIBUTES lpThreadAttributes,

// атрибуты защиты потока

DWORD dwStackSize, // размер стека в байтах

LPTHREAD_START_ROUTINE lpStartAddress,

//указатель на функцию потока

LPVOID lpParameter, // аргумент, передаваемый в функцию потока

BDWORD dwCreationFlags, // флаги управления созданием потока

LPDWORD lpThreadId,

// область памяти для возвращения идентификатора потока);…

Чаще всего вы будете применять данную функцию, просто задав значение

NULL в качестве аргумента lpThreadAttributes. Такой подход является удач-

ным при реализации большинства стандартных операций доступа. Это связано

с тем, что при задании значения NULL

используется набор параметров струк-

туры SECURITY_ATTRIBUTES,

который задан по умолчанию.

Если вам необходимо нечто большее, чем атрибуты, заданные по

умолчанию посредством значения NULL

для структуры SECU-

RITY_ATTRIBUTES,

нужно вручную сформировать эту структуру.

7.2. Состав структуры SECURITY_ATTRIBUTES

На первый взгляд, в структуре SECURITY_ATTRIBUTES

нет ничего

сложного:

typedef struct SECURITY_ATTRIBUTES

{

DWORD nLength; // размер структуры SECURITY_ATTRIBUTES;

LPVOID lpSecurityDescriptor; // дескриптор безопасности

BOOL bInheritHandle; // будет ли дескриптор наследоваться

// дочерним процессом.

}

SECURITY_ATTRIBUTES; *LPSECURITY_ATTRIBUTES;…

Заполнить поле nLength очень просто (и очень важно!) [3, 4]. Устано-

вить флаг bInheritHandle также несложно: он имеет значение типа Boolean. А

вот второе поле, которое представляет собой указатель структуры SECURI-

TY_DESCRIPTOR,

мы рассмотрим более подробно. Если вы не хотите ис-

пользовать механизмы безопасности, lpSecurltyDescriptor можно присвоить

значение NULL. Если вы намерены защитить объект от несанкционирован-

ного доступа, необходимо создать структуру SECURITY_DESCRIPTOR, со-

ответствующую этому объекту, и внести указатель на нее в структуру SE-

CURITY_ATTRIBUTES.

Структура SECURITY_DESCRIPTOR (SD) хранит в себе информацию,

связанную с защитой некоторого объекта от несанкционированного доступа. В

этой структуре содержится информация о том, какие пользователи обладают

правом доступа к объекту и какие действия эти пользователи могут выполнить

в отношении этого объекта. Следует отметить, что внутреннее строение струк-

туры SECURITY_DESCRIPTOR не документировано. Указатель на структуру

SECURITY_DESCRIPTOR в составе структуры SECURITY_ATTRIBUTES яв-

ляется указателем на тип void. Предполагается, что если вы знаете о строении

структуры SECURITY_DESCRIPTOR, значит, теоретически вы можете обойти

систему безопасности.

Дескриптор безопасности объекта хранит в себе следующую информацию:

– SID (Security ID) владельца объекта;

– SID основной группы владельца объекта;

– дискреционный список управления доступом (Discretionary Access

Control List, DACL);

– системный список управления доступом (System Access Control List,

SACL);

– управляющая информация (например, сведения о том, как списки ACL

передают информацию дочерним дескрипторам безопасности).

Идентификатор безопасности (SID) представляет собой структуру пере-

менной длины, которая однозначно идентифицирует пользователя или группу

пользователей. Внутри идентификатора безопасности (среди прочей информа-

ции) содержится 48-разрядный уникальный код аутентифицированного лица

(пользователя или группы), состоящий из значения уровня доступа, кода ос-

новного лица и кода вторичного лица.

Список DACL определяет, кто обладает (и кто не обладает) правом досту-

па к объекту. Список SACL определяет, информация о каких действиях вно-

сится в файл журнала.

Но как можно создать дескриптор безопасности, если вы не знаете его

структуры? Для этой цели следует использовать системный вызов Initialize-

SecurityDescriptor(). Этой функции следует передать указатель на дескрип-

тор безопасности SECURITY_DESCRIPTOR и значение DWORD, которое

содержит номер ревизии структуры SECURITY_DESCRIPTOR. В качестве

второго аргумента следует использовать значение

SECURITY_DESCRIPTOR_REVISION.

Функция InitializeSecurityDescriptor() инициализирует указанный вами де-

скриптор таким образом, что в нем отсутствует DASL, SACL, владелец и ос-

новная группа владельца, а все управляющие флаги установлены в значение

FALSE. При этом дескриптор имеет абсолютный формат. Что это значит? Де-

скриптор в абсолютном (absolute) формате содержит лишь указатели на ин-

формацию, связанную с защитой объекта. В отличие от этого дескриптор в от-

носительном (self-relative) формате включает в себя всю необходимую

информацию, которая располагается в памяти последовательно, поле за полем.

Таким образом, абсолютный дескриптор нельзя записать на диск (так как при

последующем чтении его с диска все указатели потеряют смысл), а относи-

тельный дескриптор – можно.

Windows позволяет преобразовывать абсолютный дескриптор в относи-

тельную форму и обратно. Обычно это требуется лишь в том случае, если вы

записываете дескриптор на диск и считываете дескриптор с диска. Системные

вызовы, требующие передачи указателя на дескриптор безопасности, работают

только с дескрипторами в абсолютном формате.

Преобразование осуществляется при помощи функций MakeSelfRelati-

veSD() и MakeAbsoluteSD(). Преобразовать абсолютную форму в относитель-

ную несложно. Однако обратное преобразование (из относительной

в абсолютную) обычно выполняется в несколько этапов. Дело в том, что при

этом необходимо подготовить несколько буферов в памяти и передать указа-

тели на них в функцию MakeAbsoluteSD().

Для работы с идентификаторами SID используются две основные функ-

ции: LookupAccountName() и LookupAccountSid(). Эти функции позволяют

преобразовать идентификатор SID в имя учетной записи и наоборот: имя учет-

ной записи – в идентификатор SID.

Если программа работает в сетевой среде, она может обратиться к этим

функциям с удаленного компьютера. Эта возможность может пригодиться, на-

пример, при разработке сервера, который обслуживает удаленных клиентов.

При обращении к любой из этих функций в качестве имени компьютера можно

указать NULL, и тогда вы сможете получить интересующие вас сведения отно-

сительно локальных пользователей.

Помимо имени или идентификатора SID каждая из этих функций также

сообщает значение перечисляемого типа, указывающее, какому классу объек-

тов соответствует этот SID (табл. 7.2). Переменная типа SID_NAME_USE со-

держит класс идентификатора SID, с которым вы имеете дело.

Чтобы получить имя текущего пользователя, следует использовать функ-

цию GetUserName(). Получив имя, вы можете определить соответствующий

SID при помощи функции LookupAccountSid().

Таблица 7.2

Имя Описание

SidTypeUser Обычный пользователь

SidTypeGroup Обычная группа

SidTypeDomain Доменное имя

SidTypeAlias Псевдоним

Окончание таблицы 7.2

SidTypeWellKnownGroup Хорошо известная группа

SidTypeDeletedAccount Старая учетная запись

SidTypeUnknown Неизвестный объект

Не всем идентификаторам SID соответствуют имена. Например, в процес-

се подключения к системе пользователю присваивается произвольный SID,

идентифицирующий текущий рабочий сеанс. Этот SID не обладает соответст-

вующим ему именем. К функциям, которые могут оказаться полезными при

работе с SID, можно отнести: AnocateAndInitializeSid(), InitializeSid(),

FreeSid(), CopySid(), IsValidSid(), GetLengthSid() и EqualSid().

Элемент управления доступом (Access Control Element, АСЕ) – это запись,

которая указывает на то, что некоторый пользователь (или группа) обладает

определенным правом. Записи АСЕ бывают трех основных разновидностей:

ACCESS_ ALLOWED_ACE_TYPE, ACCESS_DENIED_ACE_TYPE и SYS-

TEM_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 (обобщенная запись);

– GENERIC_EXECUTE (обобщенное исполнение);

– GENERIC_ALL (все права).

Этим четырем правам всегда соответствуют одни и те же биты в маске

ACCESS_MASK любой записи АСЕ.

Каждый системный объект или файл обладает индивидуальным спи-

ском ACL. Чтобы обеспечить защиту данных, о существовании которых сис-

тема не имеет представления, необходимо самостоятельно сформировать

собственный список ACL и сохранить его специальным образом.

Система безопасности может использоваться для защиты объектов не-

скольких разных типов. Для доступа к дескриптору безопасности каждого из

этих объектов следует использовать разные функции (табл. 7.3).

Чаще всего, когда говорят о защите данных, имеют в виду файлы. На

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

тупа к объектам других типов. В некоторых ситуациях может возникнуть

необходимость в создании ваших собственных объектов, доступ к которым

необходимо контролировать. Windows может не знать о существовании этих

объектов, однако это не значит, что хранящаяся в них информация не нуж-

дается в защите.

Таблица 7.3

Тип объекта Примеры Функции

Файлы (Files)

Файлы NTFS, именованные ка-

налы

GetSecurity, SetSecurity

Пользователь (User) Окна, меню

GetUserObjectSecurity, SetUse-

rObjectSecurity

Ядро ОС (Kernel)

Дескрипторы процессов и пото-

ков, объекты отображения файлов

на память, дескрипторы синхро-

низации

GetKernelObjectSecurity,

SetKernelObjectSecurity

Реестр (Registry) Ключи

RegGetKeySecurity, Reg-

SetKeySecurity

Службы (Services) Любая служба

QueryServiceObjectSecurity,

SetServiceObjectSecurity

Частный (Private)

Определяемые пользователем

объекты

CreatePrivateObjectSecurity,

GetPrivateObjectSecurity, Set-

PrivateObjectSecurity, Destroy-

PrivateObjectSecurity

Представьте, например, что вы разрабатываете базу данных, содержащую

информацию о заработках сотрудников. Для защиты этой информации можно

использовать ваши собственные списки ACL, содержащие сведения о том, кто

имеет доступ к данным о зарплате. Если база данных получает запрос от неав-

торизированного источника, система может внести сообщение об этом в жур-

нал аудита, полностью запретить доступ к базе данных или передать обратив-

шемуся клиенту все запрашиваемые им данные, за исключением секретной

информации, вместо которой будет передан символ звездочки.

Рассмотрим принцип построения списков ACL [4]. Список 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() и Ad-

dAccessAllowedAce(). Каждая из этих функций принимает в качестве аргумен-

тов указатель на буфер ACL, константу ACL_REVISION, права, которые вы

намерены предоставить или отменить, а также указатель на SID. Этот SID

идентифицирует пользователя или группу, которым соответствует АСЕ. Полу-

чить SID можно при помощи вызова LookupAccountName().

Помните, что записи АСЕ, запрещающие доступ, следует добавлять в список

в первую очередь, в противном случае Windows NT 4.0 и более ранние версии NT

будут некорректно обрабатывать взаимоисключающие АСЕ. Чтобы пояснить си-

туацию, рассмотрим следующий простой пример. Допустим, вы являетесь членом

группы ТЕСН, а также членом группы USERS. Допустим также, что в списке ACL

содержится запись, запрещающая группе USERS доступ к файлу. Другая запись

разрешает группе ТЕСН доступ к файлу. В этой ситуации вы лишены возможно-

сти прочитать файл, так как принадлежите к группе, для которой доступ к файлу

явно запрещен. Если вы не разместите все АСЕ, запрещающие доступ, в самом на-

чале списка ACL, в некоторых, версиях NT такая комбинация взаимоисключаю-

щих АСЕ будет обработана некорректно.

Когда ACL сформирован, его необходимо установить в рамках структуры

SECURITY_DESCRIPTOR. Для этого служит вызов SetSecurityDescriptorDacl().

Затем указатели на дескриптор безопасности, содержащий ACL, необходимо раз-

местить в структуре SECURITY_ATTRIBUTES, которую в свою очередь можно

передать любой API-функции, элементом которой является данная структура.

7.3. API-функции для обеспечения безопасности в ОС Windows

Рассмотрим список API-функций безопасности (табл. 7.4–7.15). В табли-

цах функции разделены на следующие категории:

– табл. 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

Изменяет группу пользователей, которой принадлежит

маркер доступа

AdjustTokenPrivileges Изменяет привилегии для маркера доступа

DuplicateToken Создает новый маркер доступа, идентичный заданному

DuplicateTokenEx

Аналогична предыдущей, но может создавать первичный

маркер доступа, используемый в функции GreateProcessAsUser

GetTokenInformation

Возвращает данные о пользователе, группе, привилегиях,

а также другую информацию, содержащуюся в маркере доступа

SetThreadToken

Присваивает заданному потоку маркер передачи полномочий

клиента

SetTokenInformation Изменяет данные о пользователе, группе, привилегиях, а так-

же другую информацию, содержащуюся в маркере доступа

OpenProcessToken Читает маркер доступа для заданного процесса

OpenThreadToken Читает маркер доступа для заданного потока

Таблица 7.5

Функция Описание

CreateProcessAsUser

Идентична функции CreateProcess(), но создает про-

цесс

с заданным маркером доступа

DdeImpersonateClient

Позволяет DDE-серверу принять полномочия DDE-

клиента для доступа к ресурсам с использованием кли-

ентских атрибутов безопасности

ImpersonateLoggedOnUser Позволяет вызываемому потоку принять полномочия

заданного пользователя (взять его маркер доступа)

ImpersonateNamedPipeClient Позволяет серверной части именованного канала

принять полномочия клиентской части

ImpersonateSelf

Возвращает маркер доступа, соответствующий вы-

зывающему процессу (часто используется для изменения

доступа на уровне потока)

LogonUser

Позволяет серверному приложению запросить мар-

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

роваться в системе от его имени

RevertToSelf Завершает процесс передачи полномочий клиента

Таблица 7.6

Функция Описание

MakeAbsoluteSD

Создает дескриптор безопасности в абсолютном

формате по образцу дескриптора в относительном

формате

MakeSelfRelativeSD

Создает дескриптор безопасности в относитель-

ном формате по образцу дескриптора в абсолютном

формате

InitializeSecurityDescriptor

Инициализирует новый дескриптор безопасно-

сти; при этом ему не присваиваются права

IsValidSecurityDescriptor Проверяет правильность дескриптора безопасности

GetSecurityDescriptorControl

Возвращает информацию об уровне доступа для

дескриптора безопасности

GetSecurityDescriptorLength

Возвращает размер заданного дескриптора безо-

пасности в байтах

GetSecurityDescriptorDacl

Возвращает указатель на DACL для заданного

дескриптора безопасности

GetSecurityDescriptorGroup

Возвращает указатель на идентификатор безо-

пасности основной группы для заданного дескрипто-

ра безопасности

GetSecurityDescriptorOwner

Возвращает указатель на идентификатор безо-

пасности владельца для заданного дескриптора

безопасности

GetSecurityDescriptorSacl

Возвращает указатель на SACL для заданного

дескриптора безопасности

SetSecurityDescriptorDacl

Обновляет информацию о DACL для заданного

дескриптора безопасности

Окончание таблицы 7.7

SetSecurityDescriptorGroup

Обновляет идентификатор безопасности группы

для заданного дескриптора безопасности

SetSecurityDescriptorOwner

Обновляет идентификатор безопасности вла-

дельца для заданного дескриптора безопасности

SetSecurityDescriptorSad

Обновляет информацию о SACL для заданного

дескриптора безопасности

Таблица 7.7

100