1060108 - Consider options for blocking network access only to the _new_ browser

Status: RESOLVED INVALID

(Core :: Networking, defect)

Description

[Valentin Gosu [:valentin] (he/him)]

The method for blocking network access to apps is fairly simple: we basically set the LOAD_ONLY_FROM_CACHE flag on the channel, or we cancel that channel entirely based on the appId.

However, recent changes to the gaia browser make blocking network access to the browser a bit more difficult. Browser windows are now opened by the system app, with the system's app manifest, hence they have appId 22. The browser app had appId 14.

Blocking access to app 22 doesn't seem like a good option, as the system also handles other tasks, such as downloads, payment, etc.

Fabrice suggested that we might block channels based on the (appId, isInBrowserElement) pair. It's unclear if this wouldn't include other usecases for the system app, or how hard this would be to do.

From what I understand, having the browser tabs be open by system was done to have each tab appear in the app manager. If so, would it be possible to set mozapp attribute to the browser's manifest, so it would get appId 14?

Comment 1

[Valentin Gosu [:valentin] (he/him)]

Fabrice, do you think we could set a specific appId for new browser windows?
Are there any upsides/downsides to these solutions?

Comment 2

[Ben Francis [:benfrancis]]

There won't be a browser manifest because there won't be a browser app. Setting the mozapp attribute of browser window iframes is probably a bad idea from a security point of view and will break a lot of things because I think we use the mozapp attribute to distinguish between app windows and browser windows in lots of places.

I don't fully understand how your channel blocking works and I'm not sure what mechanisms exist to differentiate browser windows from other iframes down at that level. Sorry I can't be more help.

Comment 3

[Valentin Gosu [:valentin] (he/him)]

The main problem is that we don't have much more info other than the appId. That's why I'm proposing we keep the browser app and manifest around, even if it's just for using the manifest and appId.
Right now browser frames get the system's appId. I'm hoping that we can find a way to give the ones that are used as browser windows a different appId, so we can just block the browser if needed. Is that possible?

I'm not totally sure what the architecture of the new rocket-bar/browser is. Do frames _need_ to be owned by system? AFAICT system has more permissions than the old browser app needed. I'm not the best person to question the security model, but it would be good to know.

Comment 4

[[:fabrice] Fabrice Desré]

(In reply to Valentin Gosu [:valentin] from comment #3)
> The main problem is that we don't have much more info other than the appId.
> That's why I'm proposing we keep the browser app and manifest around, even
> if it's just for using the manifest and appId.
> Right now browser frames get the system's appId. I'm hoping that we can find
> a way to give the ones that are used as browser windows a different appId,
> so we can just block the browser if needed. Is that possible?
> 
> I'm not totally sure what the architecture of the new rocket-bar/browser is.
> Do frames _need_ to be owned by system? AFAICT system has more permissions
> than the old browser app needed. I'm not the best person to question the
> security model, but it would be good to know.

System has more permissions than the old browser app, but that doesn't change permissions granted to remote browser frames. So I don't believe there's a security issue here.

However I agree that having all browser iframes get the system app id may not be ideal. We could indeed keep a hidden browser app used just to wrap the browser frames, but that creates a dependency of the system app on the browser app.

Jonas, Paul, any insight?

Comment 5

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

So my initial thought is that the necko code needs to be aware of the inBrowser flag anyways, so that is how we should solve this. 

One question; we previously had "system browser" windows already (e.g. web pages pinned to the homescreen open in windows which share the system appid, but are mozbrowser=true iframes). In the system browser world, are ALL iframes that have mozbrowser="true" and no mozApp attribute consider opened of the System Browser. (IE does the one system browser listen for mozBrowser events for all of these windows).

From ben's comment above it sounds like there is no distinction - i.e. if the system app embeds and iframe with mozBrowser='true' then this is  a "browser" window. 

In that case it would seem to me that we should just be using the inBrowser flag as mused in comment 0 rather than arbitrarily setting an appid. But that said, normally, when you block an app from using the network, you would want to block all network access based on appid, regardless of mozbrowser state, so we need to support this case too. Does that make any sense?



Some other thoughts on the bigger question of security architecture:

* The system app having more permissions is definitely something to consider, but changing the appid of web pages does nothing to mitigate the risk at all. The system app will still be the parent of the content, and still listen to all the mozbrowser events etc, so special casing this somehow I fear will just complicate an already complicated model.

* We already have "browser-like" windows that have the system app as their id. E.g. pin an everything.me app to the homescreen, then open it. You will see an frame which has mozBrowser="true", but no mozApp attribute, meaning that it inherits the system app appid (IIUC). 

* The only real difference between the system browser and browser app is that the browser app logic is in the system app instead of a seperate app. Code execution vulnerabilities would affect either approach equally since browser runs in parent anyways. The only increased risk here is script injection/privilege escalation issues. While we have had these in Gaia before CSP provides a strong control here, and so far we've not seen this type of issue in the browser app (though we have had XSS issues triggerable via mozBrowser messages in the past, e.g. bug 854849 which I think is the main attack surface)

Comment 6

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

> 
> One question; we previously had "system browser" windows already (e.g. web
> pages pinned to the homescreen open in windows which share the system appid,
> but are mozbrowser=true iframes). In the system browser world, are ALL
> iframes that have mozbrowser="true" and no mozApp attribute consider opened
> of the System Browser. (IE does the one system browser listen for mozBrowser
> events for all of these windows).

I realized this question isn't clear. I specifically mean iframes embedded by the system app here. Obviously other apps, and the frames they embed will have different appids.

What I am wondering is if there is anything special about the frames used for browsing vs other mozbrowser iframes in the system app.

Comment 7

[Valentin Gosu [:valentin] (he/him)]

Closing bug as b2g code is getting removed (bug 1306391).