Московский физико-технический институт
Опубликован: 12.12.2007 | Доступ: свободный | Студентов: 5485 / 1820 | Оценка: 4.34 / 4.14 | Длительность: 13:57:00
ISBN: 978-5-94774-827-7
Лекция 13:

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

< Лекция 12 || Лекция 13: 123 || Лекция 14 >

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

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

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

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

Пример проверки прав доступа к защищенному объекту

Рис. 13.3. Пример проверки прав доступа к защищенному объекту

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

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

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

Заключение

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

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

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

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

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

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

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

Пример графа доступа

Рис. 13.4. Пример графа доступа

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

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

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

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

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

Пример матрицы доступа

Рис. 13.5. Пример матрицы доступа

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

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

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

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

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

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

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

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

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

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

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

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

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

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

< Лекция 12 || Лекция 13: 123 || Лекция 14 >
Ирина Оленина
Ирина Оленина
Николай Сергеев
Николай Сергеев

Здравствуйте! Интересует следующий момент. Как осуществляется контроль доступа по тому или иному адресу с точки зрения обработки процессом кода процесса. Насколько я понял, есть два способа: задание через атрибуты сегмента (чтение, запись, исполнение), либо через атрибуты PDE/PTE (чтение, запись). Но как следует из многочисленных источников, эти механизмы в ОС Windows почти не задействованы. Там ключевую роль играет менеджер памяти, задающий регионы, назначающий им атрибуты (PAGE_READWRITE, PAGE_READONLY, PAGE_EXECUTE, PAGE_EXECUTE_READ, PAGE_EXECUTE_READWRITE, PAGE_NOACCESS, PAGE_GUARD: их гораздо больше, чем можно было бы задать для сегмента памяти) и контролирующий доступ к этим регионам. Непонятно, на каком этапе может включаться в работу этот менеджер памяти? Поскольку процессор может встретить инструкцию: записать такие данные по такому адресу (даже, если этот адрес относится к региону, выделенному менеджером памяти с атрибутом, например, PAGE_READONLY) и ничего не мешает ему это выполнить. Таким образом, менеджер памяти остается в стороне не участвует в процессе...