Имонн Салліван (PC Week Labs)

Засоби забезпечення безпеки в JDK 1.2 стали більш гнучкими, а й більш складними

Фірма Sun Microsystems пішла на певний ризик, внісши в JDK 1.2 деякі зміни в найбільш цінну частину Java: модель безпеки. Нова схема забезпечення безпеки буде набагато більш гнучкою, але і набагато складнішою.

Як встановлюється політика безпеки за допомогою JDK 1.2

У комплекті JDK 1.2, що вийшов в кінці 1997 року на стадію бета-тестування (готовий продукт повинен з'явитися в I кварталі 1998 г.), використовується модель безпеки на основі прав доступу. Ця модель дозволить проводити вкрай гнучку політику забезпечення безпеки в корпораціях, але для середнього користувача вона тільки створить додаткові труднощі. Вперше нова модель безпеки була представлена ​​на шостій щорічній конференції з World Wide Web, що пройшла в червні 1997 р в м Санта-Кларі (шт. Каліфорнія). На початку грудня розробники фірми зробили більш докладну доповідь на цю тему на конференції USENIX Symposium on Internet Technologies and Systems в Монтереї (шт. Каліфорнія).

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

Чи підуть за Sun виробники браузерів, включаючи корпорації Microsoft і Netscape Communications, залишається поки неясним.

Можливість дозволити програмам працювати поза "пісочниці", а також доступ до локальних ресурсів була в технології Java завжди, проте використовувалася вона тільки в браузері Sun HotJava.

До JDK 1.1 організація доступу "сторонніх" додатків до локальних ресурсів була непростою програмістської завданням, пов'язаної з небезпекою скоєння численних помилок. Тому фахівці Microsoft і Netscape відмовилися від застосування даної можливості технології Java в своїх продуктах.

В JDK 1.1 з'явилася підтримка програмних компонентів, забезпечених цифровими підписами, яким дозволялося виходити за рамки "пісочниці"; як Microsoft, так і Netscape підтримали цю ідею, проте кожна реалізувала її власним несумісним способом.

В JDK 1.2 система забезпечення безпеки повністю перероблена з метою спрощення вирішення завдань, найчастіше постають перед програмістами виконуючих середовищ для Java-додатків, таких, як браузери і ОС із вбудованими віртуальними Java-машинами. Доданий ряд нових класів, а в колишні внесені зміни, що полегшують як створення політики безпеки, так і її використання.

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

Доменна схема безпеки

Ще один цікавий аспект моделі забезпечення безпеки JDK 1.2 - управління доступом на базі доменів. "Доменом" (в схемі безпеки) називають середу або контекст додатки, для якого визначено власний набір припущень і вимог. Наприклад, до служб ОС для ПК пред'являються інші вимоги з точки зору забезпечення безпеки, ніж до текстового процесора.

Багато, якщо не всі "дірки" систем забезпечення безпеки утворюються на перетині різних доменів. Наприклад, додаток для користувача рівня може використовувати помилку у власному модулі ОС для отримання додаткових повноважень.

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

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

У версії JDK 1.2 як і раніше не реалізована стара, як самі комп'ютери, концепція аутентифікації користувачів. Щоб уникнути будь-якої залежності від механізмів аутентифікації конкретних ОС, фахівцям Sun доведеться в майбутньому розробити власну систему аутентифікації користувачів або, по крайней мере, рівень абстракції над відповідними засобами ОС.

Нереалізованої залишається і концепція делегування - виконання коду "на правах" деякого конкретного користувача - особливо корисна при роботі серверних Java-додатків.

Однак Java не вимагає відмови від використання відповідних засобів безпеки ОС, так що у адміністраторів залишається можливість організовувати аутентифікацію користувачів по-старому - за допомогою відповідних служб ОС.

Класи, що забезпечують розподіл прав

Права доступу абстраговані в новому класі: java.security.permission. Доступ до них може здійснюватися за допомогою інших класів, наприклад java.io.FilePermission (для файлової системи) або java.net.SocketPermission (для мережевих ресурсів).

Адміністратори зможуть, як правило, поширювати сформовані набори прав доступу у вигляді текстових файлів. Дозвіл надається (або не надається) на підставі інформації про те, з якого джерела був завантажений код і якими цифровими підписами він завірений. Наприклад, якщо програмний компонент завантажений з адреси www.company.com з цифровим підписом компанії, то йому повинен бути наданий доступ до певних каталогів на читання, до інших - на запис, а також право з'єднання з деяким безліччю серверів.

Нові класи JDK 1.2 дозволяють розробнику заздалегідь визначити, дозволена чи ні та чи інша операція. Так, звернувшись до методу нового класу java.security.AccessController, розробник може легко перевірити, чи дозволено його програмі почати виконання певної операції.

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

Версія для друку

Тільки зареєстровані користувачі можуть залишати коментарі.