Архитектура безопасности Java: -

спецификации, руководства, описания, API

8 Обсуждений и Будущие Направления

8.1 Управление Потреблением ресурсов

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

8.2 Произвольная Группировка Полномочий

Иногда удобно собрать в группу много полномочий и использовать краткое имя, чтобы обратиться к ним. Например, если мы хотели бы иметь разрешение под названием "Суперразрешение", чтобы включать (и подразумевать) оба FilePermission (" - ", "считанный, запишите") и SocketPermission (" * ", "подключение, примите"), технически мы можем использовать Полномочия класса или подобный класс, чтобы реализовать это разрешение высшего качества при использовании add методы, чтобы добавить необходимые полномочия. И такая группировка может быть произвольно усложнена.

Большим количеством сложных вопросов является следующий. Во-первых, чтобы понять, какие фактические полномочия каждый предоставляет, выделяя такое разрешение высшего качества, или фиксированный и именованный класс полномочий создается, чтобы обозначить статически указанную группу полномочий, или задействованные полномочия должны быть разъяснены в файле политики. Во-вторых, обработка политики (файл) может стать более сложной, потому что сгруппированные полномочия, возможно, должны быть расширены. Кроме того вложение сгруппированного разрешения увеличивает сложность даже больше.

8.3 Защита уровня объектов

Учитывая объектно-ориентированную природу языка программирования Java, возможно, что разработчики извлекут выгоду из ряда соответствующих механизмов защиты уровня объектов, который (1) идет вне естественной защиты, обеспеченной языком программирования Java и что (2) дополнения основанный на потоке механизм управления доступом.

Одним таким механизмом является SignedObject. Параллельный этому примитиву, мы предоставим SealedObject, который использует шифрование, чтобы скрыть контент объекта. (Из-за текущих американских инструкций контроля над экспортом на использовании шифрования, класс SealedObject будет, вероятно, обеспечен отдельный от SDK.)

GuardedObject является общим способом осуществить управление доступом в на класс/объект на уровень метода. Этот метод, однако, должен использоваться только выборочно, частично потому что этот тип управления может быть трудно администрировать на высоком уровне.

8.4 Подразделение Доменов Защиты

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

Часто домен считается поддержкой наследования: поддомен автоматически наследовал бы атрибуты безопасности родительского домена, кроме в определенных случаях, где родитель далее ограничивает поддомен явно. Ослабление поддомена правильным усилением является возможностью с понятием доверяемого кода.

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

8.5 Выполнение Апплетов с Контентом Со знаком

JAR и Явные спецификации на подписывании кода позволяют очень гибкий формат. Классы в пределах того же самого архива могут быть подписаны с различными ключами, и класс может быть без знака, подписан с одним ключом, или подписанный с многократными ключами. Другие ресурсы в пределах архива, такие как аудиоклипы и графические изображения, могут также быть подписаны или без знака, точно так же, как классы могут.

Эта гибкость вызывает проблему интерпретации. На следующие вопросы нужно ответить, особенно когда ключи обрабатываются по-другому:

1. Should images and audios be required to be signed with the
   same key if any class in the archive is signed?
2. If images and audios are signed with different keys, can
   they be placed in the same appletviewer (or browser page),
   or should they be sent to different viewers for processing?

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

Кроме того, если цифровая подпись не может быть проверена, потому что контент байт-кода файла класса не соответствует значение хэш-функции со знаком в JAR, исключение безопасности выдается, поскольку исходное намерение автора JAR ясно изменяется. Ранее, было предложение, чтобы выполнить такой код как недоверяемый. Эта идея является нежелательным, потому что апплет classloader позволяет загрузку кода, подписанного многократными сторонами. Это означает, что принятие частично измененного файла JAR позволило бы недоверяемой части кода работать вместе с и получать доступ к другому коду через тот же самый classloader.

СОДЕРЖАНИЕ | ПРЕДЫДУЩИЙ | NEXT

Свяжитесь с Нами