[Greasemonkey] greasemonkey for secure data over insecure networks / sites

Godmar Back godmar at gmail.com
Mon Jul 18 23:41:51 EDT 2005


I would tend to disagree.  

Julien's approach would use namespace protection ("preventing a
functionality from being accessed by not exposing the name through
which it can be accessed") instead of principal-based access control
("give code the privileges of the principal on whose behalf it
executes") or, for that matter capability-based access control ("allow
code only access to functionality by presenting capabilities it
holds")

In theory, this namespace-based approach works and in fact, some
systems use it.  In practice, the problem is that in most extensible
systems (Mozilla included) the extensions that are loaded need to have
access to some or all of the functionality of the base system.

A purely namespace-based approach would require that a separate
namespace be created for each principal, and that the set of names
available in it be carefully controlled.  Failing to do that - such as
blindly adding GM_xmlhttprequest - poses the problems currently
discussed on this list. The main problem with a namespace-based
approach is however that what is controlled is the set of names, and
not the set of privileges exposed. Often times, a given privilege
("create network connections") may be associated with multiple
interfaces.

By contrast, principal-based security ensures that no matter which
name (and hence calling path) is used to access a particular sensitive
functionality, the privileges of the calling principal are respected.

I think the two choices you have are:

1. either implement your own security model.  Say, for instance, that
script X has the privilege to access only http:// urls.  Include the
privileges as part of a GM scripts's header, pop up a dialog box that
says: do you want to grant script X the right to do Y. Then, use stack
inspection (follow the chain from the local 'caller' property upwards)
and ensure that
a) the request is within what the script says it would do and 
b) that the request came from script code.

This approach would only work if it is possible to identify that the
call chain does not include script code not inserted by GM.  You
could, for instance wrap the insert code like so:
function f() {
 the user's script goes here
}
f();
and then ensure that "f" is in the call path before granting GM_
privileges.  Make sure that you don't use 'f', but an impossible to
guess dynamically created name.

- alternatively, short of implementing what Mozilla already does, use
signed scripts.

 - Godmar

On 7/18/05, Julien Couvreur <julien.couvreur at gmail.com> wrote:
> No need to have principals and ACL stuff for this kind of security.
> Simply having a correct design and enforced encapsulation (private
> variables stay private and you cannot guess references to objects, you
> need to be given them by someone else) works.
> 
> Cheers,
> Julien
> 
> http://erights.org (lots of info on capability-based security, in
> contrast with principal-based security)
>


More information about the Greasemonkey mailing list