Система управления доступом

Система хранит идентификаторы безопасности в бинарной форме, однако существует и текстовая форма представления SID. Текстовая форма используется для вывода текущего значения SID, а также для интерактивного ввода (например, в реестр).

В текстовой форме каждый идентификатор безопасности имеет определенный формат. Вначале находится префикс S, за которым следует группа чисел, разделенных дефисами. Например, SID администратора системы имеет вид: S-1-5-<домен>-500, а SID группы everyone, в которую входят все пользователи, включая анонимных и гостей - S-1-1-0.

Поскольку структура SID имеет переменную длину, для копирования SID и преобразования его в текстовую форму и обратно рекомендуется прибегать к специальным функциям CopySID, ConvertSidToStringSid и ConvertStringSidToSid.

Чтобы получить бинарное значение SID по имени пользователя, нужно использовать функцию LookupAccountName. Обратная задача может быть решена при помощи функции LookupAccountSid.

Прогон программы получения идентификатора безопасности

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

#define _WIN32_WINNT 0x0500

#define UNICODE
#ifdef UNICODE
#define _UNICODE
#endif


#include <windows.h>
#include <stdio.h>
#include <sddl.h>


void main(void){

 wchar_t UserName[256];
 int MaxUserNameLength = 256; 
 
 SID Sid[1024];
 PSID pSid;
 LPTSTR StringSid;
 DWORD SidSize=1024;  
 SID_NAME_USE SidType;
 
 LPTSTR DomainName=NULL;
 DWORD DomainNameSize=16; // длина имени домена
 

 HANDLE hHeap;
 hHeap = GetProcessHeap();
 pSid = Sid[0];


 GetUserName(UserName, MaxUserNameLength); // получаем имя пользователя

 DomainName = (LPTSTR)HeapAlloc(hHeap,0,DomainNameSize * sizeof(TCHAR));

 LookupAccountName(
                   NULL,           // локальный компьютер
                   UserName, pSid, SidSize, DomainName,DomainNameSize,SidType);

 if (!ConvertSidToStringSid(pSid, StringSid))   /* память для строки выделяет сама  функция */
	 printf("Convert SID to string SID failed.");
 wprintf(L"StringSid %s\n", StringSid);

 LocalFree(StringSid);
 HeapFree(hHeap,0,DomainName);
}

В приведенной программе вначале формируются параметры вызова функции LookupAccountName. В частности, имя текущей учетной записи возвращает функция GetUserName(). Кроме того, необходимо выделить память для имени домена. Результирующее значение SID можно сравнить с тем, которое выдает утилита Whoami.exe.

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

На основе предыдущей программы рекомендуется написать программу, которая при помощи функции LookupAccountSid решает обратную задачу - позволяет выяснить имя владельца данного идентификатора безопасности.

Объекты. Дескриптор защиты

В ОС Windows все типы объектов защищены одинаковым образом. С каждым объектом связан дескриптор защиты (security descriptor). Дескриптор защиты описывается структурой типа SECURITY_DESCRIPTOR и инициализируется функцией InitializeSecurityDescriptor.

Связь объекта с дескриптором происходит в момент создания объекта. Например, один из аргументов функции CreateFile - указатель на структуру SECURITY_ATTRIBUTES, которая содержит указатель на дескриптор защиты.

Дескриптор защиты (см. рис 13.1) содержит SID владельца объекта, SID групп для данного объекта и два указателя на списки DACL (Discretionary ACL) и SACL (System ACL) контроля доступа. DACL и SACL содержат разрешающие и запрещающие доступ списки пользователей и групп, а также списки пользователей, чьи попытки доступа к данному объекту подлежат аудиту.

Структура каждого ACL списка проста. Это набор записей ACE (Access Control Entry), каждая запись содержит SID и перечень прав, предоставленных субъекту с этим SID.

В списке ACL есть записи ACE двух типов - разрешающие и запрещающие доступ. Разрешающая запись содержит SID пользователя или группы и битовый массив (access mask), определяющий набор операций, которые процессы, запускаемые этим пользователем, могут выполнять с данным объектом. Запрещающая запись действует аналогично, но в этом случае процесс не может выполнять перечисленные операции. Битовый массив или маска доступа состоит из 32 битов и обычно формируется программным образом из предопределенных констант, которые описаны в файлах-заголовках компилятора (главным образом в файле WinNT.h). Формат маски доступа можно посмотреть, например, в , .

На примере, изображенном на рис 13.1, владелец файла Александр имеет право на все операции с данным файлом, всем остальным обычно дается только право на чтение, а Павлу запрещены все операции. Таким образом, список DACL описывает все права доступа к объекту. Если этого списка нет, то все пользователи имеют все права; если этот список существует, но он пустой, права имеет только его владелец.

