Какие методы управления доступом вам известны windows

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

Размещено 27/02/2007

Благодаря применению в операционной системе Windows XP файловой системы NTFS обеспечивается ряд дополнительных возможностей защиты данных; версии Windows, не имеющие этой файловой системы, таких возможностей не обеспечивают. Одна из этих возможностей — управление доступом. С помощью таблиц управления доступом пользователь Windows XP может ограничить доступ к своим данным, размещенным на компьютере или в сети на жестких дисках формата NTFS. Средства управления доступом позволяют ограничить доступ к файлам для конкретного пользователя, компьютера или группы пользователей.

Настройка разрешений для файлов и папок.

Настройка разрешений задает тип доступа, разрешенный пользователю или группе. Например, всему финансовому отделу предоставляется разрешение на запись и чтение файла payroll.dat, содержащего данные платежной ведомости организации. При настройке разрешений устанавливается уровень доступа для групп и пользователей. Например, одному из пользователей разрешается читать содержимое файла, другому — вносить изменения в файл, а всем остальным пользователям запрещается любой доступ к файлу. Для принтеров устанавливаются аналогичные разрешения, позволяющие некоторым пользователям настраивать принтеры, а остальным — только печатать на них. Изменить разрешения, связанные с файлом или папкой, может только их владелец или тот, кому предоставлено соответствующее разрешение.

Разрешения для группы.

Лучше присваивать разрешения не пользователям, а группам, поскольку при этом исчезает необходимость управлять доступом для каждого отдельного пользователя. Если это возможно, следует вместо отдельных разрешений предоставлять разрешение Full control (Полный контроль). Настройка Deny (Запретить) применяется, чтобы исключить какую-либо подгруппу той группы, для которой установлено разрешение Allowed (Разрешено), или отменить отдельное разрешение для группы или пользователя, которым уже предоставлен полный контроль.

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

Как настроить, просмотреть, изменить или удалить разрешения для файла и папки.

1. Откройте проводник Windows, для этого нажмите кнопку Start (Пуск), выберите последовательно пункты All Programs (Все программы), Accessories (Стандартные) и щелкните Windows Explorer (Проводник).

2. Найдите файл или папку, для которых требуется настроить разрешения.

3. Щелкните файл или папку правой кнопкой мыши, выберите пункт Properties (Свойства) и щелкните вкладку Security (Безопасность). (Если вкладка Security (Безопасность) не видна, это может означать, что компьютер не подключен к домену).

4. Выполните одно из следующих действий:

5. Выполните одно из следующих действий:

6. Если флажки в поле Permissions for user or group (Разрешения для пользователя или группы) затенены или кнопка Remove (Удалить) недоступна, то файл или папка унаследовали разрешения, установленные для родительской папки.

Как вывести на экран вкладку Security.

На вкладке View (Вид) в группе Advanced settings (Дополнительные параметры) снимите флажок Use simple file sharing [Recommended] (Использовать простой общий доступ к файлам (рекомендуется)).

Источник

Какие методы управления доступом вам известны windows xp

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

Дискретное разграничение прав доступа

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

В файловой системе NTFS в Windows XP существует шесть стандартных разрешений:

В Windows 10 нет стандартного разрешения «Список содержимого папки».

Эти разрешения могут предоставляться пользователю (или группе пользователей) для доступа к папкам и файлам. При этом право «Полный доступ» включат в себя все перечисленные права, и позволяет ими управлять.

Права доступа назначаются пользователю для каждого объекта (папки и файла). Для назначения прав нужно открыть меню «Свойства» и выбрать вкладку «Безопасность». После этого выбрать необходимо пользователя, которому будут назначаться разрешения.

Создайте папки по названиям разрешений, всего у вас будет 6 папок для Windows XP и для Windows 10. Я рассмотрю на примере Windows XP, на «десятке» вам будет проще. Скачайте папки по ссылке и скопируйте в них содержимое (не сами папки, а то, что в них находится).

Отройте вкладку «Безопасность» в свойствах папки «Список содержимого папки». У меня есть пользователь user, вы можете добавить своего. Для того, что бы изменить право на объект нужно выбрать пользователя и указать ему разрешение, в данном случае «Список содержимого папки». Затем нажмите «Применить» и «ОК».

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

По аналогии установите права для соответствующих папок.

После установки прав доступа проверьте их. Для этого войдите в операционную систему под пользователем, для которого устанавливали права, в моем случае это user.

«Список содержимого папки» — предоставляет возможность просмотра файлов и папок в текущем каталоге. То есть вы можете посмотреть, что есть в папке, но запустить и открыть ничего не получиться.

«Чтение и выполнение» — предоставляет возможность открывать в данном каталоге все файлы.

«Запись» — предоставляет возможность добавления файлов в папку без права на доступ к вложенным в него объектам, в том числе на просмотр содержимого каталога.

«Изменить» — предоставляет возможность открывать и создавать (изменять) файлы в папке.

«Полный доступ» — предоставляет все возможности для работы с папкой и вложенными файлами, включая изменение разрешений.

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

Содержимое папки «Список содержимого» Ошибка запуска исполняемого файла Ошибка текстового файла

Элементы разрешений на доступ

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

Просмотреть элементы разрешений на доступ можно, нажав на кнопку «Дополнительно» во вкладке «Безопасность» и выбрав любой элемент разрешений.

Поэкспериментируйте с элементами и проверьте, как они работаю.

Элементы разрешений на доступ для записи

Владелец файла

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

Узнать, какой пользователь является владельцем файла или папки можно на закладке «Владелец» в дополнительных параметрах безопасности.

Наследование прав доступа

В файловой системе NTFS поддерживается наследование разрешений. Если вы устанавливаете разрешение на папку, то оно наследуется для всех вложенных файлов и папок.

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

Для изменения унаследованных разрешений нужно открыть вкладку «Разрешения» в дополнительных параметрах безопасности. Там же можно отключить наследование разрешений.

Запреты

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

Запреты на объекты в файловой системе NTFS

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

Разграничение прав доступа с помощью Secret Net (на примере версии 5.1)

При использовании Secret Net доступ к файлам осуществляется, в случае если пользователю присваивается соответствующий уровень допуска. В примере я использую Windows XP с установленным программным продуктом Secret Net 5.1.

Первым делом нужно запустить локальные параметры безопасности от имени Администратора: «Пуск –> Программы –> Secret Net 5 –> Локальная политика безопасности».

Далее необходимо перейти в «Параметры Secret Net» –> «Настройка подсистем» –> «Полномочное управление доступом: название уровней конфиденциальности».

Введите названия уровней. У меня это:

Настройка субъектов

Настройка субъектов в Secret Net производится в группе «Локальные пользователи и группы». Зайдите в меню «Пуск» –> «Программы» –> «Secret Net 5» –> «Управление компьютером» –> «Локальные пользователи и группы» –> «Пользователи».

Что бы настроить права администратора нужно выбрать учетную запись «Администратор» и перейти на вкладку Secret Net 5. Установим уровень доступа «секретно».

Далее установите все флажки.

После установки всех флажков нажмите «Применить» и «ОК».

Создадим нового пользователя. Для этого нужно перейти «Локальные пользователи и Группы» –> «Пользователи». Создайте новых пользователей, я назову их «Конфиденциальный» и «Секретный». По аналогии с пользователем Администратор установите для новых пользователей аналогичные уровни доступа и настройки как на рисунках ниже.

Настройка объектов

Та или иная категория конфиденциальности является атрибутом папки или файла. Изменения этих атрибутов производятся уполномоченными пользователями (в данном случае Администратором). Категория конфиденциальности может присваиваться новым файлам или папкам автоматически или по запросу.

Автоматическое присваивание категории конфиденциальности можно включить или отключить в окне настройки свойств папки. Этот параметр может редактировать только пользователь, у которого есть права на «Редактирование категорий конфиденциальности».

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

Попробуйте создать в паке новый файл или каталог, а после чего изменить ее уровень (повысить) и установить флажок «Автоматически присваивать новым файлам». У вас появиться окно «Изменение категорий конфиденциальности».

Выберите пункт «Присвоение категорий конфиденциальности всем файлам в каталоге» и нажмите «ОК» для присвоения категории конфиденциальности всем файлам кроме скрытых и системных файлов.

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

Если пользователь с категорией «Общедоступно» попробует прочитать или удалить документ, то он получит соответствующие ошибки.

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

Если вы зайдете под пользователем «Секретный» то вы сможете повысить уровень конфиденциальности файлов и работать с ними.

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

Контроль потоков данных

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

Для этого нужно запустить «Локальные параметры безопасности»: «Пуск» – «Программы» –> «Secret Net 5» –> «Локальная политика безопасности», затем перейти в группу «Параметры Secret Net» –> «Настройки подсистем» и выбрать параметр «Полномочное управление доступом: Режим работы» и включить контроль потоков. Изменения вступят в силу после перезагрузки компьютера.

Если зайти (после перезагрузки) под пользователем «Секретный» появиться выбор уровня конфиденциальности для текущего сеанса. Выберите секретный уровень.

Если вы откроете файл с уровнем «Конфиденциально», отредактируете его и попробуете сохранить под другим именем и в другую папку, то вы получите ошибку, так как уровень сеанса (секретный) выше, чем уровень файла (конфиденциальный) и включен контроль потоков данных.

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

Обучаю HTML, CSS, PHP. Создаю и продвигаю сайты, скрипты и программы. Занимаюсь информационной безопасностью. Рассмотрю различные виды сотрудничества.

Источник

1 Введение

1.1 Цели и область применения

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

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

1.2 Используемые термины

Доступ субъекта к объекту для определенных операций.

Контейнер информации в системе

Сущность определяющая пользователя при работе в системе

Человек выполняющий действия в системе или приложение выступающее от его имени.

2 Методы управления доступом

2.1 Общее описание

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

На данный момент существует три различных метода для управления доступом к объектам в системе:

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

Диаграмма 1: Системы контроля доступа

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

2.2 Модель дискреционного контроля за доступом

2.2.1 Общее описание

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

Гибкость DAC позволяет использовать его в большом количестве систем и приложений. Благодаря этому этот метод очень распространен, особенно в коммерческих приложениях. Очевидным примером использования DAC является система Windows NT/2k/XP (см. Диаграмму 2).

Диаграмма 2: Дискреционная модель контроля доступа Windows XP.

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

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

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

2.2.2 Формальное определение

2.3 Модель обязательного контроля за доступом

2.3.1 Общее описание

Обязательный контроль доступа управляет доступом на основе классификации объектов и субъектов системы. Каждому субъекту и объекту системы назначается некоторый уровень безопасности (УБ). Уровень безопасности объекта, как правило, описывает важность этого объекта и возможный ущерб, который может быть причинен при разглашении информации содержащейся в объекте. Уровень безопасности субъекта является уровнем доверия к нему. В простейшем случае все уровни безопасности являются членами некоторой иерархии. Например: Совершенно Секретно (СС), Секретно (С), Конфиденциально (К) и Рассекречено (Р), при этом верно следующее: СС > C > K > P, т.е. каждый уровень включает сам себя и все уровни находящиеся ниже в иерархии.

2.3.1.1 Обеспечение безопасности информации

Доступ субъекта к объекту предоставляется если выполнено некоторое условие отношения (которое зависит от типа доступа) между уровнями безопасности объекта и субъекта. В частности, должны выполняться следующие условия:

Выполнение этих условий, гарантирует, что данные высокоуровневых объектов (например Совершенно Секретно) не попадут в низкоуровневые объекта (например Рассекреченный) см. Диаграмму 3.

Диаграмма 3: Управление потоками информации для обеспечения безопасности данных

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

В описанной выше модели существует два неочевидных момента, которые ставят под вопрос непротиворечивость модели.

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

2. Из диаграммы видно, что пользователи с более высоки уровнем доверия не могут изменять объекты с более низким уровнем безопасности. Эта проблема разрешается тем, что пользователь при доступе к различным документам может выступать от имени субъектов с различными уровнями доверия. Т.е. пользователь с уровнем доверия «С» может выступать от имени субъектов с уровнем доверия «С», «К» и «Р».

2.3.1.2 Обеспечение достоверности информации

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

Видно что критерии правил просто поменялись местами.

Диаграмма 4: Управление потоками информации для обеспечения надежности данных.

Наряду с использованием уровней безопасности, в Обязательного Контроля за Доступом можно использовать категории. В таком случае каждому объекту и субъекту, кроме уровня безопасности можно назначить список категорий к которым он (субъект или объект) относится. Категории объекта используются для описания областей где этот объект используется, а категории субъекта описывают в каких областях субъект работает. Такая система позволяет более детально управлять доступом в системе.

2.3.2 Формальное определение

Определение 1 (Сетка уровней безопасности)

Существует конечная сетка уровней доступа с заданным на ней отношением частичного порядка .

Определение 2 (Уровень безопасности)

Существуют наборы объектов и субъектов системы:

Для каждого объекта и субъекта системы существует один и только один уровень безопасности из сетки уровней безопасности определяемый функцией: ,

Определение 3 (право на чтение)

Субъект имеет право на чтение объекта если

Определение 4 (нестрогое право на запись)

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

Определение 5 (строгое право на запись)

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

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

