Introduction

For 13.10, scopes will not be available in the app store and application confinement will prevent apps from abusing scopes and the scopes architecture. For 14.04 we'd like to have app developers able to deliver scopes via the app store. For us to be able to have scopes deliverable via click packages, we'll need to carefully design the system to support confining scopes.

Scopes create a number of interesting challenges when considering application confinement. There are two overarching issues wrt to scopes.

Issue #1: confinement

• apps - ie, apps can't attack the system (ie, scopes, the dash, etc to ship off data, enumerate things, etc)
• scopes - ie, scopes can't attack the system (ie, the dash, other scopes, user data, etc)

Issue #2: scopes privacy

This is about preventing any user data from leaving the device either by (malicious scopes) shipping off concrete data or by just querying remote sources. The latter is of concern because the query string already exposes private information.

Differentiate between scopes

• Running on Server
  • Smart scopes, by definition, have no privacy issues. Anything that runs on the smart scopes server can only deal in public information because there is no way to get per-user authentication data from the device to the SSS. Any credentials that a scope running on the SSS requires would have to be hard-baked into that scope.
• Running on Device
  • Scope querying remote data, e.g. Google docs: this is fine and doesn't create any security concerns as long as the very same scope does not have access to any other data on the local system. If that would be the case, an malicious scope could send local information to any server.
  • Scope querying local data, e.g. retrieving local music: this is fine as long as the scope does not have direct or indirect access to the internet to send the data. Indirect access means, a scope must not be able to push any data to an app (creating a file in the app container, accessing shared memory etc).

  • Scope querying local and remote data: whether the query is executed exclusively within the scope or a result of scope aggregation doesn't really matter from a security point of view. A scope having access to both local and remote data at the same time is always risky as it allows local data to be uploaded anywhere (target server is never trustworthy). However, there are use cases where this functionality is required e.g. returning somebodies music collection that is stored both locally and on U1. AppArmor doesn't really help here as it could only restrict the data that is read but it cannot restrict/verify where the data is send to. The only solution seems to be to review the source code to ensure that no data is sent off. As this doesn't scale, it's only us and OEMs that can contribute those scopes.

Questions

Q: Scopes by definition only query meaning doing read-only actions. Are there use cases where that is not sufficient?

A: In theory read-only access of the file system is sufficient, however this is not always efficient or fast enough, e.g. when searching local files/music. Creating indexed caches is the answer, but that requires write access to local disk as it's would be inefficient to do the indexing every time the scope is run. [Todo: we could have each scope in one directory, basically following the app confinement?]. However, having a cache is not sufficient if there is not possibility to keep it up to date. So, either the scope itself becomes a permanently running daemon or we allow a scope (package) to spin of daemons.

• <michi>I believe write access is OK as long as we can restrict that to a specific subtree in the file system, exclusive to the scope.</michi>

Q: If a scope wants to aggregate data from both local and remote sources, couldn't the (security) framework only allow to query the smart scope server (SSS) as remote source? The smart scope server would then delegate the query request to the respective scopes running on server.

A: That's not an solution at all as a malicious local scope can include/hide/add local information in the query string itself which is passed unchecked to the scope running on the server.

• <michi>I think the only possible answer here is that, if a scope wants access to both the filesystem (generally, not restricted to its little corner) and access to the network, the scope must be written by Canonical or, possibly, an OEM.</michi>

Q: A:

Outline of a confinement approach

To properly confine scopes and prevent data leaks, I think something along the lines below might work. Please comment!

For remote scopes, we don't really have any security issues. Scopes can do pretty much anything they like, including aggregating from arbitrary other scopes, reading from the file system, and accessing the network. The only sandboxing we'll need is most likely that a scope should be prevented from writing to files owned by another scope. Potentially, we may also want to prevent read access to scope-specific files across scope boundaries.

For local scopes, I think the following will get us closer to a solution:

- A local leaf (non-aggregating) scope can either access the file system (to search for media or the like) or (exclusive or) access the network. A local scope can have its own little corner of the file system (for example, to write caches), but each scope's file system corner is exclusive to the scope (no other scope can read or write it).

- A local aggregating scope must be written by Canonical or an OEM (no exceptions).

- All local scopes must be able to connect to the smart scopes server (and only the smart scopes server). However, a local leaf scope must be prevented from sending anything but statistics and control information to the SSS. (We cannot allow a leaf scope to send queries to a scope on the SSS because a malicious leaf scope could encode information in the query string and potentially funnel that information out via some other scope in the SSS.)

A leaf scope must not follow recommendations from the SSS. (Actually, must be physically prevented from doing that.)

With this, I think we can have leaf scopes (but not aggregating scopes) as click packages without compromising security.