677474 - Remote XUL should be allowed via capability.policy.* security prefs which can be managed with AutoConfig (enterprise-friendly)

Status: RESOLVED WONTFIX

(Core :: XUL, defect)

Description

[Kohei Yoshino [:kohei]]

+++ This bug was initially created as a clone of Bug #595397 +++

The Remote XUL whitelist should be managed via prefs like other security settings. It is important especially for enterprises where AutoConfig is used and remote XUL is required for their internal apps.

http://www.mozilla.org/projects/security/components/ConfigPolicy.html
https://developer.mozilla.org/en/Midas/Security_preferences
https://developer.mozilla.org/en/MCD,_Mission_Control_Desktop_AKA_AutoConfig

Default prefs may look like this:

pref("capability.policy.default.XUL.remote", "noAccess");
pref("capability.policy.default.XUL.local", "allAccess");

So people can override the prefs like this:

user_pref("capability.policy.policynames", "allow_remote_XUL");
user_pref("capability.policy.allow_remote_XUL.sites", "https://bugzilla.mozilla.org");
user_pref("capability.policy.allow_remote_XUL.XUL.remote", "allAccess");

Comment 1

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

I tend to agree, though I think the way we should do this is to back the permission manager using perfs rather than a sqlite database.

That way we only have preferences in one location instead of two.

Comment 2

[Mike Kaply [:mkaply]]

The problem with capability prefs is that they can't be set by the user and they can't be set by the CCK Wizard.

I'd much rather see permission manager do this.

Comment 3

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

Mike: I'm not sure I understand your comment.

The way I see it users *can* set prefs using about:config, but can't easily modify the permissions-manager database as we don't have UI for that anywhere (though there are addons which can do it).

Are you saying that the CCK wizard can modify the permissions-manager database?

Comment 4

[Mike Kaply [:mkaply]]

Any preference that begins with "capability" is not shown in about:config so a user can't mess with them.

http://mxr.mozilla.org/mozilla2.0/search?string=capability%5C.&find=&findi=&filter=^%5B^%5C0%5D*%24&hitlimit=&tree=mozilla2.0

I thought there were some other restrictions as well.


I was simply indicating that I think preferences are a poor method of modifying this because in theory there could be many sites that need this. I think permission manager is a much better place to put this.

Although think this debate was had when XUL was removed, though, wasn't it? And all the Mozilla folks argued "don't make it easy to add exceptions to the XUL stuff"


As far as CCK goes, it does modify the permissions manager for popups and XPI installs. IT would be trivial to add support for XUL.

Is remote XUL currently using the permissions manager internally?

Comment 5

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

AFAIK the plan was to remove all of the capability.* prefs. But the pref name doesn't matter, we can use some other pref branch for this if needed (i.e. bug 284673 need not block this in any way).

Comment 6

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

Remote-XUL-enabling uses the permissions manager currently. However that wasn't due to some decision to intentionally make it hard to turn on remote xul.

For what it's worth, I don't have an opinion on what prefs to back the permissions manager with if we indeed do decide to back it by prefs. It could be something outside of capability.policy.*.

But it is interesting that we've decided to hide capability.policy.* from about:config and prevented CCK from setting those prefs. The reasons that went into that might affect the resolution of this bug as well as any efforts to move permissions manager to prefs.

Comment 7

[Mike Kaply [:mkaply]]

I could be wrong on the CCK thing. It's been a while. I looked through the Mozilla code and the only capability restriction I see is showing them in about:config. So maybe we're OK.

What's the reason for having the permissions manager use prefs instead of SQL?

Doesn't the new site specific permission manager require a more robust datastore like SQL?

Comment 8

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

It just sucks to have two separate places where we store preferences.

If our current preferences are reliable enough to hold security data, then it seems like we should fix that.

Comment 9

[Tony Mechelynck [:tonymec]]

IIUC, currently there exists one (and only one) way to whitelist sites for remote XUL, namely, use the "Remote XUL Manager" extension https://addons.mozilla.org/en-US/seamonkey/addon/remote-xul-manager/ (or mutatis mutandis for Firefox and/or for other content-locales). It boasts support of Fx 4.0b9 to 7.* and Sm 2.1b2 to 2.2.* but I'd be willing to try it with later versions if I had any use for it. (Maybe I will, when I go back to the MDN pages about XUL, which do use remote XUL for examples.)

Is it really deemed necessary to add that capability to the plain-vanilla browser, considering that it already exists as an extension?

Comment 10

[Kohei Yoshino [:kohei]]

Of course I know the extension but I don't think it's the right solution. As I wrote in my comment 0, remote XUL is required for some _enterprise_ users. Managing the permission via prefs, like clipboard access, would be better than the extension. AutoConfig has ability to lock the prefs if needed.

Comment 11

[Mike Kaply [:mkaply]]

Remote XUL isn't a thing anymore.