-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/
iQIcBAEBCgAGBQJSHSpcAAoJEFHb3FjMVZVzDzcP/0hIkzXeLWQbJTCFx/rEUY+Y
vzsT7Z8yynU/rYzZS413xF+kkH/R0Z7gPNTEKUbb8GdhPkWr2KSl0CLraeZP3J3Y
AZSFZLMQBFB3kr5GNyuf9rD01LjaiKAK5f5ChtPAEMlI9C8N3oo0SWLmejFFAL+Z
Sp3X0pnRqu6ZldXC2wWfpJlVrWsQLrvZ2hMIWHiOE6yRYbwIg4+IN+WDQ8amt5UJ
KcxALTntYw3DtO2PASaTD6/f+Id2dUeHhGJsf2GI2cCitTbH1TAbKbqsdoikUYtW
q8o+RUbi6zKnC3wZNVUry5VR6erm6zUy/XpHvuzfd9FibLDrY6xpCeeHIBxEVRTO
ac8Lwm6uImfWrNhJnbPBX/emyHqExg/nMRz8oMoOOOq/3ABB7QPbf1o4CcGruRdA
pBghvvTQT7pF4vwf7APW1H3gZsK43KLi9o9sEIgphdGoLPxPa0eb3LGppoBzK6I6
aPDnRBAv9N1DuiY20/fcu4LWr8FayqwH55cLoGYBilbFmuL4GB/K+4mPzvUl+2B5
r9nWDZhIU50jtiALuTshNqfOpG4L8OrHMWBBL0l0R2ryq0eqejFrg8pvwwmy0u6F
HHGxCMg0nAkLgJ/7krwy2+j9pAzdJx67AEDg8S29kUT2kjWRtLVyYbPFwOyNrv3g
Zta4WwCQLhiT6Ba45iLj
=pgWK
-----END PGP SIGNATURE-----
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/
