Spec-Zone .ru спецификации, руководства, описания, API

Содержание документации

Синтаксис Файла Реализации и Политики Политики по умолчанию

Политика для среды приложения языка программирования Java™ (определение, какие полномочия доступны для кода из различных источников, и выполняющийся как различные принципалы) представляется объектом Политики. Более определенно это представляется a Policy подкласс, обеспечивающий реализацию абстрактных методов в Policy класс (который находится в java.security пакет).

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

Остальная часть этого документа принадлежит ссылочной реализации Политики и синтаксису, который должен использоваться в файлах политики, которые это читает. Для получения информации об использовании Средства осуществления политики, чтобы создать файл политики (не будучи должен знать необходимый синтаксис), см. документацию Средства осуществления политики (для Соляриса/Linux) (для Windows).

Вот схема для остальной части этого документа:

Реализация Политики по умолчанию

Расположение файлов Политики по умолчанию

Изменение Реализации Политики

Синтаксис Файла политики

Примеры Файла политики

Расширение свойства в Файлах Политики

Общее Расширение в Файлах Политики

Связанная Документация

Реализация Политики по умолчанию

Файл политики может быть составлен через простой текстовый редактор, или через графическую утилиту Policy Tool.

Есть по умолчанию единственный файл политики в масштабе всей системы, и единственный (дополнительный) пользовательский файл политики.

Ссылочная реализация Политики инициализируется в первый раз getPermissions метод вызывают, или всякий раз, когда refresh метод вызывают. Инициализация включает парсинг конфигурационного файла (ов) политики (см. Синтаксис Файла Политики), и затем заполнение объекта Политики.

Расположение файлов Политики по умолчанию

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

Системный файл политики по умолчанию располагается в

java.home/lib/security/java.policy  (Solaris/Linux)
java.home\lib\security\java.policy  (Windows)

Отметьте: java.home обращается к значению системного свойства, названного"java.home", который определяет каталог, который содержит среду выполнения - или каталог jre в Java Комплект разработчика SE (JDK) или высокоуровневый каталог Java Среда выполнения SE (JRE).

Системный файл политики предназначается, чтобы предоставить полномочия кода в масштабе всей системы. java.policy файл, установленный с JDK, предоставляет все полномочия стандартным расширениям, позволяет любому слушать на непривилегированных портах, и позволяет любому коду читать определенные "стандартные" свойства, которые не чувствительны к безопасности, такой как"os.name"и"file.separator"свойства.

Пользовательский файл политики по умолчанию располагается в

user.home/.java.policy  (Solaris/Linux)
user.home\.java.policy  (Windows)

Отметьте: user.home обращается к значению системного свойства, названного"user.home", который определяет корневой каталог пользователя.

Когда Политика инициализируется, системная политика загружается в первом, и затем пользовательская политика добавляется к этому. Если никакая политика не присутствует, встроенная политика используется. Эта встроенная политика является тем же самым как java.policy файлом, установленным с JRE.

Расположение файлов политики определяется в файле свойств безопасности, который располагается в

java.home/lib/security/java.security  (Solaris/Linux)
java.home\lib\security\java.security  (Windows)

policy.url.n

policy.url.n=URL

Например, система по умолчанию и пользовательские файлы политики определяются в файле свойств безопасности как

policy.url.1=file:${java.home}/lib/security/java.policy
policy.url.2=file:${user.home}/.java.policy

(См. Расширение Свойства для информации об определении значений свойств через специальный синтаксис, таких как определение java.home значение свойства через ${java.home}.)

Можно фактически определить много URL (включая формы"http://"), и все определяемые файлы политики будет загружен. Можно также прокомментировать или изменить второй, чтобы отключить чтение пользовательского файла политики по умолчанию.

Алгоритм запускается в policy.url.1, и продолжает постепенно увеличиваться, пока это не находит URL. Таким образом, если Вы имеете policy.url.1 и policy.url.3, policy.url.3 никогда не будет читаться.

Определение Дополнительного Файла Политики во Время выполнения

Также возможно определить дополнительное или различный файл политики, вызывая выполнение приложения. Это может быть сделано через"-Djava.security.policy"параметр командной строки, который устанавливает значение java.security.policy свойство. Например, если Вы используете

    java -Djava.security.manager -Djava.security.policy=someURL SomeApp

Примечания:

• URL может быть любой регулярный URL или просто имя файла политики в текущем каталоге, как в

      java -Djava.security.manager -Djava.security.policy=mypolicy SomeApp
  

