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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

8.5 Выполнение Апплетов с Подписанным Контентом

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

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

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, подписываются ли они или нет. Это временное решение будет улучшено, как только согласие достигается.

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

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

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