ScopesConfinement

Differences between revisions 19 and 55 (spanning 36 versions)
Revision 19 as of 2013-11-08 18:00:43
Size: 10200
Editor: jdstrand
Comment:
Revision 55 as of 2014-11-03 15:04:53
Size: 19372
Editor: jdstrand
Comment:
Deletions are marked like this. Additions are marked like this.
Line 15: Line 15:
= 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 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.


=== Outline of a confinement approach ===
= 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 content stored on the device. If local content 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 content stored on the device, 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 data stored on the device and the network, this poses a security concern because local content 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 or helper services) 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 data stored on the device (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 data (that is not their own) stored on the device or the internet, but not both</jdstrand>

'''Q:'''
'''A:'''

= Confinement Implementation =
Line 29: Line 45:
==== Considerations ==== == Considerations ==
Line 31: Line 47:
 * 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  * All local scopes have the ability to use the network and access the content stored on the device via helpers services. Local scopes that have access to both the network and local content 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 stored on the device may be referred to as 'scopes with content permission'.
Line 36: Line 52:
==== 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 ====
== AppStore Policy and Ubuntu Trust model for scopes ==
 * '''''Aggregating scopes with content permission''''' are considered '''''trusted''''', may run without confinement and may access the network or content stored on the device. Aggregating scopes with content permission shall be written either by Canonical or a trusted 3rd party (eg OEM). '''''Aggregating scopes with content permission shall not be delivered by arbitrary 3rd party developers in the !AppStore'''''. Canonical and trusted 3rd parties may deliver aggregating scopes with content permission via the !AppStore.
 * '''''Aggregating scopes with networking permission''''' are considered '''''trusted''''', may run without confinement and may access the network or content stored on the device. 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 content permission''''' are considered '''''untrusted''''', may access content stored on the device via helper services, shall not contact other scopes, shall run under confinement, and shall not access the network. '''''Leaf scopes with content permission may be delivered by 3rd party developers via the !AppStore (jdstrand> once interactions with URL dispatcher are properly handled, see below)'''''
 * '''''Leaf scopes with networking permission''''' are considered '''''untrusted''''', shall not access content stored on the device 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 ==
Line 44: Line 60:
  * ~/.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
  * Public endpoints:
   * /run/user/<effective-uid>/zmq/Registry-*
   * /run/user/<effective-uid>/zmq/com.ubuntu.username.leaf-fs-scope-foo-r
   * /run/user/<effective-uid>/zmq/com.ubuntu.username.leaf-net-scope-bar-r
   * /run/user/<effective-uid>/zmq/unconfined-aggregating-canonical-net-scope-r
   * /run/user/<effective-uid>/zmq/unconfined-aggregating-partner-net-scope-r
   * /run/user/<effective-uid>/zmq/unconfined-aggregating-canonical-scope-r
   * /run/user/<effective-uid>/zmq/unconfined-aggregating-partner-scope-r
  * Private endpoints
   * /run/user/<effective-uid>/zmq/priv/com.ubuntu.username.leaf-fs-scope-foo
   * /run/user/<effective-uid>/zmq/priv/com.ubuntu.username.leaf-fs-scope-foo-*
 In this manner, the master scope can simply look in the zmq/priv directory
Line 51: Line 73:
 * 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)
 * '''NOT AVAILABLE''': Leaf scopes with content permission (untrusted)
  * use the `ubuntu-scope-local-content` !AppArmor template:
   * access to certain non-sensitive files (eg, large parts of the system, 'owner @{HOME}/[^.]*' (essentially), uses private-files-strict abstraction, access to (non-scope) data in ~/.local/share, etc)
Line 56: Line 78:
   * shall allow access to app data from the same click
Line 58: Line 81:
 * Remote leaf scopes (untrusted)   * example click manifest (name in click manifest must match what is registered with the scope-registry and run via the scopes runner):{{{
{
  "description": "Local content scope description",
  "framework": "ubuntu-sdk-14.10-dev1",
  "hooks": {
    "myscope": {
      "scope": "fs-scope",
      "apparmor": "scope-security.json"
    }
  }
  "maintainer": "Some Guy <some.guy@ubuntu.com>",
  "name": "com.ubuntu.developer.username.fs-scope",
  "title": "Some fs scope",
  "version": "0.1"
}
}}}
  * click security manifest (scope-security.json):{{{
{
    "template": "ubuntu-scope-local-content",
    "policy_groups": [],
    "policy_version": 1.2
}
}}}
  * resulting AppArmor policy (example):{{{
APP_PKGNAME="com.ubuntu.developer.username.fs-scope"
APP_VERSION="1.0.0"
profile "com.ubuntu.developer.username.fs-scope_myscope_0.1" {
  #include <abstractions/base>
  #include <abstractions/private-files-strict>
  audit deny network,
  ...
  # Click install directory
  @{CLICK_DIR}/@{APP_PKGNAME}/ r,
  @{CLICK_DIR}/@{APP_PKGNAME}/@{APP_VERSION}/ r,
  @{CLICK_DIR}/@{APP_PKGNAME}/@{APP_VERSION}/** mrklix,

  # Needed by .so scopes
  /usr/lib/@{multiarch}/unity-scopes/scoperunner ixr,

  # leaf scope with content permissions
  owner @{HOME}/.local/share/unity-scopes/leaf-fs/@{APP_PKGNAME}/ r,
  owner @{HOME}/.local/share/unity-scopes/leaf-fs/@{APP_PKGNAME}/** mrwklix,

  # Allow scopes to share data with the app shipped in the same click
  owner @{HOME}/.local/share/@{APP_PKGNAME}/ rw,
  owner @{HOME}/.local/share/@{APP_PKGNAME}/** mrwkl,

  # Public endpoints
  owner /run/user/[0-9]*/zmq/Registry-s rw,
  owner /run/user/[0-9]*/zmq/Registry-p r,
  owner /run/user/[0-9]*/zmq/@{APP_PKGNAME}-r rw,
  owner /run/user/[0-9]*/zmq/c-*-r rw,

  # Private endpoints
  owner /run/user/[0-9]*/zmq/priv/@{APP_PKGNAME} rw,
  owner /run/user/[0-9]*/zmq/priv/@{APP_PKGNAME}-{c,q} rw,

  # Give broad filesystem access...
  / r,
  /**/ r,
  /{media,mnt,opt,srv}/** r, # removable media
  ...
}
}}}

 Currently, leaf scopes with content permission are not available to click scopes due to a problem with information leakage via the URL dispatcher. If/when this issue is resolved, this scope type may be allowed via the click app store.
 * Leaf scopes with networking permission (untrusted)
Line 60: Line 149:
   * no access to files outside of app directory    * no access to files outside of scope-specific directories
Line 62: Line 151:
   * optionally allows access to accounts via trust-helper (ie, cached prompting)
   * may only specify the 'networking' and 'accounts' policy groups (specifically, "location" may not be specified (see below). This is enforced by the click-reviewers-tools.
Line 63: Line 154:
   * shall allow access to app data from the same click
Line 64: Line 156:
 * '''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?

=== 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:'''
  * example click manifest (name in click manifest must match what is registered with the scope-registry and run via the scopes runner):{{{
{
  "description": "Net scope description",
  "framework": "ubuntu-sdk-14.10-dev1",
  "hooks": {
    "myscope": {
      "scope": "net-scope",
      "apparmor": "scope-security.json"
    }
  }
  "maintainer": "Some Guy <some.guy@ubuntu.com>",
  "name": "com.ubuntu.developer.username.net-scope",
  "title": "Some network scope",
  "version": "0.1"
}
}}}
  * example click security manifest (scope-security.json, note the networking policy group is not required for thi scope, but it is harmless to include):{{{
{
    "template": "ubuntu-scope-network",
    "policy_groups": [],
    "policy_version": 1.2
}
}}}
  * resulting AppArmor policy (example):{{{
APP_PKGNAME="com.ubuntu.developer.username.net-scope"
APP_VERSION="1.0.0"
profile "com.ubuntu.developer.username.net-scope_myscope_0.1" {
  #include <abstractions/base>
  #include <abstractions/private-files-strict>
  #include <abstractions/nameservice>
  #include <abstractions/openssl>
  ...
  # Click install directory
  @{CLICK_DIR}/@{APP_PKGNAME}/ r,
  @{CLICK_DIR}/@{APP_PKGNAME}/@{APP_VERSION}/ r,
  @{CLICK_DIR}/@{APP_PKGNAME}/@{APP_VERSION}/** mrklix,

  # Needed by .so scopes
  /usr/lib/@{multiarch}/unity-scopes/scoperunner ixr,

  # leaf scope with network permissions
  owner @{HOME}/.local/share/unity-scopes/leaf-net/@{APP_PKGNAME}/ r,
  owner @{HOME}/.local/share/unity-scopes/leaf-net/@{APP_PKGNAME}/** mrwklix,

  # Allow scopes to share data with the app shipped in the same click
  owner @{HOME}/.local/share/@{APP_PKGNAME}/ rw,
  owner @{HOME}/.local/share/@{APP_PKGNAME}/** mrwkl,

  # Public endpoints
  owner /run/user/[0-9]*/zmq/Registry-s rw,
  owner /run/user/[0-9]*/zmq/Registry-p r,
  owner /run/user/[0-9]*/zmq/@{APP_PKGNAME}-r rw,
  owner /run/user/[0-9]*/zmq/c-*-r rw,

  # Private endpoints
  owner /run/user/[0-9]*/zmq/priv/@{APP_PKGNAME} rw,
  owner /run/user/[0-9]*/zmq/priv/@{APP_PKGNAME}-{c,q} rw,
  ...
}
}}}
 * Leaf scopes with content 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 content 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 content 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
 * Per the scopes team, the first iteration will restrict local scopes to using helpers and block wide access to the user's HOME directory.

== Open design questions ==
 * Unlike apps, scopes' lifecycle is not visible to users so direct access to the location service is not permitted. However, location data may be useful to scopes, so location information is passed to the scope as query parameter, but users will be able to control if location information is sent to scopes at all, to selected scopes or potentially in the future with configurable (ie, obfuscated) location information ("Scopes and location services" email from 2014/06/18)
 * Leaf scopes with content permission shall not follow recommendations from the SSS. How is this enforced, via the proxy?
 * Leaf scopes with content permission currently don't allow access to hidden directories (eg, ~/.local/share), but a scope may be bundled with an app. So long as we don't give access to @{HOME}/.local/share/unity-scopes/**, we should be able to do something like '@{HOME}/.local/share/@{PKGDOMAIN}.*/** r,' (PKGDOMAIN is not currently defined and would have limitations, so wouldn't want to grant 'w')
 * Leaf scopes with content permission are disabled since they may leak private data via URL embedding via the URL dispatcher. Because of this limitation, developers may:
  * use the `ubuntu-scope-network` template and modify their scope to work withinit
  * use the `unconfined` template
  * use the `ubuntu-scope-network` template and specify an additional `read_path` or `write_path` in the security manifest for the files that the scope needs
  '''IMPORTANT''': specifying the `unconfined` template or use of `read_path/write_path` means the scope must come from a trusted source and/or require a manual review
 * Because scopes share application data with apps shipped in the same click, reviewers must be careful if the click package contains any permissions that triggers a manual review (permissions that pass the automatic checks are considered safe). Eg, if the app has wide filesystem permissions but no networking and the scope has networking but no filesystem permissions, then the app can make data from the system available to the scope and so it could send it out over the network.

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 content stored on the device. If local content 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 content stored on the device, 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 data stored on the device and the network, this poses a security concern because local content 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 or helper services) 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 data stored on the device (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 data (that is not their own) stored on the device 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 content stored on the device via helpers services. Local scopes that have access to both the network and local content 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 stored on the device may be referred to as 'scopes with content 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 content permission are considered trusted, may run without confinement and may access the network or content stored on the device. Aggregating scopes with content permission shall be written either by Canonical or a trusted 3rd party (eg OEM). Aggregating scopes with content permission shall not be delivered by arbitrary 3rd party developers in the AppStore. Canonical and trusted 3rd parties may deliver aggregating scopes with content permission via the AppStore.

  • Aggregating scopes with networking permission are considered trusted, may run without confinement and may access the network or content stored on the device. 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 content permission are considered untrusted, may access content stored on the device via helper services, shall not contact other scopes, shall run under confinement, and shall not access the network. Leaf scopes with content permission may be delivered by 3rd party developers via the AppStore (jdstrand> once interactions with URL dispatcher are properly handled, see below)

  • Leaf scopes with networking permission are considered untrusted, shall not access content stored on the device 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):

    • Public endpoints:
      • /run/user/<effective-uid>/zmq/Registry-*

      • /run/user/<effective-uid>/zmq/com.ubuntu.username.leaf-fs-scope-foo-r

      • /run/user/<effective-uid>/zmq/com.ubuntu.username.leaf-net-scope-bar-r

      • /run/user/<effective-uid>/zmq/unconfined-aggregating-canonical-net-scope-r

      • /run/user/<effective-uid>/zmq/unconfined-aggregating-partner-net-scope-r

      • /run/user/<effective-uid>/zmq/unconfined-aggregating-canonical-scope-r

      • /run/user/<effective-uid>/zmq/unconfined-aggregating-partner-scope-r

    • Private endpoints
      • /run/user/<effective-uid>/zmq/priv/com.ubuntu.username.leaf-fs-scope-foo

      • /run/user/<effective-uid>/zmq/priv/com.ubuntu.username.leaf-fs-scope-foo-*

    In this manner, the master scope can simply look in the zmq/priv directory
  • 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

  • NOT AVAILABLE: Leaf scopes with content permission (untrusted)

    • use the ubuntu-scope-local-content AppArmor template:

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

    • shall not follow recommendations from the SSS
    • example click manifest (name in click manifest must match what is registered with the scope-registry and run via the scopes runner):

      {
        "description": "Local content scope description",
        "framework": "ubuntu-sdk-14.10-dev1",
        "hooks": {
          "myscope": {
            "scope": "fs-scope",
            "apparmor": "scope-security.json"
          }
        }
        "maintainer": "Some Guy <some.guy@ubuntu.com>",
        "name": "com.ubuntu.developer.username.fs-scope",
        "title": "Some fs scope",
        "version": "0.1"
      }
    • click security manifest (scope-security.json):

      {
          "template": "ubuntu-scope-local-content",
          "policy_groups": [],
          "policy_version": 1.2
      }
    • resulting AppArmor policy (example):

      APP_PKGNAME="com.ubuntu.developer.username.fs-scope"
      APP_VERSION="1.0.0"
      profile "com.ubuntu.developer.username.fs-scope_myscope_0.1" {
        #include <abstractions/base>
        #include <abstractions/private-files-strict>
        audit deny network,
        ...
        # Click install directory
        @{CLICK_DIR}/@{APP_PKGNAME}/                   r,
        @{CLICK_DIR}/@{APP_PKGNAME}/@{APP_VERSION}/    r,
        @{CLICK_DIR}/@{APP_PKGNAME}/@{APP_VERSION}/**  mrklix,
      
        # Needed by .so scopes
        /usr/lib/@{multiarch}/unity-scopes/scoperunner ixr,
      
        # leaf scope with content permissions
        owner @{HOME}/.local/share/unity-scopes/leaf-fs/@{APP_PKGNAME}/   r,
        owner @{HOME}/.local/share/unity-scopes/leaf-fs/@{APP_PKGNAME}/** mrwklix,
      
        # Allow scopes to share data with the app shipped in the same click
        owner @{HOME}/.local/share/@{APP_PKGNAME}/   rw,
        owner @{HOME}/.local/share/@{APP_PKGNAME}/** mrwkl,
      
        # Public endpoints
        owner /run/user/[0-9]*/zmq/Registry-s                   rw,
        owner /run/user/[0-9]*/zmq/Registry-p                    r,
        owner /run/user/[0-9]*/zmq/@{APP_PKGNAME}-r             rw,
        owner /run/user/[0-9]*/zmq/c-*-r                        rw,
      
        # Private endpoints
        owner /run/user/[0-9]*/zmq/priv/@{APP_PKGNAME}          rw,
        owner /run/user/[0-9]*/zmq/priv/@{APP_PKGNAME}-{c,q}    rw,
      
        # Give broad filesystem access...
        /                         r,
        /**/                      r,
        /{media,mnt,opt,srv}/**   r, # removable media
        ...
      }
    Currently, leaf scopes with content permission are not available to click scopes due to a problem with information leakage via the URL dispatcher. If/when this issue is resolved, this scope type may be allowed via the click app store.
  • Leaf scopes with networking permission (untrusted)
    • use the ubuntu-scope-network AppArmor template:

      • no access to files outside of scope-specific directories
      • allows networking
      • optionally allows access to accounts via trust-helper (ie, cached prompting)
      • may only specify the 'networking' and 'accounts' policy groups (specifically, "location" may not be specified (see below). This is enforced by the click-reviewers-tools.
      • explicitly disallows aggregation
      • shall allow access to app data from the same click
    • 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)

    • example click manifest (name in click manifest must match what is registered with the scope-registry and run via the scopes runner):

      {
        "description": "Net scope description",
        "framework": "ubuntu-sdk-14.10-dev1",
        "hooks": {
          "myscope": {
            "scope": "net-scope",
            "apparmor": "scope-security.json"
          }
        }
        "maintainer": "Some Guy <some.guy@ubuntu.com>",
        "name": "com.ubuntu.developer.username.net-scope",
        "title": "Some network scope",
        "version": "0.1"
      }
    • example click security manifest (scope-security.json, note the networking policy group is not required for thi scope, but it is harmless to include):

      {
          "template": "ubuntu-scope-network",
          "policy_groups": [],
          "policy_version": 1.2
      }
    • resulting AppArmor policy (example):

      APP_PKGNAME="com.ubuntu.developer.username.net-scope"
      APP_VERSION="1.0.0"
      profile "com.ubuntu.developer.username.net-scope_myscope_0.1" {
        #include <abstractions/base>
        #include <abstractions/private-files-strict>
        #include <abstractions/nameservice>
        #include <abstractions/openssl>
        ...
        # Click install directory
        @{CLICK_DIR}/@{APP_PKGNAME}/                   r,
        @{CLICK_DIR}/@{APP_PKGNAME}/@{APP_VERSION}/    r,
        @{CLICK_DIR}/@{APP_PKGNAME}/@{APP_VERSION}/**  mrklix,
      
        # Needed by .so scopes
        /usr/lib/@{multiarch}/unity-scopes/scoperunner ixr,
      
        # leaf scope with network permissions
        owner @{HOME}/.local/share/unity-scopes/leaf-net/@{APP_PKGNAME}/   r,
        owner @{HOME}/.local/share/unity-scopes/leaf-net/@{APP_PKGNAME}/** mrwklix,
      
        # Allow scopes to share data with the app shipped in the same click
        owner @{HOME}/.local/share/@{APP_PKGNAME}/   rw,
        owner @{HOME}/.local/share/@{APP_PKGNAME}/** mrwkl,
      
        # Public endpoints
        owner /run/user/[0-9]*/zmq/Registry-s                   rw,
        owner /run/user/[0-9]*/zmq/Registry-p                    r,
        owner /run/user/[0-9]*/zmq/@{APP_PKGNAME}-r             rw,
        owner /run/user/[0-9]*/zmq/c-*-r                        rw,
      
        # Private endpoints
        owner /run/user/[0-9]*/zmq/priv/@{APP_PKGNAME}          rw,
        owner /run/user/[0-9]*/zmq/priv/@{APP_PKGNAME}-{c,q}    rw,
        ...
      }
  • Leaf scopes with content 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 content 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 content 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
  • Per the scopes team, the first iteration will restrict local scopes to using helpers and block wide access to the user's HOME directory.

Open design questions

  • Unlike apps, scopes' lifecycle is not visible to users so direct access to the location service is not permitted. However, location data may be useful to scopes, so location information is passed to the scope as query parameter, but users will be able to control if location information is sent to scopes at all, to selected scopes or potentially in the future with configurable (ie, obfuscated) location information ("Scopes and location services" email from 2014/06/18)
  • Leaf scopes with content permission shall not follow recommendations from the SSS. How is this enforced, via the proxy?
  • Leaf scopes with content permission currently don't allow access to hidden directories (eg, ~/.local/share), but a scope may be bundled with an app. So long as we don't give access to @{HOME}/.local/share/unity-scopes/**, we should be able to do something like '@{HOME}/.local/share/@{PKGDOMAIN}.*/** r,' (PKGDOMAIN is not currently defined and would have limitations, so wouldn't want to grant 'w')
  • Leaf scopes with content permission are disabled since they may leak private data via URL embedding via the URL dispatcher. Because of this limitation, developers may:
    • use the ubuntu-scope-network template and modify their scope to work withinit

    • use the unconfined template

    • use the ubuntu-scope-network template and specify an additional read_path or write_path in the security manifest for the files that the scope needs IMPORTANT: specifying the unconfined template or use of read_path/write_path means the scope must come from a trusted source and/or require a manual review

  • Because scopes share application data with apps shipped in the same click, reviewers must be careful if the click package contains any permissions that triggers a manual review (permissions that pass the automatic checks are considered safe). Eg, if the app has wide filesystem permissions but no networking and the scope has networking but no filesystem permissions, then the app can make data from the system available to the scope and so it could send it out over the network.

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