Jump to: navigation, search

Difference between revisions of "Trusted Bundles"

 
(11 intermediate revisions by 2 users not shown)
Line 1: Line 1:
== Overview ==
+
== High level 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 certificate. Configuring this usecase with the current signed bundle support is awkward and likely unmanageable.
+
The following is a stakeholder needs and high level design document for 'Trusted Bundles' - 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.
  
== The Problem ==
+
[[Image:01_value_identification.jpg|thumb|Value Identification: Evaluating needs and defining intent|350 px]]
The Equinox Framework (version 3.3) supports signed bundles in the following ways:
+
[[Image:02_process_definition.jpg|thumb|Goal Definition: Transforming intent into a specific goal|350 px]]
 +
[[Image:03_system_architecture.jpg|thumb|System Concept: Extending goals to a system concept|350 px]]
 +
[[Image:04_component_architecture.jpg|thumb|Component Architecture: subsystems and bundles|350 px]]
  
# Verification of signer certificates.  Does basic parsing of the certificates used to sign a bundle and associates the certificates with an installed bundle.
+
== Stakeholders and needs ==
# Verification of certificate trust.  Determines if a certificate should be trusted.  Trust authorities can be registered with the Framework to effect the trust policy.
+
# Verification of content at runtime.  Determines if the bundle content has been tampered with at runtime.
+
# 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.
+
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 ===
  
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.
+
There are several identifiable classes of stakeholders when considering the needs of the Eclipse ecosystem. A list of the identifiable stakeholders follows:
  
# Requires a security manager.
+
*'''End-users''' - People who are users of Eclipse platform based technologies. There are at least two classes:
#* 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.
+
**'''Enterprise''' - End-users who are using an Eclipse platform application in a large enterprise deployment context
#* Running with a security manager impacts performance significantly because of the extra overhead to perform permission checks.
+
**'''Standalone''' - End-users who are using a unzip-and-run Eclipse installation
# 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.
+
*'''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
  
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.
+
=== Needs evaluation ===
  
[https://bugs.eclipse.org/bugs/show_bug.cgi?id=153847 Bug 153847] has been opened to track a solution to this requirement.
+
Across these stakeholders, there are the following identifiable needs:
  
== Solution THOUGHTS ==
+
*'''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
  
