Jump to: navigation, search

Trusted Bundles

Revision as of 19:22, 25 November 2007 by Mwflaher.us.ibm.com (Talk | contribs)

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.

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

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

System intent

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.

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

System goal

With the system intent established as increasing the security of the platform, a specific goal is defined to be achieved. When potentially malicious content is defined as the potential avenue to decreasing security, the content is

From our needs statements, we also have the following subsidiary goals:

  • To achieve simplicity and usability in user interaction
  • To maintain consistency and compatibility with Java and OSGi standards
  • To achieve acceptable performance
  • To provide sufficient extensibility mechanisms

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

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

System concept

Specifically, 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.

  • usability and simplicity:
    • Concept of 'trusted signers' is familiar from browsers
    • Level of granularity is appropriately broad at the bundle level
    • Not as complex as full Java2 enablement scenario, for all classes of stakeholders
    • Alert widget and enable/disable flow supports “safe staging” usage
  • Consistency and compatibility
    • Uses standard Jar file format
    • Does not preclude Java2 permission enablement
    • 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
    • Can replace policy with more robust implementation

See the system concept diagram for

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.