On 07/03/2015 10:20, Paul Theriault wrote: I can't comment on webby-ness, but I do have thoughts about security here.
(OK, just one comment: this sounds like a variation on the existing inter app communications service - its there practically any differences, other than a forward declaration in the app manifest?Just a thought). Well, yes, it doesn't need us to introduce a new navigator API (going to start differentiating between those and any other kind of APIs ;)) that has to be standardized. More on this later. In general I think the next step here is to flesh out what some of these services might do? I'm struggling to think of actual services that would support gaia use cases in a safe way but its probably worth exploring, if only to better understand the APIs we need for gaia. Things I can think of: * Mediated systemXHR: allow systemXHR on a per origin and per destination basis, so the contacts app can access Facebook and Gmail, and only some specific URLs on those servers, for example. Or allow any random X app to access only the servers we deem it's safe for it to access to. * Mediated settings access: Allow the apps only to access the settings they actually need without adding new permissions to Gecko for each specific Gaia setting that needs more access. * Mediated dial and SMS access: allow some apps to dial and/or send and/or receive SMS including the text, but only from some specific numbers. On Fri, Feb 27, 2015 at 2:42 AM, Antonio Manuel Amaya Calvo <[email protected]<mailto:[email protected]>> wrote: On 26/02/2015 16:11, Fernando Jiménez Moreno wrote: Thanks for starting this thread Antonio. On the scenario that you propose, at least for the use case that you provided (settings), it seems that we are moving the permission check from Gecko to Gaia. Yes and not. I'm not proposing to move the permission check from Gecko to Gaia, Gecko will still have the same permission check it has now. What I'm proposing is implementing a (set) of proxy/ies of APIs. Some app(s) that will act as proxy/ies for other apps that cannot request the permission directly (because the API is certified or privileged for security reasons or because we don't want to open the API to the web). That way some apps that currently are certified (in Gaia) can be moved to privileged or even web.
From a security perspective, you _are_ just implementing more APIs, except in Gaia instead of gecko. The security of these services depends on the security checks they implement. Not saying this is a bad thing (maybe the flexibiity of an update app is useful?) but there's no escaping that the security of device relies on the security checks implemented in these services.
Correct, we're implementing more APIs but those APIs that don't change the APIs exposed by the navigator, and so they're conceptually not much different of me creating a server that exposed a set of REST APIs... which extend the things I can do on the web/using a browser, but I don't have to standardize ;). And yeah, the security of the device depends on the security checks implemented on the services. What's more is that these services actually have less information to make a security decision on. They basically only have access to the origin of the page making the request. They have access to that, and to what each origin is allowed to do. So if https://someserver.wetrust.com has access to: * Read and send SMS from +123456789 * Have socket access to someserver.com:12345 then even if https://someserver.wetrust.com is thoroughly compromised, it *still* would only be able to access to that same services. This is actually better and worse than what we currently do for privileged and certified apps: * It's worse because we don't actually check the code of someserver.wetrust.com and it's easier (I hope :P) to compromise a remote server than a locally installed app. * It's better because even if/when it's compromised, it will still have access exactly the same subset of the device APIs it previously had. Currently, if a privileged app that has access to SystemXHR is compromised, the attacker will get access to *any* server using SystemXHR (ditto if it has access to contacts, or whatever). I don't envision services as giving uncontrolled access to any of the underlying APIs, but of them giving access, to each origin, to the specific subset of the API than when the origin was submitted/we wrote the app we deemed for it safe to access. So basically the same that reviewers currently do with privileged apps, only even when the app changes it will still have access to the same subset of the underlying API. On Gecko we currently have signed apps and a list of permissions associated to them. On the content side we don't have any of this information available. Could you elaborate a bit more about how would the Service decide if a 3rd party app can access or not the wrapped resource. In other words, how would third party apps request permission to access the content controlled by the Service? Ok, again there are two different issues here. On one hand, initially the services would be services for the OS apps (that is, the Gaia apps). Those services will allow moving apps from certified to privileged or even web, if the APIs that they use can be mediated by a "service app". As such, the service can decide to serve or not the request by a combination of the origin (origin URL) and the actual data passed. A hypothetical settings service could use a table like: { "https://music.gaiamobile.org";<https://music.gaiamobile.org> : { read: ["volume.max", "volume.current", "silentmode"], write: ["volume.max"] ... } (I didn't check the actual settings that the music app uses). I know this is contrived example but this seems backwards to me. Shouldn't the settings that the music wants to access be defined in the music app itself? Yes and no. The music app will define the settings it want to access in two ways: 1. Using them ; 2. And telling the service ruleset: Hey, I'm the music app and I will need access to these settings. Now, for Gaia apps, the second part can be automated. That is, the settings app can define in it's manifest, on in some new file read at build time only, the services it need to access, and what subset of those services it need, and the build process can create the initial/static ruleset for those apps. For third party apps, though, they will have to submit their apps/needs to the ruleset server, the same way they currently submit the privileged apps, if they want to access restricted elements on the phone. That aside, lets consider the compromise scenario (which is the main challenge hosted apps). In this case, the music app has been compromised and the attacker has access to the same settings as the music app. The service has no way of of knowing that the app is compromised, so the only settings that the service can safely expose to the music app are things that don't matter to much if the music app is compromised. Correct. If the hosted app is compromised, the only things it can do on the phone is the same things it could do *before* it was compromised (so the security depends on how strict the ruleset is when giving access to something, and how narrow that access is). In general I guess the benefit here is that ability to add new, more finely grained APIs without changing the underlying gecko API. I like the concept, but I'm struggling to think of actual services that we could implement that would bring meaningful powers hosted versions of gaia apps. Each service can, and should, have it's own set of rules it applies before serving a request. So we could have a XMLHttpRequest proxy that could serve petitions using SystemXHR from some apps to a concrete set of domains (or *), a disk access proxy that could allow access from some apps to some specific directories and so on. The nice part of this is that since it's all on the Gaia side we will not be introducing any design dependencies between Gecko and Gaia (Gecko doesn't need to know anything about Gaia!). This is the initial step. I didn't talk anything about third party apps so far :) If we want to open this to third party apps, then it'll have to be on a controlled way. We can still do it by origin (https only, obviously) and we can download the actual ruleset from a Mozilla/Operator/OEM server. That would allow dynamic configuration of what apps can access what services, allowing Mozilla, an operator or an OEM to add another app without having to change the core/certified apps. For example, if we decide to add a "3D photo camera" at a later point, that requires access to a mediated API, we can just update the ruleset for that service on the Mozilla server (or the operator server, or the OEM server, or even the personal server of the user if the phone has a homebrew build!) to add the rules for https://3dphonecamera.somedeveloper.com and presto, we have a new app that has access to protected resources on a controlled way. So Mozilla just granted access to my photo library to some random third-party that they decided to trust? :) As a user, do I get a say in this? Unless we can think on some way to make my mother understands what she would be granting access to, then no :P. Seriously, though, it would be easy to allow the user to remove specific sites from the ruleset and (easy but dunno how safe unless it's a developer setting) to add new rules himself using the settings API. To me this use case feels more like extensions than apps - maybe we should be considering building extensions (that have full gecko access, and can use that to make security decisions and can provide security UI, like prompts/notifications etc) rather than trying to implement everything as an app? Well, from some point of view, everything we've written as certified apps feel like extensions already :). The security UI is a different problem, though, and one that doesn't seem to have any good solution that doesn't involve losing screen real-state. Best, Antonio Just a thought. / Paul Best, Antonio / Fernando ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição _______________________________________________ dev-b2g mailing list [email protected]<mailto:[email protected]> https://lists.mozilla.org/listinfo/dev-b2g ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição
_______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
