Differences between revisions 24 and 25
Revision 24 as of 2013-11-11 01:59:22
Size: 11463
Editor: michihenning
Revision 25 as of 2013-11-11 02:20:41
Size: 11594
Editor: michihenning
Deletions are marked like this. Additions are marked like this.
Line 72: Line 72:

<michi>I think we need a description for a local leaf scope with network access (but without filesystem access) here?</michi>


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.


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.


  • 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


  • 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

<michi>I think we need a description for a local leaf scope with network access (but without filesystem access) here?</michi>

  • 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?)

        • <michi>A remote aggregating scope cannot access a local leaf scope because the device has no endpoints that could respond to remote queries, so I think this is a non-issue. A remote aggregating scope can aggregate from a remote leaf scope all it likes because a remote leaf scope cannot provide private information. The only thing that could be leaked is the search query itself, but I don't think this is not an issue because there is no way to tie a query to a particular user.</michi>

    • 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?

    <jdstrand>Idea: use rigid directory hierarchy something like local leaf scopes under ~/local/share/scopes/leaf-local/..., remote leaf scopes under ~/local/share/scopes/leaf-remote/..., local aggregating scopes under ~/local/share/scopes/aggregating-local/... and remote aggregating scopes under ~/local/share/scopes/aggregating-remote/.... We could then adjust AppArmor policy for leaf scopes to deny ~/local/share/scopes/aggregating-* and AppArmor policy for remote aggregating scopes to deny ~/local/share/scopes/*-local. The trick would be making sure that developers use the correct directory (my idea could be simplified, but I think something like this might work)</jdstrand>

    • <michi>I don't think this can ever happen because a local scope on the device has no remotely accessible endpoint.</michi>

  • 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)