ScopesConfinement

Differences between revisions 33 and 34
Revision 33 as of 2014-02-28 22:17:46
Size: 11825
Editor: jdstrand
Comment:
Revision 34 as of 2014-02-28 22:19:23
Size: 11710
Editor: jdstrand
Comment:
Deletions are marked like this. Additions are marked like this.
Line 19: Line 19:
  * Local scope with network permission querying remote data, e.g. Google docs: no security concerns so long as the scope does not also have access to the filesystem. If filesystem permission was allowed, a malicious scope could send files on the device to any server. A scope querying remote data may query one or more data sources
  * Local scope with network permission querying multiple remote data sources via scope aggregation. Unlike when a scope simply queries multiple data sources itself, when a scope aggregates multiple remote scope queries, there is a security concern because the aggregating scope may obtain private information from other scopes (eg, consider when a legitimate Google docs leaf (non-aggregating) remote scope is configured for authentication at the remote site via the legitimate scope. A malicious aggregating scope could trigger the query for the legitimate Google docs scope and obtain the results, bypassing the intended access restrications of the legitimate scope)
  * Local scope with filesystem permission querying filesystem data, e.g. retrieving local music: no security concerns so long as the scope does not also 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).
  * Local scope with filesystem and network permissions querying local and remote data: this can happen exclusely within the scope or via scope aggregation and because the scope (aggregating or not) has access to both filesystem data and the network, this poses a security concern because filesystem data could be uploaded anywhere (target server is never trustworthy). However, there are legitimate use cases for this functionality, such as showing the user's music collection where music is stored both locally and in the cloud (eg, U1db). Because we cannot sufficiently restrict/verify remote network endpoints, these types of scopes must come from trusted sources and/or be manually reviewed.
  * Local scope querying remote data, e.g. Google docs: no security concerns so long as the scope does not also have access to the filesystem. If filesystem permission was allowed, a malicious scope could send files on the device to any server. A scope querying remote data may query one or more data sources
  * Local scope querying multiple remote data sources via scope aggregation. Unlike when a scope simply queries multiple data sources itself, when a scope aggregates multiple remote scope queries, there is a security concern because the aggregating scope may obtain private information from other scopes (eg, consider when a legitimate Google docs leaf (non-aggregating) remote scope is configured for authentication at the remote site via the legitimate scope. A malicious aggregating scope could trigger the query for the legitimate Google docs scope and obtain the results, bypassing the intended access restrications of the legitimate scope)
  * Local scope querying filesystem data, e.g. retrieving local music: no security concerns so long as the scope does not also 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).
  * Local scope querying local and remote data: this can happen exclusely within the scope or via scope aggregation and because the scope (aggregating or not) has access to both filesystem data and the network, this poses a security concern because filesystem data could be uploaded anywhere (target server is never trustworthy). However, there are legitimate use cases for this functionality, such as showing the user's music collection where music is stored both locally and in the cloud (eg, U1db). Because we cannot sufficiently restrict/verify remote network endpoints, these types of scopes must come from trusted sources and/or be manually reviewed.

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 (aka, 'remote scope')
    • Smart scopes, by definition, have no privacy issues. Anything that runs on the smart scopes server (SSS) 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-coded into that scope. Smart scopes are usually queried by the master scope but any scope may query the SSS.
  • Running on Device (aka, 'local scope')
    • Local scope querying remote data, e.g. Google docs: no security concerns so long as the scope does not also have access to the filesystem. If filesystem permission was allowed, a malicious scope could send files on the device to any server. A scope querying remote data may query one or more data sources
    • Local scope querying multiple remote data sources via scope aggregation. Unlike when a scope simply queries multiple data sources itself, when a scope aggregates multiple remote scope queries, there is a security concern because the aggregating scope may obtain private information from other scopes (eg, consider when a legitimate Google docs leaf (non-aggregating) remote scope is configured for authentication at the remote site via the legitimate scope. A malicious aggregating scope could trigger the query for the legitimate Google docs scope and obtain the results, bypassing the intended access restrications of the legitimate scope)
    • Local scope querying filesystem data, e.g. retrieving local music: no security concerns so long as the scope does not also 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).
    • Local scope querying local and remote data: this can happen exclusely within the scope or via scope aggregation and because the scope (aggregating or not) has access to both filesystem data and the network, this poses a security concern because filesystem data could be uploaded anywhere (target server is never trustworthy). However, there are legitimate use cases for this functionality, such as showing the user's music collection where music is stored both locally and in the cloud (eg, U1db). Because we cannot sufficiently restrict/verify remote network endpoints, these types of scopes must come from trusted sources and/or be manually reviewed.

Questions

Q: Because scopes typically only query for information, is it possible to deny write access entirely?

A: In theory read-only access of the file system is sufficient, however disallowing writes entirely may not always be efficient or performant (e.g. when searching local files/music, will want to create indexed caches because it is very inefficient to do index every time the scope is run).

  • <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 the remote source? The smart scope server would then delegate the query request to the respective scopes running on server.

A: That is not sufficient because a malicious local scope can include/hide/add local information (eg, from the filesystem) 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> <jdstrand>Agreed-- scopes may access filesystem data or the internet, but not both</jdstrand>

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 local scopes have the ability to use the network and access the filesystem. Local scopes that have access to both the network and the filesystem pose a privacy concern and opportunity for data theft. For this specification, scopes that access the network may be referred to as 'scopes with networking permission' and scopes that access the filesystem may be referred to as 'scopes with filesystem permission'.
  • 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

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

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

  • Leaf scopes with filesystem permission 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. Leaf scopes with filesystem permission may be delivered by 3rd party developers via the AppStore

  • Leaf scopes with networking permission 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. Leaf scopes with networking permission 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.leaf-fs-scope-foo/socket
    • ~/.local/share/scopes/com.ubuntu.username.leaf-net-scope-bar/socket
    • ~/.local/share/scopes/unconfined-aggregating-canonical-net-scope/socket
    • ~/.local/share/scopes/unconfined-aggregating-partner-net-scope/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

  • Leaf scopes with filesystem permission (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
  • Leaf scopes with networking permission (untrusted)
    • use the ubuntu-scope-network AppArmor template:

      • no access to files outside of app directory
      • allows networking
      • allows access to location data via trusted helper (ie, cached prompting)
      • 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)

  • Leaf scopes with filesystem and networking permission (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
  • Aggregating scopes with networking permission (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
  • Aggregating scopes with filesystem permission (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
  • Aggregating scopes with filesystem and networking permission (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

  • Leaf scopes with filesystem permission 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)