ScopesConfinement

Differences between revisions 18 and 21 (spanning 3 versions)
Revision 18 as of 2013-11-08 17:58:57
Size: 10193
Editor: jdstrand
Comment:
Revision 21 as of 2013-11-08 18:14:43
Size: 10148
Editor: jdstrand
Comment:
Deletions are marked like this. Additions are marked like this.
Line 15: Line 15:
= Differentiate between scopes = = Understanding different 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.
Line 17: Line 23:
   * 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.
=== Questions ===
Line 20: Line 25:
   * 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.
'''Q:''' Scopes by definition only query meaning doing read-only actions. Are there use cases where that is not sufficient?
Line 25: Line 27:
'''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>
 <jdstrand>!AppArmor confinement will provide rw access to a scope-specific path, likely under ~/.local/share somewhere</jdstrand>
Line 26: Line 31:
=== Outline of a confinement approach === '''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:'''

= Confinement Implementation =
Line 29: Line 43:
==== Considerations ==== == Considerations ==
Line 36: Line 50:
==== AppStore Policy and Ubuntu Trust model for scopes ====
 * Local aggregating scopes are considered trusted, may run without confinement and may access the network or the local filesystem. Local aggregating scopes shall be written either by Canonical or a trusted 3rd party (eg OEM). Local aggregating scopes shall not be delivered by arbitrary 3rd party developers in the AppStore. Canonical and trusted 3rd parties may deliver local aggregating scopes via the store
== AppStore Policy and Ubuntu Trust model for scopes ==
 * Local aggregating scopes are considered trusted, may run without confinement and may access the network or the local filesystem. Local aggregating scopes shall be written either by Canonical or a trusted 3rd party (eg OEM). Local aggregating scopes shall not be delivered by arbitrary 3rd party developers in the !AppStore. Canonical and trusted 3rd parties may deliver local aggregating scopes via the !AppStore
Line 39: Line 53:
 * Local leaf scopes are considered untrusted, may access portions of the local filesystem, shall not contact other scopes, shall run under confinement, and shall not access the network. Local leaf scopes may be delivered by 3rd party developers via the AppStore
 * Remote leaf scopes are considered untrusted, shall not access the local filesystem beyond their application-specific directories, shall not contact other scopes, shall run under confinement, and may access the network. Remote leaf scopes may delivered by 3rd party developers via the AppStore
 * Local leaf scopes are considered untrusted, may access portions of the local filesystem, shall not contact other scopes, shall run under confinement, and shall not access the network. Local leaf scopes may be delivered by 3rd party developers via the !AppStore
 * Remote leaf scopes are considered untrusted, shall not access the local filesystem beyond their application-specific directories, shall not contact other scopes, shall run under confinement, and may access the network. Remote leaf scopes may delivered by 3rd party developers via the !AppStore
Line 42: Line 56:
==== Design ==== == Design ==
Line 49: Line 63:
  In this manner, the master scope can simply look in ~/.local/share/scopes/*/socket* for the endpoints  In this manner, the master scope can simply look in ~/.local/share/scopes/*/socket* for the endpoints
Line 75: Line 89:
==== Open design questions ==== == Open design questions ==
Line 78: Line 92:

=== 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>
 <jdstrand>!AppArmor confinement will provide rw access to a scope-specific path, likely under ~/.local/share somewhere</jdstrand>

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

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.

Understanding different 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> <jdstrand>AppArmor confinement will provide rw access to a scope-specific path, likely under ~/.local/share somewhere</jdstrand>

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:

Confinement Implementation

Based on various discussions the scopes and security teams have come up with the following approach that mixes technology/design, AppArmor integration and AppStore processes/policy.

Considerations

  • All scopes must be allowed to talk to the smart scopes server (SSS)
  • All scopes have the ability to use the network and access the filesystem. Scopes that have access to both the network and the local filesystem pose a privacy concern and opportunity for data theft
  • Leaf scopes are data sources that are aggregated by other scopes. By definition, leaf scopes do not request data from other scopes
  • Aggregating scopes may request data from arbitrary other scopes
  • The scopes design as implemented in 13.10+ allows for individually turning off scopes as well as turning off internet searches globally for scopes. When scopes are turned off, they are never called by the master scope and therefore pose no risk and address privacy concerns

AppStore Policy and Ubuntu Trust model for scopes

  • Local aggregating scopes are considered trusted, may run without confinement and may access the network or the local filesystem. Local aggregating scopes shall be written either by Canonical or a trusted 3rd party (eg OEM). Local aggregating scopes shall not be delivered by arbitrary 3rd party developers in the AppStore. Canonical and trusted 3rd parties may deliver local aggregating scopes via the AppStore

  • TBD Remote aggregating scopes shall use only the internet and other network scopes as data sources. Remote aggregating scopes shall not have access to the filesystem beyond their application-specific directories

  • Local leaf scopes are considered untrusted, may access portions of the local filesystem, shall not contact other scopes, shall run under confinement, and shall not access the network. Local leaf scopes may be delivered by 3rd party developers via the AppStore

  • Remote leaf scopes are considered untrusted, shall not access the local filesystem beyond their application-specific directories, shall not contact other scopes, shall run under confinement, and may access the network. Remote leaf scopes may delivered by 3rd party developers via the AppStore

Design

  • All scopes provide endpoints in known locations. Eg (actual path subject to change-- the point is, the path is scope-specific such that AppArmor policy can enforce access):

    • ~/.local/share/scopes/com.ubuntu.username.local-leaf-scope-foo/socket
    • ~/.local/share/scopes/com.ubuntu.username.remote-leaf-scope-bar/socket
    • ~/.local/share/scopes/com.ubuntu.username.remote-aggregating-scope-baz/socket
    • ~/.local/share/scopes/unconfined-aggregating-canonical-scope/socket
    • ~/.local/share/scopes/unconfined-aggregating-partner-scope/socket
    In this manner, the master scope can simply look in ~/.local/share/scopes/*/socket* for the endpoints
  • Implement scopes-proxy to run on the system to communicate with SSS. Scopes connect to the scopes-proxy via a UNIX domain socket for their SSS communication. scopes-proxy can be hardened and confined with AppArmor system profile. It can filter, perform input validation, and control network destination. This also is more efficient because fewer remote connections to the SSS are required

  • Local leaf scopes (untrusted)
    • use the ubuntu-scope-filesystem AppArmor template:

      • access to certain non-sensitive files (eg, large parts of the system, 'owner @{HOME}/[^.]*', uses private-files-strict abstraction, etc)
      • explicitly disallows networking
      • explicitly disallows aggregation
    • communicates to SSS via a scopes-proxy using a UNIX domain socket allowed by AppArmor policy

    • shall not follow recommendations from the SSS
  • Remote leaf scopes (untrusted)
    • use the ubuntu-scope-network AppArmor template:

      • no access to files outside of app directory
      • allows networking
      • explicitly disallows aggregation
    • may communicate to SSS via a scopes-proxy using a UNIX domain socket allowed by AppArmor policy (this cannot be enforced but well-behaved scopes may want to do this)

  • TBD Remote aggregating scopes (untrusted)

    • use the ubuntu-aggregating-scope-network AppArmor template:

      • no access to files outside of application-specific directories
      • allows networking
      • explicitly disallows aggregation of local leaf and aggregating scopes (Question: how can this be enforced?)

    • may communicate to SSS via a scopes-proxy using a UNIX domain socket allowed by AppArmor policy (this cannot be enforced but well-behaved scopes may want to do this)

  • Local aggregating scopes (trusted)
    • may run without an AppArmor profile or use the unconfined AppArmor template if delivered as deb

    • run unconfined using the unconfined AppArmor template if delivered as click

    • may follow recommendations from the SSS

Open design questions

  • If a remote aggregating scope is able to contact arbitrary other network scopes (ie, non-filesystem scopes), how do we enforce that only network scopes are contacted? In other words, how do we prevent a remote aggregating scope from contacting a local aggregating scope or a local leaf scope?
  • Local leaf scopes shall not follow recommendations from the SSS. How is this enforced, via the proxy?

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