TrustStoreAndSessions

Trust Store & Trust Sessions

Personal computing devices are becoming an integral part of our daily life. For that, they contain a multitude of personal information. Users trust the device and with that, the operating system to ensure that any personal information is protected from being abused by remote or device-local entities (apps, other users, etc.). One of the central tasks then is to distinguish between valid accesses to from abusive use of personal information.

The Ubuntu security model can be summarized as follows:

  • Users are confined to their personal account
  • Applications are confined
  • Applications can only escape the confinement sandbox via services that are provided by the system. Ultimately, these services inherit the property of being trusted by the user from the system itself.

The services need to be classified further though. Some of the services provide access to resources and functionality that are considered abusive in nature and any access to them has to be explicitly ack'd and trusted by the user. The required user interaction is implemented by a so-called "trust prompt". Only if the user explicitly acknowledges a trust request, the service grants access to the requested resource. Any service executing this security/trust prompting is called a "trusted helper".

Persisting Trust Requests

With the explicit trust prompting in place, the system makes the assumption that user answers to trust queries remain valid until otherwise told. With that, the trusted helpers can persist answers on trust prompts in a designated central store (the so-called trust store). It contains a database of per-app/per-user trust requests, including the user's answers and a timestamp. The trust store is only accessible by trusted helpers for their specific namespace, and only a very limited set of apps do have global read/write access to the store, e.g., the system settings app. align="middle"

Trusted Prompt Session

According to the description given before, three participants of a trust prompt session can be identified:

  1. The application requesting access to a resource via a trusted helper.
  2. The trusted helper itself
  3. A trust prompt provider

Please note that (2.) and (3.) could refer to the same component. As prompting the user is obviously user visible and requires user interaction, Mir is involved in the trust prompt session, too.

The main purpose of a trusted prompt session (TPS) then is to tie together the three components mentioned before, both in terms of presenting the final prompt to the user and in terms of lifecycle/focus mgmt. (from a shell's perspective). In this respect, a temporary, virtual app is introduced that spans across all three components:

align="middle"

From a lifetime perspective, the TPS ends whenever the TPP or its surface is dismissed. Similarly, if the session is terminated for any other reason, the TPP and its surface are dismissed, too. The app cannot exercise any sort of control in this scenario and is not even guaranteed to run.

Only after the trust session has ended, control is transferred back to the app. More to this, while a TPS is active, focus mgmt. treats the session as atomic and prevents the app from being refocused separately.

Trusted Interaction Session

Extending the ideas presented before, we could apply the same principles to interaction sessions that span multiple processes. The most obvious example is interaction with input methods, or OSKs specifically. The following components are part of a trusted interaction session:

  • An application and a specific surface
  • A session-level service providing input methods
  • Potentially system chrome

Please note that (2.) and (3.) could again refer to the same component.

The main purpose of a trusted interaction session (TPS) then is to tie together the three components mentioned before, both in terms of presenting the final UI to the user and in terms of lifecycle/focus mgmt. (from a shell's perspective). In this respect, again a temporary, virtual app is introduced that spans across all three components.

From a lifetime perspective, the TIS inherits the properties of the TPS.

Use cases

Here's a collection of specific use-cases, which the TPS should be able to support.

Online Accounts

For an introduction, please refer to the design document. There are mainly two use cases for trusted sessions in Online accounts.

Opening Online Accounts from the System Settings

Given that the Online Accounts UI is provided by its own D-Bus service (online-accounts-ui), they way that it's currently opened from the System Settings is as follows: Online Accounts installs a simple system-settings plugin, which provides the Online Accounts icon, and makes a D-Bus call to online-accounts-ui when this icon is clicked.

The expected result, is that the Online Accounts UI opens on top of the System Settings window, as if it were a sub-window of it.

Requesting access from an application

In the simplest case, we have the client application talking to the Online Accounts service, which is the trusted helper and lives in a separate process. The Online Accounts service will popup a dialog on top of the client application, and the dialog contains up to three choices:

  1. Grant the application access to an existing account (with a combobox to select the account)
  2. Deny the request
  3. Grant the application access to a new account (to be created as soon as this choice is selected)

Of course, choice 1 is not given if no account exists. While the first two choices will cause the immediate dismissal of the dialog (and consequently the end of the TPS), the third choice will initiate the creation of a new account, and this requires a full UI in order to complete. The contents of the UI come from account plugins: in the case of OAuth authentications, this will be a web view; in the case of UbuntuOne this is a handful of QML pages which guide the user to the creation of the U1 account, and in the generic case it can just be any QML-based UI. Given that we need to give the ability to third-party developers to ship their own account plugins as click packages, we are faces with the problem that these plugins could contain malicious or buggy code, which we don't want to run inside the Online Accounts trusted helper. For this reason, we will be performing the account creation (that is, we'll be running the provider-specific account plugin) in a separate process.

This means that if we will have three processes involved in the TPS: the client application, the Online Accounts service (with a popup dialog) and the account plugin (with a page).

Security/TrustStoreAndSessions (last edited 2014-01-16 18:34:30 by ken-vandine)