On Tue, 12 Sep 2006, Boris Zbarsky wrote:
> 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...
I largely agree with the concerns you raised -- that scattered
security checks are significantly more complex to implement and
to get right. The problem of denying permission when it should
be granted could turn out to be a more serious problem than it
seems at first, since if programmers find their calls failing
mysteriously, it may motivate them to treat the security system
as "black magic" and manipulate principals and permissions
superstitiously at random to try to get it to do what they want.
(This approach has been commonly observed when programmers find
security models too hard to understand.)
But complexity is the enemy of security. What about an even
simpler model?
Limited Power Provided: untrusted JavaScript code is
provided with primitive objects that have limited power.
In the example mentioned on your page, a script has limited
access to the window status message:
window.status = "Status";
To implement this in the Limited Power scheme, you would set up
the namespace so that "window" refers not to the real window object,
but an object with a read-only "status" property. I believe this
would be even simpler and easier to implement and debug than the
Security Checks in Glue proposal.
-- ?!ng
_______________________________________________
dev-security mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security