• "-Djava.security.manager"параметр гарантирует, что менеджер безопасности по умолчанию устанавливается, и таким образом приложение подвергается проверкам политики. Это не требуется если приложение SomeApp устанавливает менеджера безопасности.

Если Вы используете

    java -Djava.security.manager -Djava.security.policy==someURL SomeApp

Если Вы хотите передать файл политики к appletviewer, то используйте"-J-Djava.security.policy"параметр следующим образом:

    appletviewer -J-Djava.security.policy=someURL myApplet

Изменение Реализации Политики

Альтернативный класс политики может быть дан, чтобы заменить ссылочный класс реализации Политики, пока прежний - подкласс абстрактного класса Политики и реализует getPermissions метод (и другие методы по мере необходимости).

Ссылочная реализация Политики может быть изменена, редактируя файл свойств безопасности, который является java.security файл в lib/security каталог JDK или JRE.

Один из типов свойств можно начаться java.security имеет следующую форму:

    policy.provider=PolicyClassName

PolicyClassName должен определить полностью определенное имя требуемого Policy класс реализации. Запись файла свойств безопасности по умолчанию для этого свойства является следующим:

    policy.provider=sun.security.provider.PolicyFile

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

    policy.provider=com.mycom.MyPolicy

Синтаксис Файла политики

Конфигурационный файл (ы) политики для JDK или установки JRE определяет то, что полномочия (который типы доступов системного ресурса) предоставляют кодировать из указанного источника кода, и выполняемый как указанный принципал.

Для апплета (или приложение, работающее под менеджером безопасности), чтобы быть позволенным выполнить защищенные действия (такие как чтение или запись файла), апплету (или приложение) нужно предоставить разрешение для того определенного действия. В ссылочной реализации Политики то разрешение должна предоставить запись предоставления в конфигурационном файле политики. См. ниже и "Спецификация Архитектуры безопасности Java" для получения дополнительной информации. (Единственное исключение - то, что у кода всегда автоматически есть разрешение, чтобы считать файлы из его того же самого (URL) расположение, и подкаталоги того расположения; это не нуждается в явном разрешении, чтобы сделать так.)

Конфигурационный файл политики по существу содержит список записей. Это может содержать "keystore" запись, и содержит нуль или больше записей "предоставления".

Запись Keystore

keystore является базой данных закрытых ключей и их связанных цифровых сертификатов, таких как цепочки сертификата X.509, аутентифицирующие соответствующие открытые ключи. keytool утилита (для Соляриса/Linux) (для Windows) используется, чтобы создать и администрировать keystores. keystore, определенный в конфигурационном файле политики, используется, чтобы искать открытые ключи подписывающих лиц, определенных в записях предоставления файла. keystore запись должна появиться в конфигурационном файле политики, если какие-либо записи предоставления определяют псевдонимы подписывающего лица, или если какие-либо записи предоставления определяют основные псевдонимы (см. ниже).

В это время может быть только один keystore/keystorePasswordURL запись в файле политики (другие записи после первого игнорируются). Эта запись может появиться где угодно вне записей предоставления файла. У этого есть следующий синтаксис:

keystore "some_keystore_url", "keystore_type", "keystore_provider";
keystorePasswordURL "some_password_url";

URL относительно расположения файла политики. Таким образом, если файл политики определяется в файле свойств безопасности как:

    policy.url.1=http://foo.example.com/fum/some.policy

    keystore ".keystore";

    http://foo.example.com/fum/.keystore

Тип keystore определяет хранение и формат данных keystore информации, и алгоритмы, используемые, чтобы защитить закрытые ключи в keystore и целостности keystore непосредственно. Тип по умолчанию, поддерживаемый Sun Microsystems, является собственным типом keystore под названием "JKS". Таким образом, если тип keystore является "JKS", он не должен быть определен в keystore записи.

Записи предоставления

Выполняемый код, как всегда полагают, прибывает из определенного "источника кода" (представленный объектом типа CodeSource). Источник кода включает не только расположение (URL) где код, порожденный из, но также и ссылка на сертификат (ы), содержащий открытый ключ (и), соответствующий закрытому ключу (ам), используемому, чтобы подписать код. На сертификаты в источнике кода ссылаются символьные имена псевдонима от keystore пользователя. Код, как также полагают, выполняется как определенный принципал (представленный объектом типа Principal), или группа принципалов.

