Spec-Zone .ru
спецификации, руководства, описания, API
|
|
Spec-Zone .ru
спецификации, руководства, описания, API
|
Как пример разрешения, следующий код может использоваться, чтобы произвести разрешение, чтобы считать файл, названный "abc" в/tmp каталоге:
perm = new java.io.FilePermission("/tmp/abc", "read");
Новые полномочия разделяются на подклассы или от Класса полномочий или от одного из его подклассов, таких как java.security. BasicPermission. Разделенные на подклассы полномочия (кроме BasicPermission) обычно принадлежат их собственным пакетам. Таким образом FilePermission находится в java.io пакете. Решающий абстрактный метод, который должен быть реализован для каждого нового класса разрешения, implies метод. В основном, "подразумевение b" означает, что, если Вам предоставляют разрешение "a", каждому естественно предоставляют разрешение "b". Это важно, принимая решения управления доступом.
Связанный с абстрактным классом java.security. Разрешение является абстрактным классом, названным java.security. PermissionCollection и заключительный класс java.security. Полномочия.
Класс java.security. PermissionCollection представляет набор (то есть, набор, который позволяет копии) Объектов полномочий для единственной категории (такие как полномочия файла), для простоты группировки. В случаях, где полномочия могут быть добавлены к объекту PermissionCollection в любом порядке, такой что касается полномочий файла, крайне важно, чтобы объект PermissionCollection гарантировал, что корректная семантика сопровождается когда implies функция вызывается.
Класс java.security. Полномочия представляют набор наборов Объектов полномочий, или другими словами, набора высшего качества неоднородных полномочий.
Приложения являются бесплатными добавить новые категории полномочий, которые поддерживает система. Как добавить, что такие специализированные полномочия обсуждаются позже в этом документе.
Теперь мы описываем синтаксис и семантику всех встроенных полномочий.
Каждый экземпляр разрешения обычно сгенерирован, передавая один или более строковых параметров конструктору. В общем падеже с двумя параметрами первый параметр обычно является "именем цели" (такой как имя файла, на который разрешение нацеливается), и второй параметр является действием (таким как действие "чтения" на файле). Обычно, ряд действий может быть определен вместе как разделенная от запятой составная строка.
Класс UnresolvedPermission используется, чтобы содержать такие "неразрешенные" полномочия. Точно так же класс java.security.UnresolvedPermissionCollection хранит набор полномочий UnresolvedPermission.
Во время управления доступом, проверяющего разрешение типа, который был ранее неразрешен, но чей класс был с тех пор загружен, "разрешается" неразрешенное разрешение, и соответствующее решение управления доступом принимается. Таким образом, новый объект соответствующего типа класса инстанцируют, если возможный, основанный на информации в UnresolvedPermission. Этот новый объект заменяет UnresolvedPermission, который удаляется.
Если разрешение все еще неразрешимо в это время, разрешение считают недопустимым, как будто это никогда не предоставляют в политике безопасности.
file directory (same as directory/) directory/file directory/* (all files in this directory) * (all files in the current directory) directory/- (all files in the file system under this directory) - (all files in the file system under the current directory) "<<ALL FILES>>" (all files in the file system)Отметьте, что" <<ВСЕ ФАЙЛЫ>>" являются специальной строкой, обозначающей все файлы в системе. На системе Unix это включает все файлы под корневым каталогом. На системе MS-DOS это включает все файлы на всех дисках.
Действия: читайте, запишите, удалите, и выполнитесь. Поэтому, следующее допустимые примеры кода для того, чтобы создать полномочия файла:
import java.io.FilePermission;
FilePermission p = new FilePermission("myfile", "read,write");
FilePermission p = new FilePermission("/home/gong/", "read");
FilePermission p = new FilePermission("/tmp/mytmp", "read,delete");
FilePermission p = new FilePermission("/bin/*", "execute");
FilePermission p = new FilePermission("*", "read");
FilePermission p = new FilePermission("/-", "read,execute");
FilePermission p = new FilePermission("-", "read,execute");
FilePermission p = new FilePermission("<<ALL FILES>>", "read");
> implies метод в этом классе правильно интерпретирует файловую систему. Например, FilePermission ("/-", "чтение, выполняются") подразумевает FilePermission ("/home/gong/public_html/index.html", "читайте"), и FilePermission ("мусорное ведро / *", "выполняются"), подразумевает FilePermission ("bin/emacs19.31", "выполнитесь"). Отметьте: большинство этих строк дается в зависимом от платформы формате. Например, чтобы представить доступ для чтения к файлу, названному "foo" во "временном" каталоге на диске C системы Windows, Вы использовали бы
FilePermission p = new FilePermission("c:\\temp\\foo", "read");
Двойные наклонные черты влево необходимы, чтобы представить единственную наклонную черту влево, потому что строки обрабатываются токенизатором (java.io. StreamTokenizer), который позволяет "\" использоваться в качестве строки escape (например, "\n", чтобы указать на новую строку) и который таким образом требует, чтобы две наклонных черты влево указали на единственную наклонную черту влево. После того, как токенизатор обработал вышеупомянутую целевую строку FilePermission, преобразовывая двойные наклонные черты влево в единственные наклонные черты влево, конечный результат является фактическим путем "c:\temp\foo"Необходимо, чтобы строки были даны в зависимом от платформы формате, пока нет универсальный язык описания файла. Отметьте также, что использование метасимволов такой как "*" и "-" предотвращает использование определенных имен файлов. Мы думаем, что это - маленькое ограничение, которое может быть допущено в настоящий момент. Наконец, отметьте, что "/-" и" <<ВСЕ ФАЙЛЫ>>" являются той же самой целью на системах Unix в этом, они оба обращаются ко всей файловой системе. (Они могут обратиться к многократным файловым системам, если они все доступны). Две цели потенциально отличаются на других операционных системах, таковы как MS Windows и МАКОС.
Также отметьте, что целевое имя, которое определяет только каталог, с действием "чтения", как в
FilePermission p = new FilePermission("/home/gong/", "read");
средства Вы только даете разрешение, чтобы перечислить файлы в том каталоге, не чтение любой из них. Чтобы позволить доступ для чтения к файлам, следует определить или явное имя файла, или "*" или "-", как в
FilePermission p = new FilePermission("/home/gong/myfile", "read");
FilePermission p = new FilePermission("/home/gong/*", "read");
FilePermission p = new FilePermission("/home/gong/-", "read");
И наконец, отметьте, что у кода всегда автоматически есть разрешение, чтобы считать файлы из его того же самого (URL) расположение, и подкаталоги того расположения; это не нуждается в явном разрешении, чтобы сделать так.hostname (a single host) IP address (a single host) localhost (the local machine) "" (equivalent to "localhost") hostname.domain (a single host within the domain) hostname.subdomain.domain *.domain (all hosts in the domain) *.subdomain.domain * (all hosts)Таким образом, узел выражается как имя DNS, как числовой IP-адрес, как "localhost" (для локальной машины) или как "" (который эквивалентен определению "localhost").
Подстановочный знак "*" может быть включен однажды в спецификации узла имени DNS. Если это включается, это должно быть в крайней левой позиции, как в "*.sun.com".
port_range может быть дан следующим образом:
N (a single port) N- (all ports numbered N and above) -N (all ports numbered N and below) N1-N2 (all ports between N1 and N2, inclusive)Здесь N, N1, и N2 являются неотрицательными целыми числами в пределах от от 0 до 65535 (2^16-1).
Действия на сокетах, принимают, соединяются, слушают, и решение (который является в основном поиском DNS). Отметьте, что неявно, действие "решение" подразумевается, "принимают", "соединяются", и "слушают" - то есть, те, кто может слушать или принять входящие соединения от или новичка, исходящие соединения с узлом должны быть в состоянии искать имя удаленного узла.
Ниже некоторые примеры полномочий сокета.
import java.net.SocketPermission;
SocketPermission p = new SocketPermission("java.example.com","accept");
p = new SocketPermission("192.0.2.99","accept");
p = new SocketPermission("*.com","connect");
p = new SocketPermission("*.example.com:80","accept");
p = new SocketPermission("*.example.com:-1023","accept");
p = new SocketPermission("*.example.com:1024-","connect");
p = new SocketPermission("java.example.com:8000-9000",
"connect,accept");
p = new SocketPermission("localhost:1024-",
"accept,connect,listen");
Отметьте, что SocketPermission ("Java example.com:80,8080", "примите") и SocketPermission ("java.example.com,javasun.example.com", "примите"), не допустимые полномочия сокета. Кроме того, потому что слушают, действие, которое применяется только к портам на локальном узле, тогда как принимают, действие, которое применяется к портам на обоих локальный и удаленный узел, оба действия необходимы.
Имя для BasicPermission является именем данного разрешения (например, "exitVM", "setFactory", "queuePrintJob", и т.д.). Соглашение о присвоении имен следует за иерархическим соглашением о присвоении имен свойства. Звездочка может появиться в конце имени, после ".", или отдельно, чтобы показать подстановочное соответствие. Например: "java. *" или "*" допустим, "*java", или "a*b" не допустим.
Строка действия (наследованный из Разрешения) неиспользована. Таким образом BasicPermission обычно используется в качестве базового класса для "именованных" полномочий (которые содержат имя, но никакой список действий; у Вас или есть именованное разрешение, или Вы не делаете.) Подклассы могут реализовать действия сверху BasicPermission при желании.
Некоторые из подклассов BasicPermission являются java.lang. RuntimePermission, java.security. SecurityPermission, java.util. PropertyPermission, и java.net. NetPermission.
Это - один из подклассов BasicPermission, который реализует действия сверху BasicPermission. Действия читаются и пишут. Их значение определяется следующим образом: "читайте" разрешение позволяет getProperty метод в java.lang. Система, которую вызовут, чтобы получить значение свойства, и разрешение "записи", позволяет setProperty метод, который вызовут, чтобы установить значение свойства.
createClassLoader
getClassLoader
setContextClassLoader
setSecurityManager
createSecurityManager
exitVM
setFactory
setIO
modifyThread
stopThread
modifyThreadGroup
getProtectionDomain
readFileDescriptor
writeFileDescriptor
loadLibrary.{library name}
accessClassInPackage.{package name}
defineClassInPackage.{package name}
accessDeclaredMembers.{class name}
queuePrintJob
accessClipboard accessEventQueue listenToAllAWTEvents showWindowWithoutWarningBanner
requestPasswordAuthentication setDefaultAuthenticator specifyStreamHandler
suppressAccessChecksкоторый позволяет подавлять стандартные проверки прав доступа языка программирования Java - для общественности, значение по умолчанию (пакет) доступ, защищенный, и члены парламента, не занимающие официального поста - выполняемый отраженными объектами в их точке использования.
enableSubclassImplementation enableSubstitution
getPolicy
setPolicy
getProperty.{key}
setProperty.{key}
insertProvider.{provider name}
removeProvider.{provider name}
setSystemScope
setIdentityPublicKey
setIdentityInfo
printIdentity
addIdentityCertificate
removeIdentityCertificate
clearProviderProperties.{provider name}
putProviderProperty.{provider name}
removeProviderProperty.{provider name}
getSignerPrivateKey
setSignerKeyPair
Ясно большое предостережение необходимо, рассматривая предоставление этого разрешения.
doAs
doAsPrivileged
getSubject
getSubjectFromDomainCombiner
setReadOnly
modifyPrincipals
modifyPublicCredentials
modifyPrivateCredentials
refreshCredential
destroyCredential
createLoginContext.{name}
getLoginConfiguration
setLoginConfiguration
refreshLoginConfiguration
implies метод, который представляет, как определенный класс полномочий касается других классов полномочий. Например, java.io. FilePermission ("/tmp/* ", "читайте"), подразумевает java.io. FilePermission ("/tmp/a.txt", "читайте"), но не подразумевает java.net. NetPermission. Есть другой уровень импликации, которая, возможно, не сразу очевидна для некоторых читателей. Предположите, что одному апплету предоставили разрешение, чтобы записать во всю файловую систему. Этот presumbly позволяет апплету заменять системный двоичный файл, включая среду выполнения JVM. Это эффективно означает, что апплету предоставили все полномочия.
Другой пример - то, что, если апплету предоставляют разрешение времени выполнения, чтобы создать загрузчики класса, этому эффективно предоставляют еще много полномочий, поскольку загрузчик класса может выполнить секретные операции.
Другие полномочия, которые "опасны", чтобы выделить, включают тех, которые позволяют установку системных свойств, полномочий времени выполнения для того, чтобы определить пакеты и для того, чтобы загрузить собственные библиотеки кода (потому что архитектура безопасности Java не разрабатывается к и не предотвращает злонамеренное поведение на уровне собственного кода), и конечно AllPermission.
Для получения дополнительной информации о полномочиях, включая таблицы, перечисляющие риски присвоения определенных полномочий так же как таблицы всего Java 2 SDK, встроенные методы, которые требуют полномочий, видят http://java.sun.com/j2se/sdk/1.2/docs/guide/security/permissions.html.
Чтобы создать новое разрешение, следующие шаги рекомендуются, как показано примером. Предположите, что разработчик приложений от ABC компании хочет создать специализированное разрешение, чтобы "смотреть телевизор".
Во-первых, создайте новый класс com.abc. Разрешение, которое расширяет абстрактный класс java.security. Разрешение (или один из его подклассов), и другой новый класс com.abc. TVPermission, который расширяет com.abc. Разрешение. Удостоверьтесь что implies метод, среди других, правильно реализуется. (Конечно, com.abc. TVPermission может непосредственно расширить java.security. Разрешение; промежуточное звено com.abc. Разрешение не требуется.)
public class com.abc.Permission extends java.security.Permission public class com.abc.TVPermission extends com.abc.PermissionСледующие данные показывают отношение подкласса.
Во-вторых, включайте эти новые классы с пакетом приложений.
Каждый пользователь, который хочет позволить этот новый тип разрешения для определенного кода, делает так, добавляя запись в файле политики. (Детали синтаксиса файла политики даются в более позднем разделе.) Пример кода предоставления записи файла политики из http://java.sun.com/ разрешения, чтобы наблюдать канал 5 был бы:
grant codeBase "http://java.sun.com/" {
permission com.abc.TVPermission "channel-5", "watch";
}
В коде управления ресурсами приложения, проверяя, чтобы видеть, нужно ли разрешение предоставить, AccessController вызова checkPermission метод используя com.abc. TVPermission возражают как параметр.
com.abc.TVPermission tvperm = new
com.abc.TVPermission("channel-5", "watch");
AccessController.checkPermission(tvperm);
Отметьте, что, добавляя новое разрешение, нужно создать новое (разрешение) класс и не добавить новый метод к менеджеру безопасности. (В прошлом, чтобы позволить проверить нового типа доступа, необходимо добавить новый метод к классу SecurityManager.) Если более тщательно продуманный TVPermissions, такие как "канал-1:13" или "канал - *" позволяются, то может быть необходимо реализовать объект TVPermissionCollection, который знает, как иметь дело с семантикой этих псевдо имен.
Новый код должен всегда вызывать разрешение, проверяют вызов checkPermission метод класса AccessController, чтобы осуществить встроенный алгоритм управления доступом. Нет никакой важнейшей потребности исследовать, есть ли ClassLoder или SecurityManager. С другой стороны, если алгоритм нужно оставить установленному классу менеджера безопасности, то метод SecurityManager.checkPermission должен быть вызван вместо этого.
Для апплета (или приложение, работающее под SecurityManager), чтобы быть позволенным выполнить защищенные действия, такие как чтение или запись файла, апплету (или приложение) нужно предоставить разрешение для того определенного действия. Единственное исключение - то, что у кода всегда автоматически есть разрешение, чтобы считать файлы из его того же самого CodeSource, и подкаталоги того CodeSource; это не нуждается в явном разрешении, чтобы сделать так.
Могли быть многократные экземпляры объекта Политики, хотя только один "в действительности" в любое время. Установленный в настоящий момент объект Политики может быть получен, вызывая getPolicy метод, и это может быть изменено звонком setPolicy метод (кодом с разрешением, чтобы сбросить Политику).
Исходное расположение для информации о политике, используемой объектом Политики, до реализации Политики. Конфигурация политики может быть сохранена, например, как плоский файл ASCII, как сериализированный двоичный файл класса Политики, или как база данных. Есть ссылочная реализация Политики, которая получает ее информацию из статических конфигурационных файлов политики.
Конфигурационный файл политики по существу содержит список записей. Это может содержать "keystore" запись, и содержит нуль или больше записей "предоставления".
keystore является базой данных закрытых ключей и их связанных цифровых сертификатов, таких как цепочки сертификата X.509, аутентифицирующие соответствующие открытые ключи. keytool утилита используется, чтобы создать и администрировать keystores. keystore, определенный в конфигурационном файле политики, используется, чтобы искать открытые ключи подписывающих лиц, определенных в записях предоставления файла. keystore запись должна появиться в конфигурационном файле политики, если какие-либо записи предоставления определяют псевдонимы подписывающего лица, или если какие-либо записи предоставления определяют основной псевдоним (см. ниже).
В это время может быть только одна keystore запись в файле политики (другие после того, как первый игнорируется), и это может появиться где угодно вне записей предоставления файла. У этого есть следующий синтаксис:
keystore "some_keystore_url", "keystore_type";Здесь, "some_keystore_url" определяет расположение URL keystore, и "keystore_type" определяет тип keystore. Последний является дополнительным. Если не определенный, тип, как предполагается, что определен "keystore.type" свойством в файле свойств безопасности.
URL относительно расположения файла политики. Таким образом, если файл политики определяется в файле свойств безопасности как:
policy.url.1=http://foo.bar.example.com/blah/some.policyи у того файла политики есть запись:
keystore ".keystore";тогда keystore будет загружен из:
http://foo.bar.example.com/blah/.keystoreURL может также быть абсолютным.
Тип keystore определяет хранение и формат данных keystore информации, и алгоритмы, используемые, чтобы защитить закрытые ключи в keystore и целостности keystore непосредственно. Тип по умолчанию, поддерживаемый Sun Microsystems, является собственным типом keystore под названием "JKS".
Каждая запись предоставления в файле политики по существу состоит из CodeSource и его полномочий. Фактически, CodeSource состоит из URL и ряда сертификатов, в то время как запись файла политики включает URL и список имен подписывающего лица. Система создает соответствующий CodeSource после консультации с keystore, чтобы определить сертификат (ы) об указанных подписывающих лицах.
Каждая запись предоставления в файле политики имеет следующий формат, где ведущее "предоставление" является зарезервированным словом, которое показывает начало новой записи, и дополнительные элементы кажутся в скобках. В пределах каждой записи ведущее "разрешение" является другим зарезервированным словом, которое отмечает начало нового разрешения в записи. Каждая запись предоставления предоставляет ряд полномочий указанному источнику кода и принципалам.
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 ...
};
Пробелы сразу позволяются прежде или после любой запятой. Имя класса полномочий должно быть полностью определенным именем класса, таким как java.io. FilePermission, и не может быть сокращен (например к FilePermission). Отметьте, что поле действия является дополнительным в этом, оно может быть опущено, если класс полномочий не требует этого. Если это присутствует, то это должно сразу прибыть после целевого поля.
Точное значение CodeBase значение URL зависит от символов в конце. CodeBase с запаздыванием "/" соответствует все файлы класса (не файлы JAR) в указанном каталоге. CodeBase с запаздыванием "/*" соответствует все файлы (и класс и файлы JAR) содержавшийся в том каталоге. CodeBase с запаздыванием "/-" соответствует все файлы (и класс и файлы JAR) в каталоге и рекурсивно всех файлах в подкаталогах, содержавшихся в том каталоге.
Поле CodeBase (URL) является дополнительным в этом, если это опускается, это показывает "любую кодовую базу".
Первое поле имени подписывающего лица является строковым псевдонимом, который отображается, через отдельный механизм, к ряду открытых ключей (в пределах сертификатов в keystore), которые связываются с подписывающими лицами. Эти ключи используются, чтобы проверить, что определенные классы со знаком действительно подписываются этими подписывающими лицами.
Это поле подписывающего лица может быть разделенной от запятой строкой, содержащей имена многократных подписывающих лиц, примером которых является "Адам, Канун, Чарльз", что означает подписанный Адамом и Евой и Чарльзом (то есть, отношение И, не ИЛИ).
Это поле является дополнительным в этом, если оно опускается, оно показывает "любое подписывающее лицо", или другими словами, "Не имеет значения, подписывается ли код или не".
Второе поле подписывающего лица, в записи Разрешения, представляет псевдоним keystore записи, содержащей открытый ключ, соответствующий закрытому ключу, используемому, чтобы подписать байт-коды, которые реализовывали упомянутый класс полномочий. Эта запись разрешения эффективна (то есть, разрешение управления доступом предоставят основанное на этой записи), только если реализация байт-кода проверяется, чтобы быть правильно подписанной упомянутым псевдонимом.
Основное значение определяет class_name/principal_name пару, которая должна присутствовать в пределах выполняющегося набора принципала потоков. Основной набор связывается с выполняющимся кодом посредством Предмета. Основное поле является дополнительным в этом, если оно опускается, оно показывает "любые принципалы".
Примечание по Замене Псевдонима KeyStore:
Если принципал class_name/principal_name пара определяется как единственная заключенная в кавычки строка, это обрабатывается как псевдоним keystore. С keystore консультируются и запрашивается (через псевдоним) для Сертификата X509. Если Вы находитесь, principal_class автоматически обрабатывается как javax.security.auth.x500.X500Principal, и principal_name автоматически обрабатывается как подчиненное отличительное имя от сертификата. Если отображение Сертификата X509 не находится, вся запись предоставления игнорируется.
Порядок между CodeBase, SignedBy, и полями Principal не имеет значения.
Неофициальный BNF grammer для формата файла Политики дается ниже, где неиспользованные для своей выгоды сроки являются терминалами:
PolicyFile -> PolicyEntry | PolicyEntry; PolicyFile
PolicyEntry -> grant {PermissionEntry}; |
grant SignerEntry {PermissionEntry} |
grant CodebaseEntry {PermissionEntry} |
grant PrincipalEntry {PermissionEntry} |
grant SignerEntry, CodebaseEntry {PermissionEntry} |
grant CodebaseEntry, SignerEntry {PermissionEntry} |
grant SignerEntry, PrincipalEntry {PermissionEntry} |
grant PrincipalEntry, SignerEntry {PermissionEntry} |
grant CodebaseEntry, PrincipalEntry {PermissionEntry} |
grant PrincipalEntry, CodebaseEntry {PermissionEntry} |
grant SignerEntry, CodebaseEntry, PrincipalEntry {PermissionEntry} |
grant CodebaseEntry, SignerEntry, PrincipalEntry {PermissionEntry} |
grant SignerEntry, PrincipalEntry, CodebaseEntry {PermissionEntry} |
grant CodebaseEntry, PrincipalEntry, SignerEntry {PermissionEntry} |
grant PrincipalEntry, CodebaseEntry, SignerEntry {PermissionEntry} |
grant PrincipalEntry, SignerEntry, CodebaseEntry {PermissionEntry} |
keystore "url"
SignerEntry -> signedby (a comma-separated list of strings)
CodebaseEntry -> codebase (a string representation of a URL)
PrincipalEntry -> OnePrincipal | OnePrincipal, PrincipalEntry
OnePrincipal -> principal [ principal_class_name ] "principal_name" (a principal)
PermissionEntry -> OnePermission | OnePermission PermissionEntry
OnePermission -> permission permission_class_name
[ "target_name" ] [, "action_list"]
[, SignerEntry];
Теперь мы даем некоторые примеры. Следующая политика предоставляет разрешение a.b. Foo, чтобы кодировать подписанный Роландом:
grant signedBy "Roland" {
permission a.b.Foo;
};
Следующие предоставления FilePermission ко всему коду (независимо от подписывающего лица и/или кодовой базы):
grant {
permission java.io.FilePermission ".tmp", "read";
};
Следующие предоставления два полномочий, чтобы кодировать, который подписывается и Литием и Роландом:
grant signedBy "Roland,Li" {
permission java.io.FilePermission "/tmp/*", "read";
permission java.util.PropertyPermission "user.*";
};
Следующие предоставления два полномочий, чтобы кодировать, который подписывается Литием и это прибывает из http://java.sun.com:
grant codeBase "http://java.sun.com/*", signedBy "Li" {
permission java.io.FilePermission "/tmp/*", "read";
permission java.io.SocketPermission "*", "connect";
};
Следующие предоставления два полномочий, чтобы кодировать, который подписывается и Литием и Роландом, и только если байт-коды, реализовывая com.abc. TVPermission действительно подписываются Литием.
grant signedBy "Roland,Li" {
permission java.io.FilePermission "/tmp/*", "read";
permission com.abc.TVPermission "channel-5", "watch",
signedBy "Li";
};
Причина включения второго поля подписывающего лица состоит в том, чтобы предотвратить спуфинг, когда класс полномочий не находится с установкой Среды выполнения Java. Например, копия com.abc. Класс TVPermission может быть загружен как часть удаленного архива JAR, и пользовательская политика могла бы включать запись, которая обращается к этому. Поскольку архив не долговечен, во второй раз com.abc. Класс TVPermission загружается, posssibly от различного веб-сайта, крайне важно, чтобы вторая копия была подлинна, поскольку присутствие записи разрешения в пользовательской политике могло бы отразить уверенность пользователя или веру в первую копию байт-кода класса. Причина, которую мы хотели использовать цифровые подписи, чтобы гарантировать подлинности, вместо того, чтобы хранить (значение хэш-функции) первую копию байт-кодов и использовать это, чтобы сравниться со второй копией, состоит в том, потому что автор класса полномочий может законно обновить файл класса, чтобы отразить новый проект или реализацию.
Пожалуйста, отметьте: строки для пути к файлу должны быть определены в зависимом от платформы формате; это необходимо, пока нет универсальный язык описания файла. Вышеупомянутые примеры показали строки, соответствующие на системах Соляриса. На системах Windows, когда Вы непосредственно определяете путь к файлу в строке, Вы должны включать две наклонных черты влево для каждой фактической единственной наклонной черты влево в пути, как в
grant signedBy "Roland" {
permission java.io.FilePermission "C:\\users\\Cathy\\*", "read";
};
Это - то, потому что строки обрабатываются токенизатором (java.io. StreamTokenizer), который позволяет "\" использоваться в качестве строки escape (например, "\n", чтобы указать на новую строку) и который таким образом требует, чтобы две наклонных черты влево указали на единственную наклонную черту влево. После того, как токенизатор обработал вышеупомянутую целевую строку FilePermission, преобразовывая двойные наклонные черты влево в единственные наклонные черты влево, конечный результат является фактическим путем "C:\users\Cathy\*"Наконец, вот некоторые основанные на принципале записи предоставления:
grant principal javax.security.auth.x500.X500Principal "cn=Alice" {
permission java.io.FilePermission "/home/Alice", "read, write";
};
Это разрешает любому коду, выполняющемуся как X500Principal, "cn=Alice", разрешение читать и писать в "/home/Alice". Следующий пример показывает оператор предоставления и с 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";
};
Это позволяет коду, загруженному с "www.games.example.com", подписанный "Герцогом", и выполняемый "cn=Alice", разрешение читать и писать в "/tmp/games" каталог. Следующий пример показывает оператор предоставления с заменой псевдонима KeyStore:
keystore "http://foo.bar.example.com/blah/.keystore";
grant principal "alice" {
permission java.io.FilePermission "/tmp/games", "read, write";
};
"alice" будет заменен javax.security.auth.x500. У X500Principal "cn=Alice" принятие сертификата X.509, связанного с псевдонимом keystore, alice, есть подчиненное отличительное имя "cn=Alice". Это позволяет коду, выполняемому X500Principal "cn=Alice" разрешение читать и писать в "/tmp/games" каталог.Расширение свойства подобно расширяющимся переменным в оболочке. Таким образом, когда строка как
появляется в файле политики, или в файле свойств безопасности, это будет расширено до значения указанного системного свойства. Например,
permission java.io.FilePermission "${user.home}", "read";
развернет "$ {user.home}", чтобы использовать значение "user.home" системного свойства. Если значение того свойства является "/home/cathy", то вышеупомянутое эквивалентно permission java.io.FilePermission "/home/cathy", "read";Чтобы помочь в независимых от платформы файлах политики, можно также использовать специальную нотацию "$ {/}", который является ярлыком за "$ {file.separator}". Это позволяет обозначения разрешения такой как
permission java.io.FilePermission "${user.home}${/}*", "read";
Если user.home является/home/cathy, и Вы находитесь на Солярисе, вышеупомянутое преобразовывается в: permission java.io.FilePermission "/home/cathy/*", "read";Если с другой стороны user.home является C:\users\cathy, и Вы находитесь на системе Windows, вышеупомянутое преобразовывается в:
permission java.io.FilePermission "C:\users\cathy\*", "read";Кроме того, как особый случай, если Вы разворачиваете свойство в кодовой базе, такой как
grant codeBase "file:/${java.home}/lib/ext/"
тогда любые file.separator символы будут автоматически преобразованы в/'s, который является требуемым, так как кодовыми базами являются URL. Таким образом на системе Windows, даже если бы java.home устанавливается в C:\j2sdk1.2, вышеупомянутое преобразовать в grant codeBase "file:/C:/j2sdk1.2/lib/ext/"Таким образом Вы не должны использовать $ {/} в строках кодовой базы (и Вы не были должны).
Расширение свойства имеет место где угодно, двойная заключенная в кавычки строка позволяется в файле политики. Это включает signedby, кодовую базу, целевые имена, и поля действий.
Позволяется ли расширение свойства, управляется значением "policy.expandProperties" свойства в файле свойств безопасности. Если значение этого свойства является истиной (значение по умолчанию), расширение позволяется.
Пожалуйста, отметьте: невозможно использовать вложенные свойства; они не будут работать. Например,
"${user.${foo}}"
не работает, даже если "foo" свойство устанавливается "разместить". Причиной является синтаксический анализатор свойства, не распознает вложенные свойства; это просто ищет первый "$ {", и затем продолжает смотреть, пока это не находит первое"}" и пытается интерпретировать результат "$ {user. $foo}" как свойство, но сбои, если нет такого свойства. Также отметьте: Если свойство не может быть расширено в записи предоставления, записи разрешения, или keystore записи, та запись игнорируется. Например, если системное свойство "foo" не определяется, и Вы имеете:
grant codeBase "${foo}" {
permission ...;
permission ...;
};
тогда все полномочия в этой записи предоставления игнорируются. Если Вы имеете
grant {
permission Foo "${foo}";
permission Bar;
};
тогда только "разрешение Foo..." запись игнорируется. И наконец, если Вы имеете
keystore "${foo}";
тогда keystore запись игнорируется. Одно заключительное примечание: На системах Windows, когда Вы непосредственно определяете путь к файлу в строке, Вы должны включать две наклонных черты влево для каждой фактической единственной наклонной черты влево в пути, как в
"C:\\users\\cathy\\foo.bat"Это - то, потому что строки обрабатываются токенизатором (java.io. StreamTokenizer), который позволяет "\" использоваться в качестве строки escape (например, "\n", чтобы указать на новую строку) и который таким образом требует, чтобы две наклонных черты влево указали на единственную наклонную черту влево. После того, как токенизатор обработал вышеупомянутую строку, преобразовывая двойные наклонные черты влево в единственные наклонные черты влево, конечный результат
"C:\users\cathy\foo.bat"Расширение свойства в строке имеет место после того, как токенизатор обработал строку. Таким образом, если у Вас есть строка
"${user.home}\\foo.bat"
тогда сначала токенизатор обрабатывает строку, преобразовывая двойные наклонные черты влево в единственную наклонную черту влево, и результат
"${user.home}\foo.bat"
Затем $ {user.home} свойство расширяется, и конечный результат "C:\users\cathy\foo.bat"принятие значения user.home является "C:\users\cathy". Конечно, для независимости от платформы, было бы лучше, если бы строка была первоначально определена без каких-либо явных наклонных черт, то есть, используя $ {/} свойство вместо этого, как в
"${user.home}${/}foo.bat"
Есть два протокола, поддерживаемые в реализации файла политики по умолчанию:
Протокол, сам, обозначает замену всей строки, $ {{сам}}, с одной или более основными парами класса/имени. Точная выполняемая замена зависит от содержания пункта предоставления, которому принадлежит разрешение.
Если пункт предоставления не будет содержать основной информации, то разрешение будет проигнорировано (полномочия, содержащие $ {{сам}} на их целевые имена, только допустимы в контексте основанного на принципале пункта предоставления). Например, BarPermission будет всегда игнорироваться в следующем пункте предоставления:
grant codebase "www.foo.example.com", signedby "duke" {
permission BarPermission "... ${{self}} ...";
};
Если пункт предоставления будет содержать основную информацию, то $ {{сам}} будет заменен той же самой основной информацией. Например, $ {{сам}} в BarPermission будет заменен javax.security.auth.x500. X500Principal "cn=Duke" в следующем пункте предоставления:
grant principal javax.security.auth.x500.X500Principal "cn=Duke" {
permission BarPermission "... ${{self}} ...";
};
Если будет список разделенных запятой значений принципалов в пункте предоставления, то $ {{сам}} будет заменен тем же самым списком разделенных запятой значений или принципалами. В случае, где оба основной класс и имя являются wildcarded в пункте предоставления, $ {{сам}} заменяется всеми принципалами, связанными с Subject в токе AccessControlContext. Следующий пример описывает сценарий, включающий и сам и замена псевдонима KeyStore вместе:
keystore "http://foo.bar.example.com/blah/.keystore";
grant principal "duke" {
permission BarPermission "... ${{self}} ...";
};
В вышеупомянутом примере "герцог" будет сначала расширен в javax.security.auth.x500. У X500Principal "cn=Duke" принятие сертификата X.509, связанного с псевдонимом KeyStore, "герцогом", есть подчиненное отличительное имя "cn=Duke". Затем, $ {{сам}} будет заменен той же самой основной информацией, которая только была расширена в пункте предоставления: javax.security.auth.x500. X500Principal "cn=Duke".Протокол, псевдоним, обозначает java.security. KeyStore искажают замену. KeyStore используемый тот, определенный в записи KeyStore. alias_name представляет псевдоним в KeyStore. $ {{alias:alias_name}} заменяется javax.security.auth.x500. X500Principal "DN", где DN представляет подчиненное отличительное имя сертификата, принадлежащего alias_name. Например:
keystore "http://foo.bar.example.com/blah/.keystore";
grant codebase "www.foo.example.com" {
permission BarPermission "... ${{alias:duke}} ...";
};
В вышеупомянутом примере сертификат X.509, связанный с псевдонимом, герцогом, получается от KeyStore, foo.bar.example.com/blah/.keystore. Принятие сертификата герцога определяет "o=dukeOrg, cn=duke" как подчиненное отличительное имя, тогда $ {{alias:duke}} заменяется javax.security.auth.x500. X500Principal "o=dukeOrg, cn=duke". Запись разрешения игнорируется под следующими состояниями ошибки:
getPermissions или implies метод на объекте Политики, который устанавливается в VM. Ясно, данный источник кода в ProtectionDomain может соответствовать источник кода, данный в многократных записях в политике, например потому что подстановочный знак "*" позволяется.
Следующий алгоритм используется, чтобы определить местоположение соответствующего набора полномочий в политике.
1. match the public keys, if code is signed.
2. if a key is not recognized in the policy, ignore the key
if every key is ignored, treat the code as unsigned.
3. if the keys are matched, or no signer was specified {
try to match all URLs in the policy for the keys
}
4. if the keys are matched (or no signer was specified),
and the URLs are matched (or no codebase was specified) {
try to match all principals in the policy with
the principals associated with the current executing thread.
5. if either key, URL, or principals are not matched, use built-in default
permission, which is the original sandbox permission.
Точное значение кодовой базы записи политики значение URL зависит от символов в конце. Кодовая база с запаздыванием "/" соответствует все файлы класса (не файлы JAR) в указанном каталоге. Кодовая база с запаздыванием "/*" соответствует все файлы (и класс и файлы JAR) содержавшийся в том каталоге. Кодовая база с запаздыванием "/-" соответствует все файлы (и класс и файлы JAR) в каталоге и рекурсивно всех файлах в подкаталогах, содержавшихся в том каталоге. Как пример, данный "http://java.sun.com/ -" в политике, тогда, любая кодовая база, которая находится на этом веб-сайте, соответствует запись политики. Соответствующие кодовые базы включают "http://java.sun.com/j2se/sdk/" и "http://java.sun.com/people/gong/appl.jar".
Если многократные записи являются соответствующими, то все полномочия, данные в тех записях, предоставляют. Другими словами присвоение разрешения является дополнением. Например, если код, подписанный с ключом A, получает разрешение X, и код, подписанный ключом B, получает разрешение Y, и никакая определенная кодовая база не определяется, то кодируйте подписанный и A и B, получает полномочия X и Y. Точно так же, если коду с кодовой базой "http://java.sun.com/ -" дают разрешение X, и "http://java.sun.com/people/*" дается разрешение Y, и никакие определенные подписывающие лица не определяются, то апплет от "http://java.sun.com/people/applet.jar" добирается и X и Y.
Отметьте, что URL, соответствующий здесь, является просто синтаксическим. Например, политика может дать запись, которая определяет URL "ftp://ftp.sun.com". Такая запись полезна только, когда можно получить код Java непосредственно из протокола передачи файлов для выполнения.
Чтобы определить URL для локальной файловой системы, файл, URL может использоваться. Например, чтобы определить файлы в/home/cathy/temp каталоге в системе Соляриса, Вы использовали бы
"file:/home/cathy/temp/*"Чтобы определить файлы во "временном" каталоге на диске C в системе Windows, использовать
"file:/c:/temp/*"Отметьте: URL кодовой базы всегда используют наклонные черты (никакие обратные реакции), независимо от платформы, которой они применяются к.
Можно также использовать абсолютный путь такой как
"/home/gong/bin/MyWonderfulJava"
Файл политики может быть составлен через простой текстовый редактор, или через графическую утилиту PolicyTool, которая описывается позже.
Есть по умолчанию единственный файл политики в масштабе всей системы, и единственный пользовательский файл политики.
Системный файл политики по умолчанию располагается в
{java.home}/lib/security/java.policy (Solaris)
{java.home}\lib\security\java.policy (Windows)
Здесь, java.home является системным свойством, определяющим каталог, в который Java были установлены 2 SDK. Пользовательский файл политики по умолчанию располагается в
{user.home}/.java.policy (Solaris)
{user.home}\.java.policy (Windows)
Здесь, user.home является системным свойством, определяющим корневой каталог пользователя. Когда Политика инициализируется, системная политика загружается в первом, и затем пользовательская политика добавляется к этому. Если никакая политика не присутствует, встроенная политика используется. Эта встроенная политика является тем же самым как исходной политикой песочницы.
Расположение файлов политики определяется в файле свойств безопасности, который располагается в
{java.home}/lib/security/java.security (Solaris)
{java.home}\lib/security\java.security (Windows)
Расположение файлов политики определяется как значения свойств, имена которых имеют форму policy.url.nЗдесь, n является числом. Вы определяете каждое такое значение свойства в строке следующей формы:
policy.url.n=URLЗдесь, URL является спецификацией URL. Например, система по умолчанию и пользовательские файлы политики определяются в файле свойств безопасности как
policy.url.1=file:${java.home}/lib/security/java.policy
policy.url.2=file:${user.home}/.java.policy
Можно фактически определить много URL, включая формы "http://", и все определяемые файлы политики будут загружены. Можно также прокомментировать или изменить второй, чтобы отключить чтение пользовательского файла политики по умолчанию. Алгоритм запускается в политике url.1, и продолжает постепенно увеличиваться, пока это не находит URL. Таким образом, если у Вас будет политика url.1 и политика url.3, то политика url.3 никогда не будет читаться.
Также возможно определить дополнительное или различный файл политики, вызывая выполнение приложения. Это может быть сделано через "-Djava.security.policy" параметр командной строки, который устанавливает значение java.security.policy свойства. Например, если Вы используете
java -Djava.security.manager -Djava.security.policy=pURL SomeAppЗдесь, ИЗНАНОЧНОЙ ВЯЗКОЙ является URL, определяющий расположение файла политики, тогда указанный файл политики будет загружен в дополнение ко всем файлам политики, которые определяются в файле свойств безопасности. ("-Djava.security.manager" параметр гарантирует, что менеджер безопасности по умолчанию устанавливается, и таким образом приложение подвергается проверкам политики, как описано в "управлении безопасностью для Апплетов и Приложений". Не требуется, устанавливает ли приложение SomeApp менеджера безопасности.)
Если Вы используете следующий, с двойным равняется, то только указанный файл политики будет использоваться; все другие будут проигнорированы.
java -Djava.security.manager -Djava.security.policy==pURL SomeAppЕсли Вы хотите передать файл политики к appletviewer, снова используйте "-Djava.security.policy" параметр следующим образом:
appletviewer -J-Djava.security.policy=pURL myAppletПожалуйста, отметьте: "-Djava.security.policy" значение файла политики будет проигнорировано (и для java и для appletviewer команд), если "policy.allowSystemProperty" свойство в файле свойств безопасности будет установлено в ложь. Значение по умолчанию является истиной.
getPermissions метод (и другие методы по мере необходимости). Ссылочная реализация Политики может быть изменена, сбрасывая значение "policy.provider" свойства безопасности (в файле свойств безопасности) к полностью определенному имени требуемого класса реализации Политики. Файл свойств безопасности располагается в названном файле
{java.home}/lib/security/java.security (Solaris)
{java.home}\lib\security\java.security (Windows)
Здесь, {java.home} ссылается на каталог, где среда выполнения устанавливается - или каталог jre в Java 2 SDK, или высокоуровневый каталог Java 2 Среды выполнения. Свойство policy.provider определяет имя класса политики, и значение по умолчанию является следующим:
policy.provider=sun.security.provider.PolicyFileЧтобы настроить, можно изменить значение свойства, чтобы определить другой класс, как в
policy.provider=com.mycom.MyPolicyОтметьте, что класс MyPolicy должен быть подклассом java.security. Политика. Это, возможно, стоит подчеркнуть, что такое переопределение класса политики является временным решением, и более всесторонний API политики, вероятно, сделает это ненужным.
Есть в настоящий момент все еще два исключения в пределах java.security пакета, которые являются подклассами от RuntimeException. Мы в этот момент не можем изменить их из-за требований обратной совместимости. Мы повторно посетим эту проблему в будущем.
| СОДЕРЖАНИЕ | ПРЕДЫДУЩИЙ | NEXT |
