969278 - [Offline] need to whitelist mozSettings and mozMobileConnections from about:netError frame

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::System, defect)

Description

[Michael Henretty [:mikehenrty][:mhenretty]]

In order to complete the offline spec, net_error pages will need access to these API's. We will need to whitelist this from gecko.

Comment 1

[Antonio Manuel Amaya Calvo (:amac)]

Why do we need to add a special case for this?

Why can't we just use a inline activity in settings to do the needed change (with user interaction)? The way this could work is 

about:neterror -> WebActivity(inline) -> Settings shows connectivity options
... User makes the changes he wants ...
Webactivity closes -> original app

This flow can be implemented without making any changes on the platform, and without adding any special cases to the permission checking. Special cases that can be dangerous since adding that whitelist would mean that *all* content processes would have access to that APIs. 

Part of the security model is that the parent process knows what permission a child process has, and that permission set is decided by the root process at launch time. If at a later time a request is received from a child process for a permission that isn't on that child process allowed set, then the child process is considered compromised and killed. Making the change described in comment 0 would break this model.

Comment 2

[Antonio Manuel Amaya Calvo (:amac)]

Paul, can you confirm (or deny ;)) what I said about the permission model? I think we should close this as wontfix... adding whitelists is not only a bad idea in general terms, but in this case it opens a nice hole on our security model.

Comment 3

[Paul Theriault [:pauljt] (no longer reading bugmail)]

(In reply to Antonio Manuel Amaya Calvo (:amac) from comment #2)
> Paul, can you confirm (or deny ;)) what I said about the permission model? I
> think we should close this as wontfix... adding whitelists is not only a bad
> idea in general terms, but in this case it opens a nice hole on our security
> model.

Yes thats correct. Permissions must be enforced in the parent, not in the child (we can't even trust chrome code in the child). If we whitelisted these permissions, any child process which was compromised (e.g. through a gecko bug) could send messages directly to the parent, and the parent would have no way of knowing if it was about:netError that was calling this API or some other content.

Comment 4

[Paul Theriault [:pauljt] (no longer reading bugmail)]

Btw I have started a page here which goes into more detail about the permission model. It needs a lot more input but its a start: https://wiki.mozilla.org/Security/B2G/FirefoxOSCommsHardening

Comment 5

[Cristian Rodriguez (:crdlc)]

Francis,

   According to security/permissions experts we cannot access to the set of APIs that allow us to know if we are on airplane mode, we have 3G, enable/disable them, etc... 

   I have a new approach what you could study its feasibility from the UX point of view. The idea is based on adding a button to check connectivity in the error page that allows users to see the settings app but just the items related to network/connectivity (airplane mode, wifi and data). You can see my idea implemented in this picture [1]. This approach is very feasible regarding to Gaia development and we don't need to change anything in Gecko side. Furthermore, it is almost for free without duplicating UIs and algorithms taking advantage of settings app where all those stuffs are implemented.

Thanks a lot

[1] http://i.imgur.com/DuKmZoq.png

Comment 6

[Francis Djabri [:djabber]]

Thank you Cristian for taking the initiative here - this looks good to me.

Comment 7

[Michael Henretty [:mikehenrty][:mhenretty]]

Given that we have an alternative flow that is acceptable to UX, marking this bug as WONTFIX.