Файл: 10_ua_2_.doc

Політика безпеки задає відповідність між джерелом і правами програм, що поступили з нього (формально можна вважати, що кожному джерелу відповідає своя "пісочниця"). В JDK 1.2 "рідні" програми не мають яких-небудь привілеїв в плані безпеки, і політика по відношенню до них може бути будь-ким. В результаті вийшов традиційний для сучасних ОС і СУБД механізм прав доступу з наступними особливостями:

• Java-програми виступають не від імені користувача, що їх запустив, а від імені джерела програми. (Це вельми глибоке і прогресивне трактування, якщо її правильно розвинути, див. наступний розділ);

• немає поняття власника ресурсів, який міг би міняти права; останні задаються виключно політикою безпеки (формально можна вважати, що власником всього є той, хто формує політику);

• механізми безпеки забезпечені об’єктною обгорткою.

Вельми важливим поняттям в моделі безпеки JDK 1.2 є контекст виконання. Коли віртуальна Java-машина перевіряє права доступу об’єкту до системного ресурсу, вона розглядає не тільки поточний об’єкт, але і попередні елементи стека викликів. Доступ надається тільки тоді, коли потрібним правом володіють всі об’єкти в стеку. Розробники Java називають це реалізацією принципу мінімізації привілеїв.

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

На жаль, подібні доводи суперечать одному з основних принципів об’єктного підходу - принципу інкапсуляції. Якщо об’єкт А звертається до об’єкту B, він не може і не повинен знати, як реалізований B і якими ресурсами він користується для своїх цілей. Якщо А має право викликати який-небудь метод B з деякими значеннями аргументів, B зобов’язаний обслужити виклик. Інакше при формуванні політики безпеки доведеться враховувати можливий граф викликів об’єктів, що, звичайно ж, нереальність.

Розробники Java усвідомлювали цю проблему. Щоб справитися з нею, вони ввели поняття привілейованого інтервалу програми. При виконанні такого інтервалу контекст ігнорується. Привілейована програма відповідає за себе, не цікавлячись передісторією. Аналогом привілейованих програм є файли з бітами встановлення ідентифікатора користувача/групи в ОС Unix заново, що зайвий раз підтверджує традиційність підходу, реалізованого в JDK 1.2. Відомі загрози безпеки, які привносять подібні файли. Тепер цей не кращий засіб ОС Unix перекочував в Java.

---

Розглянемо дисципліну контролю прав доступу більш формально.

Клас AccessController (вбудований менеджер безпеки) надає єдиний метод для перевірки заданого права в поточному контексті - checkPermission (Permission). Це краще (унаслідок параметризуемости), ніж безліч методів виду checkXXX, присутніх в SecurityManager - динамічно змінному менеджері безпеки з ранніх версій JDK.

Хай поточний контекст виконання складається з N стекових фреймів (верхній відповідає методу, checkPermission(p), що викликав). Метод checkPermission реалізує наступний алгоритм (див. Лістинг 10.1).

i = N;

while (i > 0) {

if (метод, що породив i-й фрейм, не має того, що перевіряється

має рацію) {

throw AccessControlException

} else if (i-й фрейм помічений як привілейований) {

return;

}

i = i – 1;

};

// З’ясуємо, чи є право, що перевіряється, у успадковуваного контексту

inheritedContext.checkPermission (p);

Лістинг 10.1. Алгоритм роботи методу checkPermission класу AccessController. (html, txt)

Спочатку в стеку шукається фрейм, що не володіє правом, що перевіряється. Перевірка проводиться до тих пір, поки або не буде вичерпаний стек, або не зустрінеться "привілейований" фрейм, створений в результаті звернення до методу doPrivileged(PrivilegedAction) класу AccessController. Якщо при породженні поточного потоку виконання був збережений контекст inheritedContext, перевіряється і він. При позитивному результаті перевірки метод checkPermission(p) повертає управління, при негативному виникає виняткова ситуація AccessControlException.

Вибраний підхід має один недолік - важкоатлета реалізації. Зокрема, при породженні нового потоку управління з ним доводиться асоціювати зафіксований "батьківський" контекст і, відповідно, перевіряти останній в процесі контролю прав доступу.

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

В цілому засоби управління доступом в JDK 1.2 можна оцінити як "наполовину об’єктні". Реалізація оформлена у вигляді інтерфейсів і класів, проте як і раніше розмежовується доступ до необ’єктних єств - ресурсів в традиційному розумінні. Не враховується семантика доступу. Мають місце і інші відзначені вище концептуальні проблеми.