Каждая запись предоставления включает одну или более "записей разрешения, которым" предшествуют дополнительным codeBase, signedBy, и основные пары имя/значение, которые определяют, какой код Вы хотите предоставить полномочиям. Основной формат записи предоставления является следующим:

  grant signedBy "signer_names", codeBase "URL",
        principal principal_class_name "principal_name",
        principal principal_class_name "principal_name",
        ... {

      permission permission_class_name "target_name", "action", 
          signedBy "signer_names";
      permission permission_class_name "target_name", "action", 
          signedBy "signer_names";
      ...
  };
        

Запись предоставления должна начаться со слова grant.

SignedBy, Principal, и CodeBase Поля

signedBy, codeBase, и principal значения являются дополнительными, и порядок этих полей не имеет значения.

A signedBy значение указывает на псевдоним для сертификата, сохраненного в keystore. Открытый ключ в пределах того сертификата используется, чтобы проверить цифровую подпись на коде; Вы предоставляете, что разрешение (я) кодирует подписанный закрытым ключом, соответствующим открытому ключу в keystore записи, определенной псевдонимом.

signedBy значение может быть списком разделенных запятой значений многократных псевдонимов. Примером является "Адам, Канун, Чарльз", что означает "подписанный Адамом и Евой и Чарльзом"; отношение И, не ИЛИ. Чтобы быть более точным, оператор как "Код, подписанный Адамом", означает "Код в файле класса, содержавшемся в JAR, который подписывается, используя закрытый ключ, соответствующий сертификату с открытым ключом в keystore, запись которого искажается Адамом".

signedBy поле является дополнительным в этом, если оно опускается, оно показывает "любое подписывающее лицо". Не имеет значения, подписывается ли код или не или кого.

Основное значение определяет a class_name/principal_name пара, которая должна присутствовать в пределах основного набора выполняющегося потока. Основной набор связывается с выполняющимся кодом посредством Предмета.

principal_class_name может быть установлен в подстановочное значение, *, который позволяет ему соответствовать любому Principal класс. Кроме того, principal_name май также быть установленным в подстановочное значение, *, позволяя это соответствовать любому Principal имя. Устанавливая principal_class_name или principal_name к *, не окружайте * кавычками. Кроме того, если Вы определяете подстановочный класс принципала, следует также определить подстановочное имя принципала.

Основное поле является дополнительным в этом, если оно опускается, оно показывает "любые принципалы".

Примечание по Замене Псевдонима KeyStore:

Если принципал class_name/principal_name пара определяется как единственная заключенная в кавычки строка, это обрабатывается как псевдоним keystore. С keystore консультируются и запрашивается (через псевдоним) для Сертификата X509. Если Вы находитесь, принципал class_name автоматически обрабатывается как javax.security.auth.x500.X500Principal, и principal_name автоматически обрабатывается как подчиненное отличительное имя от сертификата. Если отображение Сертификата X509 не находится, вся запись предоставления игнорируется.

A codeBase значение указывает на исходное расположение кода; Вы предоставляете, что разрешение (я) кодирует от того расположения. Пустое codeBase запись показывает "любой код"; не имеет значения, где код происходит из.

Отметьте: a codeBase значение является URL и таким образом не должно всегда использовать наклонные черты (никогда наклонные черты влево) как разделитель каталога, даже когда источник кода находится фактически на системе Windows. Таким образом, если исходное расположение для кода системы Windows фактически C:\somepath\api\, тогда политика codeBase запись должна быть похожей:

    grant codeBase "file:/C:/somepath/api/" {
        ...
    };

Записи Разрешения

Запись разрешения должна начаться со слова permission. Слово permission_class_name в шаблоне выше фактически был бы определенный тип полномочий, такой как java.io.FilePermission или java.lang.RuntimePermission.

"action"требуется для многих типов полномочий, такой как java.io.FilePermission (где это определяет, какой доступ к файлу разрешается). Это не требуется для категорий такой как java.lang.RuntimePermission где это не необходимо - Вы любому определили разрешение"target_name"значение после permission_class_name или Вы не делаете.

signedBy пара имя/значение для записи разрешения является дополнительной. Если существующий, это указывает на разрешение со знаком. Таким образом, сам класс полномочий должен быть подписан данным псевдонимом (ами) для разрешения, которое будет предоставлено. Например, предположите, что у Вас есть следующая запись предоставления:

  grant {
      permission Foo "foobar", signedBy "FooSoft";
  };

Затем это разрешение типа Foo предоставляют если Foo.class разрешение было помещено в файл JAR, и файл JAR был подписан закрытым ключом, соответствующим открытому ключу в сертификате, определенном псевдонимом "FooSoft", или если Foo.class системный класс, так как системные классы не подвергаются ограничениям политики.

