62. Контроль доступа в Ява с использованием технологии «песочницы»

Модель контроля доступа в Ява 1.1 была значительно усовершенствована и, по определению, все программы, реализованные в этой версии, считаются надёжными по определению (это правило распространяется на все последующие версии). Это говорит о том, что процедура верификации в версии 1.1 изменена по сравнению с 1.0 и байт-код не проверяется на уязвимости существующей версии 1.0. Несмотря на это в версии 1.1 разработана технология «песочницы». Она заключается в том, что все программы, загруженные по сети, а также выполняемые локально, выполнятся в ограниченной среде, которую и называют «песочницей». Главная политика песочницы – использование класса java.lang.SecurityManager для запуска всех аплетов как ограниченных в правах пользователей. Перед выполнением операции, на которые накладываются ограничения (к примеру, чтение локального файла), системный код ява-машины вызывает соответствующий метод для данной операции (checkread()) объекта SecurityManager. Если выполняемый код определяется ненадёжным, то генерируется исключение SecurityException, предотвращающее выполнение недопустимой операции.

Классом SecurityManager обычно пользуется браузер с поддержкой Ява, который устанавливает объект этого класса для конкретного браузера, чтобы в нём можно было безопасно запускать аплеты. Соответственно, действия ява-машины с вредоносным кодом в разных браузерах будут различны, но в общем случае на аплеты налагаются следующие ограничения:

1. аплет не может читать, записывать, переименовывать или удалять файлы. Он не может запрашивать длину или дату последнего изменения файла и даже проверять, существует ли такой файл. Это же правило действует и для каталогов;

2. аплет не может создавать сетевое соединение или принимать запрос на соединение с другой системой, кроме той, с которой он был загружен. Также он не может использовать привилегированные порты (вплоть до порта 1024 включительно);

3. аплету не разрешается проводить действия на системном уровне, такие как: загрузка библиотеки, создание нового процесса или принудительный выход из интерпретатора Ява. Аплет не может манипулировать потоками или группами потоков, кроме тех, которые создаёт сам. В Ява 1.1 аплеты не могут использовать Java API для получения информации о членах класса, которые не являются открытыми за исключением тех классов, которые загрузил сам аплет;

4. аплет не имеет доступа к некоторым графическим функциям и средствам графического интерфейса, к примеру, он не может создать задание для принтера или получить доступ к буферу обмена или очереди сообщений ОС. Помимо этого, все окна, создаваемые аплетом (графические окна в интерпретации ОС), помечаются ОС как небезопасные визуальные индикаторы. Это сделано для того, чтобы аплет не смог обмануть пользователя, приняв вид прикладного приложения.

5. аплету не разрешается чтение некоторых системных свойств, в первую очередь, данных об ОС и файловой системе, которые могут быть использованы злонамеренно;

6. аплет никогда не сможет обойти перечисленные ограничения, зарегистрировав новый объект SecutiryManager

Предположим, что аплет, выполняемый в безопасной среде, предпринимает попытку чтения из файла file1, передав имя этого файла конструктору FileInputStream(). По определению, данный класс получает доступ к системному ресурсу (файлу file1), поэтому при использовании этого класса необходим контроль доступа. Для этого существует перегруженный конструктор, который использует класс SecurityManager. При каждом вызове данного конструктора проверяется, установлен ли в системе объект SecutiryManager, является ли он единственным для виртуальной машины Ява и работает ли он в фоновом режиме для проверки аплетов. Если да, то конструктор FileInputStream вызывает метод checkread() объекта securityManager, передав в него в качестве параметра имя файла. Метод checkread() не возвращает значения и либо он нормально завершает свою работу, либо генерирует исключение SecurityException. Если выполняется возврат из этого метода, то конструктор fileInputStream производит необходимую инициализацию и завершает свою работу. В противном случае исключение передаётся вызывающему методу. Если это происходит, объект класса fileInputStream не создаётся и аплет не получает доступ к файлу.

Неудобство при этом для разработчика аплета заключается в том, что данные действия виртуальная ява-машина совершает невизуально и бывает трудно выяснить, по какой причине не получен доступ к файлу.

В ява 1.1 появляется возможность работы с ЦП ява-файлов. Для этого пакет javaSecurity расширяется подпакетом Passkey(), который предоставляет классы и интерфейсы для создания ЦП и её проверки. При работе с ява-файлами, снабжёнными ЦП, работа организуется следующим образом:

- файл класса, в котором содержится ЦП, прошедший проверку в ява-машине, считается надёжным и при запуске такой проги ей полностью предоставляется javaAPI. В данный пакет также входит возможность работы с ключами и цифровыми подписями для jar-файлов. Но следует помнить, что данный класс не отменяет технологии песочницы.

class Policy. Данный класс определяет политику безопасности ява в целом. Объект данного класса в своей работе связывает объекты CodeSource (создаваемый при доступе к системным ресурсам) с объектом Permission.

Ява-апплет получает инфу о URI файла класса и список источников, поставивших на данный файл свою ЦП. Permission определяет права доступа, предоставляемые объекту CodeSource, загружаемому из конкретного источника.

В java.io добавлен пакет FilePermission, а в java.net добавлен SocketPermission.