Разрешения в OSGi

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

В этом посте рассказывается, как сделать то же самое в среде OSGi .

OSGi

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

Безопасность в OSGi основана на архитектуре безопасности Java 2, которую мы обсуждали ранее , поэтому вы можете повторно использовать свои знания о подписывании кода и т. Д.

Однако OSGi делает еще пару шагов.

Отзыв разрешений

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

Нет никакого способа сделать это со стандартными разрешениями Java, но, к счастью, OSGi представляет решение.

Недостатком является то, что OSGi вводит собственный синтаксис для определения политик.

В следующем примере показано, как запретить PackagePermission для подпакетов com.acme.secret :

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

PackagePermission — это разрешение, определенное OSGi для авторизации импорта и экспорта пакетов. Ваше приложение может использовать такую ​​политику, чтобы гарантировать, что мобильный код не может вызывать классы в данном пакете, например, чтобы ограничить прямой доступ к базе данных.

Расширяемые условия на разрешения

Второе улучшение, которое приносит OSGi, заключается в том, что условия, при которых предоставляется разрешение, могут динамически оцениваться во время выполнения.

В следующем примере показано, как условно предоставить ServicePermission :

ServicePermission — это определенное OSGi разрешение, которое ограничивает доступ к службам OSGi .

Условие — это часть в квадратных скобках. OSGi определяет два условия, которые соответствуют конструкциям signedBy и codeBase в обычных политиках Java.

Вы также можете определить свои собственные условия . Спецификация дает подробные инструкции по условиям реализации, особенно в отношении производительности.

Различные типы разрешений

Последнее нововведение, которое OSGi привносит в модель разрешений Java, заключается в том, что существуют разные типы разрешений.

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

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

На самом деле, это утверждение не совсем точно. Каждый пакет будет иметь определенные разрешения, необходимые для работы в среде OSGi, например, возможность читать системные свойства org.osgi.framework.* .

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

Последний тип разрешений — это системные разрешения . Это разрешения, которые предоставляются пакету.

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

Локальные разрешения включают аудит. Перед установкой пакета в среду OSGi вы можете проверить ресурс разрешений OSGI-INF/permissions.perm в OSGI-INF/permissions.perm чтобы узнать, какие разрешения требуются для пакета.

Если вы не можете предоставить пакету этих разрешений, вы можете не устанавливать пакет. Дело в том, что вы можете знать все это без запуска пакета и без доступа к его исходному коду.

Интеграция в модель разрешений Java

Инфраструктура OSGi интегрирует их расширенную модель разрешений в стандартную модель разрешений Java путем создания подкласса ProtectionDomain .

Для этого каждый пакет получает BundleProtectionDomainImpl .

Этот подход позволяет OSGi использовать стандартную модель разрешений Java, которую вы уже знаете , поэтому вы можете повторно использовать большинство своих навыков в этой области. Единственное, что вам придется заново изучать, это как писать политики.

Сравнение моделей разрешений

Чтобы представить модель разрешений OSGi в перспективе, рассмотрим следующую таблицу сравнения, в которой используется терминология из спецификации XACML :

Из этой таблицы видно, что модель OSGi немного более выразительна, чем стандартная модель разрешений Java, хотя и не так выразительна, как XACML.

Ссылка: разрешения в OSGi от нашего партнера по JCG Ремона Синнема в блоге по разработке безопасного программного обеспечения .