2.4.1 Общее описание

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

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

Основными достоинствами ролевой модели управления доступом являются:

2.4.1.1 Простота администрирования

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

2.4.1.2 Иерархия ролей

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

2.4.1.3 Принцип наименьшей привилегии

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

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

2.4.1.4 Разделение обязанностей

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

Формально ролевую модель управления доступом можно изобразить следующим образом:

Диаграмма 5: Ролевая модель управления доступом.

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

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

2.4.2 Формальное определение

Сессия имеет следующие привилегии:

3 Анализ существующих моделей

3.1 Области применения

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

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

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

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

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

3.2 Фундаментальное различие

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

1. Настройка политики безопасности системы.

2. Определение прав доступа для субъектов и объектов в системе.

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

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

4 Заключение

В этой статье мы рассмотрели различные методы управления доступом:

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

5 Список литературы

[1]. Ravi S. Sandhu, Pierangela Samarati: Access Control: Principles and Practice. IEEE Comunication Magazine 1994

[2]. Osborn, S., Sandhu, R., and Nunawer, Q. Configuring Role-Based Access Control To Enforce Mandatory And Discretionary Access Control Policies. ACM Trans. Info. Syst. Security, 3, 2, 2000.

[3]. Steve Demurjian: Implementation of Mandatory Access Control in Role-based Security System. 2001

Источник

1 Введение

1.1 Цели и область применения

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

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

1.2 Используемые термины

Доступ субъекта к объекту для определенных операций.

Контейнер информации в системе

Сущность определяющая пользователя при работе в системе

Человек выполняющий действия в системе или приложение выступающее от его имени.

2 Методы управления доступом

2.1 Общее описание

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

На данный момент существует три различных метода для управления доступом к объектам в системе:

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

Диаграмма 1: Системы контроля доступа

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

2.2 Модель дискреционного контроля за доступом

2.2.1 Общее описание

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

Гибкость DAC позволяет использовать его в большом количестве систем и приложений. Благодаря этому этот метод очень распространен, особенно в коммерческих приложениях. Очевидным примером использования DAC является система Windows NT/2k/XP (см. Диаграмму 2).

Диаграмма 2: Дискреционная модель контроля доступа Windows XP.

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

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

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

2.2.2 Формальное определение

2.3 Модель обязательного контроля за доступом

2.3.1 Общее описание

Обязательный контроль доступа управляет доступом на основе классификации объектов и субъектов системы. Каждому субъекту и объекту системы назначается некоторый уровень безопасности (УБ). Уровень безопасности объекта, как правило, описывает важность этого объекта и возможный ущерб, который может быть причинен при разглашении информации содержащейся в объекте. Уровень безопасности субъекта является уровнем доверия к нему. В простейшем случае все уровни безопасности являются членами некоторой иерархии. Например: Совершенно Секретно (СС), Секретно (С), Конфиденциально (К) и Рассекречено (Р), при этом верно следующее: СС > C > K > P, т.е. каждый уровень включает сам себя и все уровни находящиеся ниже в иерархии.

2.3.1.1 Обеспечение безопасности информации

Доступ субъекта к объекту предоставляется если выполнено некоторое условие отношения (которое зависит от типа доступа) между уровнями безопасности объекта и субъекта. В частности, должны выполняться следующие условия:

Выполнение этих условий, гарантирует, что данные высокоуровневых объектов (например Совершенно Секретно) не попадут в низкоуровневые объекта (например Рассекреченный) см. Диаграмму 3.

Диаграмма 3: Управление потоками информации для обеспечения безопасности данных

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

В описанной выше модели существует два неочевидных момента, которые ставят под вопрос непротиворечивость модели.

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

2. Из диаграммы видно, что пользователи с более высоки уровнем доверия не могут изменять объекты с более низким уровнем безопасности. Эта проблема разрешается тем, что пользователь при доступе к различным документам может выступать от имени субъектов с различными уровнями доверия. Т.е. пользователь с уровнем доверия «С» может выступать от имени субъектов с уровнем доверия «С», «К» и «Р».

2.3.1.2 Обеспечение достоверности информации

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

Видно что критерии правил просто поменялись местами.

Диаграмма 4: Управление потоками информации для обеспечения надежности данных.

Наряду с использованием уровней безопасности, в Обязательного Контроля за Доступом можно использовать категории. В таком случае каждому объекту и субъекту, кроме уровня безопасности можно назначить список категорий к которым он (субъект или объект) относится. Категории объекта используются для описания областей где этот объект используется, а категории субъекта описывают в каких областях субъект работает. Такая система позволяет более детально управлять доступом в системе.

2.3.2 Формальное определение

Определение 1 (Сетка уровней безопасности)

Существует конечная сетка уровней доступа с заданным на ней отношением частичного порядка .

Определение 2 (Уровень безопасности)

Существуют наборы объектов и субъектов системы:

Для каждого объекта и субъекта системы существует один и только один уровень безопасности из сетки уровней безопасности определяемый функцией: ,

Определение 3 (право на чтение)

Субъект имеет право на чтение объекта если

Определение 4 (нестрогое право на запись)

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

Определение 5 (строгое право на запись)

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

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

2.4.1 Общее описание

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

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

Основными достоинствами ролевой модели управления доступом являются:

2.4.1.1 Простота администрирования

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

2.4.1.2 Иерархия ролей

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

2.4.1.3 Принцип наименьшей привилегии

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

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

2.4.1.4 Разделение обязанностей

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

Формально ролевую модель управления доступом можно изобразить следующим образом:

Диаграмма 5: Ролевая модель управления доступом.

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

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

2.4.2 Формальное определение

Сессия имеет следующие привилегии:

3 Анализ существующих моделей

3.1 Области применения

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

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

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

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

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

3.2 Фундаментальное различие

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

1. Настройка политики безопасности системы.

2. Определение прав доступа для субъектов и объектов в системе.

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

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

4 Заключение

В этой статье мы рассмотрели различные методы управления доступом:

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

5 Список литературы

[1]. Ravi S. Sandhu, Pierangela Samarati: Access Control: Principles and Practice. IEEE Comunication Magazine 1994

[2]. Osborn, S., Sandhu, R., and Nunawer, Q. Configuring Role-Based Access Control To Enforce Mandatory And Discretionary Access Control Policies. ACM Trans. Info. Syst. Security, 3, 2, 2000.

[3]. Steve Demurjian: Implementation of Mandatory Access Control in Role-based Security System. 2001

Источник

Семинар №2

Доклад 1. Формы представления ограничений доступа

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

Наделение легальных пользователей правами доступа к ресурсам называется авторизацией.

Процедура приведения авторизации в действие называется управлением доступом (access control).

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

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

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

Ограничение доступа может задаваться в форме правил. На основании правила система управления доступом в любой момент времени динамически решает вопрос о предоставлении или непредоставлении доступа. Правило может строиться с учетом различных факторов, в том числе длительности сеанса связи (ограничение доступа по времени использования ресурса), возраста человека (ограничение для детей на доступ к некоторым сайтам), времени суток (разрешение на использование ресурсов и сервисов Интернета только в рабочие часы). Популярной мерой ограничения доступа в Интернет является капча (capcher), в этом случае субъекту, обратившемуся с запросом к ресурсу, предлагается ввести символы, выведенные на экран в таком искаженном виде, в котором их сможет распознать только человек — таким образом исключается доступ к ресурсам искусственных субъектов (программных систем). Другим распространенным правилом является правило, которое носит специальное название — необходимо знать (need-to-know). В соответствии с этим правилом каждый сотрудник имеет право доступа только к тем информационным ресурсам, которые ему необходимы для выполнения его служебных обязанностей.

Для ограничения доступа используются также контентно- и контекстно-зависимые правила. Например, в компании может быть принято правило, что некоторым категориям пользователей запрещается доступ к документам, содержащим те или иные ключевые слова или фразы, такие как «для ограниченного использования», «секретно» или кодовое название проекта. Ограничения могут быть наложены на доступ к ресурсам, содержащим текст на иностранном языке. Это были примеры контентно-зависимых правил. В контекстно-зависимых правилах принимаются во внимание некоторые факторы, характеризующие текущее состояние среды и/или предысторию (контекст) запроса. Простейшим правилом такого рода является отказ в доступе пользователю, который сделал подряд три безуспешных попытки аутентификации. Или доступ к некоторому сетевому ресурсу предприятия может быть запрещен, если к моменту текущего обращения пользователь выполнил несколько обращений к внешнему сайту, содержимое которого не связано напрямую с его профессиональными интересами.

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

Матрица прав доступа является универсальной и наиболее гранулированной (то есть тонко дифференцированной) формой представления политики контроля доступа, она прямо «в лоб» описывает для каждого пользователя набор конкретных операций, которые ему разрешается выполнять по отношению к каждому объекту (Рис. 1).

ОбъектыUser 1User 2User 3File 1Читать и записыватьЧитать и записыватьЧитатьFile 2Читать и записыватьНет доступаЧитатьFile 3ЗаписыватьНет доступаЧитать

Рис. 1. Матрица прав доступа.

Матричный способ описания прав доступа теоретически дает возможность отразить все многообразие отношений субъектов и объектов системы для всех возможных сочетаний <субъект, объект, назначенные права>. Однако этот универсальный способ представления, как правило, очень сложно реализовать на практике из-за громоздкости матрицы, учитывая огромное число элементов — как субъектов, так и объектов — в вычислительной системе.

Особенностью матрицы прав доступа является не только ее большая размерность, но и наличие большого числа нулевых элементов. Такой вид матриц в математике называют разряженными. Нулевое значение здесь говорит о том, что для данного сочетания <субъект, объект>права доступа не определены, а именно такие сочетания составляют большинство в реальных системах. Свойство разреженности матрицы может быть использовано для более компактного представления правил доступа.

С каждым объектом можно связать список управления доступом (Access Control List, ACL), в котором указаны только те субъекты (пользователи), которые имеют разрешение на доступ к данному объекту (ресурсу). Ясно, что количество субъектов в данном списке будет значительно меньше общего числа субъектов системы. Такие списки должны быть созданы для всех ресурсов. Способ описания прав доступа набором списков столь же универсальный и гибкий, как матрица, но вместе с тем имеет более компактный вид, так как он не включает пустые элементы матрицы. Список ACL состоит из элементов управления доступом (Access Control Element, АСЕ), каждый из которых описывает права доступа определенного пользователя к данному ресурсу. На рис. 2 список ACL состоит из трех элементов АСЕ.

Рис. 2. Список управления доступом к объекту

Права доступа могут быть определены как по отношению к ресурсам, так и по отношению к пользователям. В последнем случае его называют списком разрешений (capability). На рис. 3 показан список разрешений, которые имеет пользователь User 2 по отношению к ресурсам File 1, File 2 и File 3.

Рис. 3. Список разрешений пользователя User 2

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

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

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

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

Существует два основных подхода к авторизации:

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

Помимо этих методов, взятых «в чистом виде», система управления доступом может базироваться на их комбинации.

Доклад 2. Дискреционный метод управления доступом

Одно из первых систематических изложений принципов Discretionary Access Control, DAC было предпринято в 1987 году в документе NCSC-TG-003-87, «Руководство по дискретному управлению доступом». В то время модель DAC была самой распространенной схемой управления доступом, таковой она остается и по сегодняшний день — большинство универсальных ОС реализуют дискреционную модель. В документе NCSC дается следующее определение метода DAC:

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

Отсюда следуют две главные особенности дискреционного метода:

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

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

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

Рис. 1. Просмотр и назначение дискреционных атрибутов для файла с помощью графической утилиты «Менеджер файлов» в ОССН Astra Linux SE.

Доклад 3. Мандатный метод управления доступом

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

К основным чертам мандатного метода управления доступом можно отнести следующие:

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

объектов
(файлов, каталогов)Уровень от совершенно секретно и нижеУровень от секретно и нижеУровень данных для служебного пользованияСовершенно секретноДоступ разрешен00СекретноДоступ разрешенДоступ разрешен0Данные для служебного пользованияДоступ разрешенДоступ разрешенДоступ разрешен

Рис. 1. Правило мандатного доступа, представленное в виде матрицы

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

Элементы, описывающие уровни секретности объектов или уровни допуска субъектов, называют метками безопасности (security labels). Мандатный метод управления доступом предусматривает назначение меток безопасности всем без исключения субъектам и объектам системы, чтобы в дальнейшем они использовались системой для принятия решения о допуске.

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

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

Таким образом, каждая метка безопасности состоит из двух частей (рис. 2):

Рис. 2. Структура метки безопасности объекта/субъекта

Категория относит данные к определенному виду информации. Например, разные категории могут быть присвоены материалам, относящимся к разным проектам, разным административным подразделениям, разным профессиональным группам. Одному и тому же объекту/субъекту может быть присвоено несколько категорий. Так, отчет о завершении этапа некоторой антитеррористической операции может быть отнесен не только к категории материалов, касающихся данной операции, но и дополнительно к категории материалов подразделения, занимающегося этой работой. Объекты одной категории могут быть классифицированы по-разному: например, одна часть отнесена к более высокому уровню секретности, а другая часть — к более низкому.

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

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

