On 07 Mar 2015, at 23:31, Paul Theriault <[email protected]<mailto:[email protected]>> wrote:
On Sat, Mar 7, 2015 at 9:26 PM, Antonio Manuel Amaya Calvo <[email protected]<mailto:[email protected]>> wrote: 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. Maybe, but seems far simpler to change the SystemXHR permission just to also accept a whitelist of origins that the app will connect with. That is another option, to give every special navigator API much more granularity. Writing it on gaia makes it more flexible and easier to update, IMHO, though. (PS contacts app is a bad example I think, since if it was hosted, the contacts app doesn't need to talk to gmail/facebook oauth services, right? I get your point though) It really depends on if we wish the contacts app to have some server component (other than being hosted or not). Even if the actual app code was hosted, I would prefer all the code to run locally (without any code that run server side) since that way the user's data only go from Gmail or Facebook to the phone, without any intermediate. * 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. I guess same argument, and there is the risk of exposing dangerous settings to hosted app. If the setting is dangerous then it probably should not be exposed to the hosted content, no matter how. We're requiring the permission and thus making some apps certified for innocuous settings (at least they're innocuous to read and in some case even to set). * 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. Lots of risks to mitigiate here. An attacker which compromises a hosted gaia app can send 1000 sms messages and cost the user large amounts of money. (I guess you could rate limit). But this is exactly the sort of thing that I would want to surface to the user for them to decide, rather than making the choice for them. It gets very complicated to explain very quickly though. Well, when I was thinking of giving restricted dial/send sms to some apps I was thinking more on the line of toll free numbers controlled by the app maker. Everything that costs money to the user should require an explicit approval by the user, every time. Otherwise we're just asking for problems. Best, Antonio * 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'red 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 on'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<http://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<http://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). The crucial difference you overlooking is likelihood of compromise. Currently, there is no server for an attacker compromise, that will own _all_ FxOS phones. A compromise of marketplace would be bad, but it wouldn't allow pushing malicious code to user's devices. Furthermore, I'd also argue that combination of static HTML apps and CSP is a fairly strong mitigation to cross-site scripting which is by far the most prevalent web app vulnerability (and the biggest concern if you are talking about expose privileges to a web apps). But from my investigation so far, I don't see any solution other than introduction some kind of integrity mechanism to hosted Gaia apps (i.e. making them static and signed, with CSP etc). And if we have that then a service might be a nice defense in depth layer. 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. How would a ruleset server decide whether or not to grant access to a particular hosted app (noting that it can't review the code of a hosted app) ? 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). That's basically what I am getting at - so far when looking a the most common permissions used by Gaia apps, making the API narrow enough so that is safe enough, breaks the gaia use cases. 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 ________________________________ 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
