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
- Everything is possible on server as the data there is public anyway, so no limitation which scopes is allowed to aggregate other scopes
- 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 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).
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.
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.