It would be really nice to get rid of enablePrivilege. It's incredibly
poor UX (popups asking a user to grant incomprehensible permissions), it
has weird function-level scoping, and it has opaque privilege strings
that make no sense to anyone. It also complicates security code a fair
amount.
At the same time, it seems to be used a fair bit for intranet apps.
Earlier today there was a brainstorming session about use cases for
enablePrivilege, and we came up with the following:
1) Working around same-origin restrictions
2) Working around DOM security/privacy restrictions (things like
getting the full path from a file input, or setting the value
of a file input).
3) Enabling programmatic copy/paste in Midas
4) Cross-site XHR (a variant of #1)
5) Mochitests
First of all, are there other major classes of use cases we're missing?
If not, here's a possible course of action:
A) Do something with mochitests (move the relevant one to chrome
tests, expose an object that allows running privileged code,
whatever).
B) Announce that we plan to remove this API in the release after Gecko
1.9.1. Possibly add a warning when it's used in 1.9.1.
C) Do something about the other 4 use cases. The "something" should
have only two levels of permissions: "normal sandbox website" and
the equivalent of UniversalXPConnect. The intermediate privilege
levels are more confusing than they're worth.
D) Remove enablePrivilege after 1.9.1 is done, as well as removing
signed jar code (which is really only used for enablePrivilege).
After a good bit of discussion, for item (C) we're thinking the answer
is an extension. One concern is that making the extension (which must
take input from untrusted content, obviously) secure is nontrivial. So
what would be ideal is for us to expose a communications channel that
such extensions could use and a way to have prefs specifying which sites
can use the communications channel for a given extension. Alternately,
the prefs could specify hostnames that are allowed to pass a chunk of
script with privileges (something like evalOutsideSandbox()). Or
something along those lines. The assumption is that intranet
deployments can set preferences as needed, of course.
The open question are what form this communication channel or
evalOutsideSandbox() functionality should take place. What's really
needed, I think, is feedback on use cases and some discussion (and then
a decision!) about how to make this work.
Ideally the solution we come up with should be simple enough to
implement that we can do it for 1.9.1, to allow sites to start migrating
to the new setup.
Thoughts?
Boris
P.S. Please respect the reply-to and followup-to and keep this on
m.d.platform.
_______________________________________________
dev-security mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security