Элементы, которые появляются в записи разрешения, должны появиться в указанном порядке (permission, permission_class_name, "target_name", "действие", и signedBy "signer_names"). Запись завершается с точкой с запятой.

Случай незначителен для идентификаторов (permission, signedBy, codeBase, и т.д.), но является существенным для permission_class_name или для любой строки, в которой передают как значение.

Отметьте Относительно Спецификаций Пути к файлу на Windows Systems

Отметьте: Когда Вы определяете a java.io.FilePermission,"target_name"путь к файлу. На системах Windows, всякий раз, когда Вы непосредственно определяете путь к файлу в строке (но не в кодовой базе URL), Вы должны включать две наклонных черты влево для каждой фактической единственной наклонной черты влево в пути, как в

  grant {
      permission java.io.FilePermission "C:\\users\\cathy\\foo.bat", "read";
  };

    "C:\users\cathy\foo.bat"

Примеры Файла политики

Пример двух записей в конфигурационном файле политики

  // If the code is signed by "Duke", grant it read/write access to all 
  // files in /tmp:
  grant signedBy "Duke" {
      permission java.io.FilePermission "/tmp/*", "read,write";
  };

  // Grant everyone the following permission:
  grant { 
      permission java.util.PropertyPermission "java.vendor", "read";
  };
 

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

  grant signedBy "sysadmin", codeBase "file:/home/sysadmin/*" {
      permission java.security.SecurityPermission "Security.insertProvider.*";
      permission java.security.SecurityPermission "Security.removeProvider.*";
      permission java.security.SecurityPermission "Security.setProperty.*";
  };

• Код был загружен из файла JAR со знаком, который находится в"/home/sysadmin/"каталог на локальной файловой системе.
• Подпись может быть проверена, используя открытый ключ, на который ссылается "sysadmin" имени псевдонима в keystore.

Или компонент источника кода (или оба) могут отсутствовать. Пример, где codeBase отсутствует:

  grant signedBy "sysadmin" {
      permission java.security.SecurityPermission "Security.insertProvider.*";
      permission java.security.SecurityPermission "Security.removeProvider.*";
  };

Пример без подписывающего лица:

  grant codeBase "file:/home/sysadmin/-" {
      permission java.security.SecurityPermission "Security.insertProvider.*";
      permission java.security.SecurityPermission "Security.removeProvider.*";
  };

Пример, где ни один codeBase ни signedBy включается:

  grant {
      permission java.security.SecurityPermission "Security.insertProvider.*";
      permission java.security.SecurityPermission "Security.removeProvider.*";
  };

Следующее представляет основанную на принципале запись.

  grant principal javax.security.auth.x500.X500Principal "cn=Alice" {
      permission java.io.FilePermission "/home/Alice", "read, write";
  };

Следующее представляет основанную на принципале запись с подстановочным значением.

  grant principal javax.security.auth.x500.X500Principal * {
      permission java.io.FilePermission "/tmp", "read, write";
  };

Следующий пример показывает оператор предоставления и с codesource и с основной информацией.

  grant codebase "http://www.games.example.com",
        signedBy "Duke",
        principal javax.security.auth.x500.X500Principal "cn=Alice" {
      permission java.io.FilePermission "/tmp/games", "read, write";
  };

Следующий пример показывает оператор предоставления с заменой псевдонима KeyStore:

  keystore "http://foo.example.com/blah/.keystore";

  grant principal "alice" {
      permission java.io.FilePermission "/tmp/games", "read, write";
  };

    javax.security.auth.x500.X500Principal "cn=Alice"

Расширение свойства в Файлах Политики

Расширение свойства подобно расширяющимся переменным в оболочке. Таким образом, когда строка как

    ${some.property}

    permission java.io.FilePermission "${user.home}", "read";

    permission java.io.FilePermission "/home/cathy", "read";

    permission java.io.FilePermission "${user.home}${/}*", "read";

    permission java.io.FilePermission "/home/cathy/*", "read";

    permission java.io.FilePermission "C:\users\cathy\*", "read";

    grant codeBase "file:${java.home}/lib/ext/"

    grant codeBase "file:C:/jdk1.4/jre/lib/ext/"

Расширение свойства имеет место где угодно, двойная заключенная в кавычки строка позволяется в файле политики. Это включает"signer_names", "URL", "target_name", и"action"поля.

Позволяется ли расширение свойства, управляется значением"policy.expandProperties"свойство в файле свойств безопасности. Если значение этого свойства является истиной (значение по умолчанию), расширение позволяется.

