Difference between revisions of "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