Scopes and the app store in 14.04

[Jamie Strandboge]

This email is a long time coming-- we decided first to discuss the issues on the
mailing list to better understand the problem space and then have a UDS
discussion next time.

For 13.10, scopes will not be available in the app store and application
confinement[1] 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)

To increase scopes development velocity, the scopes team will be using ICE
(zeroc-ice) for scopes. ICE normally uses TCP/UDP and opens a socket on the
loopback interface. This is very problematic for application confinement because
apps that are allowed network access (the default in the SDK) would be able to
connect to any of the loopback listeners. There are a number of ways to solve
this, but the most elegant is to implement a unix domain socket plugin for ICE.
The scopes team have done this and with this change and all scopes adopting it,
application confinement can prevent apps from attacking the system.

As for confining scopes themselves, this is a hard problem because some scopes
will need wide access to the filesystem, some networking to other sites, many to
canonical.com/ubuntu.com. There are a few things that are useful with the
current design:
 * only Canonical-trusted scopes will likely be able to share a process
 * any scopes requiring authentication credentials needs to be in its
   own process (to prevent other scopes from accessing shared memory)
 * it is possible that we could make it a requirement that scopes from
   the appstore (ie, non-Canonical scopes) must be in their own process
 * we can trigger manual reviews for scopes in general, or scopes that
   need more flexible confinement. This is not optimal because we are striving
   for as little code-reviews as possible in the app store because it just
   doesn't scale.
 * we are able to revoke scopes from the app store if they are malicious
 * appstore ratings will help self-regulate

A few things not in our favor:
 * scopes can by design do anything
 * scopes can be aggregated in any number of ways
 * due to aggregation, scopes are supposed to be able to communicate
   with arbitrary other scopes
 * even local scopes may be required to access canonical.com/ubuntu.com
   servers for side channel communications for recommendations

Confining individual scopes requires a lot of thought and discussion. Some
(non-exhaustive) discussion points:
 * can we agree that app store scopes must always run in their own process?
 * can we agree to kill a scope and all of its children if the scope is disabled
   or if the privacy setting is toggled to 'on'
 * can we agree that scopes must use the unix domain socket ICE plugin? How can
   we enforce this? (We should be able to prevent 'bind' for TCP and UDP using
   AppArmor IPC mediation, but perhaps the scopes architecture enforces this)
 * do we imagine that most scopes won't need filesystem access beyond what app
   store apps typically would need? (essentially read access to the install dir
   and write access to app/scope specific directories following the XDG base dir
   specification). If so, we may be able to treat these scopes like ordinary
   click apps (using a different AppArmor policy template though) where the
   reviews are/will be automatic.
 * A big problem is that some scopes are expected to have access to other parts
   of the filesystem. What is to stop a malicious scope from sending all the
   user's data off to the internet? Would it be possible to say that if a scope
   needed filesystem access like this, it is not allowed to connect to the
   network at all? (ie, either have networking/very limited filesystem access or
   no networking/less limited filesystem access). This seems quite tricky to get
   right
 * can we clearly define how aggregation works and how app store scopes are
   intended to participate in aggregation? Would it help if we said that app
   store scope can only be an aggragatee and not an aggregator? I don't have a
   handle on aggregation yet to understand all the security implications....

= Issue #2: scopes privacy =
Related to confining scopes is enforcing network access based on the privacy
setting. The good news is that the new design for 14.04 doesn't require that
scope authors write code to honor the setting. Instead, if privacy is toggled
on, scopes simply aren't sent the request for data. Individual scopes can also
be toggled on and off so when a scope is disabled, it isn't sent any data. This
does not handle malicious scopes that access the network directly however-- ie,
a scope that ignores SIGTERM/SIGSTOP and keeps running behind the scenes to
shovel data over the network).

To deal with both well-behaved and malicious scopes, there was the idea of
toggling between mostly-permissive AppArmor profiles to turn networking on and
off. Local scopes would always be off while smart scopes get toggled based on
privacy setting. This would work for 13.10 but is greatly complicated going
forward because networking is pretty much always needed for the side channel
communications.

Perhaps the design is sufficient to address scopes privacy though-- disabled
scopes aren't ever called/aggregated and the scopes architecture prevents
sending scopes data when the privacy setting is off, so a malicious scope can't
override being disabled or the user's privacy setting. We can add to that
SIGKILL for it and its children when it is disabled or the privacy setting is
toggled to on.


[1]https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinement

-- 
Jamie Strandboge                 http://www.ubuntu.com/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20130827/4e12e0f5/attachment.pgp>