Отметьте: невозможно использовать вложенные свойства; они не будут работать. Например,

    "${user.${foo}}"

Отметьте: Если свойство не может быть расширено в записи предоставления, записи разрешения, или keystore записи, та запись игнорируется. Например, если системное свойство"foo"не определяется, и Вы имеете:

    grant codeBase "${foo}" {
        permission ...;
        permission ...;
    };

    grant {
        permission Foo "${foo}";
        permission Bar "barTarget";
    };

    keystore "${foo}";

Системы Windows, Пути к файлам, и Расширение Свойства

    grant {
        permission java.io.FilePermission "C:\\users\\cathy\\foo.bat", "read";
    };

    "C:\users\cathy\foo.bat"

    "${user.home}\\foo.bat"

    "${user.home}\foo.bat"

    "C:\users\cathy\foo.bat"

    "${user.home}${/}foo.bat"

Общее Расширение в Файлах Политики

${{protocol:protocol_data}}

${{protocol}}

Есть два протокола, поддерживаемые в реализации файла политики по умолчанию:

1. ${{self}}

   Протокол, self, обозначает замену всей строки, ${{self}}, с одной или более основными парами класса/имени. Точная выполняемая замена зависит от содержания пункта предоставления, которому принадлежит разрешение.

   Если пункт предоставления не будет содержать основной информации, то разрешение будет проигнорировано (полномочия, содержащие ${{self}} на их целевые имена только допустимы в контексте основанного на принципале пункта предоставления). Например, BarPermission будет всегда игнорироваться в следующем пункте предоставления:

               grant codebase "www.example.com", signedby "duke" {
                   permission BarPermission "... ${{self}} ...";
               };
           
   

   Если пункт предоставления содержит основную информацию, ${{self}} будет заменен той же самой основной информацией. Например, ${{self}} в BarPermission будет заменен javax.security.auth.x500.X500Principal "cn=Duke" в следующем пункте предоставления:

   grant principal javax.security.auth.x500.X500Principal "cn=Duke" {
       permission BarPermission "... ${{self}} ...";
   };
   

   Если есть список разделенных запятой значений принципалов в пункте предоставления, то ${{self}} будет заменен тем же самым списком разделенных запятой значений или принципалами. В случае, где оба основной класс и имя являются wildcarded в пункте предоставления, ${{self}} заменяется всеми принципалами, связанными с Subject в токе AccessControlContext.

   Следующий пример описывает сценарий, включающий обоих self и KeyStore замена псевдонима вместе:

   keystore "http://foo.example.com/blah/.keystore";
   
   grant principal "duke" {
       permission BarPermission "... ${{self}} ...";
   };
   

   В вышеупомянутом примере,"duke"будет сначала расширен в javax.security.auth.x500.X500Principal "cn=Duke" принятие сертификата X.509, связанного с KeyStore псевдоним,"duke", имеет подчиненное отличительное имя"cn=Duke". Затем, ${{self}} будет заменен той же самой основной информацией, которая была только расширена в пункте предоставления: javax.security.auth.x500.X500Principal "cn=Duke".
2. ${{alias:alias_name}}

   Протокол, alias, обозначает java.security. KeyStore искажают замену. KeyStore используемый тот, определенный в KeyStore запись. alias_name представляет псевдоним в KeyStore. ${{alias:alias_name}} заменяется javax.security.auth.x500.X500Principal "DN", где DN представляет подчиненное отличительное имя сертификата, принадлежащего alias_name. Например:

   keystore "http://foo.example.com/blah/.keystore";
   
   grant codebase "www.example.com" {
       permission BarPermission "... ${{alias:duke}} ...";
   };
   

   В вышеупомянутом примере сертификат X.509, связанный с псевдонимом, duke, получается от KeyStore, foo.example.com/blah/.keystore. Принятие сертификата герцога определяет"o=dukeOrg, cn=duke"как подчиненное отличительное имя, тогда ${{alias:duke}} заменяется javax.security.auth.x500.X500Principal "o=dukeOrg, cn=duke".

   Запись разрешения игнорируется под следующими состояниями ошибки:

   • keystore запись является неуказанной
   • alias_name не обеспечивается
   • Сертификат для alias_name не может быть получен
   • Полученный сертификат не является сертификатом X.509

Связанная Документация

• Полномочия в JavaSE JDK
• Средство осуществления политики (для Соляриса) (для Win32) (для Соляриса/Linux) (для Windows)

---

Авторское право © 1993, 2011, Oracle и/или его филиалы. Все права защищены.

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