Securing your applications - OSGi in Action - page 464

14.6 Local permissions

Bundle signing provides a powerful yet fairly simple mechanism for creating desired
security policies. But it doesn't help address one nagging issue: how do you know
which permissions to grant a bundle? Even if you've verified a bundle's signature and
know that the bundle comes from a trusted provider, you still need to answer this
question. Even if you fully trust a provider, it's better to limit a bundle's permissions to
a precise set of required permissions to further prevent intended or unintended secu-
rity breaches.
The standard Java security architecture doesn't help you here; instead, you must
rely on prior knowledge about the code's requirements or trial and error. OSG i specif-
ically addresses this issue with a concept called local permissions . Local permissions are
defined by a resource contained in the bundle, which describes the maximum set of
permissions required by the bundle. This set of permission is enforced by the OSG i
framework. A bundle can be granted fewer permissions than its local permissions, but
it never gets more permissions.
At first blush, it may seem a little odd to have a bundle define its own permissions,
but the purpose is more for the deployer to audit and analyze a bundle. Bundles
aren't guaranteed to receive the permissions they request and therefore should be
programmed to degrade gracefully when they receive less. As a deployer, though,
local permissions simplify your life because you can easily determine what permissions
are required and which you're willing to give. For example, if the local permissions
request the use of network sockets, it's clear that the bundle has the potential to access
the wider internet. If you decide this is acceptable, you can trust this audit because it's
enforced by the framework at execution time.
What do local permissions look like in practice? The bundle-permission resource is
a file in the bundle's OSGI-INF / directory called permissions.perm. It contains a listing
of all of the bundle's required permissions. As a simple example, let's assume you pro-
vide a bundle that only wants to export a single package, org.foo. This bundle's OSG i-
INF /permissions.perm file is as follows:

# Tuesday, Dec 28 2009
# Foo Bundle
( org.osgi.framework.PackagePermission "org.foo" "IMPORT,EXPORT" )
Lines that start with a # are comments. All other non-empty lines describe required
permissions as encoded PermissionInfo objects. This is simple but effective when it
comes to auditing the security impact of a given bundle.
You've now learned about some powerful tools for defining a security policy; but in
the infamous words of many infomercials, “Wait! There's still more!” In the next sec-
tion, we'll cover the most advanced tool available: the ability to create custom condi-
tions for your security policy. We'll explore why you may want to do this and show you
how to do it by implementing two custom conditions.