Cool OSGi R4 Feature: Practical Security
One of the most interesting innovations in OSGi Release 4 is the security mode. I always had a problem with the Java 2 fine grained security because I failed to see how it could be used in the real world. The extremely fine detail in control that the model enables seems to be in conflict with large deployments. How can an operator define the security scope for each application? The cost of inspecting an application and analyzing its security scope is prohibitively expensive.
This is visible in practice, so far I have never been able to download a practical Java application that did not require All Permission.
In practice, this has meant that practical models reverted to a group based approach; each applications runs on one of a small number of sandboxes. An implementation of this approach is MIDP 2.0. However, the fine grained Permission classes are not very useful for these sandboxes, they seem a costly overkill.
In Release 4 we have added a group model by making the permissions depend on location (with wildcards now!) as well as the bundle signer. Release 4 fully defines the rules how to sign a bundle, something long overdue.
This model allows the operator to define any number of sandboxes and assign a bundle to a sandbox based on signer or location (or even a custom condition). For example, an operator can create a special sandbox for aapplication from a given enterprise. Obviously, this model has the previously mentioned drawback that permissions must be used coarsely because they are shared with all bundles for that enterprise. In practice, this gives most bundles too much power.
In this model the signer (e.g. the enterprise) has only a single choice: the given sandbox. This is often too coarse grained. For example, the enterprise has been given the authority to install bundles. This authority is necessary for only a few applications, definitely not all. If the install permission is part of the sandbox, the signer must give this permission to all its applications. Would it not be nice if the signer could restrict the permissions that individual bundles have?
In Release 4 we have come up with a solution; we splitted the responsibilities to define the security scope between the signer and the developer.
The developers have intricate knowledge of their applications. They are therefore in the right position to define a very tight security scope. The know exactly if they use networking, file systems etc. In Release 4 they can define this scope in a resource that is part of their bundle. These permissions are called the local permissions. The R4 Framework guarantees the bundle is restricted by its local permissions.
Why would a developer restrict itself? The key reason is auditing. The local permissions are a very concise overview of what the bundle is allowed to do when deployed. By inspecting this file, the signer knows precisely what the bundle can do when deployed; there is no need to inspect the bundle's code because the R4 Framework guarantees that the bundle can never get any permission outside the local permissions. For example, if the local permissions contain AllPermission, there is a clear reason to be suspicious of the author.
When a bundle is deployed the Framework will read the local permissions and create a related sandbox. However, this sandbox runs in another sandbox that is defined by the operator. This outer sandbox has permission that are derived by the signer or location and can be shared between many bundles. The operator can change the permissions for the outer sandbox at any time. That is, the operator stays in control at any moment in time.
So R4 will provide a very elegant model to use the powerful, flexible, and fine grained security of Java 2 without requiring a huge staff. It will be interesting to see if this model finally enables deployments that use the expensive Java 2 security in a less than binary mode.
posted by Peter @ Monday, August 15, 2005
