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 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: 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.
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.