783478 - Allow remote XUL permission for 'about' protocol pages

Status: RESOLVED INVALID

(Firefox :: General, defect)

Description

[Andres Hernandez [:andreshm]]

We need to allow remote XUL on unprivileged about pages. Currently, when adding 'allowXULXBL' permission on about protocol pages, returns NS_ERROR_UNEXPECTED.

Comment 1

[Tim Taubert [:ttaubert] (inactive)]

(In reply to Andres Hernandez [:andreshm] from comment #0)
> We need to allow remote XUL on unprivileged about pages. Currently, when
> adding 'allowXULXBL' permission on about protocol pages, returns
> NS_ERROR_UNEXPECTED.

That's because 'about:*' urls have no host. I think it would make sense to let nsContentUtils::AllowXULXBLForPrincipal() always return true if |uri->SchemeIs("about") == true|.

Totally not my area of code, adding some people that worked on this and hopefully have an opinion about it.

Comment 2

[Andres Hernandez [:andreshm]]

I tried what Tim suggested, however I think it doesn't work. Since, the method that we used to add permissions, according to https://developer.mozilla.org/en-US/docs/Remote_XUL, is nsPermissionManager::add (or nsPermissionManager::addFromPrincipal, that internally calls the same 'add' method).
This method first checks the host of the URI and it's completely based on the host. And, as you already mention since the host is empty, it throws the error. 
See: http://dxr.lanedo.com/mozilla-central/extensions/cookie/nsPermissionManager.cpp.html. 

I'm not clear if there is another way to do this, any guidance here would be appreciated.

Comment 3

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

We definitely don't want to enable XUL/XBL for all about: pages since that would include about:blank. Since any website can create an about:blank iframe this would enable websites to create a blank document and start creating XUL/XBL which would defeat the security benefits of having these features disabled.

In general, I don't see why we would want to introduce the complexity associated with enabling XUL/XBL on more pages.

What is the use-case?

Comment 4

[Andres Hernandez [:andreshm]]

We want this for Bug 776477, because we need to allow XUL on about:newtab but being unprivileged.

Comment 5

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

That's unfortunately a bit of an oxymoron. At this point we basically assume that XUL is buggy enough to be exploitable, so any page that can access XUL can cause Firefox to crash in exploitable ways. So we only want to expose XUL to trusted pages.

Comment 6

[Tim Taubert [:ttaubert] (inactive)]

(In reply to Jonas Sicking (:sicking) from comment #5)
> That's unfortunately a bit of an oxymoron. At this point we basically assume
> that XUL is buggy enough to be exploitable, so any page that can access XUL
> can cause Firefox to crash in exploitable ways. So we only want to expose
> XUL to trusted pages.

Hum, that's a fair point. I guess if we want to make about:newtab unprivileged it shouldn't use XUL at all, then.

Comment 7

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

You can still use XUL layout though, by using "display: -moz-box;" in CSS

Comment 8

[Tim Taubert [:ttaubert] (inactive)]

(In reply to Jonas Sicking (:sicking) from comment #7)
> You can still use XUL layout though, by using "display: -moz-box;" in CSS

Right, that's what we'll do. We switched to XUL when developing about:newtab because of -moz-locale-dir which only works in XUL.

Comment 9

[:Gavin Sharp [email: [e-mail]]]

(In reply to Jonas Sicking (:sicking) from comment #5)
> That's unfortunately a bit of an oxymoron.

Not really - about:home is unprivileged, but we ship it and control its content. Allowing XUL there is much different than allowing XUL for arbitrary content. If we can avoid needing to do that, we certainly should, but if it would save us a lot of work we shouldn't drop the idea entirely.