13.5 Защита ресурсов

Поскольку одной из основных сфер применения технологии Java является Internet, вопросы безопасности для этой технологии приобретают особое значение. Безопасность в сетевой среде представляет собой целый комплекс сложных вопросов, рассматриваемых в отдельном курсе. Здесь же мы уделим основное внимание защите локальных ресурсов - анализу возможности Java-программы получить несанкционированный доступ к ресурсам на том компьютере, на котором она выполняется.

Прежде всего, в самих языковых средствах Java отсутствуют некоторые возможности языка C/C++, которые наиболее часто приводят к неправильному использованию ресурсов - случайному или намеренному. Главная черта языка Java в этом отношении - отсутствие указателей. Хотя доступ к объектам в Java осуществляется по ссылкам, и физический смысл ссылки и указателя C/C++ одинаков - адрес памяти, ссылка не есть указатель. Различие состоит в том, что, во-первых, ссылка не может быть преобразована в число или какое-либо иное представление физического адреса, во-вторых, над ссылками недопустимы арифметические операции. Именно адресная арифметика в C/C++ является средством, использование которого может привести к доступу процесса за пределы той области памяти, к которой он имеет право обращаться.

Другой "лазейкой" для выполнения несанкционированных действий в языке C/C++ является слабая защита типов. C/C++ позволяют использовать типы данных в операциях, этому типу не свойственных - путем неявного преобразования типов или путем приравнивания разнотипных указателей (в том числе, и для интегрированных типов). В Java осуществляется строгий контроль типов и в большинстве случаев требуется явное преобразование типов.

Автоматическое освобождение памяти в Java также является свойством, повышающим защищенность. Можно говорить также и о том, что более последовательное воплощение в Java парадигмы объектно-ориентированного программирования также является выигрышным обстоятельством с точки зрения защиты.

Следует оговорить, что указанные различия между языками C/C++ и Java обусловлены прежде всего тем, что языки ориентированы на разные сферы применения. Те "недостатки" языка C/C++, на которые мы указываем, превращаются в уникальные достоинства при применении С/С++ в качестве языка системного программирования, а именно таково первоначальное предназначение этого языка. При разработке же приложений (а Java - язык именно для разработки приложений) эти возможности становятся ненужными и даже опасными.

Однако сами свойства языка Java еще не являются гарантией защищенности. Они обеспечиваются компилятором Java, но не предохраняют от модификации исполняемый модуль. Поскольку спецификации байт-кода Java и файла класса открыты, программы, осуществляющие несанкционированный доступ, могут писаться непосредственно в байт-кодах или на других языках с компиляцией в байт-код Java. Чтобы перекрыть этот канал несанкционированного доступа, в платформе Java выполняется верификация байт-кода.

Процесс верификации состоит из четырех шагов.

Шаг 1 выполняется при загрузке класса. При этом Java VM проверяет базовый формат файла класса - "магическое число" и номер версии, соответствие размера файла суммарному размеру его составляющих, формальное соответствие отдельных структур спецификациям.

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

отсутствие нарушений в использовании классов и методов, объявленных с модификатором final;

наличие у каждого класса (кроме класса Object) суперкласса;

соответствие спецификациям содержимого пула констант;

правильность имен классов и интерфейсов и дескрипторов всех полей и методов, ссылающихся на пул констант.

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

Шаг 3 также выполняется на этапе связывания. На этом шаге верификатор проверяет массив байт-кодов каждого метода. При этом анализируется поток данных, обрабатывающийся при выполнении метода. Верификатор исходит из того, что в любой точке программы, независимо от того, каким образом управление попало на эту точку, должны соблюдаться определенные ограничения целостности данных, которые сводятся в основном к следующим:

размер стека операндов неизменен и стек содержит операнды одного типа;

не выполняется доступ к локальным переменным неизвестного типа;

доступ к локальным переменным осуществляется только в пределах массива локальных переменных;

все обращения к пулу констант производятся к элементам соответствующего типа;

полям класса назначаются значения соответствующего типа;

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

методы вызываются с правильными аргументами;

команды перехода передают управление только внутри байт-кода метода и передача управления всегда происходит только на первый байт команды байт-кода.

Шаг 4 выполняется при первом вызове кода любого метода. Это "виртуальный шаг", он выполняется не в виде отдельного шага проверки всего байт-кода, а при выполнении каждой отдельной команды.

