Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Безпека.docx
Скачиваний:
130
Добавлен:
31.08.2019
Размер:
6.2 Mб
Скачать

14.3.3. Дискреційна модель ієрархічного керування

Розглянемо модель керування доступом, спеціально розроблену для ОС Фенікс [97]. Ця модель доповнює звичайне дискреційне керування доступом, коли є мож­ливість конкретно вказати тип доступу для будь-якої пари суб'єкт-об'єкт, чітко визначеним обмеженням процесу розповсюдження прав. Ця модель використовує суворо ієрархічну структуру користувачів, задану відносинами керівник-підлеглий, в якій права доступу зростають від підлеглого до керівника. Кожен керівник

має повне право керувати об'єктами підпорядкованих йому користувачів і від повідає за поширення на них прав доступу. На вершині ієрархії знаходиться су первізор із максимальними повноваженнями. Проте це не означає, що в системі повинен існувати такий користувач.

Для кожної пари суб'єктів і об'єктів дозволені методи доступу задаються стандартним набором прав (читання, записування, додавання, виконання) і правами керування доступом. Керування поширенням повноважень здійснюється за допомогою трьох прав: права змінювати права доступу для самого себе (m), права призначати права доступу для інших (с) і права передавати іншим повно важення керування доступом (cр). Усі права можуть зустрічатися в будь-яких комбінаціях. Єдиним обмеженням є пара с і ср: встановлювати ср можна лише за наявності с. Право керування доступу т надає суб'єкту повноваження зміню вати свої права доступу до об'єкта, але не дає змоги встановлювати права с і ср. Право керування доступом с надає суб'єкту можливість призначати права дос­тупу до об'єкта для своїх підлеглих, але не більші, ніж має сам суб'єкт. При цьому змінювати власні права цей атрибут користувачу не дозволяє. Право на передавання повноважень керування доступом ср дає змогу суб'єкту призначати своїм підлеглим право с.

Керування доступом здійснюється згідно з такими правилами.

  1. Визначення прав доступу для пари суб'єкт-об'єкт.

У таблиці прав слід явно вказати права доступу кожного суб'єкта до кожного

об'єкта.

  1. Генерування прав доступу для нового об'єкта, створеного суб'єктом.

Для кожного об'єкта, створеного суб'єктом, призначають такі права доступу:

r,w,m для суб'єкта, що створив об'єкт, а якщо він є керівником (тобто має

підлеглих) — то ще й с (право с можна надавати, незважаючи на останню умову: підлеглі можуть з'явитися пізніше);

  • r, т, с, ср для керівника суб'єкта, що створив об'єкт, і для всіх його ке­рівників аж до супервізора;

♦ решта не мають жодних прав (опціонально можна задавати для підлеглих одного й того самого керівника деякий набір прав, окрім т, с, ср).

3. Встановлення суб'єктом прав доступу деякого іншого суб'єкта до об'єкта.

Суб'єкт si може встановлювати набір прав Ρ суб'єкту s2 для об'єкта о з такими

обмеженнями:

  • якщо s1 і s2 — один і той самий суб'єкт, то встановлювати самому собі права суб'єкт може лише за наявності права т; права с і ср встановлювати самому собі не можна;

  • інакше, якщо s1 — керівник (безпосередній чи вищий) s2, то:

  • якщо s1 має на об'єкт o права с і ср, то він може встановити (відкли­кати) суб'єкту s2 права у межах своїх прав;

  • інакше, якщо si має на об'єкт o право с, то він може встановити (від­кликати) суб'єкту s2 права у межах своїх прав, окрім права с;

  • інакше, якщо s1 не має на об'єкт о права с, то він не може встановити (відкликати)

права суб'єкту s2;

  • інакше, якщо s1 не є керівником (безпосереднім чи вищим) s2, то він не може

встановити (відкликати) права суб'єкту s2.

Обмеження власних прав означає, що:

  • якщо s1 має на об'єкт o право т, це обмеження не діє в частині прав r, w, е (тоб­то s1 може встановлювати (відкликати) ці права на об'єкт о, незважаючи на те, чи має він сам на цей об'єкт такі права);

  • якщо s1 не має на об'єкт о права т, це обмеження означає, що множина прав, яку встановлює s1, має повністю належати множині прав доступу si до о.

Слід зазначити, що до каталогів застосовують такі самі правила політики без­пеки, як і

до файлів даних.

Використання будь-якої дискреційної моделі не може знизити ймовірність витоку інформації, спричиненого впровадженням «троянського коня». Як уже за­значалося в розділі 4, адекватний захист від цієї атаки може забезпечити лише мандатна модель керування доступом. Проте слід зауважити, що в реалізованій в операційній системі Фенікс моделі ієрархічного керування поширенням повно­важень передбачено заходи з обмеження можливості застосування такої атаки. По-перше, завдяки ієрархічній організації суб'єктів витік інформації може від­буватися лише в напрямку підлеглих суб'єкта, що запустив шкідливу програму (лише вниз деревом ієрархії суб'єктів). По-друге, для будь-якого начальника до файлів його підлеглих за умовчанням встановлюється лише право на читання, але не на записування і виконання. Якщо керівник не змінить ці права, будь-яка спроба впровадження «троянського коня» буде викликати протидію з боку сис­теми розмежування доступу.