Рисунок 3 иллюстрирует соотношение между классификацией и категорией. Здесь разная закраска кружков служит для обозначения разных категорий объектов.

Рис. 3. Правило мандатного доступа

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

В Astra Linux Special Edition термину «классификация» соответствует «уровень». Уровни и категории в Astra Linux Special Edition можно настроить с помощью графической утилиты «Управление политикой безопасности».

Рис. 4. Категории и Уровни в окне графической утилиты «Управление политикой безопасности».

Рис. 5. Отображение и установка допустимых мандатные уровней и категорий для пользователя test100.

Надпись на вкладке МРД расшифровывается как мандатное разграничения доступа.

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

Доклад 4. Ролевое управление доступом.

Метод управления доступом RBAC (Role-based Access Control), основанный на ролях, по сравнению с методами DAC и MAC более приближен к реальной жизни. Как видно из названия, основным его свойством является использование «ролей». Понятие «роль» в данном контексте ближе всего к понятию «должность» или «круг должностных обязанностей». Поскольку одну и ту же должность могут занимать несколько людей, то и одна и та же роль может быть приписана разным пользователям.

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

Разрешения приписываются ролям, а не отдельным пользователям или группам пользователей (рис. 1). А уже затем те или иные роли приписываются пользователю. Например, в системе управления доступом, развернутой в банке, всем юристам приписана роль «юрист», трейдерам — роль «трейдер», менеджерам — роль «менеджер» и т. д. Процесс определения ролей должен включать тщательный анализ того, как функционирует организация, какой набор функций должен выполнять работник, имеющий ту или иную должность. Каждой из ролей назначаются права доступа, необходимые и достаточные пользователям для выполнения служебных обязанностей, обусловленных приписыванием к данной роли.

Рис. 1. Схема авторизации в системах управления доступом на основе ролей

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

Все пользователи, играющие одну и ту же роль, имеют идентичные права. Изменение производственной ситуации — расширение бизнеса, внедрение новых технологий, продвижение сотрудника по служебной лестнице или перевод в другое подразделение и др. — все это может вызвать аннулирование одной роли пользователя и приписывание ему другой роли. Такой подход упрощает администрирование прав доступа: вместо необходимого в методах DAC и MAC отслеживания и обновления прав каждого отдельного пользователя в методе RBAC достаточно изменить роль или заменить одну роль другой.

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

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

Иерархия ролей создается определением для них отношений, называемых наследованием: в соответствии с этим определением если роль R2 является наследницей R1, то все права роли R1 приписываются к правам роли R2, а все пользователи роли R2 приписываются к пользователям роли R1 (рис. 2). Таким образом, установление отношений наследования является еще одним способом наделения пользователя правами наряду с явным назначением пользователю некоторой роли.

Рис. 2. Отношение наследования ролей: а — независимые роли; б — роль R2 является наследницей роли R1

Отношения наследования относятся к типу «многие ко многим», то есть у одной роли может быть несколько наследниц и одна роль может быть наследницей нескольких ролей.

Иерархия ролей обычно в той или иной степени отражает структуру реального предприятия. На рис. 3 показан фрагмент организационной структуры предприятия.

Рис. 3. Фрагмент организационной структуры предприятия

Такой организационной структуре может быть поставлена в соответствие ролевая структура, полученная в результате установления между ролями отношений наследования (рис. 4). Роль «сотрудник» представляет собой общие, наличествующие у всех сотрудников организации права. Должность менеджера по работе с клиентами добавляет к должностным обязанностям рядового сотрудника отдела ОРК еще ряд функций. Например, менеджер обязан разрабатывать план увеличения клиентской базы, что требует доступа к некоторым финансовым документам. Находящийся с ним на одном уровне менеджер отдела развития (ОР) также нуждается в расширении прав доступа к информационным ресурсам по отношению к рядовым сотрудникам отдела О Р. После установления отношений наследования с ролями «сотрудник ОРК», «сотрудник ОТР», «сотрудник ФО» и «директор» все общие права сотрудников оказались неявным образом добавлены к этим ролям-наследницам, а их пользователи соответственно переместились наверх. Наследники следующей ступени — роли «менеджер ОРК» и «менеджер ОТР» — сами являются предшественниками для роли «директор по развитию», которая, таким образом, аккумулировала права этих двух ролей.

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

Рис. 4. Структура ролей, образованная отношениями наследования

Чтобы избежать подобных ситуаций, в методе RBAC предусмотрен специальный механизм, накладывающий ограничения на приписывание ролей пользователям. Этот механизм действует следующим образом. Совокупность ролей, относительно совмещения которых нужно устанавливать ограничения, объединяется в устойчивую группу, и к ней приписывается число-ограничитель. В нашем случае это группа ролей <«инженер», «сотрудник финансового отдела»>, которой должен быть приписан ограничитель 1. Если теперь администратором будет сделана попытка приписать пользователю обе эти роли, то система заблокирует его действия.

Итак, к характерным особенностям ролевого управления доступом можно отнести следующее:

Метод RBAC нельзя отнести к хорошо масштабируемым. Он эффективно работает в пределах единой системы или приложения, таких, например, как FreeBSD, Solaris, СУБД Oracle, MS Active Directory, но на больших предприятиях, имеющих тысячи сотрудников, поддержание множества ролей с их отношениями наследования становится сложной и запутанной задачей. Занимая промежуточное положение между мандатным и дискреционным методами, ролевое управление доступом уступает им обоим в масштабируемости. В мандатном методе централизованный характер принятия решений (который не способствует масштабируемости) компенсируется простотой выполняемого алгоритма назначения прав. В дискреционном же методе, напротив, сложность механизма наделения правами компенсируется распределенным характером процедуры принятия решений.

Источник

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

Модели управления доступом подразделяются на следующие категории:

• дискреционное (избирательное) управление;
• обязательный (мандатный) метод управления;
• ролевая модель управления;
• управление доступом на основе правил.

Дискреционный контроль доступа

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

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

Мандатный контроль доступа

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

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

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

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

Преимущество ролевого метода заключается в том, что доступом к ресурсу может пользоваться несколько пользователей, которые назначены на одну и ту же роль или наоборот — один сотрудник назначается на исполнение несколько ролей без пересмотра индивидуального уровня доступа. Однако, если в интересах работы исполнитель требует расширить сферу допуска, предусмотренную ролью, то администратор пересматривает степень доступа для каждого конкретного случая. Метод ролевого управления СКУД наиболее подходит для динамичных и изменчивых облачных систем управления.

Контроль и управление доступом на основе правил

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

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

Наиболее распространённый способ доступа пользователей к данным — доступ к общим файловым ресурсам в сети. Управление доступом к файлам и папкам осуществляется с помощью прав доступа к общему файловому ресурсу и доступа к NTFS. Для обеспечения безопасности ваших файлов важно понимать, как действуют права доступа.

Права доступа к файловой системе NTFS позволяют определять уровень доступа пользователей к размещённым в сети, или локально на вашем компьютере Windows 7 файлам.

Что такое права доступа к NTFS.

Права доступа — разрешение на выполнение операций с определённым объектом, например файлом. Права могут быть предоставлены владельцем или другим имеющим на это право пользователем. Как правило, это администраторы в системе. Если вы являетесь владельцем объекта, то можете предоставить права доступа к этому объекту любому пользователю или группе пользователей.

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

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

Существует два уровня прав доступа:

• Доступ к общей папке: даёт участникам, например определённым пользователям, доступ к общим ресурсам в сети. Права доступа к общим папкам действует только тогда, когда пользователь обращается к ресурсу по сети.
• Доступ к файловой системе NTFS: даёт доступ к файлам или папкам при подключении по сети или во время входа в систему на локальном компьютере, где расположен ресурс. Доступ по NTFS для файла или папки предоставляется определённой группе или отдельным пользователям.

Существует два типа доступа по NTFS:

• Стандартные права: наиболее часто используемым разрешением является стандартный доступ к файлам и папкам; к нему относятся основные права: чтение, запись, изменение и полный контроль.
• Специальные права: особые права доступа, в которых предусмотрена большая точность управления доступом к файлам и папкам. Этот тип прав доступа более сложный в управлении, чем стандартный доступ. К ним относятся права на атрибуты чтения/записи, расширенные атрибуты, удаление вложенных папок и файлов, смена владельца и синхронизация.

Права на наследование.

Существует два типа прав доступа:

• Прямые права доступа: если объект создаётся действием пользователя, доступ, установлен по умолчанию на не дочерние объекты.
• Унаследованный доступ: доступ распространяется на объект от родительского объекта. Наследованный доступ облегчает управление разрешениями и обеспечивает единообразие доступа для всех, находящихся в данном контейнере, объектов.

Наследованный доступ позволяет набору NTFS разрешений для папки быть автоматически применённым к файлам, созданным в той папке и её подпапках. Это означает, что разрешения NTFS для всей структуры папки могут быть установлены в одном месте. И если требуются изменения, то их можно сделать в одном единственном пункте.

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

Существует три способа изменения унаследованного доступа:

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

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

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

Примечание: Если объект имеет прямое право — «Разрешить»,  запрет на унаследованное право доступа не препятствует доступу к объекту. Прямые права доступа имеют приоритет над унаследованными правами, даже над унаследованным запретом.

Блокировка наследуемых прав доступа.

После установки прав доступа на родительскую папку, созданные в ней новые файлы и папки, наследуют эти права. Для ограничения доступа к этим файлам и папкам наследование прав доступа может быть заблокировано. Например, все пользователи бухгалтерии могут иметь права на папку УЧЕТА «Изменить». На подпапке ЗАРАБОТНАЯ ПЛАТА, наследуемые права доступа могут быть заблокированы, и предоставлены только некоторым определённым пользователям.

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

Разграничение
доступа к объектам

С объектом
разграничения доступа связывается
дескриптор безопасности SD
(security
descriptor),
содержащий следующую информацию:

• идентификатор
  безопасности (SID)
  владельца объекта;

• идентификатор
  безопасности первичной группы владельца;

• дискреционный
  список
  контроля
  доступа
  (discretionary access control list, DACL);

• системный
  список контроля доступа (system
  access control list, SACL).

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

1. Список
   SACL
   управляется администратором системы
   и предназначен для аудита безопасности.

2. Список
   DACL
   управляется владельцем объекта и
   предназначен для идентификации
   пользователей и групп, которым
   предоставлен или запрещен определенный
   тип доступа к объекту. Каждый элемент
   списка DACL
   (access
   control
   entry,
   ACE)
   определяет права доступа к объекту
   одному пользователю или группе.

Состав ACE

Каждый ACE содержит
следующую информацию:

• идентификатор
  безопасности SID субъекта, для которого
  определяются права доступа;

• маска
  доступа (access
  mask,
  AM), которая специфицирует контролируемые
  данным ACE права доступа;

• тип ACE;

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

Разграничение
доступа к объектам

Элементы
списка DACL
могут быть двух типов – элементы,
запрещающие специфицированные в них
права доступа (Access-allowed
ACE), и элементы, запрещающие определенные
в них права доступа (Access-denied
ACE). Элементы для запрещения субъектам
использования определенных прав доступа
должны размещаться в «голове» списка,
до первого из элементов, разрешающих
использование субъектом тех или иных
прав доступа.

Права доступа в
Windows

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

• Стандартные
  определяют возможность доступа к
  объекту по методу, применимому к любому
  объекту (изменение владельца, изменение
  списка DACL, удаление и т.д.).

Специальные
права для файлов и папок

Стандартные права

Общие права

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

• Чтение
  (чтение DACL,
  чтение данных, чтение атрибутов и
  расширенных атрибутов, использование
  объекта для синхронизации);

• Запись
  (чтение DACL,
  запись и добавление данных, запись
  атрибутов и расширенных атрибутов,
  использование объекта для синхронизации).

Разграничение
доступа к объектам

Маркер
доступа субъекта, обращающегося к
некоторому объекту, поступает в локальную
службу безопасности LSA.
От LSA
маркер доступа поступает к монитору
безопасных ссылок (security
reference
monitor,
SRM),
который просматривает DACL
из дескриптора безопасности SD
соответствующего объекта и принимает
решение R
о предоставлении доступа субъекту или
отказе в доступе. Получив от SRM
результат R,
LSA
передает его субъекту, запросившему
доступ к объекту.

Алгоритм проверки
прав доступа к объекту

1. Если
   SID
   из маркера доступа субъекта AT
   не совпадает с SID,
   содержащемся в элементе ACE
   списка контроля доступа к объекту, то
   осуществляется переход к следующему
   ACE,
   иначе переход к п. 2.

2. Если в
   элементе ACE
   запрещается доступ к объекту для
   субъекта с данным SID,
   но этот субъект является владельцем
   объекта и запрашиваемая маска доступа
   содержит только попытку доступа к
   объекту по методу «чтение (или) изменение
   дискреционного списка контроля доступа
   к объекту», то доступ субъекта к объекту
   разрешается, иначе осуществляется
   переход к п.3.

3. Если в элементе
   ACE запрещается доступ к объекту для
   субъекта с данным SID, то сравниваются
   запрашиваемая маска доступа и маска
   доступа, определенная в ACE. Если при
   сравнении находится хотя бы один общий
   метод доступа, то попытка доступа
   субъекта к объекту отклоняется, иначе
   происходит переход к следующему ACE.

