ScopesConfinement

Differences between revisions 6 and 7
Revision 6 as of 2013-08-30 13:15:08
Size: 2870
Editor: strehl-t
Comment:
Revision 7 as of 2013-08-30 13:17:23
Size: 2786
Editor: strehl-t
Comment:
Deletions are marked like this. Additions are marked like this.
Line 15: Line 15:
= Difference of scopes = = Differentiate scopes =
Line 20: Line 20:
- 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.
   * 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.

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

SecurityTeam/Specifications/ScopesConfinement (last edited 2014-11-03 15:04:53 by jdstrand)