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.

Difference of scopes

• Running on Server
  • Everything is possible on server as the data there is public anyway, so no limitation which scopes is allowed to aggregate other scopes

- Device

• a) 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.
  b) scope querying local data, e.g. retrieving local music: this is find 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).
  c) 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.