4. Если в
   элементе ACE
   разрешается доступ к объекту для
   субъекта с данным SID,
   то также сравниваются запрашиваемая
   маска доступа и маска доступа, определенная
   в ACE.
   Если при этом маски доступа полностью
   совпадают, то доступ субъекта к объекту
   разрешается, иначе происходит переход
   к следующему ACE.

5. Если
   достигнут конец списка DACL
   из дескриптора безопасности объекта,
   то попытка доступа субъекта к объекту
   отклоняется.

• Если
  DACL
  объекта пуст, то любой доступ к нему
  запрещен всем субъектам, за исключением
  владельца объекта, которому разрешены
  чтение и (или) изменение списка контроля
  доступа к объекту.

• Если у
  объекта нет дескриптора безопасности
  (например, у папок и файлов, размещенных
  на дисках под управлением файловой
  системы FAT),
  то любые пользователи и группы могут
  получить любые права доступа к данному
  объекту.

Контейнерные и
неконтейнерные объекты

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

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

Назначение
дескрипторов безопасности вновь
создаваемым объектам

1. На
   основе явно заданного дескриптора
   безопасности (например, при вызове
   системной функции CreateFile).

2. На основе механизма
   наследования (если при создании объекта
   дескриптор безопасности не задается).

3. Из маркера доступа
   субъекта, создающего объект (если
   наследование невозможно).

Соседние файлы в предмете Защита информации

• #
• #
• #
• #
• #
• #
• #

1 Введение

1.1 Цели и область применения

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

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

1.2 Используемые термины

Доступ субъекта к объекту для определенных операций.

Контейнер информации в системе

Сущность определяющая пользователя при работе в системе

Человек выполняющий действия в системе или приложение выступающее от его имени.

2 Методы управления доступом

2.1 Общее описание

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

На данный момент существует три различных метода для управления доступом к объектам в системе:

• Дискреционный метод контроля доступа
• Обязательный метод контроля доступа
• Ролевой метод контроля доступа.

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

Диаграмма 1: Системы контроля доступа

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

2.2 Модель дискреционного контроля за доступом

2.2.1 Общее описание

Средства Дискреционного Контроля за Доступом (Discretionary Access Control — DAC) обеспечивают защиту персональных объектов в системе. Контроль является дискреционным в том смысле, что владелец объекта сам определяет тех, кто имеет доступ к объекту, а также вид их доступа.

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

Гибкость DAC позволяет использовать его в большом количестве систем и приложений. Благодаря этому этот метод очень распространен, особенно в коммерческих приложениях. Очевидным примером использования DAC является система Windows NT/2k/XP (см. Диаграмму 2).

Диаграмма 2: Дискреционная модель контроля доступа Windows XP.

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

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

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

2.2.2 Формальное определение

2.3 Модель обязательного контроля за доступом

2.3.1 Общее описание

Средства Обязательного Контроля за Доступом (Mandatory Access Control — MAC). Контроль является обязательным в том смысле, что пользователи не могут изменять стратегию MAC в отношении объектов. При создании объекта система автоматически присваивает ему атрибуты MAC, и изменить эти атрибуты может только администратор, имеющий соответствующие полномочия. Средства MAC не позволят пользователю случайно или преднамеренно сделать информацию доступной для лиц, которые не должны обладать ею.

Обязательный контроль доступа управляет доступом на основе классификации объектов и субъектов системы. Каждому субъекту и объекту системы назначается некоторый уровень безопасности (УБ). Уровень безопасности объекта, как правило, описывает важность этого объекта и возможный ущерб, который может быть причинен при разглашении информации содержащейся в объекте. Уровень безопасности субъекта является уровнем доверия к нему. В простейшем случае все уровни безопасности являются членами некоторой иерархии. Например: Совершенно Секретно (СС), Секретно (С), Конфиденциально (К) и Рассекречено (Р), при этом верно следующее: СС > C > K > P, т.е. каждый уровень включает сам себя и все уровни находящиеся ниже в иерархии.

2.3.1.1 Обеспечение безопасности информации

Доступ субъекта к объекту предоставляется если выполнено некоторое условие отношения (которое зависит от типа доступа) между уровнями безопасности объекта и субъекта. В частности, должны выполняться следующие условия:

• Доступ на чтение дается если УБ субъекта включает в себя УБ объекта.
• Доступ на запись дается если УБ субъекта включается в УБ объекта.

Выполнение этих условий, гарантирует, что данные высокоуровневых объектов (например Совершенно Секретно) не попадут в низкоуровневые объекта (например Рассекреченный) см. Диаграмму 3.

Диаграмма 3: Управление потоками информации для обеспечения безопасности данных

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

В описанной выше модели существует два неочевидных момента, которые ставят под вопрос непротиворечивость модели.

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

• Доступ на чтение дается если УБ субъекта включает в себя УБ объекта.
• Доступ на запись дается если УБ субъекта равняется УБ объекта.

2. Из диаграммы видно, что пользователи с более высоки уровнем доверия не могут изменять объекты с более низким уровнем безопасности. Эта проблема разрешается тем, что пользователь при доступе к различным документам может выступать от имени субъектов с различными уровнями доверия. Т.е. пользователь с уровнем доверия «С» может выступать от имени субъектов с уровнем доверия «С», «К» и «Р».

2.3.1.2 Обеспечение достоверности информации

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

• Доступ на запись дается если УБ субъекта включает в себя УБ объекта.
• Доступ на чтение дается если УБ субъекта включается в УБ объекта.

Видно что критерии правил просто поменялись местами.

Диаграмма 4: Управление потоками информации для обеспечения надежности данных.

Наряду с использованием уровней безопасности, в Обязательного Контроля за Доступом можно использовать категории. В таком случае каждому объекту и субъекту, кроме уровня безопасности можно назначить список категорий к которым он (субъект или объект) относится. Категории объекта используются для описания областей где этот объект используется, а категории субъекта описывают в каких областях субъект работает. Такая система позволяет более детально управлять доступом в системе.

2.3.2 Формальное определение

Определение 1 (Сетка уровней безопасности)

Существует конечная сетка уровней доступа с заданным на ней отношением частичного порядка .

Определение 2 (Уровень безопасности)

Существуют наборы объектов и субъектов системы:

Для каждого объекта и субъекта системы существует один и только один уровень безопасности из сетки уровней безопасности определяемый функцией: ,

Определение 3 (право на чтение)

Субъект имеет право на чтение объекта если

Определение 4 (нестрогое право на запись)

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

Определение 5 (строгое право на запись)

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

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

2.4.1 Общее описание

Основная идея ролевой модели контроля за доступом (Role-Based Access Control — RBAC) основана на максимальном приближении логики работы системы к реальному разделению функций персонала в организации.

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

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

Основными достоинствами ролевой модели управления доступом являются:

2.4.1.1 Простота администрирования

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

2.4.1.2 Иерархия ролей

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

2.4.1.3 Принцип наименьшей привилегии

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

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

2.4.1.4 Разделение обязанностей

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

Формально ролевую модель управления доступом можно изобразить следующим образом:

Диаграмма 5: Ролевая модель управления доступом.

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

Из диаграммы видно, что связи «Назначение ролей пользователям» и «Назначение привилегий» принадлежат типу много в много. Пользователь может иметь несколько ролей и несколько пользователей могут принадлежать одной роли. Аналогично несколько привилегий могут принадлежать одной роли и несколько ролей могут иметь одну и ту же привилегию. Также в этой модели присутствует частично упорядоченное множество — иерархия ролей. На этом множестве задано отношение принадлежности где для ролей x и y, x > y означает что роль x наследует привилегии роли y. Это отношение транзитивно.

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

2.4.2 Формальное определение

• — набор пользователей.

и — непересекающиеся наборы ролей и административных ролей

и — непересекающиеся наборы привилегий и административных привилегий.

— набор сессий

• — Привилегия -> Роль отношение много в много.

— Привилегия -> Административная роль отношение много в много.

• — Пользователь -> Роль отношение

— Пользователь -> Административная роль отношение

• — частично упорядоченная иерархия ролей

— частично упорядоченная иерархия административных ролей.

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

Сессия имеет следующие привилегии:

• Есть набор ограничений, обуславливающих какие значения компонент описанных выше разрешены или запрещены.

3 Анализ существующих моделей

3.1 Области применения

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

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

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

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

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

3.2 Фундаментальное различие

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

1. Настройка политики безопасности системы.

2. Определение прав доступа для субъектов и объектов в системе.

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

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

4 Заключение

В этой статье мы рассмотрели различные методы управления доступом:

• Модель дискреционного контроля за доступом
• Модель обязательного контроля за доступом
• Ролевая модель контроля за доступом

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

5 Список литературы

[1]. Ravi S. Sandhu, Pierangela Samarati: Access Control: Principles and Practice. IEEE Comunication Magazine 1994

[2]. Osborn, S., Sandhu, R., and Nunawer, Q. Configuring Role-Based Access Control To Enforce Mandatory And Discretionary Access Control Policies. ACM Trans. Info. Syst. Security, 3, 2, 2000.

[3]. Steve Demurjian: Implementation of Mandatory Access Control in Role-based Security System. 2001

Figure 1: The ACL Editor

Introduction

In this series of articles, I will discuss the Windows Access Control model and its implementation in Windows NT and 2000. I intend this series to be four parts long. I originally intended this series of articles to be just one part long (I was only going to write about the Windows-2000 style ACL editor), but there is so much you need to know about Windows Access Control, I might as well devote an entire series dedicated to the topic.

This first article serves as an introduction to ACL-based Authorization (from a programming point of view) in Windows NT and how the access control model is implemented. If you have never programmed with Windows security, or are just starting, this first article is for you. Although this first article will display structures in C, you should read this article even if you aren’t programming in C. It contains concepts relevant to all programmers.

This series of articles isn’t meant as a primer on security administration (there are plenty of articles, websites, courses and books on that). Rather, it is intended to discuss the Windows NT Security model from a programmatic perspective. I will already assume you know how to set permissions on files, registry keys, and are quite proficient with the ACL editor. I will also assume you know what users are and what groups are.

Access Control is not available in 16-bit Windows or Windows 95/98/ME.

Table Of Contents

The table of contents is for the entire series.

1. Part 1 — Background and Core Concepts. The Access Control Structures
   1. The Security Identifier (SID)
   2. The Security Descriptor (SD)
   3. The Access Control List (ACL)
   4. Choosing a good discretionary access control list
   5. Windows 2000 Inheritance Model
   6. The Token
   7. A Note on the Security Descriptor Definition Language
   8. Coming Up
2. Part 2 — Basic Access Control programming
   1. Choosing your language
   2. Fun with SIDs
   3. Which Groups are you a member of?
   4. Enabling Token Privileges
   5. Dissecting the Security Descriptor
   6. Walking an Access Control List
   7. Creating an Access Control List
   8. Do I Have Access?
   9. Creating and Editing a Secure Object
   10. Making Your Own Classes Secure
   11. Toy Programs Download
3. Part 3 — Access Control programming with .NET v2.0
   1. A history of .NET security.
   2. Reading a SID in .NET.
   3. Whoami .NET.
   4. Privilege handling in .NET.
   5. Running as an unprivileged user in .NET.
   6. Obtaining and editing a security descriptor in .NET, and applying it to an object.
   7. Access checks in .NET.
   8. NetAccessControl program and AccessToken class library.
4. Part 4 — The Windows 2000-style Access Control editor
   1. Features of the ACL editor (ACLUI).
   2. Getting Started.
   3. Implementing the ISecurityInformation Interface.
   4. ISecurityInformation::SetSecurity
   5. Optional Interfaces.
   6. Presenting the interface.
   7. Filepermsbox — A program to display the security descriptor on an NTFS file or folder.
   8. History

Background

One of the original design goals of Windows NT was to provide a layer that can implement security for the operating system. The way Windows NT implemented security for its objects was through the Access control model. Even role-based security and the .NET classes could not replace this ACL-based security model. ACLs are far too embedded in the NTFS architecture objects, and the registry was to be rendered obsolete (so much so, that .NET v2.0 had to relent and end up supporting the ACL model too).

To start off, I will describe the different types of structures you may meet when programming for access control. This article is intended for all programmers (this part contains no code, just structures and programming concepts).

1. The Security Identifier (SID)

Before delving into the concepts of authorization, I should take a discussion about the Security Identifier (SID). We humans like to refer to a user by their user name (like «Administrator»). A computer must refer to the user in binary. It recognises a user by means of a hash (which is called a SID). When a user is created, the computer generates a SID for that user and from then on, it will refer to that user by its SID (not its username). To see a list of your own SIDs, open up regedit and expand the HKEY_USERS tree (you will see a list of the SIDs for the currently logged on users). You can convert the raw SID struct into a textual form by using ConvertSidToStringSid(). A textual SID (usually starts with S-1-5-21-…) consists of at least 3 dash-separated values (which stand for revision, authority, sub authority, ID and primary groups).

