Like a monster from a bad horror film, some bad ideas just won't bloody die,
no matter how many times they're killed. From the brief conversations we've
had on the e-lang list with some of the Mozart architects, and from Ken
Kahn's reports of other conversations with Mozart folks, it seemed that,
even though security is currently low priority in the Mozart project, that
we at least had compatible views of security.
Thanks to Paul Snively (Thanks!) I just did a web search of the Mozart site
for security, and found the paper "Programming Languages for Distributed
Applications" http://www.mozart-oz.org/papers/abstracts/ngc98.html . It
looks like a nice paper, I look forward to giving it a good read. Given my
current quest, I looked specifically for what the paper had to say about
security. The brief section 7.1, "Language Security", ends with the
>Capabilities do not solve all problems in security . They have inherent
>weaknesses. First, the authorization to do something is given very early,
>namely when the capability is given and not when the operation is attempted.
>Second, a capability can be forwarded to anyone and it will continue
>working. Therefore, a capability-based mechanism needs to be extended–for
>example with access control based on the identity of the capability’s
If the second were an actual concern, then I can see why the first would be
as well. If the second isn't, then the only remaining motivation I can
see for the first is separate revocation, which capability systems do
trivially without any such "extensions". I believe
http://www.erights.org/elib/capability/conspire.html is an adequate
refutation of the second concern. Is there an obvious successor to this
paper? Is there a retraction of this myth posted anywhere on your site
where your students can see it?
Of course, you may not buy that the second concern has been adequately
refuted. If so, let's argue it out, and try to put this age-old issue to
rest. My preference would be to have this argument on the e-lang list, but
either forum (or cap-talk http://www.eros-os.org/pipermail/cap-talk/ ) would
be fine with me.
Your reference above is to:
> Dan S. Wallach, Dirk Balfanz, Drew Dean, and Edward W. Felten.
>Extensible security architectures for Java. In 16th Symposium on Operating
>System Principles, October 1997.
which is also online at http://www.cs.princeton.edu/sip/pub/sosp97/paper.html .
I believe the relevant section of this paper is
http://www.cs.princeton.edu/sip/pub/sosp97/node13.html , which I just
reread. It is a wonderful concentration of damaging myths about
capabilities all in one place. If this is an argument you'd like to have,
you might find good supporting material for your side in this section and
Should we succeed at settling this one, either you can avoid the pointless
effort to "extend" capability systems, or we can become informed of the
limitations of the kind of pure capability systems we're building, and stop
misinforming people at our site.
Please send submissions to email@example.com
and administriva mail to firstname.lastname@example.org.
The Mozart Oz web site is at http://www.mozart-oz.org/.