Jump to: navigation, search

Trusted Bundles

Revision as of 15:25, 11 May 2007 by Tjwatson.us.ibm.com (Talk | contribs) (New page: == Overview == Some usecases have a requirement to enable and disable bundles based on a notion of a trusted bundle. One way to establish trust is to sign a bundle with a trusted certific...)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)


Some usecases have a requirement to enable and disable bundles based on a notion of a trusted bundle. One way to establish trust is to sign a bundle with a trusted certificate. Configuring this usecase with the current signed bundle support is awkward and likely unmanageable.

The Problem

The Equinox Framework (version 3.3) supports signed bundles in the following ways:

  1. Verification of signer certificates. Does basic parsing of the certificates used to sign a bundle and associates the certificates with an installed bundle.
  2. Verification of certificate trust. Determines if a certificate should be trusted. Trust authorities can be registered with the Framework to effect the trust policy.
  3. Verification of content at runtime. Determines if the bundle content has been tampered with at runtime.
  4. Assign Java 2 permissions based on certificates used to sign a bundle. The ConditionalPermissionAdmin service and the BundleSignerCondition can be used to assign bundles permissions when a security manager is used.

Using the signed bundle support a framework could be configured to enable and disable bundles based on a notion of trusted signer certificates. To do this with the current implementation the Framework needs to be started with a security manager. Then the ConditionalPermissionAdmin and BundleSignerCondition can be used to assign AllPermissions to all bundles which are signed by a trusted certificate. Bundles which are not signed by a trusted certificate would not be granted any permissions. The OSGi specification defines ImportPackagePermission and BundlePermission permissions which must be granted to a bundle before they are allowed to access a package or bundle constraint. Bundles which have constraints (i.e. Import-Package, Require-Bundle, Fragment-Host etc.) would only be allowed to resolve if they have the permissions to access their constraints. If a bundle is not resolved then it cannot run code, export packages, contribute to the service registry or the eclipse extension registry etc.

In this case trusted bundles are granted AllPermissions and therefore would be able to resolve. Note that bundles which define no constraints would still be allowed to resolve even if they had no permissions. Using this approach a management agent can implement a policy to grant AllPermissions to only a trusted set of signers, but this approach has the following disadvantages.

  1. Requires a security manager.
    • All bundles must be security aware. This involves defining the correct permissions and implementing the proper doPriv calls to protect clients from the unnecessary permission checks.
    • Running with a security manager impacts performance significantly because of the extra overhead to perform permission checks.
  2. Bundles with no constraints would still be able to resolve. This may be a very small percentage of bundles but could be used to contribute bad extensions to the eclipse extension registry.

Running Eclipse with a security manager is currently not very attractive. Even if the performance was not an issue there are 10000s lines of code that need to be evaluated to security enable all the code in the Eclipse RCP downloads. This would not be a one time effort either. All of the eclipse committers will need to be educated on the issues of writing secure code and would have to maintain security for all new code contributed to Eclipse. This is a good long-term goal, bug can not be achieved in the short-term. Any short-term or mid-term solution should support not running with a security manager.

Bug 153847 has been opened to track a solution to this requirement.