Java Reference
In-Depth Information
with names starting with
org.foo.secure
. How can you implement such a policy with
only allow-access decisions? You'd have to exhaustively grant permissions to import
every package except the ones you want to exclude. This wouldn't even be possible in
an open-ended system. This is where a deny-access decision becomes valuable.
Assume you add a
ConditionalPermissionInfo
with a deny-access decision. Dur-
ing a permission check, if the associated conditions match and the permission being
checked is implied by the associated permissions, the bundle on the stack will be
denied permission to perform the operation. To complete the hypothetical example,
you can grant a bundle the following permission:
infos.add(admin.newConditionalPermissionInfo(
"deny-secure-packages",
new ConditionInfo[] { new ConditionInfo(
BundleLocationCondition.class.getName(),
new String[] { "file:foo.jar" }) },
new PermissionInfo[] { new PermissionInfo(
PackagePermission.class.getName(),
"org.foo.secure.*", PackagePermission.IMPORT)
}, ConditionalPermissionInfo.DENY));
This prevents it from importing packages starting with
org.foo.secure
. Of course,
to give it permission to import everything else, you also have to grant it the follow-
ing permission:
infos.add(admin.newConditionalPermissionInfo(
"allow-non-secure-packages",
new ConditionInfo[] { new ConditionInfo(
BundleLocationCondition.class.getName(),
new String[] { "file:foo.jar" }) },
new PermissionInfo[] { new PermissionInfo(
PackagePermission.class.getName(),
"*", PackagePermission.IMPORT)
}, ConditionalPermissionInfo.ALLOW));
This allows it to import everything else. This also raises another important point when
mixing allow and deny decisions into a single security policy: ordering. With allow-
and deny-access decisions, the order of
ConditionalPermissionInfo
objects in the
policy table managed by the
ConditionalPermissionAdmin
service becomes impor-
tant. When a permission check is triggered, the entries in the policy table are tra-
versed in ascending index order until the first one is found where the conditions are
satisfied and the required permission is present. If the associated access policy is
DENY
,
the check fails. If it's
ALLOW
, the checking continues with the next bundle protection
domain on the stack. Thus, in the example, to implement the policy correctly the
denied permission must be added before the allowed permission.
That covers the basics of using the
ConditionalPermissionAdmin
service. To pro-
vide a slightly more familiar approach to defining a security policy for seasoned Java
developers, you'll now use this
API
to create a policy-file reader. A lot of what you
need for doing this is provided by the
OSG
i specification already, so it's pretty easy
to accomplish.