Для команды, которая ссылается на тип, при этом:

загружается определение типа (если оно еще не загружено);

проверяется, может ли текущий выполняемый метод ссылаться на этот тип;

выполняется инициализация класса (если он еще не инициализирован).

Для команды, которая вызывает метод или осуществляет доступ к полю класса, при этом:

проверяется, существует ли поле или метод в данном классе;

проверяется правильность дескриптора вызванного метода или поля;

проверяется, имеет ли текущий выполняемый метод права доступа к этому методу или полю.

В конкретных реализациях Java VM допускается после выполнения шага 4 заменять проверенную команду байт-кода альтернативной "быстрой" формой. Например, в Sun Java VM команда байт-кода new может быть заменена командой new_quick. "Быстрая" команда выполняется так же, как и исходная, но при ее выполнении исключается повторная верификация команды. В файле класса "быстрые" команды не допускаются, они выявляются на предыдущих шагах верификации и вызывают отказ. "Быстрые" формы не являются спецификациями Java, они реализуются в конкретной Java VM.

Аплеты являются наиболее критическими с точки зрения безопасности Java-программами, поскольку аплет загружается из Internet, возможно, из непроверенного источника. Естественно, недопустимым является предоставление программе, пришедшей "неизвестно откуда" доступа к ресурсам локального компьютера. Поэтому для аплетов введены весьма жесткие ограничения на выполнение. Аплету запрещается:

получать сведения о пользователе или его домашней директории;

определять свои системные переменные;

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

осуществлять доступ по сети к удаленному компьютеру, получать список сетевых сеансов связи, которые устанавливает локальный компьютер с другими компьютерами;

открывать без уведомления новые окна, запускать локальные программы и загружать локальные библиотеки, создавать новые нити, получать доступ к группам нитей другого аплета;

получать доступ к любому нестандартному пакету, определять классы, входящие в локальный пакет.

Модель безопасности Java еще далека от совершенства, и в ее реализациях иногда обнаруживаются "лазейки" для несанкционированного проникновения. Следует отметить, что в сетевых публикациях довольно часто можно встретить критику безопасности в Java и предупреждение о принципиальной возможности "взлома" защиты Java тем или иным способам. Вместе с тем, сетевые публикации не дают оснований говорить о том, что реальные информационные системы, в которых применяется технология Java, чаще подвергаются взлому, чем системы, эту технологию не применяющие.



Информация о работе «Операционные системы "тонких" клиентов»
Раздел: Информатика, программирование
Количество знаков с пробелами: 257667
Количество таблиц: 0
Количество изображений: 26

Похожие работы

Скачать
129632
2
0

... , выдачей и приёмом лицензий). В условиях крупных сетей рекомендуется выделение под сервер лицензий отдельного компьютера (или нескольких - для резервирования). 1.1 Архитектура терминальных устройств В компьютерных технологиях трёхуровневая архитектура, синоним трёхзвенная архитектура (по англ. three-tier или Multitier architecture) предполагает наличие следующих компонентов приложения: ...

Скачать
116709
11
1

... ФС в разделе MS-DOS. Это конфигурационный файл в котором содержится информация о драйверах используемых в процессе запуска ФС. Пункт доступен супервизору или его эквивалентам. «Система учета» NetWare обладает очень гибкой системой учета ресурсов, предоставляемых в общее пользование. Используя данный пункт меню можно просмотреть, а так же имея определенные права настроить плату за использование ...

Скачать
41540
0
0

... числе на промышленных предприятиях, больше подходят клиент-серверные СУБД. Мы рассмотрим особенности таких распространенных СУБД, как Oracle и MS SQL Server. Глава 4. Язык SQL в системах управления базами данных SQL (англ. Structured Query Language — язык структурированных запросов) — универсальный компьютерный язык, применяемый для создания, модификации и управления данными в реляционных ...

Скачать
111441
18
8

... ОС Windows 95, необходимость выбора тех конкретных объектов, к которым необходимо ограничить доступ. Настоящая работа посвящена разработке программы защиты объектов операционной системы WINDOWS95 работающей в многопользовательском режиме под управлением сервера Novell NetWare (Windows NT, Unix), позволяющей проводить защиту объектов ОС на уровне пользователя. Под защитой объектов ОС Windows 95 ...

0 комментариев


Наверх