A SID can also represent a user group, a computer, a domain or even a forest. Windows maintains a list of hardcoded SIDs called the Well-Known SIDs (they represent accounts like the LocalSystem, or the NetworkService account). You can view a list of these SIDs in the WELL_KNOWN_SID_TYPE enumeration.

To convert a SID to a username, you would need to call LookupAccountSid(), and LookupAccountName() to convert a user name to a SID. However, most of the security functions accept either a SID or a username (they actually accept a TRUSTEE structure, which is a kind of union of the username and SID).

2. The Security Descriptor (SD)

Windows NT secures its objects by means of a structure called the security descriptor (SECURITY_DESCRIPTOR). The security descriptor is an integral part of the structure from which Windows objects are built. This means every object (be it file objects, registry keys, network shares, mutexes, semaphores, processes, threads, tokens, hardware, services, drivers…) recognized by Windows NT can be secured. The security descriptor structure exists in both kernel mode and user mode (and is identical in both modes). Although this allows for code reuse for both kernel mode and user mode security, it also means the SECURITY_DESCRIPTOR inherits some nasty quirks from kernel mode.

If you open up Winnt.h and scroll down to the SECURITY_DESCRIPTOR struct, you’ll see the structure of the security descriptor (Fig. 2). This SECURITY_DESCRIPTOR may actually be one of two structs, one is an absolute security descriptor (SECURITY_DESCRIPTOR), and the other is a self-relative security descriptor (Fig. 3 SECURITY_DESCRIPTOR_RELATIVE).

typedef struct _SECURITY_DESCRIPTOR
{
    BYTE Revision;             
    BYTE Sbz1;                 
    SECURITY_DESCRIPTOR_CONTROL Control;
        
    PSID Owner;                
    PSID Group;                
    PACL Sacl;                 
    PACL Dacl;                 
} SECURITY_DESCRIPTOR, *PISECURITY_DESCRIPTOR;

Figure 2: The Absolute Security Descriptor.

Notice that a security descriptor consists of five members (excluding the two version control members):

• Discretionary Access Control List (Dacl): This is where the permissions of the object are kept (who’s allowed access to the object, who’s denied).
• System Access Control List (Sacl): Specifies the type of auditing to be performed on the object. If an auditing event occurs, it will be stored in the Auditing Event Log.
• Owner: Specifies the owner of the object (as a SID). The owner of the object can always alter the security descriptor, regardless if someone else has locked out access.
• Group: Specifies the primary group of the object (as a SID). Windows mostly ignores this parameter (it was for POSIX compatibility, but its presence is rather vestigial now).
• Control: A bunch of flags that make up a 16-bit integer. It can be zero or more of the following flags:
  • SE_DACL_PRESENT: The Dacl member is valid.
  • SE_SACL_PRESENT: The Sacl member is valid.
  • SE_DACL_AUTO_INHERITED: The DACL auto-inherits and gets entries from its parent included in itself.
  • SE_SACL_AUTO_INHERITED: same as SE_DACL_AUTO_INHERITED, but it applies to the SACL.
  • SE_DACL_PROTECTED: If the parent’s ACLs conflict with any ACL defined here, override the parent’s ACL. Useful for overriding inheritance.
  • SE_SACL_PROTECTED: Same as SE_DACL_PROTECTED, but for SACLs.
  • SE_DACL_DEFAULTED: The Dacl member equals the default DACL for this object type.
  • SE_SACL_DEFAULTED: The Sacl member equals the default SACL for this object type.
  • SE_GROUP_DEFAULTED: The Group member equals the default Group for this object type.
  • SE_OWNER_DEFAULTED: The Owner is defaulted.
  • SE_SELF_RELATIVE: Indicates this security descriptor is self-relative.

The last 4 entries of this structure are all pointers, and they point to the buffers where the ACLs etc. can be found. These pointers can point to any valid location in memory (not necessarily in a contiguous block). Because the security descriptors aren’t contiguous, it is going to be rather cumbersome to write the security descriptors to disk, or across processes. Microsoft solved this problem by introducing a new structure, called the self-relative security descriptor (Fig. 3 SECURITY_DESCRIPTOR_RELATIVE).

typedef struct _SECURITY_DESCRIPTOR_RELATIVE
{
    BYTE  Revision;    
    BYTE  Sbz1;        
    SECURITY_DESCRIPTOR_CONTROL Control;
    
    DWORD OwnerOffset;
    
    DWORD GroupOffset; 
    DWORD SaclOffset;  
    DWORD DaclOffset;  

    struct SecurityDescriptorData 
    {
    
        ...            
        SID Owner;     
        ...
        SID Group;     
        ...
        ACL Sacl[]; 
        
        ...
        ACL Dacl[];
    } ;
} SECURITY_DESCRIPTOR_RELATIVE, *PISECURITY_DESCRIPTOR_RELATIVE;

Figure 3: The structure of the relative security descriptor

The self-relative security descriptor is much more complicated than the absolute security descriptor (so complex, that you cannot represent it in C++). Although the first three fields are the same as the absolute security descriptor, the security descriptors become very different after that. Following the Control member are four DWORDs (which represent offsets to the data). The data for the security descriptor all follow these four DWORDs. I’ve inserted padding bytes into the structure to illustrate that the data can appear anywhere in the buffer (simply change the Offset members to move the buffer). The four members do not need to appear in any particular order either. By choosing special offsets, you can make the Owner member appear after the group. At the expense of being horrendously complicated, the self-relative security descriptor occupies one contiguous block, making it suitable for transporting between application boundaries and storage media.

How can you tell the difference between an absolute and self-relative security descriptor? The difference is that with an absolute security descriptor, after the Control member are four pointers to the Group / Owner / SACL / DACL (in that order), and these four pointers point to separate locations in memory where the data can be found. With a self-relative security descriptor, after the Control member are four DWORDs which represent offsets to the Group / Owner / SACL / DACL. For example, if the group member has the value 0xf, then it’s telling Windows, «You can find the group SID 0xf bytes after me». 64-bit Windows makes this even more confusing when these two structures have differing sizes!

To make matters worse, Microsoft doesn’t distinguish between the absolute or self-relative security descriptor in their docs. Microsoft has reserved the right to make internal changes to the security descriptor, meaning you cannot rely on this structure being the same in future. Instead, if you want to manipulate a security descriptor, you should do so using the authorization APIs. Using the APIs encapsulate the complexity of these structures from you. So to distinguish between an absolute security descriptor and a self-relative one, call GetSecurityDescriptorControl(), and test for the SE_SELF_RELATIVE flag.

It’s important that you know which API expects an absolute security descriptor, and which ones expect a self-relative one. In Part 2 [^] of this series, you will get around to actually building a security descriptor.

3. The Access Control List (ACL)

Whenever you perform an action (e.g. a read) on an object in Windows NT, the action is encoded into a 32 bit integer (called the ACCESS_MASK). The ACCESS_MASK is specific to the object you are trying to create (if you read a file, the ACCESS_MASK would be FILE_GENERIC_READ). When you open the object with the requested ACCESS_MASK, Windows will get your username (inside your thread token) and then start reading the discretionary access control list (obtained from the security descriptor).

The DACL can be thought of as a table of user SIDs, ACCESS_MASKs, and access types. Don’t try to code it as an array of structs though. Use the low-level ACL functions GetAce(), GetAclInformation() & friends if you want to parse an ACL. In NT4, Microsoft provides a view of the ACL that looks exactly like a table of SIDs, ACCESS_MASKs and types (the EXPLICIT_ACCESS structure).

struct ACE
{
    BYTE AceType;     
    BYTE AceFlags;    
    ...
    ACCESS_MASK Mask; 
    ...
    SID Sid;          
} ;

struct ACL
{
    BYTE AclRevision;
    ...
    WORD AceCount;                  
    ...
    ACE AceList[this->AceCount];    
} ;


typedef struct _EXPLICIT_ACCESS
{
    DWORD grfAccessPermissions;     
    ACCESS_MODE grfAccessMode;      
    DWORD grfInheritance;           
    TRUSTEE Trustee;                
} EXPLICIT_ACCESS, *PEXPLICIT_ACCESS;

Figure 4: An outline of the ACL and the ACE.

If the DACL is a table, then each row in the table is called an Access Control Entry. When an action is performed, Windows will enumerate this list of ACEs to find an entry that refers to you (you being the thread token). Windows enumerates the ACEs in the order they appear in the ACL. At first sight this goes against your intuition, the Help documentation, and what the MCP books say («I thought Windows walks the Deny ACEs first, then walks the Allow ACEs. Now you’re telling me this is wrong?»). Actually, we are both right. When Windows sets the DACL, it sorts the access control entries [^] so that deny ACEs do precede allow ACEs, and the access control model follows what you were taught.

If you make a call to the low level functions, you can circumvent the sorting, and make the ACEs appear in any order you like. The Cygwin tools utilise this technique to create DACLs unordered. However, these DACLs will not obey the access control rules, and you can make files with broken ACLs.

If you (your token) isn’t found in the ACL, then the open object function fails (Access denied). If you are found, Windows will look in the ACE to see what you are allowed to do. If the ACE allows you to open the object, you are granted access. If anything fails here, you are denied access (this is an example of a security best practice: «if anything goes wrong, make sure you fail securely»).

Now that you have been granted or denied access, Windows will now make a check on the other ACL, the System Access Control List. The difference between an SACL and a DACL is that DACL contains allow / deny entries, but an SACL contains audit entries. The SACL tells Windows which actions to log in the Security Event Log (audit successes / failures). Apart from that, you can treat the SACL / DACL as the same. If Windows finds an SACL which tells it to audit the access, then the access attempt is written to the Event log.

If you want to see if an ACL allows you access to the object, use the AccessCheck() API on the object.

4. Creating a good discretionary access control list

In almost every case, Windows has already decided a good discretionary access control list for you. When you encounter an API that asks for a security descriptor (or a SECURITY_ATTRIBUTES structure), simply pass in NULL for this parameter. Passing in NULL for either the SECURITY_ATTRIBUTES or SECURITY_DESCRIPTOR will tell the system to apply the default security descriptor. And that is probably what you were after.

If you need more advanced security, make sure you create a security descriptor that has a filled DACL. If you’ve initialized a security descriptor, but have forgotten to build up a DACL (and attach it to the security descriptor), you will get a NULL DACL. Windows sees this NULL DACL as an object that has the following ACE:

«Everyone: Full control»

Therefore, Windows will allow access to the object regardless of the action. This is one case where Microsoft broke its own best practices. When it encounters something unexpected, Windows should fail securely. In this case it doesn’t. So with a NULL DACL, everyone (including malware) will be able to do anything to the object (including setting a nasty rootkit-style DACL). For this reason, don’t create security descriptors with NULL DACLs.

Setting a NULL DACL isn’t the same as setting a NULL security descriptor. When passing a NULL security descriptor, Windows will replace it with a default security descriptor, and this security descriptor is secure, and allows enough access to the object. Setting a NULL DACL means passing a valid security descriptor, whose Dacl member happens to be NULL.

In a similar way, you probably don’t want to set a DACL that doesn’t contain any Access Control entries. In this DACL, when Windows attempts to enumerate the Access Control List, it will fail on the first attempt, therefore, it will deny access regardless of the action. The result is a completely inaccessible object (not much better than a non-existent object). You must have a filled DACL if you want to access the object.

So how do we build a Discretionary access control list?

Think about who you want to allow access to and who you don’t want to allow access. Is your DACL black list based (full of deny ACEs), or white list based (full of allow ACEs). If you are creating an ACL, you should prefer a white list approach to the security descriptor. How long is the object going to last? Is it a long running object (like the app mutex for a long running process), a short running object (like a synchronization event), or is it a permanent object (like a file)?

To determine a good security descriptor decide what you are going to do to the object. If you are securing a kernel object, you probably only need to synchronize, read and read the security on it. If you are securing a file, you’ll probably need all accesses available (one day).

Generally, for permanent objects you need at least two accounts to have access to the object. The first user is the LocalSystem account (restricting access to this account can lead to serious problems if it is a permanent object). The other is the object creator (or alternatively, the current owner) of the object. You should also consider giving administrators full control to the object. Another technique you can consider is only allowing the users read and execute access. When they want to delete the file, they will have to add the DELETE right themselves, then delete it.

For short running objects, you should apply the principal of least privilege to the object. For example, if all you are going to do with an object is read from it and synchronize it, then create a DACL that only allows read and synchronize access (you can even restrict the LocalSystem’s account this way if it is a short lived object).

If your object supports inheritance, then you don’t need a special DACL on the object (unless your file is special in terms of security), you can just apply the DACL for the parent (do this by setting the auto inherit flag in the Control member of the security descriptor). The default security descriptor will apply the inheritance flag for you.

And finally, if in doubt, ask the admins!

5. Windows 2000 Inheritance Model

Starting with Windows 2000, ACLs can be set to inherit from their parent. What this means is that the ACL of the parent will be applied to the child (e.g. the permissions for «Program FilesCommon FilesMicrosoft Shared» will be the same as «Program FilesCommon Files«). A special flag in the ACE will state that it is inherited.

