Списки управления доступомРефераты >> Программирование и компьютеры >> Списки управления доступом
2.4.3 Модель Биба.
Последующим расширением модели Белла - Ла-Падулы стала модель Биба (Biba Model), разработанная в 1977 году. Целью создания модели стало добавление в модель Белла - Ла-Падулы целостности. Задача была реализована путем добавления к субъектам и объектам уровня целостности и запрета общения субъектов и объектов разных уровней.
Для дополнительного управления целостностью введены понижающие водяные знаки (нарушающие запрет на общение):
§ Если субъект читает объект более низкого уровня, то его уровень целостности снижается до уровня целостности объекта.
§ Если субъект дополняет объект более высокого уровня, то уровень целостности объекта снижается до уровня целостности субъекта.
Модель не только несет в себе достоинства и недостатки модели Белла – Ла-Падулы, но и добавляет собственные. Основной недостаток модели состоит в том, что введение уровней целостности только ограничивает возможности доступа субъектов к объектам, создавая либо значительную изоляцию между уровнями целостности, либо после определения уровней целостности этот уровень может только понижаться, что само по себе лишает его управляемости, и как следствие функциональности. Область применения модели Биба так же не выходит за пределы военных организаций.
3. ACL в UNIX-подобных операционных системах
3.1 Общие принципы и положения
3.1.1 Принципы работы ACL
Традиционная модель разграничений прав доступа в файловых системах согласно POSIX определяет 3 класса пользователей: владелец, группа-владелец и остальные. Определенные права доступа: чтение (read, r), запись (write, w) и выполнение (execute, x). В этой модели класс разрешений владельца определяет привилегии доступа для владельца файла, разрешения для группы-владельца – для группы пользователей, в которую входит владелец файла, разрешения для остальных – для всех остальных пользователей (которые не вошли в первые два пункта). Команда ls –l показывает разрешения для доступа для владельца, группы и остальных в первой колонке своего вывода (например, запись “-rw-r----” соответствует обычному файлу, который владелец может просматривать и редактировать, группа – только просматривать, а остальные пользователи не имеют никаких прав на доступ к этому файлу).
ACL состоит из набора записей (ACE). Каждый из трех классов пользователей представлен в виде ACE. Разрешения для дополнительных пользователей и групп содержатся в дополнительных ACE.
Таблица 3 показывает определенные типы записей и их текстовые представления. Каждая из этих записей состоит из типа, квалификатора, который определяет к какому пользователю или группе применяется запись, и набора разрешений (тип:квалификатор:разрешения). Квалификатор отсутствует для записей, которые в нем не нуждаются.
ACL, эквивалентный файловым битам доступа, называется минимальным ACL. Он состоит из трех записей. ACL с более чем тремя записями называется расширенным ACL. Расширенные ACL также содержат запись-маску и могут содержать любое (ограничивается конкретной реализацией ACL для конкретной файловой системы, где существует ограничение на максимальное число записей в одном ACL) количество записей для имеющихся пользователей и групп.
Таблица 3 – Типы записей ACL
Тип записи (ACE) |
Текстовое представление |
Владелец |
user::rwx |
Именованный пользователь |
user:name:rwx |
Группа владелец |
group::rwx |
Именованная группа |
group:name:rwx |
Маска |
mask::rwx |
Остальные |
other::rwx |
Записи именованных пользователей и групп относятся к классу групп, наряду с записью группы владельца. В отличие от модели разрешений POSIX.1, класс группы сейчас может содержать ACE с различными наборами разрешений, таким образом, класс разрешений группы сам по себе более не является достаточным для детального разграничения прав доступа для всех ACE, которые он содержит. Более того, смысл класса разрешений группы переопределен: согласно новой семантике, они определяют верхнюю грань разрешений, которую каждая запись класса групп будет гарантировать.
Это свойство верхней грани гарантирует, что приложения POSIX.1, не знающие об ACL, не смогут нежданно и негаданно гарантировать дополнительные разрешения в случае поддержки ACL.
В минимальном ACL класс разрешений группы идентичен разрешениям группы-владельца. В расширенном ACL класс группы может содержать записи для дополнительных пользователей и групп. Это может создать проблему: некоторые из этих дополнительных записей могут содержать разрешения, которые не содержаться в записи группы-владельца, и, таким образом, запись разрешений для группы-владельца может отличаться от класса разрешений группы.
Эта проблема решается введением записи-маски. В минимальном ACL класс разрешений групп совпадает с записью разрешений для группы-владельца. В расширенном ACL класс разрешений групп совпадает с записью-маской разрешений, тогда как запись группы-владельца все еще определяет разрешения для группы-владельца. Рисунок 1 показывает эти два случая.
Рисунок 1: Соответствие между ACE и файловыми битами прав доступа
Когда приложение изменяет класс разрешений для владельца, группы или остальных (например, команда chmod(1)), соответствующая ACE также изменяется. Подобным образом, когда приложение изменяет класс разрешений ACE, соответствующей одному из классов пользователей, изменяется разрешение для этого класса.
Класс разрешений группы определяет верхнюю грань разрешений, гарантированных записью класса групп. Случай минимального ACL тривиален. В случае расширенного ACL это реализовывается разрешениями записи-маски: эффективными будут разрешения в записях, относящихся к классу группы, который также присутствуют в записи-маске. Разрешения, которые отсутствуют в записи-маске не оказывают никакого эффекта. См. таблицу 4.
Таблица 4: Маскировка разрешений
Тип ACE |
Текстовое представление |
Разрешения |
Именованный пользователь |
user:joe:r-x |
r-x |
Маска |
mask::rw- |
rw- |
Эффективное разрешение |
r- |