firefox: test for privileges without user confirmation?

M

Martijn Saly

I'd like to test in my script, if it's going to be possible to enable
priviliges.

If I use this...

netscape.security.PrivilegeManager.enablePrivilege("UniversalXPConnect")

....it presents a dialog to the user asking if it's ok. Now I don't want
to hide that dialog, I'd like to know if it's going to be possible to
click the Allow button, before ever making this call. Basically I need
to know if the appropriate certificate is installed and enabled and such.

I need this because if the priviliges cannot be enabled, the user must
install a certficate and I want to notify the user about that. But I
don't want to force the user to click allow/deny every time the page
loads, just for the purpose of checking a privilege...

I tried using this...

netscape.security.PrivilegeManager.isPrivilegeEnabled("UniversalXPConnect")

.... and I thought it worked, because in the (Venkman) javascript
debugger, it returns true. But it turns out that it returns true just
because the javascript debugger is already a trusted extension and is
therefor already granted such privileges. In my script, however, it
returns false.

I hope I'm making sense here :)

Anyone knows what to do?
 
V

VK

Martijn said:
I'd like to test in my script, if it's going to be possible to enable
priviliges.

If I use this...

netscape.security.PrivilegeManager.enablePrivilege("UniversalXPConnect")

...it presents a dialog to the user asking if it's ok. Now I don't want
to hide that dialog, I'd like to know if it's going to be possible to
click the Allow button, before ever making this call. Basically I need
to know if the appropriate certificate is installed and enabled and such.

With a proper implementation you can't.
Netscape 4.x Java security model is the most sophisticated (forcedly)
paranoid application of security considerations ever made up to date by
the human mind.
Some day I'd like see it being studied in higher schools like the Roman
law: it is not matter that it is not used any more, but it puts your
mind into the right direction.

This way with a proper implementation of the three stages security
model it is not possible. The fact itself of *trying* to ask *anything*
beyond the sandbox is a security alert to be properly handled. But
Firefox netscape.security.* is not really Netscape's Java sandbox: it
is a native C++ implementation of the Java model, but not the code
itself. This way I cannot comment on it as it would be with a Java
applet. Look at netscape.security.PrivilegeManager and see if anything
is relaxed in comparison with Netscape 4.x JVM.
 
M

Martijn Saly

VK said:
With a proper implementation you can't.
Netscape 4.x Java security model is the most sophisticated (forcedly)
paranoid application of security considerations ever made up to date by
the human mind.
Some day I'd like see it being studied in higher schools like the Roman
law: it is not matter that it is not used any more, but it puts your
mind into the right direction.

This way with a proper implementation of the three stages security
model it is not possible. The fact itself of *trying* to ask *anything*
beyond the sandbox is a security alert to be properly handled. But
Firefox netscape.security.* is not really Netscape's Java sandbox: it
is a native C++ implementation of the Java model, but not the code
itself. This way I cannot comment on it as it would be with a Java
applet. Look at netscape.security.PrivilegeManager and see if anything
is relaxed in comparison with Netscape 4.x JVM.

I don't understand why you're pulling Java and Netscape 4.x in the
picture. I'm asking about Firefox and javascript. Quite the difference.
 
V

VK

Martijn said:
I don't understand why you're pulling Java and Netscape 4.x in the
picture. I'm asking about Firefox and javascript. Quite the difference.

Almost no difference. Gecko security model is the Netscape 4.x Java
security model (over netscape.security classes). The only difference is
that in Gecko it is implemented internally (C++) and not by using JVM.

Any other differences are only in what is taken and what is left
behind. Say Gecko doesn't implement macro targets - which is a big
implementation lack IMHO.

This way the best learning source for netscape.security.* package would
be some old Netscape manual for Capabilities API
<http://java.sun.com/developer/onlineTraining/Security/Fundamentals/Security.html#secNetscape>
 
V

VK

VK said:
This way the best learning source for netscape.security.* package would
be some old Netscape manual for Capabilities API
<http://java.sun.com/developer/onlineTraining/Security/Fundamentals/Security.html#secNetscape>

Also may look at:
<http://www.mozilla.org/projects/security/components/signed-scripts.html>
and
<http://www.mozilla.org/projects/security/components/jssec.html#privs>

This will answer your original request:
<snip> if the priviliges cannot be enabled, the user must
install a certficate and I want to notify the user about that. But I
don't want to force the user to click allow/deny every time the page
loads, just for the purpose of checking a privilege...

Netscape/Gecko security model doesn't work this way. A properly signed
(with a valid recognized certificate) JAR with your page and script
does *not* get any special privileges and it runs in the same sandbox
as a regular script. What it gets is a *privilege to ask for
privileges* : but the final decision (grant or not) is still up to user
via popup security dialog.

Other words for a regular Web page enablePrivilege request will be
silently ignored. In a relaxed environment (local page) or for properly
signed JAR such request will lead to popup security dialog and if user
presses Yes then the privilege will be granted.

More over even if user clicked Yes, the privilege will *not* be granted
to the whole script for the entire "page lifetime" but only for the
given function for the function execution period. It means that if
function fileReader() {
// request for privilege here
// the rest of code
}
only fileReader gets any privileges but not any other functions in your
script. And the next time you call fileReader it will ask for
privileges again - unless user set the checkbox "Always allow" in the
security dialog.

Overall it is far of Microsoft's security hole with "signed ActiveX" so
an extra reading is highly suggested (expecially the old Nescape 4.x
Capabilities API documentation as Mozilla's wiki is very poor and buggy
on this subject).

In answer to your original question:

try {
netscape.security.privilegeManager.enablePrivilege(strPrivilege);
}
catch (SecurityException) {
// security dialog is not allowed to be shown
// or user clicked No on your request
// always be ready for that
}
 
V

VK

VK said:
More over even if user clicked Yes, the privilege will *not* be granted
to the whole script for the entire "page lifetime" but only for the
given function for the function execution period. It means that if
function fileReader() {
// request for privilege here
// the rest of code
}
only fileReader gets any privileges but not any other functions in your
script. And the next time you call fileReader it will ask for
privileges again - unless user set the checkbox "Always allow" in the
security dialog.

That is for an external page and an external script. In Firefox
extensions (.ipx blocks) script can have "permanently allowed"
privileges. This way if you are making some intranet file manager for
Gecko then the best would be to write your own extension, sign it and
provide an installation link on relevant webpages.
For IE users what will be signed ActiveX (.ocx) to install. Other UA's
are respectively FUBAR (though Opera and now Safari have installable
"widgets" mechanics which can be thoretically twisted in the needed
way. I cannot comment too much on the later as I did not play with it).
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,743
Messages
2,569,478
Members
44,898
Latest member
BlairH7607

Latest Threads

Top