Можливий підхід до управління доступом в розподіленому об’єктному середовищі

---

Представляється, що в даний час проблема управління доступом існує в трьох майже не зв’язаних між собою проявах:

• традиційні моделі (дискреційна і мандатна);

• модель "пісочниця" (запропонована для Java-середовища і близької їй системи Safe-Tcl);

• модель фільтрації (що використовується в міжмережевих екранах).

На наш погляд, необхідно об’єднати існуючі підходи на основі їх розвитку і узагальнення.

Формальна постановка задачі розмежування доступу може виглядати таким чином.

Розглядається безліч об’єктів (в значенні об’єктно-орієнтованого програмування). Частина об’єктів може бути контейнерами, що групують об’єкти-компоненти, задаючими для них загальний контекст, виконуючими загальні функції і реалізовуючими перебір компонентів. Контейнери або вкладені один в одного, або не мають загальних компонентів.

З кожним об’єктом асоційований набір інтерфейсів, забезпечених дескрипторами (ДІ). До об’єкту можна звернутися тільки за допомогою ДІ. Різні інтерфейси можуть надавати різні методи і бути доступними для різних об’єктів.

Кожний контейнер дозволяє опитати набір ДІ об’єктів-компонентів, що задовольняють деякій умові. Результат в загальному випадку, що повертається, залежить від зухвалого об’єкту.

Об’єкти ізольовані один від одного. Єдиним видом міжоб’єктної взаємодії є виклик методу.

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

Передбачається також, що дозвіл або заборона на доступ не залежать від можливого паралельного виконання методів (синхронізація представляє окрему проблему, яка тут не розглядається).

Розмежовується доступ до інтерфейсів об’єктів, а також до методів об’єктів (з урахуванням значень фактичних параметрів виклику). Правила розмежування доступу (ПРД) задаються у вигляді предикатів над об’єктами.

Розглядається задача розмежування доступу для виділеного контейнера CC, компонентами якого винні бути що викликає и/или викликається об’єкти. ДІ цього контейнера вважається загальновідомим. Вважається також, що між зовнішніми по відношенню до виділеного контейнера об’єктами можливі будь-які виклики.

Виконання ПРД контролюється монітором обігу.

---

При виклику методу ми розділятимемо дії, вироблювані зухвалим об’єктом (ініціація виклику) і методом, що викликається (прийом і завершення виклику).

При ініціації виклику може проводитися перетворення ДІ фактичних параметрів до вигляду, доступного методу, що викликається ("трансляція інтерфейсу"). Трансляція може мати місце, якщо об’єкт, що викликається, не входить в той же контейнер, що і що викликає.

Параметри методів можуть бути вхідними и/или вихідними. При прийомі виклику виникає інформаційний потік з вхідних параметрів в об’єкт, що викликається. У момент завершення виклику виникає інформаційний потік з об’єкту, що викликається, у вихідні параметри. Ці потоки можуть фігурувати в правилах розмежування доступу.

Структуруємо безліч всіх ПРД, виділивши чотири групи правил:

• політика безпеки контейнера;

• обмеження на метод, що викликається;

• обмеження на той, що викликає метод;

• обмеження, що добровільно накладаються.

Правила, загальні для всіх об’єктів, що входять в контейнер З, назвемо політикою безпеки даного контейнера.

Хай метод M1 об’єкту O1 в точці P1 свого виконання повинен викликати метод M об’єкту Про. Правила, яким винен задовольняти M, можна розділити на три наступні підгрупи:

• правила, що описують вимоги до формальних параметрів виклику;

• правила, що описують вимоги до семантики M;

• реалізаційні правила, що накладають обмеження на можливі реалізації M;

• правила, що накладають обмеження на об’єкт, що викликається, Про.

Метод M об’єкту Про, потенційно доступний для виклику, може пред’являти до зухвалого об’єкту наступні групи вимог:

• правила, що описують вимоги до фактичних параметрів виклику;

• правила, що накладають обмеження на той, що викликає об’єкт.

Можна виділити три різновиди предикатів, відповідні семантиці и/или особливостям реалізації методів:

• твердження про фактичні параметри виклику методу M в крапці P1;

• предикат, що описує семантику методу M;

• предикат, що описує особливості реалізації методу M.

Перераховані обмеження можна назвати добровільними, оскільки вони відповідають реальній поведінці об’єктів і не пов’язані з якими-небудь зовнішніми вимогами.

---

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

---