How to avoid signed.applets.codebase_principal_support
Francis Brosnan Blazquez
Please, excuse me if I'm asking something yet solved/answered. I did
searched and tried several solutions but I'm not getting the expected
result.
I'm working on a BEEP [1] implementation for Firefox: jsVortex [2]. For
now, I've been using signed.applets.codebase_principal_support to get
access to the API that allows to create sockets, read and write, and to
close them.
However, as you known, having signed.applets.codebase_principal_support
enabled, makes not only your webapp but other, unknown, webapps that may
ask user permission to access not only to the socket API but everything.
In this context I've tried to find a firefox addon that would allow a
kind of per-site signed.applets.codebase_principal_support, that is, the
site using jsVortex still requires asking permission to the user, but
this is already known by the user, and at the same time other sites
can't ask for permissions (like having
signed.applets.codebase_principal_support = false). However it seems
there is nothing similar.
The other approach I've tried is to create a firefox extension, sign the
XPI package and then load all .js files via chrome:/// url but it makes
no difference. It still requires
signed.applets.codebase_principal_support to be enabled.
This approach also have the chrome:/// problem which is firefox
specific.
Reached this point, I'm asking for any clue or guidance. Any help will
be really appreciated ;-)
1. Is there a way to allow a user to configure its browser to accept a
list of "trusted" sites that are allowed to use UniversalXPConnect?
2. Do you think there are another way to accomplish what I'm trying?
[1] http://www.beepcore.org
[2] https://dolphin.aspl.es/svn/publico/af-arch/trunk/jsVortex/
--
Francis Brosnan Blazquez <fra...@aspl.es>
ASPL
Boris Zbarsky
> The other approach I've tried is to create a firefox extension, sign the
> XPI package and then load all .js files via chrome:/// url but it makes
> no difference. It still requires
> signed.applets.codebase_principal_support to be enabled.
I don't see why, unless you did it wrong.
> This approach also have the chrome:/// problem which is firefox
> specific.
So are the socket APIs you're using, no? Or at least Gecko-specific.
> 1. Is there a way to allow a user to configure its browser to accept a
> list of "trusted" sites that are allowed to use UniversalXPConnect?
Yes, you can set the preferences that security manager would set if the
user got prompted and accepted and say to remember that choice.
Note that we plan to remove enablePrivilege, so you might be better off
not using it unless you want to redo your stuff in a year or two.
You could write an extension that listens to particular events from a
particular site, or exposes some APIs to it. The latter is hard right
now, but we're working on providing an easy way to do it.
-Boris
Nickolay Ponomarev
> Francis Brosnan Blazquez wrote:
>
>> The other approach I've tried is to create a firefox extension, sign the
>> XPI package and then load all .js files via chrome:/// url but it makes
>> no difference. It still requires
>> signed.applets.codebase_principal_support to be enabled.
>>
>
> I don't see why, unless you did it wrong.
>
I think the OP was talking about using <script src="chrome://..."/> *from a
web page*. This isn't supposed to give the script any additional
permissions, since while extension is trusted, the web page including the
script is not. Right?
Nickolay
Boris Zbarsky
> I think the OP was talking about using <script src="chrome://..."/> *from a
> web page*. This isn't supposed to give the script any additional
> permissions, since while extension is trusted, the web page including the
> script is not. Right?
Oh. Yeah, if you load scripts via <script> they behave the same no
matter where you load them from.
-Boris
Francis Brosnan Blázquez
> > The other approach I've tried is to create a firefox extension, sign the
> > XPI package and then load all .js files via chrome:/// url but it makes
> > no difference. It still requires
> > signed.applets.codebase_principal_support to be enabled.
>
> I don't see why, unless you did it wrong.
In other reply I found why this was making no difference (or why it is
wrong). It makes sense assuming the Javascript context comes from an
external unstrusted webpage (anybody will be allowed to load from
chrome:/// which is not appropriate but I had to try ;-).
> > This approach also have the chrome:/// problem which is firefox
> > specific.
>
> So are the socket APIs you're using, no? Or at least Gecko-specific.
Certainly. But, with the enough isolation it is not a problem at all.
I'm trying to provide a BEEP API that hides these details...
..however, making a webpage to load jsVortex files (via <script src="">)
using non-standard or firefox-specific urls seems odd.
> > 1. Is there a way to allow a user to configure its browser to accept a
> > list of "trusted" sites that are allowed to use UniversalXPConnect?
>
> Yes, you can set the preferences that security manager would set if the
> user got prompted and accepted and say to remember that choice.
This sounds promising Boris. Sorry but, can you elaborate more on this.
Maybe you can point me to some document or code example (or mozilla
source). If I understand you there is a way to activate a per-site user
controlled setting that will allow UniversalXPConnect without modifying
signed.applets.codebase_principal_support. Is this right?
> Note that we plan to remove enablePrivilege, so you might be better off
> not using it unless you want to redo your stuff in a year or two.
Ok. Thanks for the advice Boris. Certainly my intention in near term is
to implement all I/O handling with websocket, but I would like to
support more firefox versions and people not having a websocket
infrastructure.
> You could write an extension that listens to particular events from a
> particular site, or exposes some APIs to it.
Ok, this solution seems to be more robust in the long term if I
understand you. I'll try to find how to do this.
> The latter is hard right
> now, but we're working on providing an easy way to do it.
Definitely exposing a particular and limited API looks like the right
thing. Is there any document or a working example implementing this
concept?
Thanks Boris, Cheers!
> -Boris
Boris Zbarsky
> This sounds promising Boris. Sorry but, can you elaborate more on this.
> Maybe you can point me to some document or code example (or mozilla
> source). If I understand you there is a way to activate a per-site user
> controlled setting that will allow UniversalXPConnect without modifying
> signed.applets.codebase_principal_support. Is this right?
Correct. I don't have a document to link to offhand, but you can take a
build in which signed.applets.codebase_principal_support is enabled, go
to a page that asks for UniversalXPConnect, allow the privilege and tell
the browser to remember it. Then quit the browser and look at the
resulting capability.policy prefs in user.js in your profile.
> Ok, this solution seems to be more robust in the long term if I
> understand you.
Yeah, indeed.
> Definitely exposing a particular and limited API looks like the right
> thing. Is there any document or a working example implementing this
> concept?
Firebug does this with their console.* APIs, I believe...
-Boris
John J. Barton
The basic strategy is to add a div element to the web page and a script
tag. The script adds window.console.log() functions. These functions
place strings on the div as attributes then raise an event on the div.
Firebug attached an event listener when it injected the div. The
listener peels off the strings to decide what to print in the Console
tab of Firebug. In that last step you have to be careful to ensure that
you don't run arbitrary code from the page.
Firebug's actually implementation is regrettably less concise. Rarely,
the div injection can interfere with layout. And of course any object
you add will collide with identical names used by pages.
Two other tidbits: 1) there is a way to add global objects into the
Javascript world that is rarely used (I don't know more about it), but
that path requires re-analyzing the security issues. 2) there is work
ongoing to make a must less painful solution, so for prototypes I would
not invest a lot of time on this part of the solution.
jjb
Francis Brosnan Blazquez
> Correct. I don't have a document to link to offhand, but you can take a
> build in which signed.applets.codebase_principal_support is enabled, go
> to a page that asks for UniversalXPConnect, allow the privilege and tell
> the browser to remember it. Then quit the browser and look at the
> resulting capability.policy prefs in user.js in your profile.
Ok, I see. I've already tried this and it does not work.
Even having the capabilities added to your prefs.js file, which adds the
following entries:
user_pref("capability.principal.codebase.p1.granted", "UniversalXPConnect");
user_pref("capability.principal.codebase.p1.id", "http://jsvortex-regtest");
user_pref("capability.principal.codebase.p1.subjectName", "");
...current caps implementation checks first if you have
signed.applets.codebase_principal_support enabled. If not enabled, caps
do not check if the user accepted or not the capabilities in the past.
This is at least what is currently implemented in
nsPrincipal::CanEnableCapability (I'm taking at look at
mozilla/caps/src/nsPrincipal.cpp).
Is this a bug or the expected behavior?
> > Ok, this solution seems to be more robust in the long term if I
> > understand you.
>
> Yeah, indeed.
Ok. I'm currently looking nsIObserver and examples around it.
> > Definitely exposing a particular and limited API looks like the right
> > thing. Is there any document or a working example implementing this
> > concept?
>
> Firebug does this with their console.* APIs, I believe...
Ok, I'll take a look on this. Cheers!
> -Boris
Francis Brosnan Blazquez
> The basic strategy is to add a div element to the web page and a script
> tag. The script adds window.console.log() functions. These functions
> place strings on the div as attributes then raise an event on the div.
> Firebug attached an event listener when it injected the div. The
> listener peels off the strings to decide what to print in the Console
> tab of Firebug. In that last step you have to be careful to ensure that
> you don't run arbitrary code from the page.
>
> Firebug's actually implementation is regrettably less concise. Rarely,
> the div injection can interfere with layout. And of course any object
> you add will collide with identical names used by pages.
It's a pitty. I'll try to check this anyway. I'm concerned about the
performance of these solution (listen for events), knowing that all
messages sent to console.{log|error|warn} are showed extremely slow on
firebug tab.
Do you think this is a problem of the event listener model or firebug is
doing some additional task that slows down console log?
> Two other tidbits: 1) there is a way to add global objects into the
> Javascript world that is rarely used (I don't know more about it), but
> that path requires re-analyzing the security issues. 2) there is work
> ongoing to make a must less painful solution, so for prototypes I would
> not invest a lot of time on this part of the solution.
Ok. Cheers!
> jjb
John J. Barton
> Hi John,
>
>> The basic strategy is to add a div element to the web page and a script
>> tag. The script adds window.console.log() functions. These functions
>> place strings on the div as attributes then raise an event on the div.
>> Firebug attached an event listener when it injected the div. The
>> listener peels off the strings to decide what to print in the Console
>> tab of Firebug. In that last step you have to be careful to ensure that
>> you don't run arbitrary code from the page.
>>
>> Firebug's actually implementation is regrettably less concise. Rarely,
>> the div injection can interfere with layout. And of course any object
>> you add will collide with identical names used by pages.
>
> It's a pitty. I'll try to check this anyway. I'm concerned about the
> performance of these solution (listen for events), knowing that all
> messages sent to console.{log|error|warn} are showed extremely slow on
> firebug tab.
>
> Do you think this is a problem of the event listener model or firebug is
> doing some additional task that slows down console log?
No one else has complained about the Firebug console log performance.
Firebug certainly does more work depending on the arguments. You could
hack Firebug to time the two parts. The event-passing solution involves
a fair bit of code but CPU is so fast now it hardly matters. Any I/O or
memory allocation will be the bottleneck.
jjb
Boris Zbarsky
> ...current caps implementation checks first if you have
> signed.applets.codebase_principal_support enabled. If not enabled, caps
> do not check if the user accepted or not the capabilities in the past.
Oh, right. You need to s/codebase/codebaseTrusted/ in those preference
names.
-Boris
Francis Brosnan Blazquez
> > ...current caps implementation checks first if you have
> > signed.applets.codebase_principal_support enabled. If not enabled, caps
> > do not check if the user accepted or not the capabilities in the past.
>
> Oh, right. You need to s/codebase/codebaseTrusted/ in those preference
> names.
Great. I've check it and works like a charm. Thanks Boris.
For those reaching this thread, the following is an example of user
preferences (prefs.js) granting access to a particular site without
having signed.applets.codebase_principal_support enabled:
user_pref("capability.principal.codebaseTrusted.p1.granted", "UniversalXPConnect");
user_pref("capability.principal.codebaseTrusted.p1.id", "http://jsvortex-regtest");
user_pref("capability.principal.codebaseTrusted.p1.subjectName", "");