Spec-Zone .ru
спецификации, руководства, описания, API
|
|
Spec-Zone .ru
спецификации, руководства, описания, API
|
| СОДЕРЖАНИЕ | ПРЕДЫДУЩИЙ | NEXT |
Фундаментальное понятие и важный стандартный блок безопасности системы являются доменом защиты [Сэлцер и Шредер 75]. Домен может быть определяющим контекст набором объектов, которые в настоящий момент непосредственно доступны принципалом, где принципал является объектом в компьютерной системе, которой предоставляют полномочия (и в результате отслеживаемость). Песочница, используемая в JDK 1.0, является одним примером домена защиты с фиксированной границей.
Понятие домена защиты служит удобным механизмом для группировки и изоляции между модулями защиты. Например, возможно (но еще обеспеченный как встроенная функция) разделить домены защиты от взаимодействия с друг другом так, чтобы любое разрешенное взаимодействие было или через код достоверной системы или явно позволено затронутыми доменами. Отметьте, что существующие объектные правила доступности остаются допустимыми под новой архитектурой безопасности.
Домены защиты обычно попадают в две отличных категории: системный домен и домен приложения. Важно что все защищенные внешние ресурсы, такие как файловая система, сетевое средство, и экран и клавиатура, быть доступным только через системные домены. Число ниже иллюстрирует доменный состав среды приложения Java.
[D]
Домен концептуально включает ряд классов, экземплярам которых предоставляют тот же самый набор полномочий. Домены защиты определяются политикой в настоящий момент в действительности. Среда приложения Java поддерживает отображение от кода (классы и экземпляры) к их доменам защиты и затем к их полномочиям, как иллюстрировано числом ниже.
[D]
Поток выполнения (который часто является, но не обязательно связан к, единственный поток Java, который поочередно не обязательно связывается к понятию потока базовой операционной системы) может произойти полностью в пределах единственного домена защиты или может включить домен приложения и также системный домен. Например, приложение, которое распечатывает сообщение, должно будет взаимодействовать с системным доменом, который является единственной точкой доступа к потоку вывода. В этом случае крайне важно, чтобы в любое время домен приложения не получил дополнительные разрешения, вызывая системный домен. Иначе, могут быть серьезные импликации безопасности.
В обратной ситуации, где системный домен вызывает метод от домена приложения, такой как тогда, когда системный домен AWT вызывает метод краски апплета, чтобы вывести на экран апплет, снова крайне важно, чтобы в любое время эффективные права доступа были тем же самым как текущими правами, включенными в домене приложения.
Другими словами "менее мощный" домен не может получить дополнительные разрешения в результате вызова или быть вызванным более мощным доменом.
Это обсуждение одного потока, включающего два домена защиты естественно, делает вывод к потоку, который пересекает многократные домены защиты. Простое и благоразумное эмпирическое правило для того, чтобы вычислить полномочия является следующим:
doPrivileged метод (см. ниже), набор полномочий потока выполнения, как полагают, включают разрешение, если это позволяется доменом защиты упомянутого кода и всеми доменами защиты, которые вызывают или вводятся прямо или косвенно впоследствии.doPrivileged метод позволяет части доверяемого кода временно включить доступу к большему количеству ресурсов, чем доступны непосредственно приложению, которое вызывало это. Это необходимо в некоторых ситуациях. Например, приложение не может быть предоставлено прямой доступ к файлам, которые содержат шрифты, но системная утилита, чтобы вывести на экран документ должна получить те шрифты, от имени пользователя. Мы обеспечиваем doPrivileged метод для системного домена, чтобы иметь дело с этой ситуацией, и методом фактически доступен всем доменам. Во время выполнения, когда доступ к критическому системному ресурсу (такому как файловый ввод-вывод и сетевой ввод-вывод) запрашивается, обрабатывающий ресурс код прямо или косвенно вызывает специальный метод класса AccessController, который оценивает запрос и решает, нужно ли запрос предоставить или отрицаться.
Такая оценка следует и обобщает "эмпирическое правило", данное выше. Фактический путь, которым проводится оценка, может измениться между реализациями. Основной принцип должен исследовать историю вызова и полномочия, предоставленные соответствующим доменам защиты, и возвратиться тихо, если запрос предоставляют, или выдайте исключение безопасности, если запрос отрицается.
Наконец, каждый домен (система или приложение) может также реализовать дополнительную защиту своих внутренних ресурсов в пределах его собственной доменной границы. Например, банковское приложение, возможно, должно поддерживать и защитить внутренние понятия, такие как текущие счета, депозиты и выводы войск. Поскольку семантика такой защиты вряд ли будет предсказуема или осуществима Java 2 SDK, систему защиты на этом уровне лучше всего оставляют разработчикам системы или разработчикам приложений. Однако, всякий раз, когда приспособлено, мы обеспечиваем полезные примитивы, чтобы упростить задачи разработчиков. Один такой примитив является классом SignedObject, деталь которого мы опишем позже.
