the cost of complexity (was: Re: [E-Lang] Java 2 "Security" (
was: Re: Welcome ChrisSkalkaand ScottSmith of Johns Hopkins))
Thu, 25 Jan 2001 15:34:19 -0800
> -----Original Message-----
> From: Jonathan S. Shapiro [mailto:email@example.com]
> Sent: Wednesday, January 24, 2001 7:50 AM
> To: firstname.lastname@example.org; email@example.com
> Cc: firstname.lastname@example.org
> Subject: Re: the cost of complexity (was: Re: [E-Lang] Java 2
> (was: Re: Welcome ChrisSkalkaand ScottSmith of Johns Hopkins))
> 3. It does not account usably (note: "usably", not "correctly") for
> transitivity. Access to an object should not depend on the
> path by which you
> obtained the object. Consider Alice xmits cap to Bob who
> xmits it to Mary.
> Imagine we intend that Mary *should* have valid access to the
> object named
> by this cap. We require a mechanism in which Bob's access can
> be rescinded
> without rescinding Mary's. Mark Miller will argue that access
> should be path
> dependent. The problem with this is that all programs must now program
> defensively against path rescind. The defensive programming becomes so
> pervasive that a more centralized solution becomes mandatory from an
> engineering perspective.
I believe that the question is nonsensical in any pure capability system.
Alice sees only the capability and has no knowledge of the identity of the
presenter. If it were otherwise, we'd be back to ACLs. Hence, Alice can
revoke the capability or not, but there's no concept of identity involved.
E-speak Beta 2.2 did this very nicely. There are 2 cases, everyone on the
same machine or at least one on a different machine. If everyone is on the
same machine, Bob gives Mary a name for the capability, and she can use it
to present the capability to Alice through the e-speak core. Since Alice
and Mary are mutually anonymous, all Alice sees is the capability. As far
as she knows, the request could have come from Bob. Hence, Alice can't even
express the concept of revoking Bob's access and not Mary's. If Alice wants
selective revocation, she must clone the capability and give one clone to
Bob and the other to Mary.
Since even names were path based in e-speak Beta 2.2, the same approach
works across machines. With path based access, every request from Mary
comes through Bob, even if Alice and Mary are on the same machine. Here
even Alice's core can't tell the difference between Bob and Mary. Again,
the question is nonsensical Mary can be introduced to Alice with Bob's
assistance, or Mary can contact Alice directly. In either case a new path
is used, allowing Alice to revoke Bob's privilege but not Mary's.
> Also, even if we assume that the software is correct, nobody
> has offered a
> cohesive architecture for mediation. It's all rather a
> handwave, and until
> we have a real and evaluatable architecture for mediation
> none of us really
> know what can be mediated successfully. I confess that I do
> not see how to
> build such a thing, but then I have not put any great amount
> of energy into
> it (yet).
E-speak Beta 2.2 mediated every request. Alice would know exactly which
access rights the requester had without knowing who that presenter was.
That's not to say that Alice might not perform an unauthorized action due to
a coding error, but no security system is going to prevent that. It might
also be that the capability was obtained under false pretenses. I believe
that's where multi-layer security is useful, in making sure that each user
has exactly the right set of capabilities.
> e-lang mailing list
Decision Technology Department
Hewlett-Packard Laboratories MS 1U-2
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-6278