7. Керування доступом в Java – середовищі

Java – це об’єктно-орієнтовна система програмування, тому й керування доступом у ній спроектоване й реалізовано в об'єктному стилі. Із цієї причини розглянути Java-середовище для нас дуже важливо. Докладно про Java-технологію й безпеку Java-середовища розказано в статті А. Таранова й В. Цишевского "Java у три роки" (Jet Info, 1998, 11-12). З дозволу авторів далі використовуються її фрагменти.

Насамперед, зупинимося на еволюції моделі безпеки Java. В JDK 1.0 була запропонована концепція "пісочниці" (sandbox) – замкненого середовища, у якій виконуються потенційно ненадійні програми (апплети, що надійшли по мережі). Програми, що розташовуються на локальному комп'ютері, уважалися абсолютно надійними, і їм було доступно все, що доступно віртуальній Java-машині.

У число обмежень, що накладаються "пісочницею", входить заборона на доступ до локальної файлової системи, на мережеву взаємодію з усіма хостами, крім джерела апплета, і т.п. Незалежно від рівня безпеки, що досягається при цьому, (а проблеми виникали й з розподілом свій/чужий, і з визначенням джерела апплета), накладені обмеження варто визнати занадто обтяжними: можливості для змістовних дій в апплетів майже не залишається.

Щоб упоратися із цією проблемою, в JDK 1.1 увели розподіл джерел (точніше, розповсюджувачів) апплетів на надійні й ненадійні (джерело визначалося по електронному підпису). Надійні апплети прирівнювалися в правах до "рідного" коду. Зроблене послаблення вирішило проблеми тих, кому прав не вистачало, але захист залишився неешелонованим й, отже, неповним.

В JDK 1.2 сформувалася модель безпеки, використовувана й в Java 2. Від моделі "пісочниці" відмовилися. Сформувалися три основні поняття:

• джерело програми;

• право й сукупність;

• політика безпеки.

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

Право – це абстрактне поняття, згідно якого, як і покладено в об'єктному середовищі, стоять класи й об'єкти. У більшості випадків право визначається двома ланцюжками символів – ім'ям ресурсу й дією. Наприклад, ресурсом може виступати файл, а дією – читання. Найважливішим методом "правових" об'єктів є implies. Він перевіряє, чи витікає одне право (запитуване) з іншого (наявного).

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

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

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

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

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

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

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

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