Default Policy Implementation and Policy File Syntax
Last Modified: 25 September 2003
Java
应用程序运行时的 环境由一个Plolicy对象代表，特别是由一个Policy类子类的一个对象代表。
Policy
使用的策略信息的地址取决于Policy的实现，Policy参考实现包括了来自静态策略config文件的信息。
Note:
Starting with this version (v 1.4), policy files used by the default policy implementation must be encoded in the UTF-8 encoding scheme. You can use the native2ascii tool to assist with this conversion.
策略可以在一个或多个策略文件中。.有一个系统策略文件和一个可选的用户策略文件，策略参考实现在第一次执行他的getPermissions方法，或任何执行更新方法时实例化，实例化过程解析policy文件。
默认情况下，系统策略文件位于
java.home
/lib/security/java.policy (Solaris)
java.home
/lib/security/java.policy (Win32)
系统策略文件允许系统级别的代码许可。随sdk安装的策略文件grant对标准扩展的所有许可，读取安全不敏感的标准属性，如"os.name" and "file.separator"等
用户策略文件默认存在于
user.home
/.java.policy
(Solaris)
user.home
/.java.policy (Win32)
当Policy实例化时，系统策略先加载，如果没有策略文件，将使用一个内置的策略。这个内置的策略和安装jre时的策略是一样的
策略文件的位置在安全属性文件security properties file,中指定，它位于
java.home
/lib/security/java.security (Solaris)
java.home
/lib/security/java.security (Win32)
策略文件的位置由形如
policy.url.n
的属性值决定
其中，n是数字，在一行内：
policy.url.n=URL
如系统默认的安全策略和用户策略如下：
policy.url.1=file:${java.home}/lib/security/java.policy
policy.url.2=file:${user.home}/.java.policy
.
可以指定形如 http://的url，也可以注释掉或改变第二条来禁止用户的策略文件。以上的数字n必须连续才能生效，否则不会被加载
Specifying an Additional Policy File at Runtime
可以在运行程序时指定附加的或不同的策略，通过java -Djava.security.manager -Djava.security.policy=someURL SomeApp 可以让指定的someURL附加在所有策略属性文件（java.policy）中指定的策略文件之后。
当使用（注意双等号） java -Djava.security.manager -Djava.security.policy==someURL SomeApp
则只有指定的策略生效，其余的策略都被忽略 。
当想要像appletviewer传递策略时，如果安全属性文件的 "policy.allowSystemProperty"值为false（默认值），则传递的策略将被忽略，
可以用实现了getPermissions方法的Policy子类来替换原来的策略参考实现类（Policy reference implementation class）。 这需要编辑安全属性文件lib/security/java.security,
policy.provider=PolicyClassName
PolicyClassName
必须使用全名称. 默认是:
policy.provider=sun.security.provider.PolicyFile
可以改为 policy.provider=com.mycom.MyPolicy 来定制
源代码可以读取来自源代码url处的文件，而不需许可。
策略文件可能包含一个"keystore"和零个以上的 "grant" entries.
Keystore Entry
Keystore
是一个包含私钥 和 经过链式验证了公钥的证书库 ，该条目被用来查找grant条目中签名者的公钥。
如果测律文件的grant条目指名了一个签名者的别名，keystore条目必须出现。或者grant条目指明了特征别名，就必须只有一个keystore/keystorePasswordURL 条目，如果有多个条目，之后的会被忽略
有如下语法：
keystore
"some_keystore_url", "keystore_type", "keystore_provider";
keystorePasswordURL "some_password_url";
some_keystore_url
指明了URL
some_password_url
指明了密码位置
注意，由 some_keystore_url构建的输入流，将被传递给KeyStore.load 方法.
如果不是基于文件的，应该明确的赋值NONE。URL应该是相对于策略文件位置的。
如策略属性文件中指明了安全策略文件：
policy.url.1=http://foo.bar.com/fum/some.policy
且该安全策略文件有条目:
keystore ".keystore";
则实际上 keystore 将从
http://foo.bar.com/fum/.keystore
加载。
当然url也可以是绝对路径的。
keystore type
定义了keystore信息的存储和数据格式，以及keystore的私钥算法，默认类型时“JKS”。
Grant Entries
被执行的代码总有来源.codesource不仅包括来源url，而且还包含对证书的引用，证书中包含公钥。证书通过别名被引用。代码也被认为作为一个或以上的特征来执行。
基本格式如下
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";
...
};
The
SignedBy
,
Principal
, and
CodeBase
Fields
signedBy, codeBase, and principal
是可选的，且次序无关。
A signedBy
是keystore中一个证书的别名。 表示授予有此证书的代码权限.
可以逗号分开多个别名，如 "Adam,Eve,Charles", 表示"signed by Adam and Eve and Charles";是 AND关系.更精确的 "Code signed by Adam" 表示"jar文件中的代码，而此jar文件是被私钥签名过的，而对应的公钥证书的别名是Adam ".
signedBy
域是可选的，如果被删除，意味着任何签名者。
principal
指明了一个 class_name/principal_name 对，该对 必须出现在执行线程的principal set中. principal set 和执行代码通过Subject 相关联。如果被删除意味着许可任何特征。
如果principal 的 class_name/principal_name 对由一个单独的引号括起来的字符串，那么他被当作一个keystore的别名。 这个 keystore 将会被查找响应的 X509证书。如果找到，则 principal class_name被自动的设为 javax.security.auth.x500.X500Principal,而 principal_name被自动的设为证书中subject的别名. 如果没有找到证书的映射，则此grant条目被忽略。
Note:
a codeBase value is a URL
，所以应该总是使用斜杠作为分隔符即便在Win32 系统上，所以 Win32 的 C:/somepath/api/,应该在codebase中表示为
grant codeBase "file:/C:/somepath/api/" {
...
}
Codebase
值的含义取决于字符串尾部的 符号 / 所有类。/*所有文件，/-所有文件包括子目录。
|
Codebase URL of Downloaded Code
|
Codebase URL in Policy
|
Match?
|
|
java.sun.com/people/gong/
|
java.sun.com/people/gong
|
Y
|
|
java.sun.com/people/gong/
|
java.sun.com/people/gong/
|
Y
|
|
java.sun.com/people/gong/
|
java.sun.com/people/gong/*
|
Y
|
|
java.sun.com/people/gong/
|
java.sun.com/people/gong/-
|
Y
|
|
java.sun.com/people/gong/appl.jar
|
java.sun.com/people/gong/
|
N
|
|
java.sun.com/people/gong/appl.jar
|
java.sun.com/people/gong/-
|
Y
|
|
java.sun.com/people/gong/appl.jar
|
java.sun.com/people/gong/*
|
Y
|
|
java.sun.com/people/gong/appl.jar
|
java.sun.com/people/-
|
Y
|
|
java.sun.com/people/gong/appl.jar
|
java.sun.com/people/*
|
N
|
|
java.sun.com/people/gong/
|
java.sun.com/people/-
|
Y
|
|
java.sun.com/people/gong/
|
java.sun.com/people/*
|
N
|
The Permission Entries
A permission entry
一定以permission开头，permission_class_name 应该是一个确定的permission 类型，如java.io.FilePermission 或java.lang.RuntimePermission. 需要为许多permission指明"action"，而有些则不需要。.
signedBy
名值对对 permission条目是可选的。如存在，则暗示一个签名许可。，即，permission 类自己必须由给定的别名签名。如:
grant {
permission Foo "foobar", signedBy "FooSoft";
}
如果Foo所在的jar文件，由FooSoft的证书签过，才会有许可，Foo.class是系统类的情况除外。
以上元素在permission语句总必须依次出现，且以分号结尾。permission语句中大小写不重要，但permission_class_name 或任何作为值传入的字符传来说，还是重要的。
Note Regarding File Path Specifications on Win32 Systems
Note:
当不在
codeBase URL
中时，文件路径指定如下
grant {
permission java.io.FilePermission "C://users//cathy//foo.bat", "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.*";
};
这表明只有符合一下条件，才能调用Security中的方法，来添加，移除provider或设置安全属性。
·
代码来自一个签名的jar。此jar在本地文件系统的 "/home/sysadmin/" 目录下.
·
签名能够被keystore中别名为"sysadmin"的公钥验证。
如果没有codebase，如下：
grant signedBy "sysadmin" {
permission java.security.SecurityPermission "Security.insertProvider.*";
permission java.security.SecurityPermission "Security.removeProvider.*";
};
则所有签名能够被验证的类都可执行以上操作。
如果没有signer，如下
grant codeBase "file:/home/sysadmin/-" {
permission java.security.SecurityPermission "Security.insertProvider.*";
permission java.security.SecurityPermission "Security.removeProvider.*";
};
则所有来自本地"/home/sysadmin/" 的类都有权限。
如既没有codeBase 也没有 signedBy，如下:
grant {
permission java.security.SecurityPermission "Security.insertProvider.*";
permission java.security.SecurityPermission "Security.removeProvider.*";
};
则任何代码都有权限执行相关操作。
下面是一个 principal-based 条目.
grant principal javax.security.auth.x500.X500Principal "cn=Alice" {
permission java.io.FilePermission "/home/Alice", "read, write";
};
允许任何有特征 X500Principal, "cn=Alice" 的客户代码读写 "/home/Alice".
grant codebase "http://www.games.com",
signedBy "Duke",
principal javax.security.auth.x500.X500Principal "cn=Alice" {
permission java.io.FilePermission "/tmp/games", "read, write";
};
This allows code downloaded from "www.games.com", signed by "Duke", and executed by "cn=Alice", permission to read and write into the "/tmp/games" directory.
The following example shows a grant statement with KeyStore alias replacement:
keystore "http://foo.bar.com/blah/.keystore";
grant principal "alice" {
permission java.io.FilePermission "/tmp/games", "read, write";
};
"alice" will be replaced by
javax.security.auth.x500.X500Principal "cn=Alice"
assuming the X.509 certificate associated with the keystore alias, alice, has a subject distinguished name of "cn=Alice". This allows code executed by the X500Principal "cn=Alice" permission to read and write into the "/tmp/games" directory.
如果 安全属性文件的 "policy.expandProperties"被设为true，则可使用扩展，何字符串中都可使用，如${java.home}和{file.separator}.扩展符不能嵌套使用。
Note:
所有被扩展使用的属性如不存在，条目会被忽略。例如如果系统没有定义属性"foo" :
grant codeBase "${foo}" {
permission ...;
permission ...;
};
则该 grant条目被忽略。如果：
grant {
permission Foo "${foo}";
permission Bar "barTarget";
};
则 "permission Foo..." 条目被忽略.
如果
keystore "${foo}";
则 keystore被忽略。
Win32 Systems, File Paths, and Property Expansion
先处理转移符号“//”，再处理扩展符号${}。所以最好使用${/}，如：
"${user.home}${/}foo.bat"
Policy
文件中也支持扩展的泛化形式。 permission 名称中可能有以下形式的字符串：
${{protocol:protocol_data}}
如果这样的字符串出现在permission名字中，protocol中的值决定了该发生扩展的精确类型,而 protocol_data 被用来帮助实现扩展。protocol_data 可能是空的，那样就可简单的写为以下形式：
${{protocol}}
默认policy文件的实现中支持两种protocols：
1.
${{self}}
The protocol, self,
指明一个条目字符串中以principal名值对发生的替换。,精确的替换依赖于permissions 跟随的grant子句的内容。
如果grant子句不含任何principal信息， permission 就会被忽略 (包含${{self}} 于target names 的permissions 只有在基于principal的grant子句上下文中才有意义。如下的BarPermission 将总是被忽略:
grant codebase "www.foo.com", signedby "duke" {
permission BarPermission "... ${{self}} ...";
};
如果grant有principal,那么， ${{self}} 将被同样的principal 信息替换，如下例${{self}} 将被替换为：javax.security.auth.x500.X500Principal "cn=Duke" 。
grant principal javax.security.auth.x500.X500Principal "cn=Duke" {
permission BarPermission "... ${{self}} ...";
};
以逗号分割的principal列表，也将以同样的方式被复制。
2.
${{alias:alias_name}}
The protocol, alias,
知名了一个 java.security.KeyStore 别名替换. The KeyStore used is the one specified in the KeyStore entry. alias_name 代表了 KeyStore中的一个别名.如:
keystore "http://foo.bar.com/blah/.keystore";
grant codebase "www.foo.com" {
permission BarPermission "... ${{alias:duke}} ...";
};
上例中 X.509 证书可以从 foo.bar.com/blah/.keystore.获得。 假设 duke的证书指明了"o=dukeOrg, cn=duke" 作为subject 的区别名称,则${{alias:duke}} 被一下字符串替换javax.security.auth.x500.X500Principal "o=dukeOrg, cn=duke".
一下错误发生时，permission将被忽略:
o
没有 keystore条目
o
没有提供 alias_name
o
alias_name
的证书不能获得。can not be retrieved
o
证书不是x.509的
扫一扫
1858
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
