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:
At least four!
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.
Don't forget the bug where we pile up garbage in an array hidden in the
principal, one element per enable. We don't actually clean up when the
JS stack frame is popped!
2) I don't see any clear definitions of what the capability strings mean.
See
http://www.mozilla.org/projects/security/components/signed-scripts.html
and the doc it links to, which requires the Internet Wayback Machine:
http://web.archive.org/web/*/http://developer.netscape.com/docs/manuals/signedobj/trust/index.htm
I tried earlier for better clarity:
http://web.archive.org/web/19981206013607/http://developer.netscape.com/docs/manuals/signedobj/trust/index.htm
Lots of talk about advanced security ergonomics (ow, my wrists are sore
from bad capability targets! ;-). Not much clarity.
Anyone up on the state of Java's capability-based security these days?
Might shed light, or heat.
The better course in my view is to take charge of our destiny. This
whole area has been horribly underowned since the death of Netscape. Yet
we know web apps are crying for greater privileges. The problem of how
to avoid posing scary dialogs is acute, however.
One thought I had the other week is to enable privileges implicitly
based on "latent trust": site has good CA-signed cert, you've connected
with SSL, you've got a password saved for this site, you are logged in.
Such a site could have some awesome powers, but not super-powers.
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.
We should scrap all this and do something better. What, I'm not sure.
I suspect it will look more like a policy language, a domain-specific
declarative language, than a bunch of string targets, even hierarchical
strings.
/be
_______________________________________________
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security
