Содержание к диссертации
Введение
Глава 1. Анализ моделей контроля и управления доступом и методов моделирования политик безопасности 12
1.1. Основные классы моделей контроля и управления доступом 13
1.1.1. Дискреционные модели контроля и управления доступом. Модель Харрисона-Руззо-Ульмана 13
1.1.2. Мандатные модели контроля и управления доступом. Модель Белла-ЛаПадулы 20
1.2. Реализация моделей контроля и управления доступом в современных операционных системах 30
1.2.1. Модель контроля и управления доступом операционной системы Linux 30
1.2.2. Модель контроля и управления доступом операционной системы Microsoft Windows 2000 36
1.3. Методы моделирования политик безопасности 40
1.3.1. Аналитические методы 40
1.3.2. Графовые методы 43
1.3.3. Объектные методы 45
1.3.4. Логические методы 49
1.3.5. Общая характеристика методов моделирования политик безопасности 52
1.4. Выводы к главе 54
Глава 2. Подход к проверке выполнения правил политик безопасности и его реализация 56
2.1. Обобщенное представление моделей контроля и управления доступом 56
2.2. Подход к проверке выполнения правил политик безопасности 61
2.3. Инструментарий моделирования 62
2.4.1. Концептуальные модели подсистем контроля и управления доступом 63
2.4.2. Реализация концептуальной модели 67
2.5. Применение инструментария моделирования 72
2.5.1. Описание дискреционной системы 72
2.5.2. Описание мандатной системы 73
2.5.3. Описание комбинированной системы 74
2.6. Выводы к главе 77
Глава 3. Средства проверки выполнения правил политик безопасности 79
3.1. Метод автоматизированного анализа выполнения правил политик безопасности 79
3.2. Модуль резолюций 81
3.2.1. Структура модуля 81
3.2.2. Принцип анализа выполнения правил политики безопасности средствами модуля резолюций 86
3.2.3. Пример использования модуля резолюций для анализа выполнения правил политик безопасности 89
3.3. Система проверки выполнения правил политик безопасности 94
3.3.1. Общая архитектура 94
3.3.2. Компоненты системы 96
3.4. Выводы к главе 100
Глава 4. Методика проверки выполнения правил политики безопасности и ее применение 101
4.1. Описание методики 101
4.2. Пример применения методики на базе операционной системы Microsoft Windows 2000 103
4.2.1. Предварительный анализ 103
4.2.2. Логические описания 105
4.2.3. Анализ выполнения правил политики безопасности 133
4.3. Выводы к главе 136
Заключение 138
Список литературы 140
- Реализация моделей контроля и управления доступом в современных операционных системах
- Концептуальные модели подсистем контроля и управления доступом
- Принцип анализа выполнения правил политики безопасности средствами модуля резолюций
- Пример применения методики на базе операционной системы Microsoft Windows 2000
Введение к работе
В наши дни обеспечение безопасности информационных систем (ИС) входит в круг интересов всех участников информационного процесса. Функционирование государственных и коммерческих ИС становится невозможным без поддержания их безопасности и целостности. Прогресс в области защищенных информационных технологий сопровождается усилением требований поддержания безопасности. Однако динамика статистики нарушений свидетельствует о кризисе информационной безопасности, основными причинами которого являются недостатки проектирования и эксплуатации средств защиты. Функции ИС должны выполняться при осуществлении надлежащего контроля информации, что гарантировало бы защиту информации от нежелательного распространения, изменения или потери.
На основании сформировавшихся требований потребителей разработчики ИС предлагают модели контроля и управления доступом (КУД), реализуемые в разрабатываемых продуктах. Для задания политики безопасности (ПБ) потребители вынуждены использовать решения, предлагаемые производителем (рис. В.1). Отсутствие у потребителя гарантий, кроме утверждений разработчиков, что в используемой системе ПБ выполняется корректно, является одной из основных причин нарушений безопасности.
Эта проблема особенно остро стоит в ИС, к которым предъявляются повышенные требования гарантированности защиты: в системах управления технологическими процессами, движением транспорта, проведения банковских операций, обработки секретной информации.
Значительным шагом на пути решения указанной проблемы является разработка и применение ГОСТ Р ИСО 15408, который приходит на смену нормативным документам Гостехкомиссии [1-7]. ГОСТ совместим с системой международной стандартизации и предписывает составление профиля защиты, включающего ПБ (рис. В.2) [8-11].
Стандарт накладывает требования обеспечения гарантированности выполнения системой правил ПБ. Согласно стандарту установление гарантированности основывается на активном исследовании ИС, в результате чего должны быть выявлены причины невыполнения ПБ [8-10, 12]. Поэтому введение нового ГОСТ требует создания методов и инструментария проверки выполнения ПБ. Автоматизация анализа выполнения ПБ позволит придать ему объективный характер, обеспечить надежность защиты информации и качество сертификационных исследований.
Моделирование выполнения правил ПБ — это новое научное направление, теоретическая и методологическая базы которого в настоящее время только формируются в работах таких ученых как Грушо А.А., Расторгуев С. П., Щербаков А.Ю., Деннинг Д.Е., МакЛин Д., Сандху Р., Самарати П. Специалисты Гостехкомиссии и ее подведомственных организаций разрабатывают средства автоматизации анализа защитных свойств (например, НКВД, АИСТ). Однако упомянутые средства не решают задачу в полном объеме. Данная работа опирается на результаты указанных исследований и развивает их отдельные положения применительно к задачам моделирования защитных механизмов и автоматизации проверки выполнения правил ПБ.
С практической точки зрения наиболее важной является задача разработки средств проверки выполнения правил ПБ, которая представляет одно из направлений более общей задачи обеспечения информационной безопасности. В этой связи разработка подхода к автоматизации анализа выполнения правил ПБ является актуальной проблемой, имеющей важное теоретическое и практическое значение.
Целью работы является обеспечение сертификационных исследований информационных систем по ГОСТ Р ИСО 15408 средствами проверки выполнения правил ПБ, основанными на применении метода автоматизированного анализа безопасности достижимых состояний.
Для достижения поставленной цели в работе решались задачи;
1. Анализ моделей КУД, средств защиты современных ИС, а также методов моделирования ПБ.
2. Разработка формы представления системных состояний, требований модели КУД и правил ПБ, предназначенной для моделирования и анализа средств защиты и универсальной по отношению к широкому классу моделей КУД.
3. Разработка метода проверки выполнения правил ПБ путем автоматизированного анализа безопасности достижимых состояний.
4. Разработка системы проверки выполнения правил ПБ, позволяющей автоматизировать процесс исследования ИС на предмет соблюдения ПБ.
5. Создание методики проверки выполнения правил ПБ в ходе сертификационных исследований ИС по ГОСТ Р ИСО 15408.
Для решения поставленных задач использовались системный анализ, теория алгоритмов, теория множеств, теория вычислений, методы математического моделирования и математической логики.
Научная новизна диссертационной работы состоит в следующем;
1. Проведен сравнительный анализ методов, используемых для моделирования и исследования ПБ.
2. Предложен и обоснован подход к проверке выполнения правил ПБ путем автоматизированного анализа достижимых состояний ИС.
3. Разработаны концептуальные модели подсистем КУД для современных операционных систем (ОС).
4. Разработана форма представления системных состояний, требований модели КУД и правил ПБ в виде системы логических предикатов.
5. Предложен метод проверки выполнения правил ПБ путем анализа безопасности достижимых состояний на основе вычисления предикатов, описывающих ПБ, в контексте системных состояний и модели КУД.
6. Разработана система проверки выполнения правил ПБ, позволяющая автоматизировать процесс исследования ИС путем генерации ее логического описания, вычисления предикатов и интерпретации результатов.
7. Разработана методика проверки выполнения правил ПБ в ходе сертификационных исследований ИС по ГОСТ Р ИСО 15408.
Практическая ценность работы определяется возможностью использования полученных в ходе работы результатов для проведения анализа ПБ и проверки ИС на соответствие ПБ. Метод автоматизированной проверки выполнения ПБ и средство описания системных состояний, правил ПБ и требований модели безопасности использованы при разработке программ и методик сертификационных исследований специализированной ИС (акт об использовании от ЗАО "РНТ", г. Москва). Подход к проверке ПБ путем автоматизированного анализа достижимых состояний испытываемой системы использован при разработке представления модели КУД, реализованной в системе мониторинга безопасности сложных информационных комплексов (акт об использовании от ЗАО "АРГО-Технолоджи", г. Москва). Метод автоматизированного анализа выполнения правил ПБ и разработанный комплекс средств оценки защищенности использованы при создании системы проверки выполнения ПБ организаций (акт об использовании от НИИ системотехники ХК "Ленинец", г. С.-Петербург). На основе теоретических и практических результатов разработаны учебно-методические материалы, используемые для подготовки специалистов в области защиты вычислительных систем по дисциплинам "Теоретические основы защиты информации" и "Безопасность ОС" в СПбГУАП (акт об использовании от СПбГУАП) и СШПТУ.
Основные теоретические и практические результаты диссертационной работы доложены и обсуждены: на Российской научно-технической конференции "Методы и технические средства обеспечения безопасности информации" (СПбГПУ, 1998-2002 гг.); на Санкт-Петербургском семинаре "Информационная безопасность-99" (СПбГТУ, 1999 г.); на ведомственной конференции "Проблемы обеспечения информационной безопасности на федеральном железнодорожном транспорте" (Внедренческий центр ГУП "Аттестационный центр Желдоринформзащита МПС РФ", 2001 г.); на Межрегиональной конференции "Информационная безопасность регионов России" (Институт информатики и автоматизации РАН, 2001, 2002 гг.); на Российской научно-технической конференции "Проблемы информационной безопасности в системе высшей школы" (МИФИ, 2002, 2003 гг.). Основные положения, выносимые на защиту:
1. Обоснование подхода к проверке выполнения правил ПБ путем автоматизированного анализа безопасности достижимых состояний ИС.
2. Метод проверки выполнения правил ПБ, основанный на вычислении предикатов, описывающих системные состояния, требования модели КУД и правила ПБ.
3. Система проверки выполнения правил ПБ.
4. Методика проверки выполнения правил ПБ на основе автоматизированного анализа безопасности состояний.
Диссертация состоит из введения, четырех глав, заключения и списка литературы из 95 наименований.
В первой главе рассмотрены основные классы моделей КУД и их реализации в современных ОС, проведен анализ методов моделирования ПБ, сформулирована задача автоматизированной проверки выполнения правил ПБ с использованием логического подхода.
Во второй главе рассмотрен предложенный автором подход к проверке выполнения правил ПБ путем автоматизированного анализа достижимых состояний испытываемой системы. Приведена разработанная форма представления системных состояний, правил ПБ и требований модели КУД в виде логических предикатов.
В третьей главе изложены теоретические основы предложенного автором метода проверки выполнения правил ПБ путем анализа безопасности достижимых состояний на основе вычисления предикатов. Приведена разработанная архитектура системы проверки выполнения правил ПБ, позволяющей автоматизировать процесс исследований ИС.
В четвертой главе рассмотрена разработанная автором методика проверки выполнения правил ПБ на основе автоматизированного анализа безопасности состояний, приведен пример применения СП при анализе подсистемы защиты, реализованной в ОС Windows 2000.
В заключении приведены результаты и выводы, полученные автором в ходе выполнения работы.
Реализация моделей контроля и управления доступом в современных операционных системах
Сегодня UNIX-системы используются на самых разнообразных аппаратных платформах. На их базе реализовано множество систем управления и обработки данных. Наибольшее распространение в среде некоммерческого сектора получили системы на основе ОС Linux. Как и в любой другой UNIX-системе, Linux предоставляет широкие возможности по организации дискреционного контроля доступа [28-35].
В ОС Linux определен один тип объектов, в котором содержатся данные, — файл. Файлы в Linux играют ключевую роль, что не всегда справедливо для других ОС. Вся информация хранится в виде файлов, доступ к периферии осуществляется в виде чтения/записи в специальный файл. Когда запускается программа, ядро загружает соответствующий исполняемый файл. Ядро Linux само является исполняемым файлом.
Важное понятие, связанное с файлами, — каталог. Каталог представляет собой набор файлов, тем самым позволяя формировать некоторую логическую структуру содержащейся в системе информации. Кроме файлов каталоги могут содержать подкаталоги. Таким образом, в ОС Linux файлы организованы в иерархическую древовидную структуру, в которой каждый узел соответствует каталогу. Такая система названа файловой системой. Помимо функции информационного хранилища файлы в ОС Linux определяют привилегии субъектов (пользователей), поскольку права пользователей в большинстве случаев контролируются с помощью прав доступа к файлам.
В Linux-системе с каждым файлом сопоставлены два владельца: владелец-пользователь (UID) и владелец-группа (GID). Особенностью является тоэ что владелец-пользователь может не быть членом владельца-группы. Это придает гибкость в организации доступа к файлам. Кроме этого с файлом связана маска прав доступа, которая определяет права доступа для трех классов пользователей файла: владелец файла; все пользователи, кроме владельца файла, принадлежащие к связанной с файлом группе; все остальные пользователи, не входящие в ранее названные категории.
Для каждой категории пользователей определены три основных типа прав доступа к файлам: право на чтение (г), право на запись (w)5 право на исполнение (х). Если пользователь не является суперполъзователем, который имеет любой доступ ко всем объектам независимо от прав доступа к ним, то при попытке действия над объектом тип запрашиваемого доступа сверяется с маской. Система хранит связанные с файлом права доступа в битовой маске, называемой кодом доступа к файлу.
Каждый каталог ОС Linux, почти как обычный файл, имеет набор нрав доступа, которые влияют на доступность файлов в каталоге, но права г, w, х для каталога имеют свое предназначение.
Помимо маски прав файл имеет дополнительные атрибуты управления доступом, обычно имеющие смысл, когда файл содержит исполняемый код: бит SUDD (set UID, задать идентификатор пользователя при выполнении файла); бит SG1D (set GID, задать идентификатор группы при выполнении файла); бит "sticky bit4 (бит фиксации, сохранить сегмент кода).
Данные 6и?ьі имеют значение только для файлов, у которых установлено право х для какой-либо категории пользователей (табл. 1.1).
Изменение идентификатора используется для управления доступом к критическим данным. Конфиденциальная информация может быть защищена от публичного доступа или изменения при помощи стандартных прав доступа на чтение/запись/выполнение. Владелец файла создает программу, которая будет предоставлять ограниченный доступ к файлу. Затем для файла программы устанавливается флаг доступа SUID, что позволяет другим пользователям получать ограниченный доступ к файлу только при помощи данной программы. Очевидно, возможна компрометация SUID-программы для нарушения зашиты. Самое простое правило защиты SUID-программы — запрет чтения такой программы.
Пример SUID-программы —passwd. Никто не может производить запись в файл паролей. Но пользователи все же имеют возможность менять свой пароль. Достигается это посредством программы passwd, так как ее владельцем является суперпользователь и для нее установлен флаг SUED.
Не столь полезна установка флага SGUD, которая выполняет те же функции, но для идентификатора группы файла.
Бит фиксации sticky bit исторически использовался для исполняемых файлов и назывался флагом сохранения сегмента кода (saveext-image). В ранних версиях ОС Linux, если для файла был установлен этот бит, при его выполнении образ программы (код и данные) оставался в файле подкачки до выключения системы. Поэтому при следующем запуске программы системе не приходилось искать файл в структуре каталогов системы, а можно было быстро переместить программу из файла подкачки в память. В современных системах данный бит избыточен и определен только для каталогов.
Концептуальные модели подсистем контроля и управления доступом
Широкий класс моделей КУД базируется на представлении ИС в виде состояний и функций переходов между ними. В описании модели Белла-ЛаПадулы предложена теорема, формально доказывающая безопасность ИС и получившая название основной теоремы безопасности [22, 23]. Теорема утверждает, что ИС с безопасным начальным состоянием является безопасной тогда и только тогда, когда при любом переходе системы из одного состояния в другое не возникает никаких новых и не сохраняется никаких старых отношений доступа, которые будут небезопасны по отношению к функции уровня безопасности нового состояния. На основе принципа доказательства безопасности ИС указанным способом, т.е. на основе рассмотрения безопасности системы в начальном состоянии и в достижимых состояниях (по индукции относительно состояний), предлагается подход к проверке выполнения ограничений путем анализа достижимых состояний ИС. Для проверки выполнения правил политики предлагается оценивать выполнение ограничений в начальном состоянии и в последующих, достижимых, состояниях системы.
Для реальной системы при проверке ограничений С пространство перебора ограничивается областью определения. Подход состоит в использовании для решения задачи анализа выполнения правил ПБ следующей последовательности действий (рис. 2.3) [68]: моделирование начального состояния (рис. 2.3Д), моделирование требований модели КУД (рис. 2,3,1); формирование ограничений и их моделирование (рис. 2.3,1); генерация достижимых состояний системы (рис, 2.3,3); проверка выполнения ограничений в полученных состояниях (рис. 2.3,2 и рис, 2.3?4). Данный подход закладывает основы для разработки средств автоматизированного анализа выполнения правил ПБ, В соответствии с предложенным подходом решение проблемы автоматизированной проверки ПБ требует создания инструментария моделирования для описания состояний ИС, требований моделей КУД и правил ПБ. Он должен быть универсальным по отношению к применяемым моделям безопасности и независим от исследуемой ИСиПБ. При реализации подхода к проверке выполнения правил ПБ в соответствии с проведенным анализом методов моделирования ПБ предлагается использовать логическое представление, заключающееся в построении концептуальной модели субъектов, объектов и их атрибутов безопасности и ее задании в виде системы (набора) логических термов.
Основные требования, предъявляемые к системе предикатов, следующие: поддержка описания контроля доступа и распространения прав; возможность описания политик в больших системах, состоящих из миллионов объектов. Подразумевается необходимость применения правил к группам объектов, нежели к каждому из них в отдельности; комбинирование правил, что позволяет группировать базовые правила управления и безопасности в отношении ролей, организационных единиц и специальных приложений. Комбинированные правила облегчают администрирование политики в крупных промышленных ИС; возможность анализа выполнения политики и ее проверки на наличие конфликтов и противоречий в спецификации. Декларативное описание облегчает анализ; расширяемость, что должно обеспечить поддержку новых типов политик, которые могут появиться в будущем; понятность и простота в обращении; независимость от объекта моделирования. Для того, чтобы выработать обобщенную схему, применимую для различных ИС, следует на базе современных ОС построить концептуальные модели подсистем КУД и обобщить их.
Принцип анализа выполнения правил политики безопасности средствами модуля резолюций
Для использования MP необходимо его установить, добавить к созданному проекту файл %SPRDIR%\lib\SPR.LIB и подключить заголовочный файл %SPRDIR%\mclude\SPR.h? где %SPRDIR% каталог установки MP. Модуль резолюций представляет собой ядро системы проверки выполнения правил ПБ. Входные параметры MP составляют три описания которые моделируют начальное состояние системы, правила перехода из состояния в состояние (правила КУД) и правила ПБ (ограничения), В процессе работы MP обрабатывает список ограничений, отмечая каждое как выполненное или нет. В процессе анализа MP генерирует рабочий протокол с трассой логического вывода. До запуска MP необходимо сформировать три файла (например, exmm3s.se, exacr.se, exmssc.se) и расположить их в текущей директории. Затем следует вызвать функцию LoadScopes, указав ей в качестве аргументов имена файлов с описаниями. Например; LoadScopes(,,exmm3s,sc11? "exacrsc", "exmssc.sc"). В случае успешного выполнения LoadScopes вернет L В случае если невозможно открыть или прочитать какой-либо файл с описанием, она вернет один из следующих кодов ошибки доступа: SPR TEMP CREATE_ERR (невозможно создать временный файл), SPRM3SACCESS ERR (невозможно открыть или прочитать файл с описанием начального состояния); SPR ACR_ACCESS ERR (невозможно огкрыть или прочитать файл с описанием правил контроля доступа); SPR SSC_ACCESS_ERR (невозможно открыть или прочитать файл с описанием ограничений). Возможны синтаксические ошибки, допущенные при создании какого-либо логического описания. Тогда MP обнаружит синтаксическую ошибку при загрузке описаний, и функция LoadScopes вернет код синтаксической ошибки: SPR_M3S_SYNTAX_ERR (синтаксическая ошибка в описании состояния); SPR_ACR_SYNTAX_ERR (синтаксическая ошибка в описании правил КУД); SPR_SSC_SYNTAX_ERR (синтаксическая ошибка в описании ограничений). Для уточнения причины ошибки и определения ее местоположения, необходимо вызвать функцию Error. Функция Error возвращает строку, указывающую семантику и позицию ошибки в описании. Если LoadScopes вернула один из кодов, указанных выше, то необходимо скорректировать соответствующее описание и повторно вызвать функцию LoadScopes. Если LoadScopes вернула код ошибки SPR_PROLOG_FAIL_ERR, то это означает, что MP не может работать в целевой системе.
Требуется произвести повторную установку MP и вызвать LoadScopes снова. После успешного выполнения LoadScopes процесс анализа запускается посредством вызова Start. Функция Start работает в асинхронном режиме и создает параллельную нить логических вычислений. Если Start вернула 1, то это означает успешный запуск процесса. Если Start вернула один из следующих кодов ошибки: SPR_REPORT_CREATE_ERR, SPR_TRACE_CREATE_ERR или SPR_TEMPJTREATE_ERR, то Start не может создать в текущей директории соответствующий файл результатов процесса анализа: файл отчета SPR.REP, файл трассы SPR.TRC или временный файл. Данная ситуация может произойти по следующим причинам: нехватка дискового пространства, текущая директория недоступна для записи и т.д. Необходимо решить проблему, связанную с директорией (исправить права доступа, сменить текущую директорию и т.д.), и повторить вызов Start. Анализ выполнения правил ПБ может занимать продолжительное время, но он выполняется асинхронно. Основная программа может во время процесса вычислений выполнять другие задачи. Если основная программа закончила работу до завершения анализа, то анализ будет прерван, и все результаты логического вывода будут утеряны.
Для проверки статуса процесса анализа используется функция GetState. Она возвращает одно из следующих значений: SPR_EVALUATION_NOT__INIT (описания не были загружены); SPR„EVALUATION_NOT_BEGIN (описания были загружены, но процесс анализа не запущен); SPR__EVALUATION_COMPLETE (процесс анализа успешно завершился); SPR„EVALUATION JN PROCESS (процесс анализа еще выполняется). Если GetState вернула код ошибки SPR_REPORT_ACCESS_ERR? SPRJTRACE_ACCESS_ERR или SPR_TEMP_ACCESS_ERR, то это сигнализирует об ошибке доступа MP к одному из файлов результатов: к файлу отчета SPR.REP, к файлу трассы SPRTRC или к временному файлу. При любом из этих кодов ошибки процесс анализа считается прерванным. Требуется исправить данные ошибки и снова вызвать LoadScopes и Start, Если GetState вернула код ошибки SPR_PROLOG_MACHINE_FAlL_ERR, это означает, что
Пролог не в состоянии продолжить анализ. Требуется вызвать функцию Error, которая вернет сообщение об ошибке Пролога, после чего необходимо исправить ошибку в описании (например, исключить бесконечную рекурсию, деление на ноль, неизвестный предикат) и повторно запустить анализ. После того, как MP завершил работу (GetState вернула код SPR_EVALUATION_COMPLETE), в текущей директории создаются два файла: SPR.REP и SPRTRC. Файл SPR.REP содержит список ограничений, помеченных "succeeded" ("верно") или Tailed1 ("неверно"). Файл SPR.TRC может включать подробную трассу процесса логического вывода, если трасса была включена в процессе выполнения процесса анализа. Процесс анализа может быть приостановлен при помощи вызова функции Suspend и возобновлен посредством вызова Resume. После успешного выполнения LoadScopes или Suspend можно включить трассировку вызовом функции ТгасеОп. В режиме трассировки MP наполняет файл SPR.TRC целями, выводимыми Прологом. Можно включить/выключить трассировку, если процесс оценки приостановлен посредством вызова Suspend, По умолчанию трассировка выключена. После LoadScopes возможен вызов функции Reset, которая вернет MP в начальное состояние (состояние до вызова LoadScopes).
Пример применения методики на базе операционной системы Microsoft Windows 2000
Степень детализации для ОС Windows 2000 определена следующая. Рассматривается локальная станция, изолированная от сетевого взаимодействия. В проверке участвует фиксированный набор сущностей и основные требования модели КУД, реализованной в ОС Windows 2000. Таким образом, анализу подвергается т уменыненная копия,т ОС без потери общности. Для данной системы автоматически построено описание начального состояния [95], записаны в виде правил Пролога требования модели КУД и создано описание ограничений. В качестве ограничений приведен ряд правил ПБ, Использование СП позволило автоматически обнаружить состояния, в которых из-за ошибок реализации ОС Windows 2000 не выполняется ПБ. Сущности. В системе рассматриваются сущности трех видов: элементы файловой системы — директории и файлы, содержащие защищаемую информацию; учетные записи пользователей, которые осуществляют доступ к информации; группы пользователей, представляющие собой объединения учетных записей с целью упрощения администрирования системы. Файловая система имеет древовидную структуру. У каждого ее элемента есть единственный родительский элемент — директория (каталог, папка). Существует единственная директория, которая является родителем для самой себя — это корневая директория root. Она всегда присутствует в системе и не может быть удалена. У каждой директории может быть несколько дочерних директорий и файлов. Директория, не имеющая дочерних элементов, называется пустой. Файлы не могут иметь дочерних элементов. Каждый элемент файловой системы имеет единственного владельца из числа пользователей. Владелец определяется при создании элемента, но в процессе функционирования системы файл или директория могут быть взяты во владение другим пользователем при наличии у него необходимых для этого прав. Передать файл или директорию во владение нельзя.
Доступ пользователя к информации определяется правами, которые он имеет на директорию либо на файл. Права могут быть либо разрешающими, либо запрещающими. Каждый пользователь системы состоит в одной или в нескольких группах. Определенные пользователи могут создавать учетные записи новых пользователей или удалять существующие. Единственная учетная запись, которая всегда присутствует в системе и не может быть удалена, соответствует пользователю-администратору и имеет идентификатор admin. Операции. Все элементарные операции можно подразделить на следующие группы: операции по созданию и удалению сущностей (файлов, директорий, учетных записей); операции по изменению атрибутов сущностей (взятие файла во владение, изменение прав доступа пользователя к директории); операции получения доступа к информации (например, операция чтения пользователем информации из файла). Производить операции могут только пользователи. Возможность проведения той или иной операции определяется системой КУД с использованием конкретных алгоритмов. Алгоритм работы подсистемы КУД. Пользователь может выполнить определенное действие только после получения разрешения на данное действие от подсистемы КУД. Решение подсистемы КУД основывается на информации о пользователе, группах, к которым он принадлежит, и, если запрашивается доступ к элементу файловой системы, об атрибутах файлов либо директорий.
При определении разрешения некоторому пользователю доступа к некоторому элементу файловой системы рассматриваются все группы, в которых состоит учетная запись данного пользователя. Общее правило таково: пользователю разрешен доступ тогда и только тогда, когда он или хотя бы одна из групп, к которым он принадлежит, имеет разрешение на данный вид доступа, и при этом ни данный пользователь, ни одна из групп, к которым он принадлежит, не имеет запрещения на данный вид доступа. Каждому пользователю ставится в соответствие учетная запись, которая имеет уникальный идентификатор — строковое имя с использованием символов латинского алфавита и цифр. Начинается имя со строчной буквы. Единственным атрибутом любого пользователя является subjectGroups — список групп, в которых состоит его учетная запись. Правила именования групп такие же, как для учетных записей. Все файлы и каталоги описываются одинаково. У каждого из них есть специальный атрибут objectType, в который при создании заносится соответствующая информация — файл это или директория. В дальнейшем значение этого атрибута измениться не может. Значением атрибута parentObject каящого элемента файловой системы является идентификатор родительской директории. Для корневой директории это ее собственное имя.
Для каждого элемента также единственным образом определяется пользователь, владеющий им. Его идентификатор хранится у каждого файла или директории в специальном атрибуте ohjectOwner. Именование элементов файловой системы производится по тем же правилам, что и для пользователей. Для хранения информации о правах доступа пользователей и групп к элементам файловой системы у каждого файла и директории для каждого пользователя и каждой группы создается отдельный атрибут, имя которого совпадает с именем пользователя или группы, а значение представляет собой список всех разрешений и запрещений на доступ для данного пользователя или группы к данному файлу или директории.