Кроме списка DACL дескриптор защиты включает также список SACL, который имеет такую же структуру, что и DACL, то есть состоит из таких же ACE записей, только вместо операций, регламентирующих доступ к объекту, в нем перечислены операции, подлежащие аудиту. В примере на рис 13.1 операции с файлом процессов, запускаемых Сергеем, описанные в соответствующем битовом массиве будут регистрироваться в системном журнале.

Итак, дескриптор защиты имеет достаточно сложную структуру и его формирование выглядит непростой задачей. К счастью, в Windows есть стандартный механизм, назначающий доступ к объектам "по умолчанию", если приложение не позаботилось создать его явно. В таких случаях говорят, что объекту назначена стандартная защита. Примером может служить создание файла при помощи функции CreateFile, где параметру-указателю на структуру SECURITY_ATTRIBUTES присвоено значение NULL. Некоторые объекты используют только стандартную защиту (мьютексы, события, семафоры).

Субъекты хранят информацию о стандартной защите, которая будет назначена создаваемым объектам, в своем маркере доступа (см. следующий раздел). Разумеется, в ОС Windows есть все необходимые средства для настройки стандартной защиты, в частности, списка DACL "по умолчанию", в маркере доступа субъекта.

Основной источник информации о защите объекта - Win32-функция GetSecurityInfo, тогда как настройка защиты объекта может быть осуществлена при помощи функции SetSecurityInfo.

Прогон программы получения информации из дескриптора защиты файла

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

#define _WIN32_WINNT 0x0500
#ifndef UNICODE
#define UNICODE
#endif

#include <windows.h>
#include <stdio.h>
#include <sddl.h>
#include <Aclapi.h>

