Boris Zbarsky wrote:
Brendan and I have been doing some thinking about actually defining what
security model we're using. Our current model has a bit of a
neither-fish-nor-fowl aspect to it.
I've written up the two directions we think we could go at
<http://wiki.mozilla.org/Security:Security_Checks_In_Glue> and
<http://wiki.mozilla.org/Security:Scattered_Security_Checks>.
The former model describes a setup close to what Netscape 2-4 had,
according to Brendan. The latter model describes what we _think_ we're
doing right now. Except we're doing a really bad job of it, and I
question whether we could ever really do it effectively. So I
personally lean toward the glue model...
In any case, I'd love feedback on these documents, as well as any
alternate proposals for what we should be doing.
Those are really clear, thanks.
Is it fair to say that for Security_Checks_In_Glue, on entry to a DOM
method we're just pre-evaluating all the security checks that would be
performed during this method call by a correctly-implemented
Scattered_Security_Checks?
If that's so, then issues with correct principal switching and
propagation go away as an implementation issue, but conceptually they
still need to be considered by Security_Checks_In_Glue when we figure
out what permissions are needed by each method.
Maybe the thing to do is to go with Security_Checks_In_Glue, but replace
our scattered security checks with security assertion annotations that
are processed by some tool (say Oink-based) to statically verify that
the glue checks ensure they won't fail. That would give us the benefits
of Security_Checks_In_Glue --- performance, ease of understanding for
Javascript developers, early abort --- while avoiding the disadvantages
of inconsistency between a method's glue checks and what it actually does.
Rob
_______________________________________________
dev-security mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security
