[E-Lang] Java 2 "Security" (was: Re: WelcomeChrisSkalkaandScottSmith of Johns Hopkins)

Jonathan S. Shapiro shap@cs.jhu.edu
Fri, 26 Jan 2001 20:31:16 -0500


David Wagner wrote:
> 
> Jonathan S. Shapiro wrote:
> >It's a perfectly okay design, but it isn't an ACL system
> >anymore. It also, in practice, is an infeasible design.
> 
> Well, ok, what shall we call it?  I'll try to adapt to whatever
> nomenclature you prefer. [1]

Please understand: the issue here is not that I object to your design
(though I do). The issue here is that the term "ACL" is used already.
Your design is a different design, and should be called something
different.

> But what's of much more interest to me than semantics is a technical
> question: What's the matter with designs that combine ACL's and
> delegation?  For instance, what's broken about my proposal?

Assuming we restrict ourselves to feasible designs, I have no objection
to discusssing them. Whether they are appropriate for the e-lang list is
a separate discussion.

> (I wasn't suggesting dynamic introduction of principals, so that's not
> the problem.)

Then I have failed to intake your design in the press of other things.
If you can send me a URL for the entry in the e-lang archives, I will
read it. Perhaps I am mistaken and the design is feasible.

> [1] By the way, if an eventual goal of this list is to be an advocate
> for capabilities systems...

This is a list for discussion of the E Capability Secure Scripting
Language. As such, it is inherently a list for discussions about (at
least one) capability system. Lately, the discussion has branched out a
little, both because the CapIDL work has (we hope) a larger target
audience than just E and because Mark and I and a few others are
currently working to build stronger ties between E and EROS.

With that as context, I would say that within this list the advocacy
question is forgone. E has already made the decision that capabilities
are going to be its foundational mechanism (as has EROS, though watch
that space separately, as I do not entirely agree with mark about ACLs).
The reason in this list to discuss the (largely nonexistent) merits of
ACLs is educational.

Ultimately, the real problem with ACLs is neither delegation nor user
identity. The real problem is that it has long since been formally shown
[Ullman '74] that the ACL class of protection mechanism is broken. The
"safety problem" is undecideable in an ACL system, from which it follows
that the security of an ACL system cannot in general be shown. It *can*
be shown in the special case of finite systems (which is probably the
one we care about). Unfortunately, in finite systems, the answers are
(a) yes, safety is decidable, and (b) the answer is "it's not safe." The
same paper showed that the jump from decidable to undecidable systems is
an extremely small step, extremely subtle, and very easy to cross in
advertently. Given this, the burden to show the formal viability of some
new proposal really must rest on the proposer, and it is appropriate for
readers to take the view "broken until proven working" for any given
proposal.


Jonathan