There are currently two solution thoughts for enabling the loadtime security feature.
+
*'''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
  
Installed -> Resolved approach
+
*'''Community'''
 +
**A solid reputation as a platform which has security in mind for its users and member companies
  
 +
== System intent ==
  
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.
+
Given these defined stakeholders and needs, the primary intent of the solution can be defined as:
  
Resolved -> Active approach
+
To increase the security of the Eclipse platform
  
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:
+
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.
  
# Packages can be exported/imported
+
See the [http://wiki.eclipse.org/Image:01_value_identification.jpg system intent diagram] which details stakeholders, needs and defines the system intent.
# 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.
+
# The bundle can contribute extension points and extensions to the extension registry.
+
  
[[Category:Equinox|Category:Security|Trusted Bundles]]
+
== System goal ==
 +
 
 +
With the system intent established as increasing the security of the platform, a specific goal which will meet that intent must be defined. If malicious content is defined as the avenue to decreasing security, then restricting that malicious content is a way to increase security. The overall system goal is thus defined as:
 +
 
 +
by restricting active content
 +
 
 +
The specific process of restricting breaks down into several constituent processes:
 +
 
 +
*<u>Identifying</u> active content as it is installed into the system
 +
*<u>Enforcing</u> the system policy given identified content
 +
*<u>Alerting</u> the user when the system encounters unknown content
 +
*<u>Managing</u> the configuration of the system with respect to known content
 +
*<u>Extending</u> the system with additional mechanisms for identification and enforcement
 +
 
 +
From our needs statements, we also have the following <b><u>subsidiary goals</u></b> that must be addressed by the solution:
 +
 
 +
*Achieving simplicity and usability in user interaction
 +
*Maintaining consistency and compatibility with Java and OSGi standards
 +
*Achieving acceptable performance
 +
*Providing sufficient extensibility mechanisms
 +
 
 +
See the [http://wiki.eclipse.org/Image:02_process_definition.jpg system goal diagram] which specializes the intent into a specific system goal.
 +
 
 +
== System concept ==
 +
 
 +
The proposed concept takes advantage of the existing functionality of OSGi with respect to signed bundle content and extends it with a model that will enforce constraints on the integrity of the content and the identity of the content signer as bundles are loaded into the system. Specifically, the concept:
 +
 
 +
using a bundle-signer based security system at load time
 +
 
 +
The concept uses the cryptographic formats used by Jar file format for verifying the integrity of signed bundles. Authenticating the signers will be enabled through standard chains of X.509 certificates. This standard signature and certificate format will be joined with the lifecycle of the OSGi runtime, allowing the ability to enable or disable bundles based on the content integrity and signer authenticity.
 +
 
 +
An evaluation of the concept with respect to secondary needs is required to assess the appropriateness of the solution:
 +
 
 +
*<b>Usability and simplicity</b>
 +
**Concept of 'signers' and 'trust' is familiar from secured browser connections (SSL) and signed email (S/MIME)
 +
**Level of granularity is appropriately broad at the bundle level, instead of at the level of classes and resources
 +
**Not as complex as full Java2 enablement scenario, for all classes of stakeholders (users, developers and administrators)
 +
**Alert widget and enable/disable flow could support “safe staging” style of user interaction: http://www.andrewpatrick.ca/CHI2003/HCISEC/hcisec-workshop-whitten.pdf
 +
 
 +
*<b>Consistency and compatibility</b>
 +
**Uses standard Jar file format, including Jar signatures: http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html#Signed%20JAR%20File
 +
**Does not preclude Java2 permission enablement, subsystems required for this solution are a subset of those required to enable Java2 permission-based security
 +
**Potentially simplifies Java2 permission story: Trust, expiration, usage, etc can be dealt with early in bundle lifecycle
 +
 
 +
*<b>Performance</b>
 +
**Not yet measured, potential impact of cryptographic operations can be mitigated by sensible and secure caching
 +
 
 +
*<b>Extensibility</b>
 +
**Can augment trust with additional engines (centralized, replicated, hardware-based, etc.)
 +
**Can replace policy with more robust implementation (supporting key-usage, whitelists/blacklists, revocation, etc)
 +
 
 +
See the [http://wiki.eclipse.org/Image:03_system_architecture.jpg system concept diagram] which describes the specific process and decomposed it into constituent processes.
 +
 
 +
== Level 1 decomposition ==
 +
 
 +
The <b><u>authentication subsystem</u></b> is responsible for <u>identifying</u> content; specifically it performs the function of <u>verifying</u> signed content, and <u>authenticating</u> trusted signers. The subsystem is responsible for processing bundles as they are loaded from the filesystem into the OSGI runtime. There are two engines implemented by the authentication subsystem, the verification engine and the authentication engine. The verification engine exposes an API for inspecting the details of a piece of signed content. The verification engine uses the authentication engine to establish the authenticity of a signer by verifying the certificate chain presented alongside the signed content.
 +
 
 +
The <b><u>authorization subsystem</u></b> is responsible for <u>enforcing</u> a policy based on a piece of signed content. Specifically, it does this by <u>authorizing</u> the bundle to load based on its authentication status and a defined policy. If the bundle is not authorized, then it is placed into the disabled state as supported by Equinox. In this state, the bundle will not be activated, nor will it contribute services or Eclipse extensions into the system. If it is authorized, then the bundle is allowed to load as normal.
 +
 
 +
The <b><u>alerts subsystem</u></b> is responsible for <u>alerting</u> the user when unknown or potentially malicious content is encountered. It monitors when bundles are disabled by the authorization subsystem and supports <u>notifying</u> the user via a notification widget on the status line. When there are no problems in the system, a green shield will be displayed, meaning that the system is running in compliance with the defined authorization policy. If a bundle is disabled due to an authorization failure, the widget will throb a yellow or red shield, depending on the severity of the situation. The user clicks on this widget to invoke the management subsystem, where they can deal with the situation in a manner consistent with the concept of “safe staging”.
 +
 
 +
The <b><u>management subsystem</u></b> is responsible for <u>managing</u> the configuration of the system. The particular functions that it supports include <u>setting</u> the launch parameters required to enable the system, <u>adding</u> and <u>removing</u> trusted signers to the installed trust engines, and <u>editing</u> the parameters of the current authorization policy.
 +
 
 +
The <b><u>extension mechanisms</u></b> support deployers and developers in <u>extending</u> the system with additional and alternate implementations of certain services. Specifically, the system allows for the installation of additional trust engines for authorizing content, for the installation and specification of alternate policy engines, and for the contribution of alternate user interfaces for managing enablement, trust and policy.
 +
 
 +
== Level 2 subsystem decompositions ==
 +
<i>Coming soon</i>
 +
 
 +
 
 +
[[Category:Equinox]]
 +
[[Category:Security|Trusted Bundles]]

Latest revision as of 18:54, 9 January 2008

High level overview

The following is a stakeholder needs and high level design document for 'Trusted Bundles' - 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.

Value Identification: Evaluating needs and defining intent
Goal Definition: Transforming intent into a specific goal
System Concept: Extending goals to a system concept
Component Architecture: subsystems and bundles

Stakeholders and needs

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

System intent

Given these defined 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.

See the system intent diagram which details stakeholders, needs and defines the system intent.

System goal

With the system intent established as increasing the security of the platform, a specific goal which will meet that intent must be defined. If malicious content is defined as the avenue to decreasing security, then restricting that malicious content is a way to increase security. The overall system goal is thus defined as:

by restricting active content

The specific process of restricting breaks down into several constituent processes:

  • Identifying active content as it is installed into the system
  • Enforcing the system policy given identified content
  • Alerting the user when the system encounters unknown content
  • Managing the configuration of the system with respect to known content
  • Extending the system with additional mechanisms for identification and enforcement

From our needs statements, we also have the following subsidiary goals that must be addressed by the solution:

  • Achieving simplicity and usability in user interaction
  • Maintaining consistency and compatibility with Java and OSGi standards
  • Achieving acceptable performance
  • Providing sufficient extensibility mechanisms

See the system goal diagram which specializes the intent into a specific system goal.

System concept

The proposed concept takes advantage of the existing functionality of OSGi with respect to signed bundle content and extends it with a model that will enforce constraints on the integrity of the content and the identity of the content signer as bundles are loaded into the system. Specifically, the concept:

using a bundle-signer based security system at load time

The concept uses the cryptographic formats used by Jar file format for verifying the integrity of signed bundles. Authenticating the signers will be enabled through standard chains of X.509 certificates. This standard signature and certificate format will be joined with the lifecycle of the OSGi runtime, allowing the ability to enable or disable bundles based on the content integrity and signer authenticity.

An evaluation of the concept with respect to secondary needs is required to assess the appropriateness of the solution:

  • Usability and simplicity
    • Concept of 'signers' and 'trust' is familiar from secured browser connections (SSL) and signed email (S/MIME)
    • Level of granularity is appropriately broad at the bundle level, instead of at the level of classes and resources
    • Not as complex as full Java2 enablement scenario, for all classes of stakeholders (users, developers and administrators)
    • Alert widget and enable/disable flow could support “safe staging” style of user interaction: http://www.andrewpatrick.ca/CHI2003/HCISEC/hcisec-workshop-whitten.pdf
  • Consistency and compatibility
    • Uses standard Jar file format, including Jar signatures: http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html#Signed%20JAR%20File
    • Does not preclude Java2 permission enablement, subsystems required for this solution are a subset of those required to enable Java2 permission-based security
    • Potentially simplifies Java2 permission story: Trust, expiration, usage, etc can be dealt with early in bundle lifecycle
  • Performance
    • Not yet measured, potential impact of cryptographic operations can be mitigated by sensible and secure caching
  • Extensibility
    • Can augment trust with additional engines (centralized, replicated, hardware-based, etc.)
    • Can replace policy with more robust implementation (supporting key-usage, whitelists/blacklists, revocation, etc)

See the system concept diagram which describes the specific process and decomposed it into constituent processes.

Level 1 decomposition

The authentication subsystem is responsible for identifying content; specifically it performs the function of verifying signed content, and authenticating trusted signers. The subsystem is responsible for processing bundles as they are loaded from the filesystem into the OSGI runtime. There are two engines implemented by the authentication subsystem, the verification engine and the authentication engine. The verification engine exposes an API for inspecting the details of a piece of signed content. The verification engine uses the authentication engine to establish the authenticity of a signer by verifying the certificate chain presented alongside the signed content.

The authorization subsystem is responsible for enforcing a policy based on a piece of signed content. Specifically, it does this by authorizing the bundle to load based on its authentication status and a defined policy. If the bundle is not authorized, then it is placed into the disabled state as supported by Equinox. In this state, the bundle will not be activated, nor will it contribute services or Eclipse extensions into the system. If it is authorized, then the bundle is allowed to load as normal.

The alerts subsystem is responsible for alerting the user when unknown or potentially malicious content is encountered. It monitors when bundles are disabled by the authorization subsystem and supports notifying the user via a notification widget on the status line. When there are no problems in the system, a green shield will be displayed, meaning that the system is running in compliance with the defined authorization policy. If a bundle is disabled due to an authorization failure, the widget will throb a yellow or red shield, depending on the severity of the situation. The user clicks on this widget to invoke the management subsystem, where they can deal with the situation in a manner consistent with the concept of “safe staging”.

The management subsystem is responsible for managing the configuration of the system. The particular functions that it supports include setting the launch parameters required to enable the system, adding and removing trusted signers to the installed trust engines, and editing the parameters of the current authorization policy.

The extension mechanisms support deployers and developers in extending the system with additional and alternate implementations of certain services. Specifically, the system allows for the installation of additional trust engines for authorizing content, for the installation and specification of alternate policy engines, and for the contribution of alternate user interfaces for managing enablement, trust and policy.

Level 2 subsystem decompositions

Coming soon