As stated in the previous section, Windows walks the list of ACEs until it reaches the end or finds an ACE that matches you. If inheritance is enabled, when Windows reaches the end of the list, it will start walking the ACL of the parent folder to find a matching ACE. Therefore, the object will have the parent’s ACL applied to itself, automatically. This only occurs if the ACL is set to inherit from the parent object.

If the folder also has inheritance, Windows will walk up that folder too. This can continue all the way until Windows hits a folder that has inheritance disabled, or it hits the root of the drive. The result is that the resultant ACL is a merged view of the current object and its parent. The ACEs that come from the parent are called inherited ACEs, and the ACEs that come from the file itself are called the protected ACEs.

To support ACL inheritance, you must design your classes to have parent-child relationships (like a file/folder, or a registry key/value). The parent will be referred to as a container (e.g. folder), and the child will be referred to as an object (like a file).

For really advanced ACL control, Windows 2000 supports applying ACEs only to folders and not files (and vice versa). The ACE flag that controls inheritance also states which type of inheritance to apply. There are four flags:

1. OBJECT_INHERIT_ACE (OI): indicates the ACE gets inherited to child objects (e.g. files).
2. CONTAINER_INHERIT_ACE (CI): indicates the ACE gets inherited to child containers (e.g. subfolders).
3. INHERIT_ONLY_ACE (IO): indicates the ACE applies not to this object, but to child objects (e.g. child files/subfolders only).
4. NO_PROPAGATE_INHERIT_ACE (NP): do not apply this ACE to grandchildren, just the direct children (e.g. apply files but not files in subfolders).

These flags can be (and usually are) combined. To make the ACE apply to every child object within yourself (including inside subfolders), specify (OBJECT_INHERIT_ACE | CONTAINER_INHERIT_ACE).

For a more complete description of ACE inheritance, check out Keith Brown’s book.

6. The Access Token

The final structure I will describe today is the Access token. I don’t want to delve too much into this structure otherwise I may stray off topic (it’s relevant not only to access control, but to privileges, policy, group membership as well as IPC across logon sessions). The access token forms an integral part of both the thread and process objects. The access token identifies who you are in the context of security. Windows NT maintains user information per process, as this allows processes and threads to run as a different user (if you wanted to know how Task Manager knows which user a process runs under, it’s in the access token). The access token is the feature that allows services, runas, and fast user switching to exist.

The access token can either be a process token, a primary thread token, or a thread impersonation token. Unless your thread is impersonating, your thread doesn’t have a token (you’ll be using the process token instead). Once you’ve made your thread impersonating, you’ll have an impersonation token associated with your thread. You can convert your impersonation token into a primary token (suitable for CreateProcessAsUser()) by calling DuplicateTokenEx()).

When you log in to Windows, your processes will have their tokens set to your username when run. If you open your own token and look inside it, you can find out the name of the user you are running as (all without needing to invoke GetUserName()).

Figure 5: An illustration of the access token.

There’s a lot of information you can gleam from a token via GetTokenInformation(). For example:

• TokenUser: Which user the process runs as.
• TokenGroupsandPrivileges: Which groups the user belongs to (as well as TokenGroups, TokentRestrictedSids, TokenPrivileges and TokenUser).
• TokenGroups: The complete list of groups to which the user belongs (gives more information than «net.exe user <user>«, WMI, User Management console, and «control userpasswords2«).
• TokenPrivileges: The list of privileges.
• TokenDefaultDacl, TokenOwner, TokenDefaultGroup: The definition of a default security descriptor.
• TokenType: Whether this token impersonates.
• TokenSource: The source of the access token.
• TokenRestrictedSids: The list of restricted SIDs.

For the purposes of access control, most of the information we need from the access token are in the TokenGroupsandPrivileges structure. With this value, you rollup the GetUserName(), NetUserGroups(), CheckTokenMembership() and LookupPrivilegeValue() APIs all in one. The token shows that being a member of the administrators group also makes you a member of the None group, the Authenticated Users group, the Users group, the Power Users group, and the LOCAL group. This is useful to you as you now have a list of user groups to which you belong, and can now search an ACL using this list. To see if an ACL grants you access:

1. Open up your thread token.
2. Get the list of groups.
3. Obtain the SECURITY_DESCRIPTOR for the object.
4. Get the ACL from the security descriptor.
5. For each ACE in the ACL, lookup the SID associated with that ACE.
6. Lookup this SID in the list of groups you created in step 2.
7. If found, see if it is a deny or allow ACE.
8. If it is an allow ACE, compare the ACCESS_MASK with your desired ACCESS_MASK.
9. If all accesses are allowed, you are allowed access.
10. If an error occurs, you are denied access.

Add in error/parameter checking to the above list (and auditing), and you have just created yourself a pseudo AccessCheck() function.

You’ve probably already encountered the default security descriptor. Whenever you encountered an API that requested a SECURITY_ATTRIBUTES parameter, you most likely passed in NULL for that parameter (which means «default security descriptor»). By calling GetTokenInformation(TokenDefault*), you can find out what that default security descriptor is.

The privileges are a list of policies that must be enabled before you are allowed to perform certain system-critical functions (like shutdown the system, or install drivers). These privileges are configurable via group policy (user rights assignment), and are listed in your thread token. The privileges are disabled by default (exception: SeChangeNotifyPrivilege), so you must enable the privilege before you can use it. The Platform SDK provides a sample function SetPrivilege() that can enable and disable a privilege whenever you need it. I strongly suggest you add this function to your security utility library, because you are going to reuse that function again and again, especially with access control. Enabling a privilege then becomes a matter of adding two lines to your code:

...
SetPrivilege(SePrivilegeName, TRUE); 



SetPrivilege(SePrivilegeName, FALSE);
...

Figure 16: Enabling and disabling a privilege using the Platform SDK sample function.

I don’t want to go into sandboxing or impersonation (since they are rather off topic for access control). If you want to know more about impersonation and privileges, look at this WindowsSecurity article, or Paul Cooke’s book.

7. A note on the Security Descriptor Definition Language

The Security Descriptor Definition Language is an attempt to represent a security descriptor in text form that both administrators and programs can understand. The full reference (and in my humble opinion, the only decent reference) to the SDDL format is located in the help documentation.

Briefly, the SDDL string contains the following parts: a group, an owner, the DACL and SACL. These sections are delimited by a one-letter label followed by a colon (O: delimits the owner, G: delimits the group, D: delimits the DACL, S: delimits the SACL). Following the group and delimiters are SIDs that denote the owner and group. Following the D: and S: delimiters are a list of bracket separated entries (each bracket represents an ACE in the list).

The ACE bracket consists of six semicolon delimited terms that represent ACE type, inheritance, ACCESS_MASK, GUID, inherited GUID, and user SID respectively. The ACE brackets are stacked up in the list to form the overall ACL. Prefixing the list of ACE brackets can be some other flags; these represent the control flags for the security descriptor. The following is an example SDDL we will dissect (I’ve separated the different sections for clarity):

O:AOG:DAS:D:(A;;RPWPCCDCLCSWRCWDWOGA;;;S-1-0-0)(A;;GA;;;SY)

First, tokenize this string using the delimiters:

O:	G:	S:	D:
AO	DA		(A;;RP WP CC DC LC SW RC WD WO GA;;;S-1-0-0) (A;;GA;;;SY)

Figure 7a: The SDDL string tokenized into separate strings.

Next, expand the SID strings and ACE strings:

Owner	Group	SACL	DACL
Account Operators	Domain Administrators		(A;;ADS_RIGHT_DS_READ_PROP | ADS_RIGHT_DS_WRITE_PROP | ADS_RIGHT_DS_CREATE_CHILD | ADS_RIGHT_DS_DELETE_CHILD | ADS_RIGHT_DS_LIST | ADS_RIGHT_DS_SELF | READ_CONTROL | WRITE_DAC | WRITE_OWNER | GENERIC_ALL;;; null SID)(A;;GENERIC_ALL;;;LocalSystem)

Figure 7b: The SDDL string with the SID strings and ACE strings expanded

Finally, expand the constant strings:

Owner	Group	SACL	DACL
Account Operators	Domain Administrators		Allow (null SID): 0x01e000bb Allow LocalSystem: 0x100000

Figure 7c: The security descriptor that the SDDL string specifies.

This is the meaning of the SDDL string specified. For a whole bunch of example SDDL strings, take a look at the %windir%securitytemplates*.inf files. This is what Windows Setup used to apply the default security descriptors for your Windows installation. See if you can decrypt the security descriptors for those strings. (To find out the answers, you can call the ConvertStringSecurityDescriptorToSecurityDescriptor() function on the security descriptor strings.)

Sorry about the poor explanation about SDDL strings. Like I said, the best reference for SDDL is in the SDK documentation, and I still stand by that statement.

8. Coming Up

In this part, you learnt how Windows NT secured its objects using security descriptors. You discovered that Windows recognizes users, groups and computers as SIDs. You learnt that security descriptors originally came from kernel mode, therefore they can be complex beasts. You were shown the parts of a security descriptor, the five components which make it up, and how it is stored in memory. You were then shown the two types of access control list. You discovered the structure of the ACL, how Windows reads an ACL, and how inheritance is implemented within the Access control model. The last structure you learnt about was the access token. You were taught what information can be read from a token, and finished off with enabling a permission.

In Part 2, you will start writing some example code for reading and writing security descriptors. You will also obtain information from the primary token to create a WhoAmI clone. Whilst you are waiting for the next article to come up, I want you to choose which technique you are going to program with. I am going to present four ways of programming with security:

1. The low level way. If you need to program for NT3.5, and don’t have ATL, you’ll have no choice but to choose this method. This method makes direct calls to the low level ACL functions, and they are horrible! Not only is it nontrivial to program, this method is also excessively complex and error prone (no wonder Windows NT had so many security bugs [^]!). Unless you need to support backward compatibility (since when did you care about backward compatibility?), I strongly recommend you steer clear of this method if you can help it. If you want a preview of this method, check out the SDK docs on SetEntriesInAcl() [^].
2. The Windows 2000 way. Realising how difficult method 1 was, Microsoft invented an alternative API for creating security descriptors, the Security Descriptor Definition Language (SDDL). Initially, SDDL may not be much better than low level authorisation (just as complex, and not as compatible). However, being in text mode makes SDDL infinitely more readable, for both programmers and administrators. And if you look closely at a number of SDDLs, along with the corresponding ACLs, you’ll soon get the hang of it. Windows 2000 also introduces API helpers to automate repetitive tasks (like printing a SID in text form). If you want a preview, check out the SDK docs on ConvertStringSecurityDescriptorToSecurityDescriptor() [^].
3. The ATL way. As part of the Trustworthy Computing Initiative, Microsoft made a number of updates to ATL, culminating in the ATL security classes. If you have Visual C++ .NET, and don’t mind programming with ATL C++, you’ll want to choose this method. To see a preview, check out the CSecurityDesc() [^] class from the Visual C++ help.
4. The .NET way. Starting with v2.0 of the .NET Framework, you can also choose to program security descriptors in a fully object oriented managed environment. Note, that I will not cover this in part 2 of the series. Instead programming security in .NET will have its very own part in this series (Part 3). If you have Visual Studio .NET 2005, you should strongly consider choosing this method. You can see a preview in the System.Security.AccessControl [^].

History

The history and bibliography are now maintained in Part 4 [^].

Next Part… [^]

Figure 1: The ACL Editor

Introduction

In this series of articles, I will discuss the Windows Access Control model and its implementation in Windows NT and 2000. I intend this series to be four parts long. I originally intended this series of articles to be just one part long (I was only going to write about the Windows-2000 style ACL editor), but there is so much you need to know about Windows Access Control, I might as well devote an entire series dedicated to the topic.

This first article serves as an introduction to ACL-based Authorization (from a programming point of view) in Windows NT and how the access control model is implemented. If you have never programmed with Windows security, or are just starting, this first article is for you. Although this first article will display structures in C, you should read this article even if you aren’t programming in C. It contains concepts relevant to all programmers.

This series of articles isn’t meant as a primer on security administration (there are plenty of articles, websites, courses and books on that). Rather, it is intended to discuss the Windows NT Security model from a programmatic perspective. I will already assume you know how to set permissions on files, registry keys, and are quite proficient with the ACL editor. I will also assume you know what users are and what groups are.

Access Control is not available in 16-bit Windows or Windows 95/98/ME.

Table Of Contents

The table of contents is for the entire series.

1. Part 1 — Background and Core Concepts. The Access Control Structures
   1. The Security Identifier (SID)
   2. The Security Descriptor (SD)
   3. The Access Control List (ACL)
   4. Choosing a good discretionary access control list
   5. Windows 2000 Inheritance Model
   6. The Token
   7. A Note on the Security Descriptor Definition Language
   8. Coming Up
2. Part 2 — Basic Access Control programming
   1. Choosing your language
   2. Fun with SIDs
   3. Which Groups are you a member of?
   4. Enabling Token Privileges
   5. Dissecting the Security Descriptor
   6. Walking an Access Control List
   7. Creating an Access Control List
   8. Do I Have Access?
   9. Creating and Editing a Secure Object
   10. Making Your Own Classes Secure
   11. Toy Programs Download