void main(void){

 PSID pSid;
 PSECURITY_DESCRIPTOR pSD;
 PACL pDACL;
 LPTSTR StringSid = NULL;
 ULONG Error;
 HANDLE hFile;
 
 hFile = CreateFile(TEXT("MyFile.txt"), READ_CONTROL, 0, NULL, OPEN_EXISTING,
                                  FILE_ATTRIBUTE_NORMAL, NULL);
 
 Error = GetSecurityInfo(hFile, 
	                  SE_FILE_OBJECT,        // тип объекта
	                  OWNER_SECURITY_INFORMATION | DACL_SECURITY_INFORMATION, 
                         pSid,                 // Sid владельца
			     NULL,                  // Sid группы
			     pDACL, NULL,   // списки прав доступа
			     pSD         // дескриптор защиты);
   if(Error != ERROR_SUCCESS) printf("GetSecurityInfo Error\n");

 
 if (!ConvertSidToStringSid(pSid, StringSid)) /* память для строки выделяет сама  функция */
  printf("Convert SID to string SID failed.");
 
wprintf(L"StringSid %s\n", StringSid);
 
 LocalFree(pSD);
 LocalFree(StringSid);
}

Задача данной программы - открыть существующий файл MyFile.txt и применить функцию GetSecurityInfo для извлечения идентификатора безопасности владельца из дескриптора защиты файла. Затем идентификатор преобразуется в текстовую форму и выводится на экран.

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

На основе предыдущей программы рекомендуется написать программу, которая выводит на экран список прав доступа к обозначенному файлу.

Субъекты безопасности. Процессы, потоки. Маркер доступа

Так же как и объекты, субъекты должны иметь отличительные признаки - контекст пользователя, для того, чтобы система могла контролировать их действия. Сведения о контексте пользователя хранятся в маркере (употребляются также термины "токен", "жетон") доступа. При интерактивном входе в систему пользователь обычно вводит свое имя и пароль. Система (процедура Winlogon) по имени находит соответствующую учетную запись, извлекает из нее необходимую информацию о пользователе, формирует список привилегий, ассоциированных с пользователем и его группами, и все это объединяет в структуру данных, которая называется маркером доступа. Маркер также хранит некоторые параметры сессии, например, время окончания действия маркера. Таким образом, именно маркер является той визитной карточкой, которую субъект должен предъявить, чтобы осуществить доступ к какому-либо объекту.

Вслед за оболочкой (Windows Explorer) все процессы (а также все потоки процесса), запускаемые пользователем, наследуют этот маркер. Когда один процесс создает другой при помощи функции CreateProcess, дочернему процессу передается дубликат маркера, который, таким образом, распространяется по системе.

Основные компоненты маркера доступа показаны на рис 13.2.

Включая в маркер информацию о защите, в частности, DACL, Windows упрощает создание объектов со стандартными атрибутами защиты. Как уже говорилось, если процесс не позаботится о том, чтобы явным образом указать атрибуты безопасности объекта, на основании списка DACL, присутствующего в маркере, будут сформированы права доступа к объекту по умолчанию. Настройку стандартной защиты можно осуществить при помощи функции , .

Если процесс обладает правом TOKEN_QUERY доступа к объекту, то большую часть содержимого маркера можно считать при помощи функции GetTokenInformation. Чтобы получить описатель маркера, необходимо воспользоваться функцией OpenProcessToken.

В качестве примера рассмотрим программу, задача которой - получение текстового значения Sid владельца процесса из маркера доступа данного процесса.

#define _WIN32_WINNT 0x0500
#ifndef UNICODE
#define UNICODE
#endif

#include <windows.h>
#include <stdio.h>
#include <sddl.h>

void main(void){
 
 DWORD TokenUserBufSize=256;
 LPTSTR StringSid;
 TOKEN_USER *ptUser;
 HANDLE hHeap;
 HANDLE hToken   = NULL;

 hHeap = GetProcessHeap();
 ptUser = (TOKEN_USER *)HeapAlloc(hHeap, HEAP_ZERO_MEMORY, TokenUserBufSize); 

 if (!OpenProcessToken(GetCurrentProcess(), TOKEN_QUERY, hToken)) 
           printf("OpenProcessToken Error\n");

 if (!GetTokenInformation(hToken,  // описатель маркера доступа
	                   TokenUser, // нужна информация о пользователе
				ptUser,  // буфер для информации
				TokenUserBufSize, TokenUserBufSize))  
           printf("GetTokenInformation Error\n");;
      
 if (!ConvertSidToStringSid(ptUser->User.Sid, StringSid))  
	 printf("Convert SID to string SID failed.");
  wprintf(L"StringSid %s\n", StringSid);

 CloseHandle(hToken);
 LocalFree(StringSid);
 HeapFree(hHeap,0,ptUser);
}

Задача данной программы - получить описатель текущего процесса при помощи функции OpenProcessToken и применить функцию GetTokenInformation для извлечения из него идентификатора безопасности владельца. После чего идентификатор преобразуется в текстовую форму и выводится на экран.

В следующей лекции будет приведен пример программы получения из маркера доступа информации о привилегиях пользователя.

Написание, компиляция и прогон программы получения стандартного списка контроля доступа к объектам из маркера доступа процесса

На основе предыдущей программы рекомендуется написать программу, которая выводит на экран список прав доступа "по умолчанию" для объектов, создаваемых данным процессом.

Проверка прав доступа

После формализации атрибутов защиты субъектов и объектов можно перечислить основные этапы проверки прав доступа , , , см. рис 13.3.

Этапов проверки довольно много. Наиболее важные этапы из них:

Очевидно, что для процедуры проверки важен порядок расположения ACE в DACL. Поэтому Microsoft предлагает так называемый предпочтительный порядок размещения ACE. Например, для ускорения рекомендуется размещать запрещающие элементы перед разрешающими.

Заключение

Подсистема защиты данных является одной из наиболее важных. В центре системы безопасности ОС Windows находится система контроля доступом. Реализованные модели дискреционного и ролевого доступа являются удобными и широко распространены, однако не позволяют формально обосновать безопасность приложений в ряде случаев, представляющих практический интерес. С каждым процессом или потоком, то есть, активным компонентом (субъектом), связан маркер доступа, а у каждого защищаемого объекта (например, файла) имеется дескриптор защиты. Проверка прав доступа обычно осуществляется в момент открытия объекта и заключается в сопоставлении прав субъекта списку прав доступа, который хранится в составе дескриптора защиты объекта.

Приложение. Формальные модели защищенности в ОС Windows

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

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

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

Имеется совокупность объектов {Oi}, субъектов {Si} и пользователей {Ui}. Вводится операция доступа {Si} -> {Oj}, под которой подразумевается использование i-м субъектом информации из j-го объекта. Основные варианты доступа: чтение, запись и активация процесса, записанного в объекте. В результате последней операции появляется новый субъект {Si} -> {Oj} -> {Sk}.

Во время загрузки создается ряд субъектов (системных процессов), и к их числу принадлежит оболочка S_shell, с помощью которой прошедшие аутентификацию пользователи могут создавать свои субъекты (запускать свои программы). При помощи выполняемых программ пользователи осуществляют доступ к объектам (например, осуществляют чтение файлов). В итоге деятельность такого пользователя может быть описана ориентированным графом доступа (см. рис 13.4).

Множество графов доступа можно рассматривать как фазовое пространство, а функционирование конкретной системы - как траекторию в фазовом пространстве. Защита информации может состоять в том, чтобы избегать "неблагоприятных" траекторий. Практически такое управление возможно только ограничением на доступ в каждый момент времени, или, как утверждается в известной "оранжевой" книге , все вопросы безопасности информации определяются описанием доступов субъектов к объектам.

Можно ввести также особый вид субъекта, который активизируется при каждом доступе и называется монитором обращений. Если монитор обращений в состоянии отличить легальный доступ от нелегального и не допустить последний, то такой монитор называется монитором безопасности (МБ) и является одним из важнейших компонентов системы защиты.

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

Модели управления доступом регламентируют доступ субъектов к объектам. Наиболее распространена так называемая дискреционная (произвольная) модель, в которой обычные пользователи могут принимать участие в определении функций политики и присвоении атрибутов безопасности. Среди дискреционных моделей классической считается модель Харрисона-Руззо-Ульмана (см. ) - в ней система защиты представлена в виде набора множеств, элементами которых являются составные части системы защиты: субъекты, объекты, уровни доступа, операции и т.п.

С концептуальной точки зрения текущее состояние прав доступа при дискреционном управлении описывается матрицей (см. рис 13.5), в строках которой перечислены субъекты, в столбцах - объекты, а в ячейках - операции, которые субъект может выполнить над объектом. Операции зависят от объектов. Например, для файлов это операции чтения, записи, выполнения, изменения атрибутов, а для принтера - операции печати и управления. Поведение системы моделируется с помощью понятия состояния Q = (S,O,M), где S,O,M - соответственно текущие множества субъектов, объектов и текущее состояние матрицы доступа.

С учетом дискреционной модели можно следующим образом сформулировать задачу системы защиты информации. С точки зрения безопасности, поведение системы может моделироваться как последовательность состояний, описываемых совокупностью субъектов, объектов и матрицей доступа. Тогда можно утверждать, что для безопасности системы в состоянии Q0 не должно существовать последовательности команд, в результате которой право R будет занесено в ячейку памяти матрицы доступа M, где оно отсутствовало в состоянии Q0. (критерий Харрисона-Руззо-Ульмана). По существу необходимо ответить на вопрос: сможет ли некоторый субъект S когда-либо получить какие-либо права доступа к некоторому объекту O?

Очевидно, что для обеспечения безопасности необходимо наложить запрет на некоторые отношения доступа. Харрисон, Руззо и Ульман доказали, что в общем случае не существует алгоритма, который может для произвольной системы, ее начального состояния Q0 и общего права r решить, является ли данная конфигурация безопасной. Чтобы удовлетворить критерию безопасности в общем случае, в ИС должны отсутствовать некоторые операции создания и удаления сущностей, в результате чего эксплуатация подобной системы теряет практический смысл.

Каналы утечки информации в системах с дискреционным доступом

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

Очевидно, что для каждого субъекта S, активизированного в момент времени t, существует единственный активизированный субъект S', который активизировал субъект S. Поэтому можно, анализируя граф, подобный изображенному на рис 13.5, выявить единственного пользователя, от имени которого активизирован субъект S.

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

В этом случае схематичное изображение канала утечки в виде разрешенного доступа от имени разных пользователей к одному и тому же объекту будет выглядеть следующим образом:

Ui -> (Write)-> O, в момент времени t1 и Uj -> (Read)-> O в момент времени t2, где i≠j и t1 < t2,

Фактически это означает, что ничто не мешает легальному пользователю (например, вследствие программной ошибки) перебросить секретную информацию во вновь созданный объект, доступ к которому открыт всем желающим, или организовать скрытый канал утечки при помощи троянского коня.

Итак, формальный анализ показывает, что безопасное использование систем с дискреционным контролем доступа предполагает наличие дополнительных защитных мер, а именно - тщательное проектирование и корректную реализацию системы защиты.

Ролевая политика безопасности

Другая возможность, предоставляемая ОС Windows - управление ролевым, в частности привилегированным доступом. Ролевая политика предназначена в первую очередь для упрощения администрирования информационных систем с большим числом пользователей и различных ресурсов.

В ролевой политике управление доступом осуществляется с помощью правил. Вначале для каждой роли указывается набор привилегий по отношению к системе и полномочий, представляющих набор прав доступа к объектам, и уже затем каждому пользователю назначается список доступных ему ролей. Классическое понятие субъект замещается понятиями пользователь и роль. Примером роли является присутствующая почти в каждой системе роль суперпользователя (группа Administrator для ОС Windows). Количество ролей обычно не соответствует количеству реальных пользователей - один пользователь может выполнять несколько ролей, и наоборот, несколько пользователей могут в рамках одной и той же роли выполнять типовую работу.

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