Closed Bug 783478 Opened 10 years ago Closed 10 years ago
Allow remote XUL permission for 'about' protocol pages
We need to allow remote XUL on unprivileged about pages. Currently, when adding 'allowXULXBL' permission on about protocol pages, returns NS_ERROR_UNEXPECTED.
OS: Mac OS X → All
Hardware: x86 → All
Version: unspecified → Trunk
(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.
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.
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?
We want this for Bug 776477, because we need to allow XUL on about:newtab but being unprivileged.
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.
(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.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → INVALID
You can still use XUL layout though, by using "display: -moz-box;" in CSS
(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.
(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.
You need to log in before you can comment on or make changes to this bug.