Trusted Bundles

High level overview

The following is a stakeholder needs and high level design document for security related functionality being developed for the Eclipse 3.4 release. We will be building upon the 3.3 work of applying signatures to the bundles that make up the Eclipse platform.

Stakeholders and needs

There are several classes of stakeholders that have different needs regarding a security solution for the Eclipse platform. The exercise of defining a direction for security functionality must begin with the identification of these stakeholder and an evaluation of their needs.

Stakeholder identification

There are several identifiable classes of stakeholders when considering the needs of the Eclipse ecosystem. A list of the identifiable stakeholders follows:

• End-users - People who are users of Eclipse platform based technologies. There are at least two classes:
  • Enterprise - End-users who are using an Eclipse platform application in a large enterprise deployment context
  • Standalone - End-users who are using a unzip-and-run Eclipse installation
• Administrators - People tasked with managing a multi-user installation of an Eclipse platform based application
• Developers - People who code bundles for the Eclipse RCP
• Community - The general Eclipse community, including the Foundation and partner companies

Needs evaluation

Across these stakeholders, there are the following identifiable needs:

• End-users
  • Increased security from potentially malicious active content packaged as OSGi bundles
  • Security from subverted or misdirected administration (E)
  • Accommodation of a potentially low level of security competency
  • Usability and simplicity in setting and maintaining a secure configuration
  • Acceptable performance while using the Eclipse platform with security enabled

• Administrators
  • Increased security from potentially malicious active content packaged as OSGi bundles
  • Dynamicity of administration to deal with active threats
  • Simplicity of administration for a deployment wide configuration
  • Extensibility to contribute alternative implementations of security services

• Developers
  • Consistency with existing Java deployment packaging formats
  • Compatibility with existing and upcoming Java and OSGi security technologies
  • Extensibility to contribute alternate implementations of security services

• Community
  • A solid reputation as a platform which has security in mind for its users and member companies

Value identification

Value diagram

Given these stakeholders and needs, the primary intent of the solution can be defined as “To increase the security of the Eclipse platform”. This addresses the most fundamental needs of the most important stakeholders. The beneficiaries of the solution will be Eclipse users, administrators and community members – such as member companies and the foundation itself. The operand – which is the object of the value related change – is the Eclipse platform itself, and the value related attribute is security. In this case the transformation will be increasing.

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

Solution THOUGHTS

Design with below goals in mind

1. RCP app can be configured such as untrusted bundles will be prevented from loading/resolving.
2. Provide a point where code can plug in custom load time policy handler
3. Dynamically allow bundles to be disable/enable at runtime
4. Allowing a load time policy to be configured in a way such that alert pop up will come up if signed bundle are not trusted or classes are being tampered at runtime.
5. Honors the policy state changes at runtime
6. Changeing load time policy is possible through some config UI...

Comparison of two verification approaches 

Installed -> Resolved approach

Prevent the bundle from entering the RESOLVED state if it is not signed by a "good" or "trusted" signer. This way no code could be run or from the non-trusted bundle. One disadvantage with this approach is that ALL the bundles will go through the parsing and checking of certs part that is very expensive. One way to mitigate the problem is by having some caching of certificate parsing, however, it will get tricker when if bundles are signed w/ timestamps.

Resolved -> Active approach

Checking the trust bundles when they go from resolved to active state. This approach does not have parsing ALL bundles part as Installed->Resolved approach. However, this approach has below problems:

1. Packages can be exported/imported
2. Code can be executed from the bundle (unless the bundle has a lazy activation policy). Remember the BundleActivator is only one entry execution entry point for a bundle. Any package exported from the bundle can provide execution entry points which other bundles can call.
3. The bundle can contribute extension points and extensions to the extension registry.

We will take the Installed -> Resolved approach for our prototypes. It will leverage lots of exiting support of signed bundle in Eclipse 3.3. A user will be able to configure the load time security policy though a property file.

User Experiences 

Verifying the bundles that changes the state from Installed to Resolved will not be able to display a warning dialog to the user if the bundles are not trusted according to the load time security policy. Therefore, the bundles that were not resolved due to security reason will be 'held' in memory and displayed to the user when the UI is available.

An alternative is port a trimmed down version of SWT into the load time security bundle or fragment. However, this would require big effort to do so.

Load time verification 

The load time security involves three basic steps

1. Parsing the certificate from the bundles
2. Validating the certificates
3. Making sure resources/bundles are not tampered

In order to mitigate the performance hit of this feature, the above steps will be done at different stage. For example, step 1 and step 2 will be done at the Install Time. Step 3 will execute as resources/classes are loaded from the bundle.

Install bundles 

When bundles are installed, the certificates that are used to signed bundles are parsed at installed time and cached for later use. Additionally, the result of validating certificates and whether the certificates are valid w/ timestamps, valid w/o timestamps, or invalid.

Load time security policy 

The load time security policy is configurable through some properties. The policy will be something like this

• Unsigned (Allow, deny, prompt)
• Expired Certs (Allow, deny, prompt)
• Signed w/ trusted signers ( passes by default)
• Signed w/ untrusted signers (Allow, deny, prompt)
• Tampered contents (Fail by default)