3. Part 3 — Access Control programming with .NET v2.0
   1. A history of .NET security.
   2. Reading a SID in .NET.
   3. Whoami .NET.
   4. Privilege handling in .NET.
   5. Running as an unprivileged user in .NET.
   6. Obtaining and editing a security descriptor in .NET, and applying it to an object.
   7. Access checks in .NET.
   8. NetAccessControl program and AccessToken class library.
4. Part 4 — The Windows 2000-style Access Control editor
   1. Features of the ACL editor (ACLUI).
   2. Getting Started.
   3. Implementing the ISecurityInformation Interface.
   4. ISecurityInformation::SetSecurity
   5. Optional Interfaces.
   6. Presenting the interface.
   7. Filepermsbox — A program to display the security descriptor on an NTFS file or folder.
   8. History

Background

One of the original design goals of Windows NT was to provide a layer that can implement security for the operating system. The way Windows NT implemented security for its objects was through the Access control model. Even role-based security and the .NET classes could not replace this ACL-based security model. ACLs are far too embedded in the NTFS architecture objects, and the registry was to be rendered obsolete (so much so, that .NET v2.0 had to relent and end up supporting the ACL model too).

To start off, I will describe the different types of structures you may meet when programming for access control. This article is intended for all programmers (this part contains no code, just structures and programming concepts).

1. The Security Identifier (SID)

Before delving into the concepts of authorization, I should take a discussion about the Security Identifier (SID). We humans like to refer to a user by their user name (like «Administrator»). A computer must refer to the user in binary. It recognises a user by means of a hash (which is called a SID). When a user is created, the computer generates a SID for that user and from then on, it will refer to that user by its SID (not its username). To see a list of your own SIDs, open up regedit and expand the HKEY_USERS tree (you will see a list of the SIDs for the currently logged on users). You can convert the raw SID struct into a textual form by using ConvertSidToStringSid(). A textual SID (usually starts with S-1-5-21-…) consists of at least 3 dash-separated values (which stand for revision, authority, sub authority, ID and primary groups).

A SID can also represent a user group, a computer, a domain or even a forest. Windows maintains a list of hardcoded SIDs called the Well-Known SIDs (they represent accounts like the LocalSystem, or the NetworkService account). You can view a list of these SIDs in the WELL_KNOWN_SID_TYPE enumeration.

To convert a SID to a username, you would need to call LookupAccountSid(), and LookupAccountName() to convert a user name to a SID. However, most of the security functions accept either a SID or a username (they actually accept a TRUSTEE structure, which is a kind of union of the username and SID).

2. The Security Descriptor (SD)

Windows NT secures its objects by means of a structure called the security descriptor (SECURITY_DESCRIPTOR). The security descriptor is an integral part of the structure from which Windows objects are built. This means every object (be it file objects, registry keys, network shares, mutexes, semaphores, processes, threads, tokens, hardware, services, drivers…) recognized by Windows NT can be secured. The security descriptor structure exists in both kernel mode and user mode (and is identical in both modes). Although this allows for code reuse for both kernel mode and user mode security, it also means the SECURITY_DESCRIPTOR inherits some nasty quirks from kernel mode.

If you open up Winnt.h and scroll down to the SECURITY_DESCRIPTOR struct, you’ll see the structure of the security descriptor (Fig. 2). This SECURITY_DESCRIPTOR may actually be one of two structs, one is an absolute security descriptor (SECURITY_DESCRIPTOR), and the other is a self-relative security descriptor (Fig. 3 SECURITY_DESCRIPTOR_RELATIVE).

typedef struct _SECURITY_DESCRIPTOR
{
    BYTE Revision;             
    BYTE Sbz1;                 
    SECURITY_DESCRIPTOR_CONTROL Control;
        
    PSID Owner;                
    PSID Group;                
    PACL Sacl;                 
    PACL Dacl;                 
} SECURITY_DESCRIPTOR, *PISECURITY_DESCRIPTOR;

Figure 2: The Absolute Security Descriptor.

Notice that a security descriptor consists of five members (excluding the two version control members):

• Discretionary Access Control List (Dacl): This is where the permissions of the object are kept (who’s allowed access to the object, who’s denied).
• System Access Control List (Sacl): Specifies the type of auditing to be performed on the object. If an auditing event occurs, it will be stored in the Auditing Event Log.
• Owner: Specifies the owner of the object (as a SID). The owner of the object can always alter the security descriptor, regardless if someone else has locked out access.
• Group: Specifies the primary group of the object (as a SID). Windows mostly ignores this parameter (it was for POSIX compatibility, but its presence is rather vestigial now).
• Control: A bunch of flags that make up a 16-bit integer. It can be zero or more of the following flags:
  • SE_DACL_PRESENT: The Dacl member is valid.
  • SE_SACL_PRESENT: The Sacl member is valid.
  • SE_DACL_AUTO_INHERITED: The DACL auto-inherits and gets entries from its parent included in itself.
  • SE_SACL_AUTO_INHERITED: same as SE_DACL_AUTO_INHERITED, but it applies to the SACL.
  • SE_DACL_PROTECTED: If the parent’s ACLs conflict with any ACL defined here, override the parent’s ACL. Useful for overriding inheritance.
  • SE_SACL_PROTECTED: Same as SE_DACL_PROTECTED, but for SACLs.
  • SE_DACL_DEFAULTED: The Dacl member equals the default DACL for this object type.
  • SE_SACL_DEFAULTED: The Sacl member equals the default SACL for this object type.
  • SE_GROUP_DEFAULTED: The Group member equals the default Group for this object type.
  • SE_OWNER_DEFAULTED: The Owner is defaulted.
  • SE_SELF_RELATIVE: Indicates this security descriptor is self-relative.

The last 4 entries of this structure are all pointers, and they point to the buffers where the ACLs etc. can be found. These pointers can point to any valid location in memory (not necessarily in a contiguous block). Because the security descriptors aren’t contiguous, it is going to be rather cumbersome to write the security descriptors to disk, or across processes. Microsoft solved this problem by introducing a new structure, called the self-relative security descriptor (Fig. 3 SECURITY_DESCRIPTOR_RELATIVE).

typedef struct _SECURITY_DESCRIPTOR_RELATIVE
{
    BYTE  Revision;    
    BYTE  Sbz1;        
    SECURITY_DESCRIPTOR_CONTROL Control;
    
    DWORD OwnerOffset;
    
    DWORD GroupOffset; 
    DWORD SaclOffset;  
    DWORD DaclOffset;  

    struct SecurityDescriptorData 
    {
    
        ...            
        SID Owner;     
        ...
        SID Group;     
        ...
        ACL Sacl[]; 
        
        ...
        ACL Dacl[];
    } ;
} SECURITY_DESCRIPTOR_RELATIVE, *PISECURITY_DESCRIPTOR_RELATIVE;

Figure 3: The structure of the relative security descriptor

The self-relative security descriptor is much more complicated than the absolute security descriptor (so complex, that you cannot represent it in C++). Although the first three fields are the same as the absolute security descriptor, the security descriptors become very different after that. Following the Control member are four DWORDs (which represent offsets to the data). The data for the security descriptor all follow these four DWORDs. I’ve inserted padding bytes into the structure to illustrate that the data can appear anywhere in the buffer (simply change the Offset members to move the buffer). The four members do not need to appear in any particular order either. By choosing special offsets, you can make the Owner member appear after the group. At the expense of being horrendously complicated, the self-relative security descriptor occupies one contiguous block, making it suitable for transporting between application boundaries and storage media.

How can you tell the difference between an absolute and self-relative security descriptor? The difference is that with an absolute security descriptor, after the Control member are four pointers to the Group / Owner / SACL / DACL (in that order), and these four pointers point to separate locations in memory where the data can be found. With a self-relative security descriptor, after the Control member are four DWORDs which represent offsets to the Group / Owner / SACL / DACL. For example, if the group member has the value 0xf, then it’s telling Windows, «You can find the group SID 0xf bytes after me». 64-bit Windows makes this even more confusing when these two structures have differing sizes!

To make matters worse, Microsoft doesn’t distinguish between the absolute or self-relative security descriptor in their docs. Microsoft has reserved the right to make internal changes to the security descriptor, meaning you cannot rely on this structure being the same in future. Instead, if you want to manipulate a security descriptor, you should do so using the authorization APIs. Using the APIs encapsulate the complexity of these structures from you. So to distinguish between an absolute security descriptor and a self-relative one, call GetSecurityDescriptorControl(), and test for the SE_SELF_RELATIVE flag.

It’s important that you know which API expects an absolute security descriptor, and which ones expect a self-relative one. In Part 2 [^] of this series, you will get around to actually building a security descriptor.

3. The Access Control List (ACL)

Whenever you perform an action (e.g. a read) on an object in Windows NT, the action is encoded into a 32 bit integer (called the ACCESS_MASK). The ACCESS_MASK is specific to the object you are trying to create (if you read a file, the ACCESS_MASK would be FILE_GENERIC_READ). When you open the object with the requested ACCESS_MASK, Windows will get your username (inside your thread token) and then start reading the discretionary access control list (obtained from the security descriptor).

The DACL can be thought of as a table of user SIDs, ACCESS_MASKs, and access types. Don’t try to code it as an array of structs though. Use the low-level ACL functions GetAce(), GetAclInformation() & friends if you want to parse an ACL. In NT4, Microsoft provides a view of the ACL that looks exactly like a table of SIDs, ACCESS_MASKs and types (the EXPLICIT_ACCESS structure).

struct ACE
{
    BYTE AceType;     
    BYTE AceFlags;    
    ...
    ACCESS_MASK Mask; 
    ...
    SID Sid;          
} ;

struct ACL
{
    BYTE AclRevision;
    ...
    WORD AceCount;                  
    ...
    ACE AceList[this->AceCount];    
} ;


typedef struct _EXPLICIT_ACCESS
{
    DWORD grfAccessPermissions;     
    ACCESS_MODE grfAccessMode;      
    DWORD grfInheritance;           
    TRUSTEE Trustee;                
} EXPLICIT_ACCESS, *PEXPLICIT_ACCESS;

Figure 4: An outline of the ACL and the ACE.

If the DACL is a table, then each row in the table is called an Access Control Entry. When an action is performed, Windows will enumerate this list of ACEs to find an entry that refers to you (you being the thread token). Windows enumerates the ACEs in the order they appear in the ACL. At first sight this goes against your intuition, the Help documentation, and what the MCP books say («I thought Windows walks the Deny ACEs first, then walks the Allow ACEs. Now you’re telling me this is wrong?»). Actually, we are both right. When Windows sets the DACL, it sorts the access control entries [^] so that deny ACEs do precede allow ACEs, and the access control model follows what you were taught.

If you make a call to the low level functions, you can circumvent the sorting, and make the ACEs appear in any order you like. The Cygwin tools utilise this technique to create DACLs unordered. However, these DACLs will not obey the access control rules, and you can make files with broken ACLs.

If you (your token) isn’t found in the ACL, then the open object function fails (Access denied). If you are found, Windows will look in the ACE to see what you are allowed to do. If the ACE allows you to open the object, you are granted access. If anything fails here, you are denied access (this is an example of a security best practice: «if anything goes wrong, make sure you fail securely»).

Now that you have been granted or denied access, Windows will now make a check on the other ACL, the System Access Control List. The difference between an SACL and a DACL is that DACL contains allow / deny entries, but an SACL contains audit entries. The SACL tells Windows which actions to log in the Security Event Log (audit successes / failures). Apart from that, you can treat the SACL / DACL as the same. If Windows finds an SACL which tells it to audit the access, then the access attempt is written to the Event log.

If you want to see if an ACL allows you access to the object, use the AccessCheck() API on the object.

4. Creating a good discretionary access control list

In almost every case, Windows has already decided a good discretionary access control list for you. When you encounter an API that asks for a security descriptor (or a SECURITY_ATTRIBUTES structure), simply pass in NULL for this parameter. Passing in NULL for either the SECURITY_ATTRIBUTES or SECURITY_DESCRIPTOR will tell the system to apply the default security descriptor. And that is probably what you were after.

If you need more advanced security, make sure you create a security descriptor that has a filled DACL. If you’ve initialized a security descriptor, but have forgotten to build up a DACL (and attach it to the security descriptor), you will get a NULL DACL. Windows sees this NULL DACL as an object that has the following ACE:

«Everyone: Full control»

Therefore, Windows will allow access to the object regardless of the action. This is one case where Microsoft broke its own best practices. When it encounters something unexpected, Windows should fail securely. In this case it doesn’t. So with a NULL DACL, everyone (including malware) will be able to do anything to the object (including setting a nasty rootkit-style DACL). For this reason, don’t create security descriptors with NULL DACLs.

Setting a NULL DACL isn’t the same as setting a NULL security descriptor. When passing a NULL security descriptor, Windows will replace it with a default security descriptor, and this security descriptor is secure, and allows enough access to the object. Setting a NULL DACL means passing a valid security descriptor, whose Dacl member happens to be NULL.

In a similar way, you probably don’t want to set a DACL that doesn’t contain any Access Control entries. In this DACL, when Windows attempts to enumerate the Access Control List, it will fail on the first attempt, therefore, it will deny access regardless of the action. The result is a completely inaccessible object (not much better than a non-existent object). You must have a filled DACL if you want to access the object.

