On 08/27/2013 03:38 PM, Jamie Strandboge wrote:
>
> 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
Not necessarily. If we give them broad network access yes. If we restrict the
access to certain labels no. This does require us getting labels working with
local ip sockets. This won't require a full cipso/ipsec solution which is needed
if the packets go off machine.
> 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.
>
sure this works as well
> 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
This is a REQUIREMENT to have security on these
> * 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.
sure, but part of the idea is that we use confinement requirements to filter
out what doesn't need review.
> * 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
so can applications, its the sandbox that limits what they can do
> * scopes can be aggregated in any number of ways
sure and hence require the transitive closure permission of the aggregate
> * due to aggregation, scopes are supposed to be able to communicate
> with arbitrary other scopes
Define arbitrary. We have to be able to limit what data and scopes they
can communicate with at a policy level otherwise we can NEVER have none
Canonical scopes.
Sure the api can allow for arbitrary scopes but this has to be bound at
run time by the policy
> * even local scopes may be required to access canonical.com/ubuntu.com
> servers for side channel communications for recommendations
>
Again this must be controlable
> 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?
I don't know that we can agree but it is a hard requirement, without we can not
provide any security guarantees
> * 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'
which privacy setting? Scopes will have more than one level of control, and just
because privacy is on does not mean a scope may not be useful locally
> * 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)
I don't think this is a hard requirement as noted above. We certainly need to
mediate the communication channel but I don't think that is a requirement we
need to foist on the scopes architecture.
> * 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.
I think that assumption is false. While I don't know what the scopes will be
that want broader access, I can imagine they exist. At some time we will want to
support this
Perhaps we require such scopes to be audited, perhaps we can come up with something
better.
> * 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
As a default maybe, but again I can see use cases for this. We need to be careful
and audit things like this.
> * 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....
>
Again that would be a major limitation, and could cut out useful scopes. I
think it needs to be more along the lines of this scope can use these other
scopes/data types as sources.
Some of it can be preseeded some of it can be dynamic, and the user should be
able to revoke such rights at any time.
> = 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).
>
We have to confine each scope that could be malicious
> 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.
>
Again, with a little more work this won't be the case
> 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.
>
Are we saying that there won't be any scopes that are useful with the privacy
setting toggled on? I can certainly think of lots of cases where a local scope
search would be useful
>
> [1]https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinement
>
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
