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/
signature.asc
Description: OpenPGP digital signature
-- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