So how do we build a Discretionary access control list?

Think about who you want to allow access to and who you don’t want to allow access. Is your DACL black list based (full of deny ACEs), or white list based (full of allow ACEs). If you are creating an ACL, you should prefer a white list approach to the security descriptor. How long is the object going to last? Is it a long running object (like the app mutex for a long running process), a short running object (like a synchronization event), or is it a permanent object (like a file)?

To determine a good security descriptor decide what you are going to do to the object. If you are securing a kernel object, you probably only need to synchronize, read and read the security on it. If you are securing a file, you’ll probably need all accesses available (one day).

Generally, for permanent objects you need at least two accounts to have access to the object. The first user is the LocalSystem account (restricting access to this account can lead to serious problems if it is a permanent object). The other is the object creator (or alternatively, the current owner) of the object. You should also consider giving administrators full control to the object. Another technique you can consider is only allowing the users read and execute access. When they want to delete the file, they will have to add the DELETE right themselves, then delete it.

For short running objects, you should apply the principal of least privilege to the object. For example, if all you are going to do with an object is read from it and synchronize it, then create a DACL that only allows read and synchronize access (you can even restrict the LocalSystem’s account this way if it is a short lived object).

If your object supports inheritance, then you don’t need a special DACL on the object (unless your file is special in terms of security), you can just apply the DACL for the parent (do this by setting the auto inherit flag in the Control member of the security descriptor). The default security descriptor will apply the inheritance flag for you.

And finally, if in doubt, ask the admins!

5. Windows 2000 Inheritance Model

Starting with Windows 2000, ACLs can be set to inherit from their parent. What this means is that the ACL of the parent will be applied to the child (e.g. the permissions for «Program FilesCommon FilesMicrosoft Shared» will be the same as «Program FilesCommon Files«). A special flag in the ACE will state that it is inherited.

As stated in the previous section, Windows walks the list of ACEs until it reaches the end or finds an ACE that matches you. If inheritance is enabled, when Windows reaches the end of the list, it will start walking the ACL of the parent folder to find a matching ACE. Therefore, the object will have the parent’s ACL applied to itself, automatically. This only occurs if the ACL is set to inherit from the parent object.

If the folder also has inheritance, Windows will walk up that folder too. This can continue all the way until Windows hits a folder that has inheritance disabled, or it hits the root of the drive. The result is that the resultant ACL is a merged view of the current object and its parent. The ACEs that come from the parent are called inherited ACEs, and the ACEs that come from the file itself are called the protected ACEs.

To support ACL inheritance, you must design your classes to have parent-child relationships (like a file/folder, or a registry key/value). The parent will be referred to as a container (e.g. folder), and the child will be referred to as an object (like a file).

For really advanced ACL control, Windows 2000 supports applying ACEs only to folders and not files (and vice versa). The ACE flag that controls inheritance also states which type of inheritance to apply. There are four flags:

1. OBJECT_INHERIT_ACE (OI): indicates the ACE gets inherited to child objects (e.g. files).
2. CONTAINER_INHERIT_ACE (CI): indicates the ACE gets inherited to child containers (e.g. subfolders).
3. INHERIT_ONLY_ACE (IO): indicates the ACE applies not to this object, but to child objects (e.g. child files/subfolders only).
4. NO_PROPAGATE_INHERIT_ACE (NP): do not apply this ACE to grandchildren, just the direct children (e.g. apply files but not files in subfolders).

These flags can be (and usually are) combined. To make the ACE apply to every child object within yourself (including inside subfolders), specify (OBJECT_INHERIT_ACE | CONTAINER_INHERIT_ACE).

For a more complete description of ACE inheritance, check out Keith Brown’s book.

6. The Access Token

The final structure I will describe today is the Access token. I don’t want to delve too much into this structure otherwise I may stray off topic (it’s relevant not only to access control, but to privileges, policy, group membership as well as IPC across logon sessions). The access token forms an integral part of both the thread and process objects. The access token identifies who you are in the context of security. Windows NT maintains user information per process, as this allows processes and threads to run as a different user (if you wanted to know how Task Manager knows which user a process runs under, it’s in the access token). The access token is the feature that allows services, runas, and fast user switching to exist.

The access token can either be a process token, a primary thread token, or a thread impersonation token. Unless your thread is impersonating, your thread doesn’t have a token (you’ll be using the process token instead). Once you’ve made your thread impersonating, you’ll have an impersonation token associated with your thread. You can convert your impersonation token into a primary token (suitable for CreateProcessAsUser()) by calling DuplicateTokenEx()).

When you log in to Windows, your processes will have their tokens set to your username when run. If you open your own token and look inside it, you can find out the name of the user you are running as (all without needing to invoke GetUserName()).

Figure 5: An illustration of the access token.

There’s a lot of information you can gleam from a token via GetTokenInformation(). For example:

• TokenUser: Which user the process runs as.
• TokenGroupsandPrivileges: Which groups the user belongs to (as well as TokenGroups, TokentRestrictedSids, TokenPrivileges and TokenUser).
• TokenGroups: The complete list of groups to which the user belongs (gives more information than «net.exe user <user>«, WMI, User Management console, and «control userpasswords2«).
• TokenPrivileges: The list of privileges.
• TokenDefaultDacl, TokenOwner, TokenDefaultGroup: The definition of a default security descriptor.
• TokenType: Whether this token impersonates.
• TokenSource: The source of the access token.
• TokenRestrictedSids: The list of restricted SIDs.

For the purposes of access control, most of the information we need from the access token are in the TokenGroupsandPrivileges structure. With this value, you rollup the GetUserName(), NetUserGroups(), CheckTokenMembership() and LookupPrivilegeValue() APIs all in one. The token shows that being a member of the administrators group also makes you a member of the None group, the Authenticated Users group, the Users group, the Power Users group, and the LOCAL group. This is useful to you as you now have a list of user groups to which you belong, and can now search an ACL using this list. To see if an ACL grants you access:

1. Open up your thread token.
2. Get the list of groups.
3. Obtain the SECURITY_DESCRIPTOR for the object.
4. Get the ACL from the security descriptor.
5. For each ACE in the ACL, lookup the SID associated with that ACE.
6. Lookup this SID in the list of groups you created in step 2.
7. If found, see if it is a deny or allow ACE.
8. If it is an allow ACE, compare the ACCESS_MASK with your desired ACCESS_MASK.
9. If all accesses are allowed, you are allowed access.
10. If an error occurs, you are denied access.

Add in error/parameter checking to the above list (and auditing), and you have just created yourself a pseudo AccessCheck() function.

You’ve probably already encountered the default security descriptor. Whenever you encountered an API that requested a SECURITY_ATTRIBUTES parameter, you most likely passed in NULL for that parameter (which means «default security descriptor»). By calling GetTokenInformation(TokenDefault*), you can find out what that default security descriptor is.

The privileges are a list of policies that must be enabled before you are allowed to perform certain system-critical functions (like shutdown the system, or install drivers). These privileges are configurable via group policy (user rights assignment), and are listed in your thread token. The privileges are disabled by default (exception: SeChangeNotifyPrivilege), so you must enable the privilege before you can use it. The Platform SDK provides a sample function SetPrivilege() that can enable and disable a privilege whenever you need it. I strongly suggest you add this function to your security utility library, because you are going to reuse that function again and again, especially with access control. Enabling a privilege then becomes a matter of adding two lines to your code:

...
SetPrivilege(SePrivilegeName, TRUE); 



SetPrivilege(SePrivilegeName, FALSE);
...

Figure 16: Enabling and disabling a privilege using the Platform SDK sample function.

I don’t want to go into sandboxing or impersonation (since they are rather off topic for access control). If you want to know more about impersonation and privileges, look at this WindowsSecurity article, or Paul Cooke’s book.

7. A note on the Security Descriptor Definition Language

The Security Descriptor Definition Language is an attempt to represent a security descriptor in text form that both administrators and programs can understand. The full reference (and in my humble opinion, the only decent reference) to the SDDL format is located in the help documentation.

Briefly, the SDDL string contains the following parts: a group, an owner, the DACL and SACL. These sections are delimited by a one-letter label followed by a colon (O: delimits the owner, G: delimits the group, D: delimits the DACL, S: delimits the SACL). Following the group and delimiters are SIDs that denote the owner and group. Following the D: and S: delimiters are a list of bracket separated entries (each bracket represents an ACE in the list).

The ACE bracket consists of six semicolon delimited terms that represent ACE type, inheritance, ACCESS_MASK, GUID, inherited GUID, and user SID respectively. The ACE brackets are stacked up in the list to form the overall ACL. Prefixing the list of ACE brackets can be some other flags; these represent the control flags for the security descriptor. The following is an example SDDL we will dissect (I’ve separated the different sections for clarity):

O:AOG:DAS:D:(A;;RPWPCCDCLCSWRCWDWOGA;;;S-1-0-0)(A;;GA;;;SY)

First, tokenize this string using the delimiters:

O:	G:	S:	D:
AO	DA		(A;;RP WP CC DC LC SW RC WD WO GA;;;S-1-0-0) (A;;GA;;;SY)

Figure 7a: The SDDL string tokenized into separate strings.

Next, expand the SID strings and ACE strings:

Owner	Group	SACL	DACL
Account Operators	Domain Administrators		(A;;ADS_RIGHT_DS_READ_PROP | ADS_RIGHT_DS_WRITE_PROP | ADS_RIGHT_DS_CREATE_CHILD | ADS_RIGHT_DS_DELETE_CHILD | ADS_RIGHT_DS_LIST | ADS_RIGHT_DS_SELF | READ_CONTROL | WRITE_DAC | WRITE_OWNER | GENERIC_ALL;;; null SID)(A;;GENERIC_ALL;;;LocalSystem)

Figure 7b: The SDDL string with the SID strings and ACE strings expanded

Finally, expand the constant strings:

Owner	Group	SACL	DACL
Account Operators	Domain Administrators		Allow (null SID): 0x01e000bb Allow LocalSystem: 0x100000

Figure 7c: The security descriptor that the SDDL string specifies.

This is the meaning of the SDDL string specified. For a whole bunch of example SDDL strings, take a look at the %windir%securitytemplates*.inf files. This is what Windows Setup used to apply the default security descriptors for your Windows installation. See if you can decrypt the security descriptors for those strings. (To find out the answers, you can call the ConvertStringSecurityDescriptorToSecurityDescriptor() function on the security descriptor strings.)

Sorry about the poor explanation about SDDL strings. Like I said, the best reference for SDDL is in the SDK documentation, and I still stand by that statement.

8. Coming Up

In this part, you learnt how Windows NT secured its objects using security descriptors. You discovered that Windows recognizes users, groups and computers as SIDs. You learnt that security descriptors originally came from kernel mode, therefore they can be complex beasts. You were shown the parts of a security descriptor, the five components which make it up, and how it is stored in memory. You were then shown the two types of access control list. You discovered the structure of the ACL, how Windows reads an ACL, and how inheritance is implemented within the Access control model. The last structure you learnt about was the access token. You were taught what information can be read from a token, and finished off with enabling a permission.

In Part 2, you will start writing some example code for reading and writing security descriptors. You will also obtain information from the primary token to create a WhoAmI clone. Whilst you are waiting for the next article to come up, I want you to choose which technique you are going to program with. I am going to present four ways of programming with security:

1. The low level way. If you need to program for NT3.5, and don’t have ATL, you’ll have no choice but to choose this method. This method makes direct calls to the low level ACL functions, and they are horrible! Not only is it nontrivial to program, this method is also excessively complex and error prone (no wonder Windows NT had so many security bugs [^]!). Unless you need to support backward compatibility (since when did you care about backward compatibility?), I strongly recommend you steer clear of this method if you can help it. If you want a preview of this method, check out the SDK docs on SetEntriesInAcl() [^].
2. The Windows 2000 way. Realising how difficult method 1 was, Microsoft invented an alternative API for creating security descriptors, the Security Descriptor Definition Language (SDDL). Initially, SDDL may not be much better than low level authorisation (just as complex, and not as compatible). However, being in text mode makes SDDL infinitely more readable, for both programmers and administrators. And if you look closely at a number of SDDLs, along with the corresponding ACLs, you’ll soon get the hang of it. Windows 2000 also introduces API helpers to automate repetitive tasks (like printing a SID in text form). If you want a preview, check out the SDK docs on ConvertStringSecurityDescriptorToSecurityDescriptor() [^].
3. The ATL way. As part of the Trustworthy Computing Initiative, Microsoft made a number of updates to ATL, culminating in the ATL security classes. If you have Visual C++ .NET, and don’t mind programming with ATL C++, you’ll want to choose this method. To see a preview, check out the CSecurityDesc() [^] class from the Visual C++ help.
4. The .NET way. Starting with v2.0 of the .NET Framework, you can also choose to program security descriptors in a fully object oriented managed environment. Note, that I will not cover this in part 2 of the series. Instead programming security in .NET will have its very own part in this series (Part 3). If you have Visual Studio .NET 2005, you should strongly consider choosing this method. You can see a preview in the System.Security.AccessControl [^].

History

The history and bibliography are now maintained in Part 4 [^].

Next Part… [^]