Имонн Салливан (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-машина автоматически проверяет все полномочия всех процессов, находящихся в стеке вызовов, чтобы убедиться, что текущее приложение не нарушает требований действующей политики безопасности путем обращения к более привилегированному коду.
