Boris Zbarsky wrote:
It looks like this list might actually work for security discussion, so
here goes... ;)
At the moment, our expanded-capability architecture suffers from four
issues:
1) It's only possible to expand capabilities for a JS stack frame, not
for a web page in general, unless one says to never ask at all for that
principal.
2) I don't see any clear definitions of what the capability strings mean.
3) It's not clear whether some capabilities should imply others (eg
should UniversalXPConnect imply UniversalBrowserWrite?). This is hard
to do if the capabilities are just opaque strings, fwiw... See also
issue #2.
4) A lot of our code does comparisons to the system principal or checks
for the chrome protocol instead of doing capability checks. See issue #2.
I'd like to get some discussion started, either here, or in a wiki, on
fixing these issues.
Last time I sent this around, the one response I got was from Darin:
"I want to second #2! ;-) Can someone, who knows what these
capability strings mean, please volunteer some rough documentation?"
-Boris
Unfortunately, "this does not work" equates to "this software is not
capable" for most users. Let the user know when pref controlled
capabilities are violated at least. The CAPS policy for mail/news is an
example. How far do you have to dig to find that capabilities can be
managed. Don't make a secret of what the product is capable of, for the
sake of security, and let the user decide.
JoeS
_______________________________________________
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security
